USB as product-internal interconnect system?

I can't answer any of your questions directly, but I'm involved in a product design that uses IEEE-1394 internally and it appears that it's going to be quite successful.

So in principal you should do just fine.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Reply to
Tim Wescott
Loading thread data ...

They're getting much cheaper. Cypress has a USB host microcontroller that -- while full of silicon bugs :-( -- seems to get a lot of use and is in the 'some low dollars per' range pricewise. The microcontroller isn't nearly powerful enough to be a general purpose host, but appears to be usable when a very specific type of device is the only kind that will be connected, e.g., memory cards, USB serial class devices, etc.

At Wal*Mart you can get a cigarette lighter dongle that has a little FM transmitter in it and a USB connector. You stick a regular old USB memory card into the thing and it plays back your MP3 files over FM... all for $24.95. I didn't get one, but I'm curious just how 'compatible' it is with various memory cards, since for that price they must be using an approach with not much more power than Cypress', and I'm told that some USB memory cards (such as some from Sony) contain embedded hubs, which I'd guess would be too complex for such a unit to use (i.e., it's not smart enough to be able to enumerate through the hub).

---Joel Kolstad

Reply to
Joel Kolstad

I'm designing a product that includes a number of interchangable boards that give various capabilities, each with its own small microcontroller and sensors/actuators. Any modules in a system would be connected to a more powerful main board (basically the reference design of a PDA). It must be easy for the user to open the box and plug in new modules, or plug them into sites on the outside, and also for third parties to provide modules that also plug in.

I was designing my own interconnect standard that included power and bidirectional data lines (ideally at least1mbps), maybe based on RS485, and a way for devices to announce their type and capabilities. As I worked on the design I started to realize I was reinventing USB. I've been looking at the details of USB, and it certainly does all I need and more.

Also, fortunately, the central processor board is based on a PDA that has a USB host capability (and HID driver, which my modules could use), and I could use small USB enabled processors in the modules. I guess I'd also have to provide a hub based on one of the available hub chips.

I was hoping this group could give me a sanity check before I proceed to design a system based on USB.

- Is anyone aware of other products using USB in this way?

- Any other approaches to plug-and-play or mix-and-match smart modules in a system?

- To keep the costs down I would not want to use standard USB connectors internally - just headers (but still shielded cable). It this likely to cause EMI problems? I would have to use the 12mbps version of USB to keep latency low.

Thanks for reading all the way to the end :-)

- Chris Graham

Reply to
Chris Graham

connectors

to

Laptops routinely use USB as an internal interconnect, particularly for WLAN cards and for built-in flash memory readers. They generally seem to use 2mm pitch pin headers on the PCB and rather thin shielded cable (similar to the type of cable used for off-the-shelf CD-ROM audio cables).

Reply to
larwe

Unfortunately, AIUI, there are no really cheap solutions to providing a USB host, you pretty much need a fairly powerfull micro in order to talk to the USB controller chip. USB peripherals can be $0.99 and below.

Reply to
Ian Stirling

formatting link

Seems I may be wrong, I last looked a fair few months ago. I don't know how much above device is (awaiting quote).

Linux + host controller seems a usefull match, as you don't have to write code for several dozen devices, they just (more or less) work. Then again, there is the fact that linux may be a poor match for some things you'd like to do.

Reply to
Ian Stirling

One big caveat, could be that USB, does not have a timeout in the drivers. If a command is sent to a device, that the system 'knows' is there, and a reply is expected, the system can hang waiting for a reply. This becomes more likely, as noise levels and cable lengths increase. You would either have to write your own master handler, and add such protection, or add a hardware watchdog to all the devices (including the master). Personally, if the system is mant to be reliable, I'd consider Ethernet. Easy to implement, has built in error checking, better signal protection on the lines etc. etc..

Best Wishes

Reply to
Roger Hamlett

I work with a company that is developing a linux based PDA-like reference design based on the TI OMAP ARM/DSP processor that includes USB hosting and an HID driver (human/computer interface devices). It also has a touch screen, and everything else a state of the art PDA has.

I'm intending to use this as the embedded host processor, so the availability of USB would almost be free, except for providing an embedded hub.

This isn't cheap, but is within the cost parameters of my product. (Which is not really a PDA, but is a smart modular device - actually a family of modular musical instruments.)

- Chris

Reply to
Chris Graham

Excellent! I assumed that might be the case, but I wasn't sure. (I'm more of a software guy than a hardware guy)

That interconnect system would be ideal for my design.

- Chris

Reply to
Chris Graham

Please let us know how much they are.

Reply to
Guy Macon

....

Look here:

formatting link

--
Guy Macon
Reply to
Guy Macon

Besides debates on the merits of USB for this purpose, are there other, maybe more fitting, serial interconnect standard? Seems to be enough of them. Like CANBUS

Reply to
Brian

I'd take a hotplug controller for the power and perhaps LVDS for the unidirectional data channels.

Rene

--
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net
Reply to
Rene Tschaggelar

USB is strictly a polled bus, so while your device may not have sent back any data yet (effectively hanging), it MUST be sitting there sending back 'NAK' packets or the lower level bus drivers will fail your I/O request.

The same can't be said for I2C, RS-232, PCI, Ethernet, etc.! (And while I'm personally haven't traditionally been a big fan of polled busses, USB somewhat sold me on the concept...)

Having the polling done at the hardware level rather than having to do it in software is convenient. Realistically, the only way a USB bus hangs is due to buggy/crashing devices -- NOT due to line noise problems, device removal, etc. Those are all elegantly handled by the system.

If you're programming at the TCP/IP level, this makes sense (since even though Ethernet can't detect device removal, the TCP/IP stack will time out sooner or later...).

---Joel

Reply to
Joel Kolstad

Will do. Currently leaving email program to download 3000 spams :/

Reply to
Ian Stirling

No response as of yet, maybe after the weekend.

Reply to
Ian Stirling

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.