RE: [ECOS] USB host mode support?

[tim at cygnetinc dot com (Tim Michals)]

Lewin,

>What's your flash/ROM budget
4M of ROM and 8M RAM.

Yes I agree with the issues of drivers for USB are a pain, because devices
are changing, no standards.

Question for you mentioned:
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.

So you have done this?

Yes, a true embedded LinuxOS maybe the way to go, but, I'm trying to avoid
this.  What would be my best embedded Linux for ARM?


Thanks



Tim

-----Original Message-----
From: Lewin A.R.W. Edwards [mailto:larwe@larwe.com]
Sent: Tuesday, February 20, 2001 9:40 AM
To: Tim Michals; ecos-discuss@sources.redhat.com
Subject: RE: [ECOS] USB host mode support?


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."