Could you consider using a bootloader? (IIRC Atmel provides an
application note or some code to demonstrate how one can have a MCU boot
over the CAN bus).
Hence you don't perform a chip erase when you change your program (since
your application will be bootloaded cleanly).
Then you can keep your timing info either in EEPROM or in some bytes of
flash inside of the bootloader code area. (the later is better if you
make your devices able to also bootload EEPROM content).
So it's just when you flash the bootloader that the manual setup is done
once.
Juergen Harms wrote:
I wonder whether there is some approach to provide specific CPUs with
some program-readable identifier that allows to individually recognise
each CPU in a way that survives programming operations that start by
erasing the chip.
To be more clear, here is why I need this: I am having a bus with many
AT90CAN nodes, each of them driving timed events. The CPU clock of
each node is used to generate the necessary clock information. I use a
polynomic correction algorithm to correct hardware-specific clock
deviation, having a polynome which is specifically defined for each
CPU (resp. its PCB).
At present, I maintain a list of CPUs and their individual correction
polynomes and manually introduce them into the object code before a
device is re-programmed. That is a tedious and error-prone way of
doing (even if I store the polynome in eeprom and only need to adapt
the object code when eeprom is re-programmed).
I would like to automatize the manual procedure by some lookup
algorithm that uses a CPU id as a key. Has anybody come across this
problem and found a solution? The ideal way would be to have a zone of
the eeprom (a single byte would be enough) that is protected against
programming-triggered erasure, and that can be used by the application.
(Note: during normal operation, there is a DCF-driven master timer
that sends timer messages over the bus, allowing the nodes to
synchronize; but the system must continue to work even if temporarily
the master timer goes away - hence the need to adapt each node at
least with a basic timer-offset correction).
_______________________________________________
AVR-chat mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/avr-chat
_______________________________________________
AVR-chat mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/avr-chat
