Tcl and USB
Peter Hiscocks
instrument GUI on a PC, via the serial port. This works well, but we're
considering migrating to USB.
Ideally, there would be some way to communicate via USB to a National
Semiconductor USBN9602 USB chip, and send information from the Tk gui to and
from the various registers (endpoints) on that chip.
I've looked at Dejanews for discussions on Tcl and USB, and it seems as if
there is currently no general purpose way to do this from Tcl on both the
Windows and Linux platform.
Some mention is made in Dejanews of a driver that makes the USB look like a
COM port. Is this generally available? If so, can anyone suggest a pointer
to information about it?
Failing that, am I correct in assuming that we'd have to write the USB
driver to do this?
Thanks -
Peter
--
Peter D. Hiscocks
Department of Electrical and Computer Engineering
Ryerson University,
350 Victoria Street,
Toronto, Ontario, M5B 2K3, Canada
Phone: (416) 979-5000 Ext 6109
Fax: (416) 979-5280
Email: phis...@ee.ryerson.ca
URL: http://www.ee.ryerson.ca/~phiscock
David Gravereaux
>Some mention is made in Dejanews of a driver that makes the USB look like a
>COM port. Is this generally available? If so, can anyone suggest a pointer
>to information about it?
Many USB devices can act as a com port. USB modems for example. This is done
in their drivers and doesn't require any special work to Tcl.
>Failing that, am I correct in assuming that we'd have to write the USB
>driver to do this?
Maybe the other way, though. You might have to write a Tcl style channel driver
to access the public functions the driver provides at the application level.
The winsock channel driver might be the best example to start from
(tclWinSock.c). It's big, but not as big as the pipe channel driver. It could
even be a Tcl extension and not require a patch to the core.
--
David Gravereaux <davy...@pobox.com>
Tomasoft Engineering, Hayward, CA
[species: human; planet: earth,milkyway,alpha sector]
Cameron Laird
David Gravereaux <davy...@pobox.com> wrote:
>Peter Hiscocks <phis...@pascal.ee.ryerson.ca> wrote:
>
>>Some mention is made in Dejanews of a driver that makes the USB look like a
>>COM port. Is this generally available? If so, can anyone suggest a pointer
>>to information about it?
>
>Many USB devices can act as a com port. USB modems for example. This is done
>in their drivers and doesn't require any special work to Tcl.
>
>>Failing that, am I correct in assuming that we'd have to write the USB
>>driver to do this?
>
>Maybe the other way, though. You might have to write a Tcl style channel driver
>to access the public functions the driver provides at the application level.
>The winsock channel driver might be the best example to start from
>(tclWinSock.c). It's big, but not as big as the pipe channel driver. It could
>even be a Tcl extension and not require a patch to the core.
.
.
... or you could hire someone like David or
ActiveState to work out an implementation.
Their deep experience with channels and such
likely makes them far more productive at this
sort of work than you can be on short notice.
--
Cameron Laird <Cam...@Lairds.com>
Business: http://www.Phaseit.net
Personal: http://starbase.neosoft.com/~claird/home.html
David Gravereaux
Yes, it does lean toward the advanced side. I remember looking at USB concepts
a ways back. On windows, the bus isn't intended to be available to applications
-- just the devices on the bus. I think it might be the responsibility of the
author of the USB endpoint device driver to provide the public interface at the
C level. This way, the application using the hardware doesn't have to know the
binary protocol for "extend grabber arm" just call ExtendGrabberArm(deviceId,
distance); or whatever it is..
From Tcl, you might want to call that with an fconfigure like this:
set chan [myUSB $data1 $data2 $data3]
fileevent readable $chan ....
fconfigure $chan -extendgrabber 43.267
But if the hardware isn't really stream oriented, a Tcl channel driver might not
be needed and could be action oriented like this:
set device1 [myUSB new $bus $id]
myUSB $device1 extendgrabber 43.267
set positionMatrix [myUSB $device1 getlocations]
Even without streams a Tcl channel driver model provides, you can still do
asynchronous callbacks with Tcl_AsyncMark()/Tcl_QueueEvent().
Peter Hiscocks
was my original impression. I think we'll just stick to the serial port.
(Low speed USB isn't that much faster anyway, when you factor out all the
overhead.)
Peter
Peter Hiscocks <phis...@pascal.ee.ryerson.ca> wrote:
: We have an application where we talk to hardware from a Tcl/Tk virtual
Tom Wilkason
news:ao2t3v$lp2$1...@ns2.ryerson.ca...
> Well, thanks for the suggestions, but it all sounds a bit daunting, which
> was my original impression. I think we'll just stick to the serial port.
> (Low speed USB isn't that much faster anyway, when you factor out all the
> overhead.)
>
> Peter
>
>
>
> Peter Hiscocks <phis...@pascal.ee.ryerson.ca> wrote:
> : We have an application where we talk to hardware from a Tcl/Tk virtual
> : instrument GUI on a PC, via the serial port. This works well, but we're
> : considering migrating to USB.
>
> : Ideally, there would be some way to communicate via USB to a National
> : Semiconductor USBN9602 USB chip, and send information from the Tk gui to
and
> : from the various registers (endpoints) on that chip.
>
No sure of your specific interface, but take a look at
http://www.ftdichip.com/, they have some low-cost products we have used with
Tcl that use the USB port to connect to legacy devices such as RS-232 or
parallel I/O. Their drivers work just fine with the Tcl channel interface.
Tom Wilkason