sergio masci wrote:
> 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
>   
I have built an  EEPROM-based  bootloader, an "updater device". It is 
built into a small aluminum tube.
Inside is a small PCB which contains a single RAMTRON (32Kx8). The 
RAMTRON contains an image
of memory. 4 different complex algorithms are used.

The updater is updated via a programmer driven from the line. It updates 
from the website. As soon as
the internal RAMTRON is updated, the internal PIC takes over.

My client simply mails one of these to everybody needing updates.

--Bob Axtell  
                                                                                                        










































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