[iyonix-support] Re: Castles USB API
- From: Thomas Milius <Thomas-Milius@xxxxxxxxxxx>
- To: iyonix-support@xxxxxxxxxxxxx
- Date: Sun, 30 Mar 2008 11:11:57 +0200
In message <8ab1dd874f.davehigton@xxxxxxxxxxxxx>
Dave Higton <davehigton@xxxxxxxxxxxxx> wrote:
> In message <229f8d7e4f.Thomas@xxxxxxxxxxxxxxxxxxxxxxxxx>
> Thomas Milius <Thomas-Milius@xxxxxxxxxxx> wrote:
>
> > In message <02cd146f4f.Thomas@xxxxxxxxxxxxxxxxxxxxxxxxx>
> > Thomas Milius <Thomas-Milius@xxxxxxxxxxx> wrote:
> >
> ...
> > But now my questions are:
> >
> > How can I influence this flag for a given USB connection to a certain
> > endpoint?
> >
> > Does anyone know whether short packages at bulk transfers in default are
> > accepted or rejected?
>
> I can't remember whether there was any further correspondence on
> this topic. I apologise for not answering before.
>
> Bulk transfers are difficult. You have to know that a transfer
> is needed, and you have to know the exact size in advance. If
> you request a transfer and the device doesn't have any data to
> transfer, the Castle USB stack at least will wait until the device
> has data, or indefinitely if it doesn't. (As an aside, this makes
> the choice of Bulk for USB MIDI ludicrous. But that's what they
> went for.)
>
> Perhaps you have to request 2 bytes every 16 ms, and, if the bytes
> show that more data are ready, request the other 62 bytes.
>
Many thanks for the information. Unfortunately I can't do this. I am trying
to talk to my OBD device which contains one of the popular serial to USB
converters of FTDI inbuild.
The format of the FTDI is a bit special. It is a mixture of interrupt and
bulk, even the incoming endpooint is of bulk type. The FTDI collects all
serial data and transmits 64 Bytes (2 Status Bytes containing the state of
the serial line and 62 byte received serial data) in case that 62 Bytes have
been received over the serial line.
It also transmits fewer bytes in case that the serial control lines are
changing or a programmable timer will expire. In worst case it only tells you
the 2 Status Bytes every 16 ms if you are polling the bus. (I didn't found a
hint what is happening to the Bytes in case you are not polling but I assume
that they are simply ignored).
I didn't get the device working under my Iyonix until now and your remarks
above sounds like this is not possible. I exspected this meanwhile :-(.
However the FTDI chips are very popular and used inside may be one hundred
USB devices so it is worth to spent some time on it to write a driver for the
chips in general. I shall do so. Because Castles USB source are now open at
ROOL there is in general a chance to do so. However ROOL made a small mistake
at the publishing. One library is still missing in the moment so I can't
recompile the stack :-(. But I am sure that this will change during the next
weeks/months :-).
The problem is that the USB specification isn't precise about the handling of
short packages in bulk mode. So you can't say the Castles Stack is not
correct. In my opinion the problem is on the side of the device. However it
is widely used. The NetBSD-Base of Castles USB stack seems to able to cope
with this packages but needs a certain flag to be set.
My idea is to modify the Castle USB interface by two parameters if
opening the USB file stream (must be checked in detail, whether it is
possible and correct):
- shortpackage. Will allow to receive such packages by setting the according
NetBSD flag.
- notelength. Will insert one byte into the buffer containing the length
of the received data at the beginning of every received data package.
In worst case this might be zero in case of zero length short packages.
It won't be entered in case that no package is received. The device drvier
has to puzzle out this information.
This would allow you to cope with such devices too, it is backward compatible
and I assume that it won't be much work to implement it.
Best Regards
Thomas Milius
---
To alter your preferences or leave the group,
visit //www.freelists.org/list/iyonix-support
Other info via //www.freelists.org/webpage/iyonix-support
Other related posts:
