Distinguishing one Arduboy from another in software?

Wow guys awesome work it’s soemthing we will look into supporting and maybe we can have se documentation on but currently there are no plans to serialize the software mostly because it’s a giant pain in the ass to manage in production. Having to rebuild the code every device… Sorry :frowning:

But maybe in the future once we go to retail :smile:

Keep up the good work and we will follow along try to include what we can! Thanks!

You would never do that. The builder responsible for flashing all the chips would either support adding a serial # at a certain address or it wouldn’t. Obviously doing it by hand would be insane.

“The builder” is me, I build the test jig and software that programs the chips :slight_smile:

I just looked into it a bit more and it should actually be possible to set some flags in avr dude to throw some data into memory space, and barring that it should also be able to directly patch the hex file as well.

Really nice to have bunnie on my team of advisors :smile:

1 Like

Sorry if it wasn’t clear, but I was even thinking it was more “is this already happening by default” – and that’s it.

I’ll expand a little on what I said earlier - don’t change the bootloader for this (there’s enough to do without adding scope creep).

Hi guys,

I’m sorry for this question but isn’t there ANY ID or serial code which you will refer in the future?

I mean how will you trace the production or maybe single batches? Shouldn’t you be able to differenziert between the first produced Arduboy and the 9843th one?

This is maybe kinda off the developing topic but still distinguishing one Arduboy from another.

Wow you plan on burning all production units by hand? If so then yeah it’s just a simple script to change a few bytes of the hex file each time before it’s burned… if you’re already doing it by hand you just write the script once and use the script vs calling avrdude directly - and then you have serials. Of course you’d have to have a local file or something to track the # as it increments, but you get the idea.

I’ll expand a little on what I said earlier - don’t change the bootloader for this (there’s enough to do without adding scope creep).

It’s really a process change, not a bootloader change. We have to compile our own bootloader anyways as I’ve mentioned before… so it’s really just a matter of wether we set aside 4-5 bytes for a serial # or we don’t. It’s pretty much just a one liner: char[5] PROGMEM serial = {0,0,0,0,0} and then the burn script would increment the # in the hex file.

Ok, then.


Lists of many options for production programming - many of which offer serialization.

(one of the few Atmel docs I’ve seen that looks to be recently updated)

Yeah it seems logical that a distributor or assembler could do that kind of thing for you with some automated equipment. :slight_smile:

Ok - I think I finally sorted out why there is a mess of misleading information on this.

Here’s the table from the ATmega32u2 data sheet:

Table 23-6.Signature Row Addressing 
Signature Byte                                 Z-Pointer Address
Device Signature Byte 1                        0x0000
Device Signature Byte 2                        0x0002
Device Signature Byte 3                        0x0004
RC Oscillator Calibration Byte                 0x0001
Unique Serial Number                           From 0x000E to 0x0018

Here’s the table from the ATmega32u4 data sheet:

Table 27-6.Signature Row Addressing 
Signature Byte                                 Z-Pointer Address
Device Signature Byte 1                        0x0000
Device Signature Byte 2                        0x0002
Device Signature Byte 3                        0x0004
RC Oscillator Calibration Byte                 0x0001

The …32u4 does NOT have an identifier bytes - but the …32u2 does.

The data is held in the Signature Row - which is a different data store than any of RAM, EEPROM, or flash.

The USB Device ID note was likely written before the ATmega??u4 series was released. So at that time, all the Atmel USB capable devices had this. But now - this is not true anymore.

So - no Atmel ID for Arduboy. But at least I understand what’s going on.

How did you access it then? Was it mapped into the address space? I guess that’s what that says without further context… but I thought registers were that low, or maybe it was IO… lol… i’d have to look.

If you chase into the functions stored in the boot loader, you get flash_read_sig. It does use the LPM instruction, but with a special setup involving the SIGRD bit. That would be the SIGnature ReadD bit. Those very low EEPROM addresses are apparently doubly mapped based on this bit.

Interesting. Thanks for the explanation.

I know this topic is almost exactly one year old, but I was wondering if this was solved or not… Alongside that, I was wondering if it’s possible to just use a program to store a psuedo-random serial to EEPROM a specific point (either the first entry or last entry) that every program can use? Would that just be the easiest route?

I would say it was resolved, not solved.

The ATmega32u4 does not have the signature byte feature, and individually programming a random or pseudo-random value for each item in the manufacturing stage would likely be not worth the effort - especially since absolutely everything in the Arduboy could be overwritten by the owner/user.

In its place, I think any program needing this will need to do its own pseudo-random generation, based on whatever sources of entropy it can find. I would think that the best one in the Arduboy is using a high-rate timer/counter, and grabbing the low bits upon receipt of button pushes, repeating until you have the needed number of random bits.

I only quickly skimmed this topic again, so I may have missed if something like this has been proposed, but:

As mentioned there are 16 bytes at the start of EEPROM reserved by the Arduboy library for system use. Only 3 bytes have been defined so far and only one, EEPROM_AUDIO_ON_OFF, is actually currently being used. I don’t see many more being required for future uses.

I suggest we reserve 2 bytes (one int) in system EEPROM for Unit ID. Library functions could be added to set and retrieve this ID, such as:
void writeUnitID(unsigned int id)
unsigned int readUnitID()

A very simple sketch could be written that you could upload to set or change the ID when required.

We wouldn’t police the actual value set. It would be up to the group of users requiring unique IDs to make sure they were all different. If the use of the ID became popular, someone could set up a registry or wiki to help assign unique IDs.


I like the idea of a psuedo random several byte long identifier. :slight_smile: Means we really need some sort of setup sketch… but why do people need unique ID again anyways?

Off of the top of my head, I can think of a few ideas…

I was thinking of making a Tomogachi or Digimon-type ‘game’ eventually where you are given a creature at random. I’d love it if I had a seed to lock each Arduboy to a specific range of creatures. In the original Pokémon games, you were only able to catch certain monsters on different versions of the game. This could kinda simulate something like that. I can also think of multiplayer games being able to remember who they’re talking to, too.

It would have been interesting if every chip had a unique code imbedded in it.

But most of what is needed here can be done in software. Repeated calls to micros() if done at random times - triggered by keypresses - can build up a random number sufficient for most purposes. It would certainly be enough to distinguish between two Arduboys that have somehow managed to establish communication. And if you need that value for later? Stash it in EEPROM.

1 Like

Exactly how you’d do it with a setup routine.

Resurrecting this topic just to announce that, as of version 3.1.0 of the Arduboy2 library, functions writeUnitID() and readUnitID() are available to set and retrieve a 16 bit value that can be used to uniquely identify units. An example sketch, SetNameAndID, is included to allow setting the ID. Some coordination would be necessary to make sure the IDs are unique for a situation that required it.

Related functions writeUnitName() and readUnitName() are also available for setting an up to 6 character unit name.