gnupic: Thread: Silly programmer idea

I had a silly idea while reading the programming
spec for one of the 18F chips.  For the process,
you basically stuff instructions into the micro
and make it do the work for you.  Well,  why not
go a step further and stuff a little program in
FLASH that reads form the serial port (SPI) if
the chip has one, and programs that data into
FLASH?  At the end go back to normal programming
mode and overwrite the little bootstrap chunk--
if necessary.  Maybe make the host programmer
software smart and have it pick a chunk of memory
that is free so that's not an issue?

Hmmmm....  It may not be worth the hassle.  I
wonder if this is similar to how you ICD these
chips.  Do you just clock instructions into
the core or something?  Sort of like a poor mans
JTAG.

Cheers,
David

On Tue, Jan 27, 2004 at 02:08:22AM -0500, David Willmore wrote:
> 
> I had a silly idea while reading the programming
> spec for one of the 18F chips.  For the process,
> you basically stuff instructions into the micro
> and make it do the work for you.  Well,  why not
> go a step further and stuff a little program in
> FLASH that reads form the serial port (SPI) if
> the chip has one, and programs that data into
> FLASH?

Not silly at all. It's called a bootloader and there
are a bunch of them for each and every PIC that can
write its own program memory.

The most intriquing one for the 18F is Wouter van Ooijen's
ZPL (Zero Pin Loader). Instead of using the serial port
(which IMHO is too powerful a resource to dedicate to
a bootloader) it programs by wiggling the reset pin in
timed bursts. That means that the programming takes up
no hardware resources at all on the chip.

>  At the end go back to normal programming
> mode and overwrite the little bootstrap chunk--
> if necessary.

Usually your option below is done.

>  Maybe make the host programmer
> software smart and have it pick a chunk of memory
> that is free so that's not an issue?

Right. 

I love bootloaders because the decouple the chip from
the programmer. All of my successful 16F projects that
I've done were developed with Wouters Wloader 16F bootloader

It's one of the reasons that when I get started again that
the 16F88 will be my base chip of choice. It can program its
own memory and with 4K there's more than enough to save a bootloader.

BAJ

> > I had a silly idea while reading the programming
> > spec for one of the 18F chips.  For the process,
> > you basically stuff instructions into the micro
> > and make it do the work for you.  Well,  why not
> > go a step further and stuff a little program in
> > FLASH that reads form the serial port (SPI) if
> > the chip has one, and programs that data into
> > FLASH?
> 
> Not silly at all. It's called a bootloader and there
> are a bunch of them for each and every PIC that can
> write its own program memory.

Well, yeah, sort of a very stripped down boot loader--
not the almost-a-TCP-stack complexity ones that I've
seen, at least.

> The most intriquing one for the 18F is Wouter van Ooijen's
> ZPL (Zero Pin Loader). Instead of using the serial port
> (which IMHO is too powerful a resource to dedicate to
> a bootloader) it programs by wiggling the reset pin in
> timed bursts. That means that the programming takes up
> no hardware resources at all on the chip.

The reset line?  Hmmm, I've got to look into how that
works.

> >  At the end go back to normal programming
> > mode and overwrite the little bootstrap chunk--
> > if necessary.
> 
> Usually your option below is done.

But, unless I know how ICD works, going from holding
the chip in programming mode and running instructions
is still a big mystery.

> >  Maybe make the host programmer
> > software smart and have it pick a chunk of memory
> > that is free so that's not an issue?
> 
> Right. 
> 
> I love bootloaders because the decouple the chip from
> the programmer. All of my successful 16F projects that
> I've done were developed with Wouters Wloader 16F bootloader
> 
> It's one of the reasons that when I get started again that
> the 16F88 will be my base chip of choice. It can program its
> own memory and with 4K there's more than enough to save a bootloader.

I'm unfamiliar with the self programming 16F chips.  I've
been focusing on the little non-self programming parts and
the 18F of-course-we-can-program-ourselves parts.  I need
to stare at how the 16F self program, it seems.

But, I was asking the original question in the context of the
18F series.  I don't know enough to say that it's the same
question as the 16F parts.  So, I'll go RTFM.

Thanks Byron.

Cheers,
David

On Tue, Jan 27, 2004 at 12:16:27PM -0500, David Willmore wrote:
> > > I had a silly idea while reading the programming
> > > spec for one of the 18F chips.  For the process,
> > > you basically stuff instructions into the micro
> > > and make it do the work for you.  Well,  why not
> > > go a step further and stuff a little program in
> > > FLASH that reads form the serial port (SPI) if
> > > the chip has one, and programs that data into
> > > FLASH?
> > 
> > Not silly at all. It's called a bootloader and there
> > are a bunch of them for each and every PIC that can
> > write its own program memory.
> 
> Well, yeah, sort of a very stripped down boot loader--
> not the almost-a-TCP-stack complexity ones that I've
> seen, at least.

Most of the ones that I've seen are simple protocol. I'm
definitely in Wouter's camp which is to save as much of
the memory space and I/O map as possible, even at the cost
of a slowdown in programming speed.

> 
> > The most intriquing one for the 18F is Wouter van Ooijen's
> > ZPL (Zero Pin Loader). Instead of using the serial port
> > (which IMHO is too powerful a resource to dedicate to
> > a bootloader) it programs by wiggling the reset pin in
> > timed bursts. That means that the programming takes up
> > no hardware resources at all on the chip.
> 
> The reset line?  Hmmm, I've got to look into how that
> works.

Pretty simple, It measures the time between resets and has
morse code like dits (short delays) and dashes (longer delays)
which make up a binary stream. Extra long delay between resets
means that there's no programmer attach, so run the application.

You can find ZPL here:

http://www.circuitcellar.com/flash2002/honorable.htm

> 
> > >  At the end go back to normal programming
> > > mode and overwrite the little bootstrap chunk--
> > > if necessary.
> > 
> > Usually your option below is done.
> 
> But, unless I know how ICD works, going from holding
> the chip in programming mode and running instructions
> is still a big mystery.

I'm lost here. With a bootloader, the chip isn't in programming
mode. It's in normal mode all the time, either running the
bootloader or executing the loaded application.

Can you clarify?

> > It's one of the reasons that when I get started again that
> > the 16F88 will be my base chip of choice. It can program its
> > own memory and with 4K there's more than enough to save a bootloader.
> 
> I'm unfamiliar with the self programming 16F chips.  I've
> been focusing on the little non-self programming parts and
> the 18F of-course-we-can-program-ourselves parts.  I need
> to stare at how the 16F self program, it seems.

Basically the same way as the 18F parts, using the same registers
as the data EEPROMs.

> 
> But, I was asking the original question in the context of the
> 18F series.  I don't know enough to say that it's the same
> question as the 16F parts.  So, I'll go RTFM.

It's pretty much the same.

To help in your reading here is a PIC bootloader page that
talks about all of the current bootloaders. The original page
seems to be down, so here's a google cache entry:

http://216.239.41.104/search?q=cache:Y7DNK0a-qUQJ:www.ac.ugal.ro/staff/ckiku/software/picbootloader.htm+Wouter+ZPL&hl=en&ie=UTF-8

> 
> Thanks Byron.

No problem.

BAJ

> > Well, yeah, sort of a very stripped down boot loader--
> > not the almost-a-TCP-stack complexity ones that I've
> > seen, at least.
> 
> Most of the ones that I've seen are simple protocol. I'm
> definitely in Wouter's camp which is to save as much of
> the memory space and I/O map as possible, even at the cost
> of a slowdown in programming speed.

Okay, I'm not talking about anything that will stay resident
in the chip.  I'm thinking of starting with a blank device
attached to an ICSP (or sitting in a socket in one).  Enter
programming mode, program in the boot loader, use the ICD
to run the boot loader, talk to it to dump in code quickly--
maybe using a bunch of chip resouces if available (PSP?)--
and once done, clear out the bootloader as if it were never
there.  

I'm not thinking of some special stay resident thing.  Just
a way to leverage the existing ICSP/ICD features to speed programming.

> > The reset line?  Hmmm, I've got to look into how that
> > works.
> 
> Pretty simple, It measures the time between resets and has
> morse code like dits (short delays) and dashes (longer delays)
> which make up a binary stream. Extra long delay between resets
> means that there's no programmer attach, so run the application.
> 
> You can find ZPL here:
> 
> http://www.circuitcellar.com/flash2002/honorable.htm

Ahh, reading through the ICD doc for the 16F877a, I think I
see what you're looking at.  Cute.  Not quite what I'm
looking for.  I'm looking for a way to speed the process
by using *more* resources. :)  Think blank chip in socket
programming, not mostly programmed chip in circuit.  The
two methods don't preclude each other but I'm just not
thinking about that other method right now.

> > But, unless I know how ICD works, going from holding
> > the chip in programming mode and running instructions
> > is still a big mystery.
> 
> I'm lost here. With a bootloader, the chip isn't in programming
> mode. It's in normal mode all the time, either running the
> bootloader or executing the loaded application.
> 
> Can you clarify?

Sure, I think I did so, somewhat, above, but let me restate to
try to be clear on this exact point.  Take a new chip with no
bootloader and put it in a socket in the programmer--you have
access to all of its pins and there is no inconvenient circuit
to get in the way.  Now, ask "is there a way to program it faster
than bit banging on the ICSP signals.  Short of the PSP, I
don't think so.  And that's only going to be good for 40 pin
and larger chips, so it might just not be worth it.

> > I'm unfamiliar with the self programming 16F chips.  I've
> > been focusing on the little non-self programming parts and
> > the 18F of-course-we-can-program-ourselves parts.  I need
> > to stare at how the 16F self program, it seems.
> 
> Basically the same way as the 18F parts, using the same registers
> as the data EEPROMs.

Ahh, okay.  One or two more bits to say what data space you're
refering to.  Gotcha.  I'm reading the doc for the 16F877a now...

> > But, I was asking the original question in the context of the
> > 18F series.  I don't know enough to say that it's the same
> > question as the 16F parts.  So, I'll go RTFM.
> 
> It's pretty much the same.

Good. :)

> To help in your reading here is a PIC bootloader page that
> talks about all of the current bootloaders. The original page
> seems to be down, so here's a google cache entry:
> 
> http://216.239.41.104/search?q=cache:Y7DNK0a-qUQJ:www.ac.ugal.ro/staff/ckiku/software/picbootloader.htm+Wouter+ZPL&hl=en&ie=
> UTF-8

Oh, thank you. :)

> > Thanks Byron.
> 
> No problem.

:)

Cheers,
David