Thread: [Libphidget-devel] serial numbers

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

For USB devices (phidget in particular) what is the maximum size of a
serial number?

No maximum size.  It's defined in hardware as a string, so it would be the
maximum length of a string in USB.  Probably 255 bytes or something.  In
Windows, I'm representing the serial number with a long.

Vadim, we fetch a string, which is always string descriptor #3, for serial
number, and then we parse this string to get the number.  This is the asm
declaration for the string.

USBStringDescription3:
     db Ch		; Length, db is a byte
     db 03h		; 3 is a string descriptor
     dsu "00001";	; string, defined in Unicode.

So you see that I'm using 5 digits only.  There is nothing to prevent me
from stretching this when I reach 99,999.  Be nice if that change didn't
break code.

Chester

>
>
> For USB devices (phidget in particular) what is the maximum size of a
> serial number?
>
>
>
> -------------------------------------------------------
> In remembrance
> www.osdn.com/911/
> _______________________________________________
> Libphidget-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libphidget-devel
>

On Wed, 2002-09-11 at 21:18, fit...@ph... wrote:
> 
> No maximum size.  It's defined in hardware as a string, so it would be the
> maximum length of a string in USB.  Probably 255 bytes or something.  In
> Windows, I'm representing the serial number with a long.
> 
> Vadim, we fetch a string, which is always string descriptor #3, for serial
> number, and then we parse this string to get the number.  This is the asm
> declaration for the string.
> 
> USBStringDescription3:
>      db Ch		; Length, db is a byte
>      db 03h		; 3 is a string descriptor
>      dsu "00001";	; string, defined in Unicode.
> 
> So you see that I'm using 5 digits only.  There is nothing to prevent me
> from stretching this when I reach 99,999.  Be nice if that change didn't
> break code.
> 
> Chester

So for example I get this back

12 - 3 - 48 - 0 - 48 - 0 - 55 - 0 - 52 - 0 - 49

12 bytes is the length of the message (does that include the first
byte?)

3 is the string descriptor

48 48 55 52 49  (unicode?) is 00741

12 includes the first byte, and the last byte, which you aren't printing
out.  The last byte is 0.

(49/0) in Unicode reduces trivially to 49 in ASCII, or '1'.

Chester

> So for example I get this back
>
> 12 - 3 - 48 - 0 - 48 - 0 - 55 - 0 - 52 - 0 - 49
>
> 12 bytes is the length of the message (does that include the first
> byte?)
>
> 3 is the string descriptor
>
> 48 48 55 52 49  (unicode?) is 00741

On Wed, 2002-09-11 at 21:48, fit...@ph... wrote:
> 
> 12 includes the first byte, and the last byte, which you aren't printing
> out.  The last byte is 0.

darn cut and paste!

> 
> USBStringDescription3:
>      db Ch		; Length, db is a byte
>      db 03h		; 3 is a string descriptor
>      dsu "00001";	; string, defined in Unicode.
> 
> So you see that I'm using 5 digits only.  There is nothing to prevent me
> from stretching this when I reach 99,999.  Be nice if that change didn't
> break code.

Will a serial ever be anything more than a number, making full use of
unicode?

> >
> > USBStringDescription3:
> >      db Ch		; Length, db is a byte
> >      db 03h		; 3 is a string descriptor
> >      dsu "00001";	; string, defined in Unicode.
> >
> > So you see that I'm using 5 digits only.  There is nothing to prevent me
> > from stretching this when I reach 99,999.  Be nice if that change didn't
> > break code.
>
> Will a serial ever be anything more than a number, making full use of
> unicode?

I don't see any reason to complicate matters.  So, it should be safe to
use the straightforward algorithm that you have right now.

Chester

