I'll jump in from the sidelines after following this thread: with all the 
discussions and what's been written so far, why doesn't the list as a whole 
write the darn book?
There is a lot more specialized knowledge; little scarcity of people that 
don't mind writing a few pages, specialists in all areas of applications, 
industrial and hobbist appplications, etc.
A wikipedia/online book should not be too difficult to write, if there is 
someone who can get the ball rolling and give momentum to the project. 
Opensource software manages to do it, and wikipedia is going strong too!

Alex

From: Byron A Jeff <byron@cc.gatech.edu>
Reply-To: "Microcontroller discussion list - Public." 
<piclist@mit.edu>
To: "Microcontroller discussion list - Public." 
<piclist@mit.edu>
Subject: Re: [PIC] - Book Reccomendations for beggining PIC Programming
Date: Mon, 25 Apr 2005 08:54:51 -0400

On Sun, Apr 24, 2005 at 09:02:27PM -0700, William Chops Westfield wrote:
>
> On Apr 24, 2005, at 7:00 PM, Byron A Jeff wrote:
>
> >The fact of the matter is that the 18F architecture simplifies
> >stuff because it lessens issues with banking.
> >
> A point of contention seems to be the degree to which things should be
> simplified for the "beginning user."  A rich set of 
peripherals is nice,
> but is more to understand, especially if your goal is along the lines 
of
> getting people used to bit twiddling.  A CPU with fewer banking issues
> is
> nice too, unless you want to convey the idea that many microcontrollers
> have annoying little "quirks" that users will have to learn 
to work
> with.

Bill,

We were all taught bit twiddling because that's all there was. Also
I'm pretty sure no one wants to teach annoying quirks.

>
> Imagine a single-chip PDP-11 (with memory, flash, uarts, and pins to
> control)
> In some sense, that would be a wonderful thing.  Or something
> implementing
> Knuth's made-up assembler language.  In some other sense, those would 
be
> really nice teaching aids.  In another sense, they'd present such an
> incomplete view of the world that they'd be near useless.
>
> (Hmm.  Corollary:  Any class in "assembly language" should 
teach at
> least two different architectures.)

It's tough enough to teach one. For my CS students assembly's main points
are twofold:

1) It's the last level of language that has all abstraction stripped. So
you have access to everything at the AL level.

2) That same lack of abstraction complicates solving tasks for programmers.
That's the reason that most development is done in higher level languages
that abstracts much of the hardware.

All of us who program in PIC assembly pretty much choose to do it. With
the myriad high level languages available, and the ever expanding memory
capabilities, the need for programming in assembly is greatly lessened.

The primary reason for knowing PIC assembly (IMHO of course) is that it's
the common language of PIC programmers. Note here on the list when folks
ask about PICBasic, JAL, or even C, that there are a limited number of
responses because each language is regionalized. However virtually everyone
knows PIC assembly and uses it to communicate ideas to each other.

But getting back to the original point simpler is relative and contextual.
Bit twiddling is generally fine when it's the only task (i.e. the blinking
LED). And of course when teaching initial concepts one tends to isolate
individual tasks in order to highlight them.

But multiple task management add another level of complexity that is made
more difficult with bit twiddling alone.

Let me try another analogy (as I like analogies). Imagine you had to perform
a series of housecleaning tasks and you have your apprentice. Naturally
you'd teach the apprentice how to sweep, and dust, and wash windows and the
like in isolation.

Now put said apprentice into a situation where the only way to accomplish
the total task is to do all of the tasks at the same time.

Can you see that's a completely different level of complexity?

Now come back to the start and explain to the apprentice that you have
these mobile robots that will perform these tasks autonomously once you've
properly programmed them. Now admittedly programming them initially is
a bit more complex than simply doing the task yourself. But on the other
hand once the robot is setup, it'll toddle off and dust without your
supervision.

Now which technique seems more difficult in isolation? Probably programming
the robot because in the time it task you to set up the robot to do the
task you could have been finished already.

But now get back to the real world where you have a limited amount of time
to complete all of the tasks and they must be performed at the same time.
The power of the autonomous robot becomes evident, because once you've set
it up and send it on its way, you don't have a bother with it until it
completes the task, at which point it'll come back to you and ask for more.

The power of the set and forget nature of the robot isn't realized until
you have to overlap tasks. But overlapping tasks is what gets done on
real projects.

Finally if that's the case then why not teach programming the robots and
never bother doing things yourself. Well there's always the time where
you need two windows washed at the same time, but you only have
one robot for the task. So then you can set the robot on one of the windows,
but the other you'll still need to do by hand.

In short I agree with simplicity in isolation, but isolation often doesn't
match up with real projects. So juggling tasks is a part of the learning
process.

I guess that the start of a good introductory chapter.

Comments?

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


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