> Yes, I saw that.  I'd said to him before that the only problem with
> MCU-based projects is when the MCU is presented as a "black-
> box" - that part of the appeal used to be learning some electronics
> techniques by reading the "how it works" write-up, but if the
> workings of the software aren't explained, then that opportunity to
> learn is lost

I guess the editors have a decision to make - if they're going to have
micro-based electronic projects, should they also be explaining the
s/w part as fully as the h/w ?

A circuit diagram is generally quite easy to follow. s/w provided with
projects is not always so. Often the text describing the s/w is just an
overview. The commenting and program structure of SC projects I've
looked at leaves a lot to be desired and even with my experience and
patience, he said humbly, it takes some time to figure out what's going
on. You actually get more of an idea from the printed overview and
I've found it sometimes easier to re-write the s/w *my* way from
scratch, keeping useful and/or well-written routines from the original

Not wishing to pick on John Clarke, but take this example

http://www.siliconchip.com.au/cms/A_105432/article.html

http://us1.webpublications.com.au/static/downloads/articles/105432_drumkit16
.ASM

Not written in my style at all (a lot of the code above could be
replaced with FSR loops, dt statements etc) and would be much
more understandable with fuller comments for each actual section
function, not just (obvious) individual instructions

However, you could say all that is really needed is the hex file to
make the project run. Having the source code available is merely
a courtesy on the part of the author. My opinion is that it should
be up to a certain standard, although deadlines may possibly not
allow complete commenting

As it is, I'm porting this to a high-speed 4550 with 15 inputs so
understanding how the original works is important. I find myself
going back to the overview in the magazine and referring to the
schematic though

> Yep, although it can be a problem for readers if they use too
> many different MCUs.  If it's PIC one day, Atmel the next and
> Freescale on a Friday, it's a bit much to expect the reader to be
> across all those and own programmers (although for Atmels a
> few resistors seems to do it...) for each.

The devices that seem to get the best coverage are the PICAXE.
Quite a little community behind PICAXE

I'm on the fence about them. The purist in me sees them as being
removed (because of the high-level language) from how a PIC
really works, but I do appreciate that they are an introduction to
micros

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist