RE: [ECOS] USB host mode support?

["Lewin A.R.W. Edwards" <larwe at larwe dot com>]

Hi Tim,

 >>I'm curious to know what kind of USB peripherals you think will be

 >Mostly wireless USB devices, the idea is still to keep the OS very small and
 >able to do some type of plugNPlay.  ie download a new OS if required.
 >Dynamic loading would be nice.

Hmm, I see. FWIW, the way we solved the need for wireless networking is to 
put Ethernet on the appliance and tell users to buy an 
Ethernet-to-wireless-flavor-of-the-month adapter. My experience as a 
consumer of a couple of appliances with host-side USB is that the 
instruction manual says "You can use the USB ports to plug in a mouse or 
external keyboard. At some stage, a future civilization with may develop a 
semi-working driver for one printer that will be obsolete by the time the 
driver for our proprietary OS becomes available", and in V1.001 of the 
device the port is left unpopulated due to lack of interest.

As Bart said, if you can specify exactly what people are going to plug in 
there, it's a bit different because you can build in your own drivers. 
(You're at the mercy of those other companies though - every time they 
update their product, you need new drivers). But you're probably not going 
to get Red Hat to write those drivers for you and put them into eCos - at 
least, not for free :)

 >I agree to some of the ideas of Linux, but the issue is we have a size 
issue.

What's your flash/ROM budget (actually, is it flash or ROM?) Can you store 
the OS compressed in flash/ROM and decompress it all to RAM? Can you get 
really funky and implement a compressed overlay type system where a small 
overlay manager is always in RAM, and the required code for whatever the 
user is doing is decompressed on-the-fly out of flash? (Works quite well 
with highly modal systems).

 >Yes, USB is a pain to support on the host side.  But as devices
 >become more internet and device aware this will become a requirement.

Your devices or devices in general? I don't think host-side USB is 
applicable to the vast majority of systems, simply because most embedded 
systems are either standalone appliances or peripherals, hence either no 
USB or slave-side USB.

Until a decent completely vendor-independent standard is evolved for the 
common case devices (serial, LAN, storage, &c) it simply won't be possible 
to implement true "plug and play" USB without proprietary drivers. To my 
knowledge, the only class of devices that can be implemented generically 
right now is the HID class, which means basically keyboards, mice and 
joysticks.

 From our understanding, Internet connectivity for an embedded appliance 
means Ethernet for the office environment, or one of a number of competing 
wireless protocols in the home environment.

 >Also, it is still me understanding most of the USB device support under
 >Linux must be compiled, therefore, as you add a new device you must 
recompile >the OS?

Much like the other poster, I haven't actually tried it as yet but in Linux 
many items can either be compiled into the kernel or dynamically loaded. 
You could keep your kernel size as small as possible and dyna-load the 
module for whatever pludule the user has poked at you.


I'm very interested in your comments because they touch on issues that we 
have discussed internally at my company in the past. I formed certain 
opinions, and it would be useful to compare these with the opinions of others.
=== Lewin A.R.W. Edwards (Embedded Engineer)
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/

"Und setzet ihr nicht das Leben ein,
Nie wird euch das Leben gewonnen sein."