RE: Learning PIC on the job
"Sergey A. Dryga" <[email protected]>
| Newsgroups | gmane.comp.hardware.microcontrollers.gnupic |
|---|---|
| Message-ID | <001401c5a20b$bf9ec300$ad0aa8c0@NUT> |
Byron, I think your description of the purpose of a bootloader is the best I have seen so far. It has to be put in "HowTo" for newbies. Also, I think that the question "what is better, bootloader or programmer?" should not be raised at all. There are situations when one is better than another. I suggest the perl approach: there is more than one way to do things. Let's give newbies some credit and give them options to choose from. BTW, what bootloader do you prefer? I really have not had experience with bootloaders since I started with a homebrew programmer. I might be able to provide PICs with booloader for newbies. Cheers, Sergey > -----Original Message----- > From: Byron A Jeff [mailto:[email protected]] > Sent: Monday, August 15, 2005 9:58 PM > To: [email protected] > Subject: Re: [gnupic] Learning PIC on the job > > On Tue, Aug 16, 2005 at 08:33:48AM +0800, Chen Xiao Fan wrote: > > It is better to buy a programmer which is more reliable. > > You are a pro now so maybe you will have no problem > > with a JDM/Tait or bootloader. Actually bootloader should > > be the last resort. New comers do not quite understand > > how a bootloader work. They will be frustrated when they > > fried some PICs before they can blink a LED. > > As you know I disagree. I think it's wrong to peg newbies as dumb or > stupid > simply because they have a lack of knowledge on a subject. Simply explaing > to > them in clear language what to do and most of them get it. > > For example traditional programming vs. bootloaders. Simple analogy: > Imagine > if every time you wanted to install a new program on your computer you had > to > open the case, remove the hard disk, put the hard disk in a special > machine > to load the software, then reverse the process. Further imagine that you > had > to do this each and every time you wanted to change the software on your > computer. This is analogous to the traditional programming process for > a microcontroller. > > A bootloader works like a BIOS. It's a program that's in your computer > that > can load other programs. Now PIC chips come to you completely blank. So > you use the traditional programmer to put the bootloader onto the chip. > From then on the chip can load programs for itself. > > Each method has its advantages and disadvantages. Traditional programmers > work with blank chips. Traditional programmers also use no resources on > the chip such as memory or I/O pins. Bootloaders can give you a lot of > flexibility. There are bootloaders that wiggle the MCLR pin in a special > way to program the chip for example. However by definition they must > occupy > some memory space in order to operate. Also you have the chicken and egg > problem of getting the bootloader onto the chip in the first place. > > But at the end of the day bootloaders mimic the software installation > processes of the computers we use every day. And frankly mirroring > a known process is simpler for a new user than an unfamiliar one. > > BTW why do you think that a newbie is any more likely to fry a raw PIC as > opposed to a bootloaded one? The fact of the matter is that lots and lots > of > newbies got started using the Basic Stamp, which had a serial EEPROM > bootloader coupled with a simple HLL interpreter. > > > > > I will recommend Wisp 628 and PICkit 1 now for beginners. > > So you have to get two programmers? Or is it one or the other? > > > > Later I will recommend PIckit 2 after we get it to work with > > Linux. > > And so a newbie will have to plunk down $50 just to get started? > And for this you get 1 part (16F690), a pot, some LEDs and > a programmer? Seems pricey to me to pay for convenience. Then on > top of that any Linux person will have to wait until Mchip gets around > to releasing the protocol to talk to the programmer. > > Hmmm. > > BAJ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected]