> > > 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 listserv@mitvma.mit.edu with SET PICList DIGEST in the body