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]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.