Re: Control ofUSB devices
- From: Daniel Platt <DanP57@xxxxxxxxxxxxx>
- Date: Thu, 08 Nov 2007 16:26:09 -0500
Richard Maine wrote:
Rich Townsend <rhdt@xxxxxxxxxxxxxxxxxxx> wrote:
You're assuming here that Terence is using a Mac. In fact, I believe he is a
Windows fellow.
Yes. It is fairly common for Windows folk (including Terence) to give
Windows-specific advice without giving as much as a hint of it being
Windows-specific, even when the problem statement specifically cites
some other operating system. I was amused and almost wondered whether
this reply was intentionally meant as humorous "turnabout". Probably
not, I suppose. The "apple.com" in the URLs is a bit of a hint.
The "turnabout" was indeed a *bit* intentional. But the question was interesting to me, so I took it seriously enough to look up the info, and, regardless of the apple specifics, do point in the correct general direction for unix-like systems (ie, ioctl, fcntl).
If CYGWIN is a part of this discussion, I found:
http://www.pololu.com/projects/prj0003/
http://sourceforge.net/project/shownotes.php?release_id=195978&group_id=46487
http://cygwin.com/cygwin-ug-net/using-specialnames.html#id4729483
Admitedly, the introductions of the cited docs do give a pretty good
overview of the generalities, even though the specifics quickly get Mac
specific (with some elements of more general Unix applicability such as
the ioctl stuff).
I think what Terence needs is a driver for his USB devices, that hides all
of the details of the USB protocol (which are far removed from simple
RS232) behind a standard virtual serial interface. I imagine the
manufacturers of his devices are the place to look for such drivers.
This is really the best starting place. I'd found some situations where ioctl() calls were important simply to configure the /dev/ttyS0 (or equiv) devices on other systems, but in this case, it would be talking to the DRIVER about the usb-mounted com port.
Yes. Note that some USB device manufacturers consider their
communication protocols to be proprietary and won't give you any
information other than about the API to their drivers. This can be
annoying.
Garmin comes to mind from personal experience. An annoying consequence
that I've personally seen relates to my Garmin GPS, which has both USB
and serial ports. My Mac laptop that I used to take on trips had USB
ports, but no serial ones. You'd think then that the obvious thing to do
would be to use the USB port on the GPS. Nope, didn't work because
Garmin didn't support Macs (this is slowly changing) and their USB
protocol was proprietary. Their serial protocol followed some
GPS-related standard whose name I don't recall without looking it up.
Thus you could make things work by using the serial port on the GPS, a
3rd party (Keyspan) serial-to-usb adaptor, and going into the usb port
on the Mac. It made for a mess of cables and boxes - not very convenient
for travel. The silliness was compounded when I wanted to use some
Windows software running in Virtual PC (it was a PPC Mac). The only way
to do that involved another step of usb/serial masquerading. It worked,
but Rube Goldberg would have been proud.
Did that for a while with my GPS -- then found my USB com port did not have the drivers for the new intel Macs... so sad.
Dan
.
- References:
- Control ofUSB devices
- From: Terence
- Re: Control ofUSB devices
- From: Daniel Platt
- Re: Control ofUSB devices
- From: Rich Townsend
- Re: Control ofUSB devices
- From: Richard Maine
- Control ofUSB devices
- Prev by Date: Re: reading two separate files
- Next by Date: Re: dynamic allocation doubt
- Previous by thread: Re: Control ofUSB devices
- Next by thread: Re: Control ofUSB devices
- Index(es):
Relevant Pages
|
