LUFA Focus: Automatic Device Serials

I’ve started work developing the new Host mode Class Driver Framework for LUFA – the Host mode version of the Device Class Driver Framework I’ve already completed for the next release, in an effort to make incorporating the standard classes easier into LUFA powered projects. There’s a LOT of work to be done, so I am once again faced with the age-old dilemma: either release it on time with the Host Class Framework missing, or delay the release even more and finish it. I don’t want to delay this release any more than I have to since it’s already a month late, but I’ll let the majority decide. You can see how an application will look with the new host framework here, which is a work-in-progress.

Now, on to the next LUFA Focus article for the next release: Automatic Serial Numbers.

USB Devices have the option of supplying a unique serial number to the host during enumeration, in the form of a string descriptor referenced in the device descriptor. This serial number is required to be unique within the given device’s VID and PID space, meaning that when used in conjunction with the device VID/PID it forms a globally unique serial number.

Globally unique identifiers are extremely useful in the field of computing, as they help differentiate between physically different but electrically identical devices (for example, two Mass Storage USB Disks of the same manufacturer and type). With a unique serial, the host can map shared resources (such as COM port numbers under Windows) to a physical device, so that even if the device is moved between ports the same COM port number is still used.

However, the USB 2.0 specification itself doesn’t require a unique serial number to be fixed into each device, as it can be expensive to manufacture devices with different serials, and the aim of USB is to make low-cost USB peripherals. Some classes of device such as the Mass Storage class do mandate such a unique serial, but for the most part many devices simply don’t need them. If not presented with a unique serial, the host will construct one from the device VID/PID and the USB port the device is plugged into.

This presents a slight problem; shared resources are no longer shared correctly. As many LUFA users have noticed, moving a CDC device from one port to another causes the device to be re-enumerated with a different COM port number – annoying, to say the least. But again, maintaining unique serial numbers is something many developers aren’t willing to do. Enter the new LUFA Automatic Serials.

On the larger series 6 and 7 USB AVRs (AT90USBxxx6 and AT90USBxxx7) there is a unique serial number embedded within the signature row, for just this purpose. Until now, there hasn’t been a good way to extract this serial and use it in the USB descriptors. However, with the new release, on compatible AVRs, it is simply a matter of setting the serial number descriptor index to the new magic USE_INTERNAL_SERIAL< value. That is:

USB_Descriptor_Device_t PROGMEM DeviceDescriptor =
{
        //...
	.SerialNumStrIndex      = USE_INTERNAL_SERIAL,
        //...
};

Which will cause the library to automatically extract and supply the internal serial number as the device’s serial number when requested by the host. On the smaller USB AVRs, this magic value simply equates to NO_DESCRIPTOR, forcing the host to construct a pseudo-unique serial number via the above method, meaning users are no worse off than they are now. With a bit of preprocessor use to test the value of USE_INTERNAL_SERIAL, developers could even supply their own serial numbers on AVR models lacking the internal serial number.

 

Comments: 2

Leave a reply »

 
 
 

Release, dammit!
Been sat here for months putting off development of the embedded part of my code waiting for the API to stabilise.

Besides, I’d have thought that releasing now would delay your host framework only slightly.

As long as the host API doesn’t need to change anything in the device API, then there is no reason not to release. 🙂

 

I’m also waiting for the next release. I’ve been playing around with the alpha, and the class drivers are exactly what I’m needing for my MIDI project. Keep the good work coming, it’s appreciated! 🙂

 

Leave a Reply

 
(will not be published)
 
 
Comment
 
 

 

Vital Stats

  • 35 Years Old
  • Australian
  • Lover of embedded systems
  • Firmware engineer
  • Self-Proclaimed Geek

Latest Blog Posts

RSS