??? 11/08/06 16:29 Read: times |
#127585 - As I understand it Responding to: ???'s previous message |
I think what you want to do is like this:
1. You issue a command to a 89C51, telling it to go into reprogramming mode. Your user application code quits (so to speak) and jumps into a small bootloader. This bootloader may be the Atmel one or it may be your own custom bootloader. 2. The bootloader expects a new application to be sent to it down the RS485. You must decide on the data format and comms protocol. I would recommend looking at the Atmel bootloader for guidance. The new application can in theory be any size. The boot loader erases the bits of the Flash where the application goes. This is a point of no return! Note also that the bootloader should not erase itself from flash, or erase any persistent variables which may be stored in flash. 3. The new application is sent to the 89C51 down the RS485. The bootloader receives the bytes and stores them in flash. In most implementations the data will be protected with checksums, as a comms glitch would screw up your new application code. The bootloader therefore verifies blocks and sends acknowledge or retry responses to the transmitting device. 4. When the new code is in Flash, the bootloader quits (so to speak) by jumping in to the start of the application or jumping to the reset vector. I would not recommend downloading to multiple devices in parallel because it would be difficult to distinguish all the ack and retry responses. |
Topic | Author | Date |
Bootloader Guidance | 01/01/70 00:00 | |
As I understand it | 01/01/70 00:00 | |
Can I do this? | 01/01/70 00:00 | |
you are (partially) right | 01/01/70 00:00 | |
FLIP is not a possibility | 01/01/70 00:00 | |
reliability is relatively easy when done right | 01/01/70 00:00 | |
FLIP still possibility | 01/01/70 00:00 | |
Would FLIP/BatchISP manage RS485? | 01/01/70 00:00 | |
On WinCE?![]() | 01/01/70 00:00 | |
More hints | 01/01/70 00:00 |