Post by thread:[EE:] USB cable length. Evolution. Lack of testing

Herbert Graf wrote: > > And why do I have to add a separate and distinct 'device driver' > > for EVERY new device, unlike RS232 or firewire, where the > > application talks to ONE STANDARDIZED API? > > You don't. For example many storage devices use the "mass storage" driver, > most modern OS's have the driver and therefore you don't need to install > anything. Devices can also be "HID" which also don't require new drivers. But I still have to load a -driver- for each and EVERY device. With Firewire there is ONE driver and each app ties to it as needed (and as expected). And every MP3 player I've tried in the last month requires that it's OWN driver be loaded. None seem to support the generic 'storage' device type (e.g. Yepp, IRiver, WaveX, Rio...). It's been a royal PITA, especially since the Yepp install nuked my USB connectivity and it took many many hours to purge the registry after the uninstall royally messed up. It will be a cold day in hades before Samsung gets another dollar out of me. > > And if one has used a few dozen different devices over time, > > one is stuck with ALL those drivers being loaded by Winblows, > > even if the device is now in the dumpster. > > Any device worse a dollar has drivers with an uninstall feature, you get > what you pay for. The Yepp wasn't cheap, and it came from a supposedly reputable company. It went back untested. > > And of course USB works every time, and is EASY to implement > > on embedded processors like the PIC (NOT!). > > And firewire is? I don't think there is a PIC with firewire, there is a PIC > with USB. I don't know of many PIC applications that need the 400mbs pipe firewire gives, but it looks to be LOT easier to code for. Unfortunately I am about to be -forced- to implement USB on one of our medical devices. I am not looking forward to the task. > USB-serial devices out there it's just a matter of time before working with > USB is easier then with the legacy ports. PLEASE point me in the right direction. I have just been told (this afternoon) that a research device which works just fine with optically isolated RS232, must now do USB so that it can tie to wireless 802.11 USB dongles for laptops. ARGGHH!!! > > P&P stands for Plug and PRAY, remember? Or is than now "Plug and PAY!". > I used to be like you, I think you should give USB a try again, today's > devices and drivers are approaching flawless. TTYL It looks like I'm not going to have a choice. By amazing coincidence my boss has ordered that we "MUST HAVE" USB on our stimulator for the clinical trials phase. I now get to dig through the archives to find Novembers "PIC USB" thread and try to 'make it go'... Any idea where to get those 'micro USB' PCB connectors, suitable drivers/chips, PIC code and my life back? I'd like to use some USB-Serial blobs, but that has been explicitly ruled out since they (collaborative design team) wants 802.11 without actually understanding what that really involves. Maybe if I hadn't slammed USB I wouldn't be forced to use it now :{ Da pain... da pain. Thanks for the collective ear and direction. Robert -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

> > You don't. For example many storage devices use the > "mass storage" driver, > > most modern OS's have the driver and therefore you don't need to install > > anything. Devices can also be "HID" which also don't require > new drivers. > > But I still have to load a -driver- for each and EVERY device. > With Firewire there is ONE driver and each app ties to it > as needed (and as expected). A prof of mine once said: you NEVER get something for nothing. The "one driver" approach of firewire means all the hardware needs to be a certain complexity, USB was developed to be cheap if you don't need the speed. > And every MP3 player I've tried in the last month requires > that it's OWN driver be loaded. None seem to support the generic > 'storage' device type (e.g. Yepp, IRiver, WaveX, Rio...). > It's been a royal PITA, especially since the Yepp install > nuked my USB connectivity and it took many many hours to purge the > registry after the uninstall royally messed up. > It will be a cold day in hades before Samsung gets another > dollar out of me. You have to blame the RIAA for that. It's their insistence on "protecting" their IP that results in stupid and hacked implementations like what you're seeing. {Quote hidden}> > > And if one has used a few dozen different devices over time, > > > one is stuck with ALL those drivers being loaded by Winblows, > > > even if the device is now in the dumpster. > > > > Any device worse a dollar has drivers with an uninstall > feature, you get > > what you pay for. > > The Yepp wasn't cheap, and it came from a supposedly reputable > company. It went back untested. Blame the RIAA for forcing the companies to come up with "secure" ways of doing things, ways that go beyond the spirit of the technologies used. > > > And of course USB works every time, and is EASY to implement > > > on embedded processors like the PIC (NOT!). > > > > And firewire is? I don't think there is a PIC with > firewire, there is a PIC > > with USB. > > I don't know of many PIC applications that need the 400mbs pipe > firewire gives, but it looks to be LOT easier to code for. And that's my point. With firewire you either have all or nothing, you CAN'T do firewire cheap and slow. Why? It was NEVER meant for that, USB is. > > USB-serial devices out there it's just a matter of time before > working with > > USB is easier then with the legacy ports. > > PLEASE point me in the right direction. I have just been told Reread what I said. {Quote hidden}> > I used to be like you, I think you should give USB a > try again, today's > > devices and drivers are approaching flawless. TTYL > > It looks like I'm not going to have a choice. By amazing coincidence > my boss has ordered that we "MUST HAVE" USB on our stimulator > for the clinical trials phase. I now get to dig through the > archives to find Novembers "PIC USB" thread and try to 'make it go'... > > Any idea where to get those 'micro USB' PCB connectors, > suitable drivers/chips, PIC code and my life back? After the tone and way you have treated my opinion I hope you don't expect help from me, but for the record: you won't be receiving any. ---------------------------------- Herbert's PIC Stuff: http://repatch.dyndns.org:8383/pic_stuff/ -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email spam_OUTlistservTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

> > > And why do I have to add a separate and distinct 'device driver' > > > for EVERY new device, unlike RS232 or firewire, where the > > > application talks to ONE STANDARDIZED API? > > > > You don't. For example many storage devices use the "mass storage" driver, > > most modern OS's have the driver and therefore you don't need to install > > anything. Devices can also be "HID" which also don't require new drivers. > > But I still have to load a -driver- for each and EVERY device. > With Firewire there is ONE driver and each app ties to it > as needed (and as expected). This is blatently NOT TRUE. HID and storage devices all use common drivers. Also, how many different kinds of devices can you interface with firewire? Have you every tried anything other than a camera, scanner or storage device? Is there any support for anything other than cameras, scanners and storage devices? > And every MP3 player I've tried in the last month requires > that it's OWN driver be loaded. None seem to support the generic > 'storage' device type (e.g. Yepp, IRiver, WaveX, Rio...). Not the fault of USB. I'd blame it on the makers of the various devices. If I was designing one, I'd let it have two modes: 'storage only' and 'enhanced'. Only the latter would require a custom driver. > It's been a royal PITA, especially since the Yepp install > nuked my USB connectivity and it took many many hours to purge the > registry after the uninstall royally messed up. > It will be a cold day in hades before Samsung gets another > dollar out of me. Don't blame USB: Blame Samsung. > > > And if one has used a few dozen different devices over time, > > > one is stuck with ALL those drivers being loaded by Winblows, > > > even if the device is now in the dumpster. > > > > Any device worse a dollar has drivers with an uninstall feature, you get > > what you pay for. > > The Yepp wasn't cheap, and it came from a supposedly reputable > company. It went back untested. Again: Blame Samsung > > > And of course USB works every time, and is EASY to implement > > > on embedded processors like the PIC (NOT!). > > > > And firewire is? I don't think there is a PIC with firewire, there is a PIC > > with USB. > > I don't know of many PIC applications that need the 400mbs pipe > firewire gives, but it looks to be LOT easier to code for. Don't bet on Firewire being that much easier. And of course, you can't even get into the Firewire world without being able to handle that 400Mb/Sec data rate. Certainly more expensive then the 1.5Mb/Sec or even 12Mb/Sec of USB. > Unfortunately I am about to be -forced- to implement USB on one of our > medical devices. I am not looking forward to the task. If it bothers you, just use the FTDI chip. The RS232 version will let you operate just like you would with a serial level shifter like a MAX232. The parallel version will let you get considerably better performance. > > USB-serial devices out there it's just a matter of time before working with > > USB is easier then with the legacy ports. > PLEASE point me in the right direction. I have just been told > (this afternoon) that a research device which works just fine with > optically isolated RS232, must now do USB so that > it can tie to wireless 802.11 USB dongles for laptops. ARGGHH!!! Now here you'll have some trouble, I'm afraid. I'm not sure what the 802.11 dongle is going to want, but at a minimum your controller will have to implement an IP stack. You'll probably be able to get away with UDP/IP instead of TCP/IP, but it'll still be non-trivial. You will also have to provide a Host implementation of USB, which is also non-trivial. Finally, you will likely have to implement all the code behind 802.11, which is really non-trivial. I'd be looking for an alternative/easier solution here. What processor do you have in your instrument? What OS, if any, does it run? Bob Ammerman RAm Systems -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email .....listservKILLspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body

Herbert Graf wrote: > > > And every MP3 player I've tried in the last month requires > > that it's OWN driver be loaded. None seem to support the generic > > 'storage' device type (e.g. Yepp, IRiver, WaveX, Rio...). > You have to blame the RIAA for that. It's their insistence on "protecting" > their IP that results in stupid and hacked implementations like what you're > seeing. That actually makes sense. There had to be some good reason that MP3 players are so stupidly implemented. I also recently read where the linux geeks had figured out the protocol for Sony MD players, but discovered that the data packets are all encrypted so they can't use it as a portable storage device. > > The Yepp wasn't cheap, and it came from a supposedly reputable > > company. It went back untested. > > Blame the RIAA for forcing the companies to come up with "secure" ways of > doing things, ways that go beyond the spirit of the technologies used. How long before our hard drives are forced to NOT store MP3's that are not officially sanctioned? > > I don't know of many PIC applications that need the 400mbs pipe > > firewire gives, but it looks to be LOT easier to code for. > > And that's my point. With firewire you either have all or nothing, you > CAN'T do firewire cheap and slow. Why? It was NEVER meant for that, USB is. Yes, I agree with that. Unfortunately, from my jaded perspective USB is still complex compared to a 'legacy' port. > > Any idea where to get those 'micro USB' PCB connectors, > > suitable drivers/chips, PIC code and my life back? > > After the tone and way you have treated my opinion I hope you don't expect > help from me, but for the record: you won't be receiving any. Thank you for the offer. I meant no disrespect. I'm just very frustrated with my recent bad USB experiences. I'm sure there is good money to be made by a USB-PIC experienced engineer. It's been a most enlightening thread. Thanks again to all who contributed. Robert -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email listservKILLspammitvma.mit.edu with SET PICList DIGEST in the body

Robert Rolf wrote: > Unfortunately I am about to be -forced- to implement USB on one of our > medical devices. I am not looking forward to the task. Then farm it out. I'm sure I remember hearing of an embedded systems company around here somewhere... > Any idea where to get those 'micro USB' PCB connectors, > suitable drivers/chips, PIC code and my life back? PICs only support slow speed USB, which is nearly useless. Unfortunately full speed USB PICs probably won't be out until late this year. If you want to stick with PICs and do real USB, you can have the PIC talk to an interface chip like the Phillips PDIUSBD12D. There are also others from National, TI, and Cypress. Cypress has a lot of micros with USB capability. I don't remember the details, but I looked at using them a couple of times and each time walked away in disgust. Maybe they've cleaned up their act since I've tuned them out. > I'd like to use some USB-Serial blobs, > but that has been explicitly ruled out since they (collaborative > design team) wants 802.11 without actually understanding what that > really involves. I don't understand what one has to do with the other, and why an 802.11 interface precludes USB connectivity via a USB to serial chip. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email EraseMElistservspam_OUTTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

Josh Koffman wrote: > My read on that was that he's expected to use a consumer USB to 802.11 > adapter, made for use on a home computer or laptop. That might > preclude the USB to serial chip as I'm not sure there are any that > act as USB hosts. I could be wrong though. If I'm right, I don't envy > him at all. I hadn't even considered that he wanted to drive an 802.11 interface via USB from his little portable device. That is **not trivial**, since, among other things, this requires implementing a USB host controller. I thought this device was supposed to talk USB and 802.11. In that case they would be done separately. The easiest way to do 802.11 is probably to interface to a fully canned PC card. In either case that requires a protocol stack and a bunch of essentially PCI host logic. This is not something that seems a good fit for a PIC. I'd first look to one of the ARM varieties that have lots more horsepower and with much of the code available already. It will suck a lot more power, both for the 802.11 and the processor. Some of the ARM varieties are specifically designed for portable devices and are reasonably power efficient for the cycles, like the Intel XScale. Still, the whole processor part will be a lot more complicated than a PIC. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email KILLspamlistservKILLspammitvma.mit.edu with SET PICList DIGEST in the body

Josh Koffman wrote: > > Olin Lathrop wrote: > > I don't understand what one has to do with the other, and why an 802.11 > > interface precludes USB connectivity via a USB to serial chip. > > My read on that was that he's expected to use a consumer USB to 802.11 > adapter, made for use on a home computer or laptop. That might preclude > the USB to serial chip as I'm not sure there are any that act as USB > hosts. I could be wrong though. If I'm right, I don't envy him at all. Unfortunately Josh, that is exactly what my boss expects. The people involved see all these cheap WI-FI USB dongles that hang off USB ports, and figure that is should be "relatively simple" to make it work with the current PIC hardware. In other words, the want me to put a USB port on the unit so they can plug in an 802.11 dongle. 'It's USB, right? It should just -work-' I know better, but this is a collaboration with another large group, and they have a lot of newly degreed engineers (as well as some older ones, long since removed from hands-on design) who know all about the 'lastest stuff'. But since I don't have a degree, my experience/knowledge/skill means squat. The FTDI chips will certainly make basic hardwired USB comms easy. The target user will have a laptop, and probably won't have a real RS232 port today. It's the TCP/IP stack and Wi-Fi handshaking that will be the killer if I can't convince them it as bad an I idea as we all know it is. I'm going to take the tact that if they think it is so easy to implement, let them do it. I'll supply all relevant tech doc, and let them have at it. Hopefully they'll believe me once they have to get their hands a bit dirty coding. And 802.11 is way overkill just to get a wireless link. I'm hoping to find something from Radiometrix, RFM or the like, but nothing I've seen so far can touch the price of a 802.11b USB dongle. Of course they also neglect to note that the dongle has to be attached to a $2000 laptop to be able to work, and that you also need a wireless router too. The problem is simple. RF wireless @ 19.2kbs full duplex to 150' and dirt cheap, with the remote side the size of a silver dollar (3cm or so although something the size of an eraser could be made to work as a 'clip on'). IR is not allowed because of line of sight and distance issues. My unit is only the size of half a deck of cards, running on a AA cell boosted to 3.3V, although 7.2V -may- become available in one variation. So of course that tiny USB dongle is the 'perfect' solution... There must be something COTS out there, I just haven't dug deep enough yet. I'm thinking maybe wireless keyboard or mice if the intrinsic data rate is high enough. Thanks again for all the helpful ideas and feedback. Especially Olin. Let's put this thread to bed, and I'll let you know what I ultimately end up with. Probably looking for a new job. Robert -- http://www.piclist.com hint: To leave the PICList spamBeGonepiclist-unsubscribe-requestspamBeGonemitvma.mit.edu

Quoting Robert Rolf <TakeThisOuTRobert.RolfEraseMEspam_OUTUALBERTA.CA>: > Josh Koffman wrote: > > > > Olin Lathrop wrote: > > > I don't understand what one has to do with the other, and why an 802.11 > > > interface precludes USB connectivity via a USB to serial chip. > > > > My read on that was that he's expected to use a consumer USB to 802.11 > > adapter, made for use on a home computer or laptop. That might preclude > > the USB to serial chip as I'm not sure there are any that act as USB > > hosts. I could be wrong though. If I'm right, I don't envy him at all. seems my first email didn't get through, unfortunately yet, I have uncovered *more* information about this > Unfortunately Josh, that is exactly what my boss expects. The people > involved the classic boss-that-doesn't-know-shit problem > see all these cheap WI-FI USB dongles that hang off USB ports, and figure > that > is should be "relatively simple" to make it work with the current PIC > hardware. In other words, the want me to put a USB port on the unit so > they can plug in an 802.11 dongle. 'It's USB, right? It should just -work-' no, and here are more info each USB dongle needs a different driver in a PC, (see the source for the linux kernel), the Atmel-based stuff even needs to have firmware to be uploaded to it. > I know better, but this is a collaboration with another large group, > and they have a lot of newly degreed engineers (as well as some older ones, > long since removed from hands-on design) who know all about the 'lastest > stuff'. > But since I don't have a degree, my experience/knowledge/skill means squat. ah, I see what kind of company that is... been there, done that > The FTDI chips will certainly make basic hardwired USB comms easy. The > target > user will have a laptop, and probably won't have a real RS232 port today. > It's the TCP/IP stack and Wi-Fi handshaking that will be the killer if > I can't convince them it as bad an I idea as we all know it is. notably, the personal privacy issues this raises are staggering see below {Quote hidden}> I'm going to take the tact that if they think it is so easy to implement, > let them do it. I'll supply all relevant tech doc, and let them have at it. > Hopefully they'll believe me once they have to get their hands a bit dirty > coding. And 802.11 is way overkill just to get a wireless link. I'm hoping > to find something from Radiometrix, RFM or the like, but nothing I've seen > so > far can touch the price of a 802.11b USB dongle. Of course they also neglect > to note > that the dongle has to be attached to a $2000 laptop to be able to work, and > that > you also need a wireless router too. there are some Aurel 433 Mhz component the size of a quarter or so that do it for less than 50 USD. that should do it. however, there is more to this issue : > The problem is simple. RF wireless @ 19.2kbs full duplex to 150' and dirt > cheap, > with the remote side the size of a silver dollar (3cm or so although > something the size of an eraser could be made to work as a 'clip on'). > IR is not allowed because of line of sight and distance issues. > My unit is only the size of half a deck of cards, running on a AA cell > boosted > to 3.3V, although 7.2V -may- become available in one variation. > So of course that tiny USB dongle is the 'perfect' solution... one issue you'll have once you have added the wireless stuff is that the battery will be drained *much* faster... > There must be something COTS out there, I just haven't dug deep enough yet. > I'm thinking maybe wireless keyboard or mice if the intrinsic data > rate is high enough. > > Thanks again for all the helpful ideas and feedback. > Especially Olin. there are more things against 802.11 (or any radio links in that matter). first, 802.11 is very easy to completely obbliterate with a couple of 2.4 Ghz wireless phones then you have the problem of the dude sitting in the parking lot outside with a laptop and listening in to whatever occurs in your device, potentially mucking with it's data. so you need encryption, SSL ain't gonna be cheap by any means on a pic (don't even think it's doable) and you'll probably get a nice FDA shoot-down for this, as it would allow medical data to be aired for anyone to learn about... the only thing I'd see is transform your device into an compact-flash form-factor attachment for a wifi-enabled PDA (sharp zaurus comes to mind) that would do the data communication stuff, effectively raising the price of the stuff by 500 USD or so. now, the (star-trek fan) doc would prolly be positively impressed by the "tricorder"-looking contraption... but this ain't gonna fly financially... > Let's put this thread to bed, and I'll let you know what I ultimately > end up with. Probably looking for a new job. I think this is your best bet. Explain the above reasons in full length in your resignation letter > Robert Amaury ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ -- http://www.piclist.com hint: To leave the PICList RemoveMEpiclist-unsubscribe-requestTakeThisOuTmitvma.mit.edu

{Quote hidden}>-----Original Message----- >From: Robert Rolf [EraseMERobert.RolfUALBERTA.CA] >Sent: 11 January 2004 09:08 >To: RemoveMEPICLISTEraseMEEraseMEMITVMA.MIT.EDU >Subject: Re: [EE:] USB cable length. Evolution. Lack of testing > >Unfortunately Josh, that is exactly what my boss expects. The >people involved see all these cheap WI-FI USB dongles that >hang off USB ports, and figure that is should be "relatively >simple" to make it work with the current PIC hardware. In >other words, the want me to put a USB port on the unit so they >can plug in an 802.11 dongle. 'It's USB, right? It should just >-work-' I know better, but this is a collaboration with >another large group, and they have a lot of newly degreed >engineers (as well as some older ones, long since removed from >hands-on design) who know all about the 'lastest stuff'. But >since I don't have a degree, my experience/knowledge/skill means squat. > >The FTDI chips will certainly make basic hardwired USB comms >easy. The target user will have a laptop, and probably won't >have a real RS232 port today. It's the TCP/IP stack and Wi-Fi >handshaking that will be the killer if I can't convince them >it as bad an I idea as we all know it is. The FTDI chip do make basic USB comms easy, but only as a slave USB device. They will not be usefull for you to implement a USB master that you require to use other USB peripherals such as the wifi adapter. Mike ======================================================================= This e-mail is intended for the person it is addressed to only. The information contained in it may be confidential and/or protected by law. If you are not the intended recipient of this message, you must not make any use of this information, or copy or show it to any person. Please contact us immediately to tell us that you have received this e-mail, and return the original to us. Any use, forwarding, printing or copying of this message is strictly prohibited. No part of this message can be considered a request for goods or services. ======================================================================= Any questions about Bookham's E-Mail service should be directed to RemoveMEpostmasterspam_OUTKILLspambookham.com. -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads