Detect hardware version, best way?

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello!

I'm about to make a new revision of our hardware and the programmer wants a general way of detecting which hardware version his software is running on. This would enable him to have a unique code that runs on all different H/W versions. Are there any smart solutions to this? If I can get a full byte (256 combinations) that’s good, but at least 64.

Here are some options:
* Each H/W ver has a unique value on AD0.
* Clock in a value from PA0-PA2 using a mux.
* Always use PA0-PA7 to read a value. (Takes a lot of pins.)
* Store the H/W ver in EEPROM. (Not good solutions since it requires different hex files for each H/W version, what we are trying to avoid.)

Please, what is the standard way of doing this? Any suggestions are welcome.'

Kind regards
Bjorn Hilliges

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Atmel uses a few pins to read the hardware version numbers with their tools.

The adc read would be the most economical pin wise, but you will need to make the steps wide enough to cater for reading fluctuation due to temperature, voltage etc.

Do you really need 64 hardware versions?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

js wrote:
Do you really need 64 hardware versions?

No, not really. I could go down to 32. Currently we have 5 versions already.

/Björn

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

With a 10 bit ADC you have 1024 steps. So with 64 versions you only get 16 counts between steps or about 1.5% change per version, too close for my taste. :?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is adding a cheap external parallel-serial shift register to the SPI port, with the parallel pins set to the hardware revision an option? Adds cost of board space and the IC, but for low run products could be worth it.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Take a look at the Maxim one wire DS2406, DS2502, etc. These have a unique 48 bit serial number and OTP EEPROM. Just batch program the EEPROM in the one wire chips for each production run of a particular hardware revision and then solder them into the boards. You also get the bonus of the unique built in serial number for each board. There is more than enough EEPROM for a complex hardware revision code scheme. Your batch programmer could even transfer records of the hardware revision for each serial number into a production data base.

http://www.maxim-ic.com/products...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Best way" is in the eye of the beholder.

For my products, nearly every one uses EEPROM something - calibration values, setup information, serial numbers, etc. So, since EEPROM had to be programmed anyway, storing the hardware version/revision in EEPROM is a logical choice. If you are not using EEPROM at all, then a hardware solution may be the best way to go for you.

Personally, I would't waste an entire port for hardware version (unless the pins were unused anyway). Using the A/D is a pin efficient method, but 64 steps may be pushing the limit (especially if you use 1% tolerance resistors). If you are going to go with this method, you should consider using 0.5% or better resistors for your divider.

Once again, if it were me, I would store the hardware version into internal EEPROM, and be done with the whole issue. No tolerance worries, no extra pin usage, no extra hardware, no extra cost.