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>
On Aug 31, 2015, at 9:01 AM, Rob Groner <rgroner at RTD.com> wrote:> > 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.Right, I was trying to make clear that iSerialNumber can be 3 for every board (or 42 or whatever) even though every board returns a unique string when you request the string indexed by iSerialNumber.> > 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.No, just as a variable string descriptor.> > 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.And I've never used a PIC32 :-) If it has a flat 32-bit address space, then forget what I said about __attribute__. It would only be for the smaller PICs that use different instructions (and different address spaces) for code and data.> 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.http://ww1.microchip.com/downloads/en/AppNotes/01176A.pdf <http://ww1.microchip.com/downloads/en/AppNotes/01176A.pdf> has code (Example 6) that allows you to specify a custom function to generate the string descriptor responses. It looks like it should be fairly simple to special-case the serial number descriptor. -- Charles Lepple clepple at gmail -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20150831/51ecd25e/attachment-0001.html>
No, just as a variable string descriptor. By ?variable string descriptor?, do you mean what is contained in the example in the App Note? I?m just asking for clarification, in case variable string descriptor is something different than shown there. The way they do the string descriptors in the example is how I have mine now. They return a size and address, but it is to something that was defined at compile time. I guess I?ve been fixated on that, so I don?t know if I can simply pass a different string that what was defined before. And I don?t know how to handle something of an unknown size (though in my case, the MAX size of the serial number can be defined) That?s why I was asking about the variable string descriptor...it sounds more like something where you can pass a string of any size and address, which would definitely be what I?m looking for. Looking at the data being passed, I realized that battery.type is something else that I possibly won?t know until the code is running. Our UPS can use different attached batteries, and will be able to discern what it is at runtime, and that?s when it would be able to report battery.type. Thanks for the help Charles?that is a very good link to the Appnote considering you haven?t done PIC32 work. ? My google skills failed me. 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/> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20150902/0dada53b/attachment.html>