fit...@ph... wrote:
> 
> > >
> > > USBStringDescription3:
> > >      db Ch          ; Length, db is a byte
> > >      db 03h         ; 3 is a string descriptor
> > >      dsu "00001";   ; string, defined in Unicode.
> > >
> > > So you see that I'm using 5 digits only.  There is nothing to prevent me
> > > from stretching this when I reach 99,999.  Be nice if that change didn't
> > > break code.
> >
> > Will a serial ever be anything more than a number, making full use of
> > unicode?
> 
> I don't see any reason to complicate matters.  So, it should be safe to
> use the straightforward algorithm that you have right now.

Just a thought: why does the serial number have to be a number, no
matter how coded? Give you an example: az93c12 - what's wrong with this
number?

What's the primary purpose of the serial number? Let me guess: unique
identifier?

I sincerely hope that you will run out of serial numbers ;)

> Chester

--vt

> fit...@ph... wrote:
> >
> > > >
> > > > USBStringDescription3:
> > > >      db Ch          ; Length, db is a byte
> > > >      db 03h         ; 3 is a string descriptor
> > > >      dsu "00001";   ; string, defined in Unicode.
> > > >
> > > > So you see that I'm using 5 digits only.  There is nothing to prevent me
> > > > from stretching this when I reach 99,999.  Be nice if that change didn't
> > > > break code.
> > >
> > > Will a serial ever be anything more than a number, making full use of
> > > unicode?
> >
> > I don't see any reason to complicate matters.  So, it should be safe to
> > use the straightforward algorithm that you have right now.
>
> Just a thought: why does the serial number have to be a number, no
> matter how coded? Give you an example: az93c12 - what's wrong with this
> number?

No good reason, it just happened this way.  The first piece of working
sample code I got my hands on did it this way, so that's what I do.

> What's the primary purpose of the serial number? Let me guess: unique
> identifier?

Yup.

> I sincerely hope that you will run out of serial numbers ;)

You mean with a 5-digit string, or a 32-bit long?  I would consider
phidgets to be a success if I ran out with the 5 digit string.

Chester

According to fit...@ph...:

> > Just a thought: why does the serial number have to be a number, no
> > matter how coded? Give you an example: az93c12 - what's wrong with this
> > number?
> 
> No good reason, it just happened this way.  The first piece of working
> sample code I got my hands on did it this way, so that's what I do.
> 
> > What's the primary purpose of the serial number? Let me guess: unique
> > identifier?
> 
> Yup.

Then, the string serves as good as the number, though you can a) add more
significant information to it (like, the release variations, or specific
options included into an instance of a phidget), b) extend the address space
(though this is rather theoretical at this moment).

How much of the existing code will break if the serial happens to be a
malformed number?

> > I sincerely hope that you will run out of serial numbers ;)
> 
> You mean with a 5-digit string, or a 32-bit long?  I would consider
> phidgets to be a success if I ran out with the 5 digit string.

That's what I was implying ;)

> Chester

--vt

> Then, the string serves as good as the number, though you can a) add more
> significant information to it (like, the release variations, or specific
> options included into an instance of a phidget), b) extend the address space
> (though this is rather theoretical at this moment).
>
> How much of the existing code will break if the serial happens to be a
> malformed number?

Well, it doesn't bother me very much, because I just release a new Windows
version and tell everyone to go use it.  It's nice owning your own
sandbox.  I just try not to change it all the time..  As long as my
library is smart enough to figure out all the old phidgets, I don't worry
about broken code.

I don't think it's really worth mucking with, because USB provides other
mechanisms for device versioning, and so forth.  Particularly with the HID
devices.

With the soft phidgets, all that data, including the serial number,
version, .... extraneous information like programmable logic
device firmware versions, get stored into a fat EEPROM.  And it makes no
sense to cram everything into the serial number when it can stay
structured?

Chester

According to fit...@ph...:

