Dynamic USB Serial Number (PIC18F4550)

Hi all,

I had a search in the forums but could not come up with anything like what I am trying to do.

I am designing a device of which a number of identical units will be built. There is the possibility of two of these devices being attached to the same computer at a time so I need some way to uniquely identify them.

The devices will likely be built by people who have no programming knowledge beyond programming the pic with a hex file so changing anything in code is not possible. The obvious solution is to use a port (e.g. PORTD) with pullups/downs to give a hardware settable address that can be read in code.

As I can see it there are two ways to do this addressing in code:

- Transmit the device address as the first byte in all USB transfers and have the software decode it appropriately. This would work but is a bit clunky and increasing the size of USB transfers, not by much but I would still prefer to avoid it.

- Use the USB Serial Number that is sent during enumeration in the Device Descriptor. This is my preferred method but also the one that causes a lot of headaches.

The Serial number can be set during EasyHID setup and I have found the file/location where it is stored. Of course someone who knew how could change the serial number and recompile the code for each device, however as I said the people who will be building it may not know how to do this. It is also very bad practice as a designer to have duplicate devices programmed differently because every firmware update would have to recompiled for every device.

So the code where the serial number string resides looks something like this (it may be slightly inaccurate as I do not have the code with me right now, but its near enough):

Code:

---

; serial number
String3
        retlw        (String4-String3)/2
        retlw        DSC_STR
        retlw '3'
        retlw 0x00

String4

---

The code above would identify the device by the string '3'. What I would like to do is replace '3' with PORTD and set PORTD to e.g. 0x33. However when I do this I get the warning that "argument out of range: least significant bits used". This results in the Serial Number being identified as '?' (0b00111111 or 0x3F).

No matter what I try I cannot set the '3' to any variable. I have tried all combinations of variables defined in both asm and PBP and I can write the contents of PORTD to PORTB (set to outputs) in asm successfully but I just cannot get the Serial Number character to reflect that of PORTD. This may be some fundamental misunderstanding on my part (I'm not that hot on asm) but if anyone can think of how I can do this it would be a great help!

cheers

Andy

To get the S/N to change at runtime, you'd have to overwrite the flash memory where that string resides, then force the PC to enumerate again.

Not worth it.

If you want it to be selected by PORTD jumpers, then just create a command that the PC program sends to the PIC requesting the value of PORTD. The PIC then reads the PORT and sends the value back to the PC.

That only has to be done once when the program connects to the device.

Another way is to let the PC program assign an ID number and send it to the PIC. Store it in EEPROM, and return the value upon request from the PC.
Then the PC program can keep track of which ID's have been used, to minimize possible duplicates. And the user doesn't need to do anything.

The S/N can then be used to indicate the firmware version. So it knows which command to send to get the ID.
<br>

Thanks for the reply Darrel.

I can see how assigning a serial number on the PC side could overcome this problem but you have to admit its a bit of a bodge and if you end up having to keep a lookup table of handle to serial number then a software crash would lose that information and you would have un-plug and then reattach your devices to re-assign serial numbers - very clunky! For a one off application this might be OK however this device is likely to be used in many different pieces of software in the future and minimising the PC side coding is very desirable.

When you say overwriting the flash and re-enumerating is not worth it which part is not worth it? if its the re-enumerating can I not just write over the flash before calling USBINIT? Or is writing to the flash the hard part?

Thanks

Andy

Sure, you could just write the PORTD value to flash on power-up (if it changed). Then when the device connects to the PC ... it will have the new S/N.

But yes ... writing the string to flash IS the hard part, and that would limit you to 256 devices (globally).

Some programmers will allow you to save an incrementing S/N to flash on each program cycle. The meLabs programmer let's you do that. But finding the correct location in flash to put the data is the hard part there. If the program changes, the string location will too.

It's a tough one.
<br>

OK, I failed to realise that the location in flash will change (although it does make sense now I think about it).

Limiting to 256 devices is no problem, there will never be that many in existence.

I think what I shall do is revert to an earlier version of my firmware that uses an extra byte in the USB Transfers to identify the device.

Thanks for the help Darrel.