Comments for Memos From the Cube http://fourwalledcubicle.com/blog Blog for Dean Camera Mon, 08 Mar 2010 17:24:03 +0000 http://wordpress.org/?v=2.9.2 hourly 1 Comment on Obtaining a VID and PID by Zac http://fourwalledcubicle.com/blog/archives/544/comment-page-1#comment-1581 Zac Mon, 08 Mar 2010 17:24:03 +0000 http://fourwalledcubicle.com/blog/?p=544#comment-1581 A similar situation exists with Ethernet devices (IEEE OUI for $1650). But the IEEE has the good sense to sell smaller blocks (IEEE IAB, which is very much like sharing a VID) for only $550, and there doesn't appear to be a renewal fee, unless you want to keep your name secret. A similar situation exists with Ethernet devices (IEEE OUI for $1650). But the IEEE has the good sense to sell smaller blocks (IEEE IAB, which is very much like sharing a VID) for only $550, and there doesn’t appear to be a renewal fee, unless you want to keep your name secret.

]]> Comment on Obtaining a VID and PID by Dean Camera http://fourwalledcubicle.com/blog/archives/544/comment-page-1#comment-1580 Dean Camera Mon, 08 Mar 2010 10:42:32 +0000 http://fourwalledcubicle.com/blog/?p=544#comment-1580 Very good point Alan. I'll be bringing up something related to your Guitar Hero point in my next blog/rant entry. However, while I do realise that the USB-IF exists to make money, I think it's deplorable that they make it near-impossible for hobbyists to break into the world of USB without violating a contract somewhere. LUFA uses PIDs in the Atmel range explicitly granted to me by Atmel for use in the project, which makes me lucky, however others have limited options. I've tried to help out somewhat by making it allowable to use the LUFA PIDs in *hobbyist non commercial* projects compatible with the official LUFA demo, but it's still a royal pain. Comparing values is cheap and even the cruddiest embedded host can do it; if the USB-IF had expanded it to a 128-bit GUID system like Windows uses we wouldn't be in this mess, they could still charge for USB certification/advertisement, and things would still work as they do now except small businesses and hobbyists wouldn't be screwed. I think MCS Electronics' resale of their VID uses your negative rights idea; even though the extra clauses weren't in the agreement they signed, the USB-IF revoked their purchased VID when they found out people had an alternative to sending them piles of money high enough for them to swim in. Since products already exist with the "blacklisted" VID value the USB-IF cannot relicense it, so MCS still sell out the PID space since it's guaranteed not to clash. You loose the rights to use the USB logo on your product, but that's where the "compatible/compliant" difference comes in and to the consumer, nothing matters so long as it has a plug that fits one of the holes on their computer. - Dean Very good point Alan. I’ll be bringing up something related to your Guitar Hero point in my next blog/rant entry. However, while I do realise that the USB-IF exists to make money, I think it’s deplorable that they make it near-impossible for hobbyists to break into the world of USB without violating a contract somewhere. LUFA uses PIDs in the Atmel range explicitly granted to me by Atmel for use in the project, which makes me lucky, however others have limited options. I’ve tried to help out somewhat by making it allowable to use the LUFA PIDs in *hobbyist non commercial* projects compatible with the official LUFA demo, but it’s still a royal pain. Comparing values is cheap and even the cruddiest embedded host can do it; if the USB-IF had expanded it to a 128-bit GUID system like Windows uses we wouldn’t be in this mess, they could still charge for USB certification/advertisement, and things would still work as they do now except small businesses and hobbyists wouldn’t be screwed.

I think MCS Electronics’ resale of their VID uses your negative rights idea; even though the extra clauses weren’t in the agreement they signed, the USB-IF revoked their purchased VID when they found out people had an alternative to sending them piles of money high enough for them to swim in. Since products already exist with the “blacklisted” VID value the USB-IF cannot relicense it, so MCS still sell out the PID space since it’s guaranteed not to clash. You loose the rights to use the USB logo on your product, but that’s where the “compatible/compliant” difference comes in and to the consumer, nothing matters so long as it has a plug that fits one of the holes on their computer.

- Dean

]]> Comment on Obtaining a VID and PID by Alan Chatham http://fourwalledcubicle.com/blog/archives/544/comment-page-1#comment-1579 Alan Chatham Mon, 08 Mar 2010 10:09:00 +0000 http://fourwalledcubicle.com/blog/?p=544#comment-1579 There are two other options I've seen out there as well: just pick a random number, which is probably fine for hobby stuff, and what I'll call negative rights, which is somewhat more legit for real devices, and also the model that V-USB is using The first option is picking random VIDs and PIDs. In practice, the VID/PID pair tells the operating system what drivers to load for the USB device. So as long as you pick an as-yet unused number, your device will work fine. The drawback is that if in the future, some device legitimately takes that number, then any system you've installed your device on won't recognize the rightful owner of the VID/PID's device, since the OS will load up the drivers for your device, and it's awkward. The second option, negative rights, is much more interesting. If you purchase a VID from the USB-IF, basically what you're buying is the guarantee that the USB-IF will never, ever, ever give someone else that VID. Now, the USB-IF won't let you give out the legal rights to PID blocks. However, (and something that I don't think has been tested in the legal system) there isn't much to stop a VID owner from promising someone else that they won't use a certain number or block of numbers. Hence, the developer would not be buying the right to use a number, but rather the promise that that VID/PID will never be used by its owner. The difference I assume would be that if you bought a PID from someone, you might have some legal claim to the rights of being a member of the USB-IF, while if you're buying this "negative right", you're still violating the USB-IF's contract (for using a VID/PID that you don't own), but your device will be guaranteed not to conflict with someone else's in the future. This brings me to my final point, which is that it seems to be that the USB-IF's actual legal recourse for punishing people who use unlicensed VID/PID pairs is to sue them for breach of contract. If you join the USB-IF and get a VID, you sign documents saying that you will only use the VID that's been assigned to you by the USB-IF. Since a 16 bit number isn't copyrightable, though, if you don't join the USB-IF, you can use any number and there's not much they can do about it. Of course, if you're not a member of the USB-IF, you can't get your stuff USB certified (even though it still works), and you can't use any USB markings, since that belongs to the USB-IF. Of course, I'm no lawyer, so this should all be taken with a grain of salt, but the ideas are some I've seen elsewhere. From personal experience, I know that any USB Guitar Hero controllers will only work with the games if they have the proper VID/PID pairs, and the number of unlicensed third party controllers seems to indicate that the USB-IF at least isn't too concerned with them, even if Activision and Harmonix have sued some makers over other stuff. There are two other options I’ve seen out there as well: just pick a random number, which is probably fine for hobby stuff, and what I’ll call negative rights, which is somewhat more legit for real devices, and also the model that V-USB is using

The first option is picking random VIDs and PIDs. In practice, the VID/PID pair tells the operating system what drivers to load for the USB device. So as long as you pick an as-yet unused number, your device will work fine. The drawback is that if in the future, some device legitimately takes that number, then any system you’ve installed your device on won’t recognize the rightful owner of the VID/PID’s device, since the OS will load up the drivers for your device, and it’s awkward.

The second option, negative rights, is much more interesting. If you purchase a VID from the USB-IF, basically what you’re buying is the guarantee that the USB-IF will never, ever, ever give someone else that VID. Now, the USB-IF won’t let you give out the legal rights to PID blocks. However, (and something that I don’t think has been tested in the legal system) there isn’t much to stop a VID owner from promising someone else that they won’t use a certain number or block of numbers. Hence, the developer would not be buying the right to use a number, but rather the promise that that VID/PID will never be used by its owner. The difference I assume would be that if you bought a PID from someone, you might have some legal claim to the rights of being a member of the USB-IF, while if you’re buying this “negative right”, you’re still violating the USB-IF’s contract (for using a VID/PID that you don’t own), but your device will be guaranteed not to conflict with someone else’s in the future.

This brings me to my final point, which is that it seems to be that the USB-IF’s actual legal recourse for punishing people who use unlicensed VID/PID pairs is to sue them for breach of contract. If you join the USB-IF and get a VID, you sign documents saying that you will only use the VID that’s been assigned to you by the USB-IF. Since a 16 bit number isn’t copyrightable, though, if you don’t join the USB-IF, you can use any number and there’s not much they can do about it. Of course, if you’re not a member of the USB-IF, you can’t get your stuff USB certified (even though it still works), and you can’t use any USB markings, since that belongs to the USB-IF. Of course, I’m no lawyer, so this should all be taken with a grain of salt, but the ideas are some I’ve seen elsewhere. From personal experience, I know that any USB Guitar Hero controllers will only work with the games if they have the proper VID/PID pairs, and the number of unlicensed third party controllers seems to indicate that the USB-IF at least isn’t too concerned with them, even if Activision and Harmonix have sued some makers over other stuff.

]]> Comment on Obtaining a VID and PID by László Monda http://fourwalledcubicle.com/blog/archives/544/comment-page-1#comment-1578 László Monda Mon, 08 Mar 2010 01:19:59 +0000 http://fourwalledcubicle.com/blog/?p=544#comment-1578 Very interesting writing. I wasn't aware of this issue and certainly wouldn't pay around $2000. Buying a whole 16 bit space is absolutely overkill! Very interesting writing.

I wasn’t aware of this issue and certainly wouldn’t pay around $2000. Buying a whole 16 bit space is absolutely overkill!

]]> Comment on I’m Chuffed! Also, bored. by Michael http://fourwalledcubicle.com/blog/archives/496/comment-page-1#comment-1576 Michael Sun, 07 Mar 2010 19:17:04 +0000 http://fourwalledcubicle.com/blog/?p=496#comment-1576 Just finished merging the MassStorage demo with the XPLAINBridge project. I use a jumper across TDO and TMS to select flash drive mode. Very straight forward. If I knew more about USB, I'd attempt make the USB Serial Port and the Mass Storage device available at the same time... Let me know if you want to fold the code into your baseline and I'll send you a zip... Just finished merging the MassStorage demo with the XPLAINBridge project. I use a jumper across TDO and TMS to select flash drive mode. Very straight forward. If I knew more about USB, I’d attempt make the USB Serial Port and the Mass Storage device available at the same time…
Let me know if you want to fold the code into your baseline and I’ll send you a zip…

]]> Comment on I’m Chuffed! Also, bored. by Dean Camera http://fourwalledcubicle.com/blog/archives/496/comment-page-1#comment-1575 Dean Camera Sun, 07 Mar 2010 13:18:59 +0000 http://fourwalledcubicle.com/blog/?p=496#comment-1575 Excellent Michael! Glad to hear my work is still useful to you. Let me know if you have any other enhancement ideas for me. - Dean Excellent Michael! Glad to hear my work is still useful to you. Let me know if you have any other enhancement ideas for me.

- Dean

]]> Comment on I’m Chuffed! Also, bored. by Michael http://fourwalledcubicle.com/blog/archives/496/comment-page-1#comment-1572 Michael Sat, 06 Mar 2010 19:55:46 +0000 http://fourwalledcubicle.com/blog/?p=496#comment-1572 Dean, once again your work pays me dividends. I just built and installed the MassStorage demo for the XPLAIN, saving me oodles of time. I'm going to attempt to fold it into the XPLAIN_Bridge project so I can quickly switch, probably via yet another jumper setting, between serial, flash drive, and PDI programmer... Dean, once again your work pays me dividends. I just built and installed the MassStorage demo for the XPLAIN, saving me oodles of time. I’m going to attempt to fold it into the XPLAIN_Bridge project so I can quickly switch, probably via yet another jumper setting, between serial, flash drive, and PDI programmer…

]]> Comment on Mein Server! by Dean Camera http://fourwalledcubicle.com/blog/archives/508/comment-page-1#comment-1568 Dean Camera Fri, 05 Mar 2010 05:43:54 +0000 http://fourwalledcubicle.com/blog/?p=508#comment-1568 Yes, altering that value will indeed alter the software USART baud rate. However, due to limitations imposed by the fact that it is indeed software and not hardware USART, you probably won't be able to dial it up much further than the existing 9600 baud without transmission errors due to insufficient cycles to bit-bang the data. - Dean Yes, altering that value will indeed alter the software USART baud rate. However, due to limitations imposed by the fact that it is indeed software and not hardware USART, you probably won’t be able to dial it up much further than the existing 9600 baud without transmission errors due to insufficient cycles to bit-bang the data.

- Dean

]]> Comment on Mein Server! by Michael http://fourwalledcubicle.com/blog/archives/508/comment-page-1#comment-1567 Michael Fri, 05 Mar 2010 03:47:02 +0000 http://fourwalledcubicle.com/blog/?p=508#comment-1567 Thanks a million, Dean. I'm glad you did this so I didn't have to! Do you think changing the bridge baud rate would be as simple as changing the BAUD macro in SoftUART.h, e.g. to 115200? Thanks a million, Dean. I’m glad you did this so I didn’t have to! Do you think changing the bridge baud rate would be as simple as changing the BAUD macro in SoftUART.h, e.g. to 115200?

]]> Comment on Mein Server! by Dean Camera http://fourwalledcubicle.com/blog/archives/508/comment-page-1#comment-1564 Dean Camera Wed, 03 Mar 2010 11:22:46 +0000 http://fourwalledcubicle.com/blog/?p=508#comment-1564 Yes, it would be perfectly possible to do both at the same time -- if the Atmel/Jungo driver allowed it. As it stands I can't figure out any way to get the Atmel AVRISP driver to bind to an arbitrary interface within the device, rather than the device itself, so I can't turn the app into a composite device with dual programming/serial capabilities. - Dean Yes, it would be perfectly possible to do both at the same time — if the Atmel/Jungo driver allowed it. As it stands I can’t figure out any way to get the Atmel AVRISP driver to bind to an arbitrary interface within the device, rather than the device itself, so I can’t turn the app into a composite device with dual programming/serial capabilities.

- Dean

]]>