> > Then, the string serves as good as the number, though you can a) add more
> > significant information to it (like, the release variations, or specific
> > options included into an instance of a phidget), b) extend the address space
> > (though this is rather theoretical at this moment).
> >
> > How much of the existing code will break if the serial happens to be a
> > malformed number?
> 
> Well, it doesn't bother me very much, because I just release a new Windows
> version and tell everyone to go use it.  It's nice owning your own
> sandbox.  I just try not to change it all the time..  As long as my
> library is smart enough to figure out all the old phidgets, I don't worry
> about broken code.
> 
> I don't think it's really worth mucking with, because USB provides other
> mechanisms for device versioning, and so forth.  Particularly with the HID
> devices.
> 
> With the soft phidgets, all that data, including the serial number,
> version, .... extraneous information like programmable logic
> device firmware versions, get stored into a fat EEPROM.  And it makes no
> sense to cram everything into the serial number when it can stay
> structured?

True. My rationale, though, was: Occam's Razor. Why should I parse the
serial to number when it is *enough* to treat it as a string?

One reason I might think of: memory. But is this reason good enough? Not to
me - how many phidgets will I have on the adapter, and how many bytes will I
lose if I store serials as numbers? Definitely less than amount of code
necessary to parse it...

Performance - how often do I have to compare the serial with something?
Don't think more than once - at initialization.

Just thinking aloud...

> Chester

--vt

On Thu, 2002-09-12 at 02:33, Vadim Tkachenko wrote:
> According to fit...@ph...:
> 
> > > Then, the string serves as good as the number, though you can a) add more
> > > significant information to it (like, the release variations, or specific
> > > options included into an instance of a phidget), b) extend the address space
> > > (though this is rather theoretical at this moment).
> > >
> > > How much of the existing code will break if the serial happens to be a
> > > malformed number?
> > 
> > Well, it doesn't bother me very much, because I just release a new Windows
> > version and tell everyone to go use it.  It's nice owning your own
> > sandbox.  I just try not to change it all the time..  As long as my
> > library is smart enough to figure out all the old phidgets, I don't worry
> > about broken code.
> > 
> > I don't think it's really worth mucking with, because USB provides other
> > mechanisms for device versioning, and so forth.  Particularly with the HID
> > devices.
> > 
> > With the soft phidgets, all that data, including the serial number,
> > version, .... extraneous information like programmable logic
> > device firmware versions, get stored into a fat EEPROM.  And it makes no
> > sense to cram everything into the serial number when it can stay
> > structured?
> 
> True. My rationale, though, was: Occam's Razor. Why should I parse the
> serial to number when it is *enough* to treat it as a string?

treating it as a string might be fine, but if Chester will give us a
heads up before he starts assigning alpha numeric serial numbers we can
change the code before he starts selling phidgets with such.

> 
> One reason I might think of: memory. But is this reason good enough? Not to
> me - how many phidgets will I have on the adapter, and how many bytes will I
> lose if I store serials as numbers? Definitely less than amount of code
> necessary to parse it...

Memory isn't an issue, you can only have 128 USB device (I think), so
128*256 (Max string length), what's that 32K, think I could spare that
worse case.

> 
> Performance - how often do I have to compare the serial with something?
> Don't think more than once - at initialization.

Actually, since this is the unique ID for all devices it is used QUITE a
lot, but I don't think a string compare will be too expensive.

> 
> Just thinking aloud...
>  

On Thu, 2002-09-12 at 02:18, Vadim Tkachenko wrote:
> According to fit...@ph...:
> 
> > > Just a thought: why does the serial number have to be a number, no
> > > matter how coded? Give you an example: az93c12 - what's wrong with this
> > > number?
> > 
> > No good reason, it just happened this way.  The first piece of working
> > sample code I got my hands on did it this way, so that's what I do.
> > 
> > > What's the primary purpose of the serial number? Let me guess: unique
> > > identifier?
> > 
> > Yup.
> 
> Then, the string serves as good as the number, though you can a) add more
> significant information to it (like, the release variations, or specific
> options included into an instance of a phidget), b) extend the address space
> (though this is rather theoretical at this moment).
> 
> How much of the existing code will break if the serial happens to be a
> malformed number?

The code won't really break, but you won't have a valid unique Identify
and so might generate an exception when looking for the device (not
found because it couldn't locate the device).

Converting serial number to a string isn't that difficult, but I don't
think it is necessary right now.