[Nut-upsdev] USB HID Spec help (passing strings)

Rob Groner rgroner at RTD.com
Mon Aug 31 13:01:54 UTC 2015


iSerialNumber does not need to be unique per device - it is not very many bits wide.

I’m pretty sure I don’t *need* iSerialNumber…I mean, I could just remove it from the report descriptor altogether.  But since it is available to give, and we are writing each board’s serial number into flash as part of the micro-controller programming (we aren’t talking a staggering number of boards per year here), I figured I should try to send the actual serial number.

NUT and other tools match against the string returned from the "get string descriptor" request (not iSerialNumber itself - the string indexed by it) and the procedure for modifying that is going to be specific to each USB device controller.

By this do you mean…just simply send the serial number as data (like all other report values) instead of as a string pointer index, and interpret the bytes on the NUT end?  I have already written an RTD UPS driver for NUT, so adding a custom function isn’t a problem.  I was trying to search through other drivers to find an example of where they passed a string without using the string index method.

like PICs make this harder, but there is a C __attribute__ or something that you should be able to use). Otherwise, does your USB framework allow callbacks for arbitrary requests?

Hmm…I’ll admit, I’ve never used __attribute__, and I honestly don’t know enough about how Microchip PIC32’s handle the USB framework to know.  I’ll have to research both of those.

I wondered if I could somehow set the pointer for the iSerialNumber string index to the address of it in memory (in other words, load it from Flash into a global var, and then use that address when the iSerialNumber pointer is requested), but from how it is implemented, I couldn’t figure it out.  I’ll look again.

Thanks for the help.


Rob Groner
Software Engineer Level II

RTD Embedded Technologies, Inc.
ISO 9001 and AS9100 Certified
Ph: +1 814-234-8087
www.rtd.com<http://www.rtd.com/>

From: Charles Lepple [mailto:clepple at gmail.com]
Sent: Friday, August 28, 2015 6:51 PM
To: Rob Groner <rgroner at RTD.com>
Cc: nut-upsdev at lists.alioth.debian.org
Subject: Re: [Nut-upsdev] USB HID Spec help (passing strings)

On Aug 28, 2015, at 2:21 PM, Rob Groner <rgroner at RTD.com<mailto:rgroner at RTD.com>> wrote:

We’re wrapping up our first version of the UPS we’re making, and so I’m going over the USB code and came across one loose end.  The serial number of the unit (iSerialNumber according to the USB HID doc) is a constant, but it’s of course a different constant for each UPS.

iSerialNumber does not need to be unique per device - it is not very many bits wide.

  Right now we store that value in the Flash on the device, but the only way I’ve seen to pass the serial number over USB is to encode it as a constant in the code and then reference it as a USB HID String Index.  We aren’t going to rebuild/program for each UPS, so there must be a way to take the value in flash memory and send that as the serial number.  In other words, how do you send a “variable” length string across USB?  Actually, the length can be known ahead of time, but the data itself will be the variable.

NUT and other tools match against the string returned from the "get string descriptor" request (not iSerialNumber itself - the string indexed by it) and the procedure for modifying that is going to be specific to each USB device controller.

Typically the string descriptor table is an array of pointers, and this is often why USB devices cluster the string indexes together starting at 1 (rather than having a sparse array). If you can make the pointer corresponding to the serial number point to RAM, you should be all set (Harvard architecture chips like PICs make this harder, but there is a C __attribute__ or something that you should be able to use). Otherwise, does your USB framework allow callbacks for arbitrary requests?

--
Charles Lepple
clepple at gmail



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20150831/518ac198/attachment.html>


More information about the Nut-upsdev mailing list