gnupic: Re: [gnupic] Learning PIC on the job
Subject:
RE: [gnupic] Learning PIC on the job
From:
"Sergey A. Dryga" ####@####.####
Date:
16 Aug 2005 03:39:44 +0100
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 ####@####.####
> Sent: Monday, August 15, 2005 9:58 PM
> To: ####@####.####
> 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: ####@####.####
> For additional commands, e-mail: ####@####.####
