[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-chat] How can I individualise specific CPUs?

From: Bernard Fouché
Subject: Re: [avr-chat] How can I individualise specific CPUs?
Date: Fri, 18 Sep 2009 12:52:48 +0200
User-agent: Thunderbird (Windows/20090812)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]