I think it is already online & dispersed over the world.... Check http://www.finitesite.com/d3jsys/ and I am sure that this is an incomplete list. John Ferrell http://DixieNC.US ----- Original Message ----- From: "Ale[x] Garbino" To: Sent: Monday, April 25, 2005 12:37 PM Subject: Re: [PIC] - Book Reccomendations for beggining PIC Programming > 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 -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist