libphidget-devel Mailing List for Phidget Library (Page 3)
Status: Alpha
Brought to you by:
jstrohm
Menu
▾
▴
libphidget-devel — Mailing list for developers of libphidget
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(134) |
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(23) |
Jul
(11) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Jack S. <js...@ja...> - 2002-09-12 12:41:51
|
On Thu, 2002-09-12 at 03:27, Vadim Tkachenko wrote: > Jack, > > Code for extracting the serial number looks funny (phidget.c from 651 to > 659). he he, got that from somewhere else. > > Line 658: j is never used again... yeah, j could just be (i-2)/2 in that example > > General: one-letter variable names are evil... I agree, but I think they are fair game when used as temporary generic local variables (and you don't use a bunch of them at once). > > Question to self: how does C support Unicode? not sure, I'm sure some other library has it. I didn't want to require a whole library for turning a unicode into a number. > > Another one: how come that GCC compiles the code that mustn't compile under > true C? I don't follow, what do you mean exactly? > servo_example.cc: you've probably noticed that the Version string is not > null-terminated... I believe there's a CVS pseudo-variable name for what > you're trying to achieve, though I don't remember it right now. Plus, don't > forget that *that* is the *revision* of servo_example.cc file, not the > general version - in order to have that, you'll have to get the @VERSION@ - > probably make configure.in create config.h - that's a long story. I didn't find a CVS variable for what I wanted. Since those examples are one file only examples, then the version of the file is the version of the example. I was thinking about adding a function to the libraries to get there version info and printing that out also. |
|
From: Vadim T. <vt...@fr...> - 2002-09-12 08:27:15
|
Jack, Code for extracting the serial number looks funny (phidget.c from 651 to 659). Line 658: j is never used again... General: one-letter variable names are evil... Question to self: how does C support Unicode? Another one: how come that GCC compiles the code that mustn't compile under true C? servo_example.cc: you've probably noticed that the Version string is not null-terminated... I believe there's a CVS pseudo-variable name for what you're trying to achieve, though I don't remember it right now. Plus, don't forget that *that* is the *revision* of servo_example.cc file, not the general version - in order to have that, you'll have to get the @VERSION@ - probably make configure.in create config.h - that's a long story. I'm not going to fix anything now, just want to get the overall picture before that. --vt |
|
From: Vadim T. <vt...@fr...> - 2002-09-12 07:33:46
|
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 |
|
From: <fit...@ph...> - 2002-09-12 07:28:18
|
> 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 |
|
From: Vadim T. <vt...@fr...> - 2002-09-12 07:18:45
|
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 |
|
From: <fit...@ph...> - 2002-09-12 07:15:24
|
> 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 |
|
From: Vadim T. <vt...@fr...> - 2002-09-12 07:10:16
|
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 |
|
From: Jack S. <js...@ja...> - 2002-09-12 02:51:18
|
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! |
|
From: <fit...@ph...> - 2002-09-12 02:49:22
|
> > > > 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 |
|
From: <fit...@ph...> - 2002-09-12 02:48:16
|
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 |
|
From: Jack S. <js...@ja...> - 2002-09-12 02:46:50
|
> > 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? |
|
From: Jack S. <js...@ja...> - 2002-09-12 02:45:31
|
On Wed, 2002-09-11 at 21:41, Vadim Tkachenko wrote: > According to Jack Strohm: > > > > > > Could you please explain to me the equilibristics behind getting the device > > > > > serial number? > > > > > > > > hmmm, what does 'equilibristics' mean first of all? > > > > > > Convoluted, complication actions requiring total concentration, just about > > > the same as juggling > > > > > > > yeah, I looked it up, said something about juggling. What specific > > juggling action are you referring too? > > Chester explained it already. > > I didn't realize the algorithm of getting the serial number. ha ha, neither did I, I had grabbed the code from another program (And it was bugged), but it's working now. |
|
From: Vadim T. <vt...@fr...> - 2002-09-12 02:42:03
|
According to Jack Strohm: > > > > Could you please explain to me the equilibristics behind getting the device > > > > serial number? > > > > > > hmmm, what does 'equilibristics' mean first of all? > > > > Convoluted, complication actions requiring total concentration, just about > > the same as juggling > > > > yeah, I looked it up, said something about juggling. What specific > juggling action are you referring too? Chester explained it already. I didn't realize the algorithm of getting the serial number. --vt |
|
From: Jack S. <js...@ja...> - 2002-09-12 02:39:51
|
On Wed, 2002-09-11 at 21:35, Vadim Tkachenko wrote: > According to Jack Strohm: > > > > Could you please explain to me the equilibristics behind getting the device > > > serial number? > > > > hmmm, what does 'equilibristics' mean first of all? > > Convoluted, complication actions requiring total concentration, just about > the same as juggling > yeah, I looked it up, said something about juggling. What specific juggling action are you referring too? |
|
From: Vadim T. <vt...@fr...> - 2002-09-12 02:35:15
|
According to Jack Strohm: > > Could you please explain to me the equilibristics behind getting the device > > serial number? > > hmmm, what does 'equilibristics' mean first of all? Convoluted, complication actions requiring total concentration, just about the same as juggling --vt |
|
From: Jack S. <js...@ja...> - 2002-09-12 02:25:42
|
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 |
|
From: <fit...@ph...> - 2002-09-12 02:18:32
|
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
>
|
|
From: <fit...@ph...> - 2002-09-12 02:15:34
|
> Jack, > > Could you please explain to me the equilibristics behind getting the device > serial number? > > --vt > > > ------------------------------------------------------- > In remembrance > www.osdn.com/911/ > _______________________________________________ > Libphidget-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libphidget-devel > |
|
From: Jack S. <js...@ja...> - 2002-09-12 02:14:28
|
On Wed, 2002-09-11 at 21:11, Vadim Tkachenko wrote: > Jack, > > Could you please explain to me the equilibristics behind getting the device > serial number? hmmm, what does 'equilibristics' mean first of all? |
|
From: Jack S. <js...@ja...> - 2002-09-12 02:12:47
|
For USB devices (phidget in particular) what is the maximum size of a serial number? |
|
From: Vadim T. <vt...@fr...> - 2002-09-12 02:11:12
|
Jack, Could you please explain to me the equilibristics behind getting the device serial number? --vt |
|
From: Jack S. <js...@ja...> - 2002-09-12 00:56:22
|
> kinda of a pain, you can only run make indent if you use version X. > > > I'd propose to leave 'make indent' alone for a while and just keep > > coding, hoping that this issue would go away soon ;/ > We could just not allow "make indent/indent-local" to be used unless the right version of indent exists. |
|
From: Jack S. <js...@ja...> - 2002-09-12 00:48:28
|
V On Wed, 2002-09-11 at 19:45, Vadim Tkachenko wrote: > Jack Strohm wrote: > > > > > So, when do you think you'll be ready to merge the INDENT branch back > > > > in? > > > > > > Now? > > > > did you run "make indent" before you checked it in, or do I need to run > > it. > > > > I checked it out and when I ran "make indent" and then "cvs diff" I got > > a few differences. Only once, each run of "make indent" after that > > didn't change it anymore. > > What version of indent are you running, again? [jstrohm@oishi libphidget]$ indent --version GNU indent 2.2.8 > I guess I just have to upgrade the OS, that's all... > kinda of a pain, you can only run make indent if you use version X. > I'd propose to leave 'make indent' alone for a while and just keep > coding, hoping that this issue would go away soon ;/ yeah maybe. |
|
From: Vadim T. <vt...@fr...> - 2002-09-12 00:45:40
|
Jack Strohm wrote: > > > So, when do you think you'll be ready to merge the INDENT branch back > > > in? > > > > Now? > > did you run "make indent" before you checked it in, or do I need to run > it. > > I checked it out and when I ran "make indent" and then "cvs diff" I got > a few differences. Only once, each run of "make indent" after that > didn't change it anymore. What version of indent are you running, again? I guess I just have to upgrade the OS, that's all... I'd propose to leave 'make indent' alone for a while and just keep coding, hoping that this issue would go away soon ;/ --vt |
|
From: Vadim T. <vt...@fr...> - 2002-09-12 00:37:19
|
According to Jack Strohm: > > > So, when do you think you'll be ready to merge the INDENT branch back > > > in? > > > > Now? > > did you run "make indent" before you checked it in, or do I need to run > it. > > I checked it out and when I ran "make indent" and then "cvs diff" I got > a few differences. Only once, each run of "make indent" after that > didn't change it anymore. Could you please send me the script(1)ed 'cvs diff'? I don't get any differences whatsoever... --vt |
