On Thu, 10 Apr 2008, Harold Hallikainen wrote:

> 
> > A few weeks ago there was considerable activity on Boot Loaders, just a
> > quick question without a lot of detail, just wanted to make sure there
> > wasn't some obvious roadblock.
> >
> > I have a 18F1320 (slave) that has USART going to onboard fiber optic
> > transmitter/receiver (62.5/125um) that is then converted to 2 wire
> > RS-485 with a B&B FOSTC converter and then to a PLC (TRI-PLC
> > T100MD888)(master). The PLC is programmable and online
> > monitoring/control via RS-232 to a PC. I also have a RS-232/RS-485
> > converter and have talked to the PIC over the Fiber optic/Rs-485 network
> > with a terminal program. I am thinking that either I can use the
> > RS-232/RS-485 converter to use the boot loader (after having programed
> > the 1320 with the boot loader) from a PC, or via the PLC which has been
> > programmed to pass through the 1320 program.
> >
> > Comments?
> >
> 
> Sounds like it should work. How are you going to start bootloader
> execution? I typically check for a button press during power up. If the
> button is down, I go in to the bootloader. If not, I go to the
> application. It's possible to have the application also call the
> bootloader, but should the application get corrupted, you need another way
> to get to the bootloader.
> 

I use a flag in RAM. During reset I check the flag, if it is a specific 
value I increment a counter and if the counter goes above 3 the bootloader 
goes into program mode. Otherwise I wait a short while, clear the flag and 
start the user's app. During reset, if the flag is not set to the right 
value I set it, then clear the counter.

This allows the bootloader to see 4 resets in quick succession and enter 
program mode on the 4th reset. Similarly 4 resets in quick succession 
while in program mode causes the bootloader to comes out of program mode 
and start executing the user app.

This does have the drawback of not starting the user's app immediately but 
you don't lose an I/O pin on need to add a switch to go into program mode.

> Also, on bootloaders, I've started writing them to accept the Intel hex
> ascii records directly with either DC1/DC3 or RTS/CTS handshaking. Nothing
> special is then required on the host end, just send the ascii file.

I use XON/XOFF and have my compiler generate pad characters at the end of 
each record. This allows me to stream a program at 19.2k from a dumb 
terminal emulator without worrying about delays at the end of each record.

Regards
Sergio
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist