[iyonix-support] Re: Castles USB API

  • From: Dave Higton <davehigton@xxxxxxxxxxxxx>
  • To: iyonix-support@xxxxxxxxxxxxx
  • Date: Sat, 29 Mar 2008 22:31:34 GMT

In message <229f8d7e4f.Thomas@xxxxxxxxxxxxxxxxxxxxxxxxx>
          Thomas Milius <Thomas-Milius@xxxxxxxxxxx> wrote:

> In message <02cd146f4f.Thomas@xxxxxxxxxxxxxxxxxxxxxxxxx>
>           Thomas Milius <Thomas-Milius@xxxxxxxxxxx> wrote:
> 
> > In message <4f6ef5deadIan_Hamilton@xxxxxxxxxxxxxxxx>
> >           Ian Hamilton <Ian_Hamilton@xxxxxxxxxxxxxxxx> wrote:
> > 
> > > ...
> > > 
> > > I hope something above is useful.
> > > 
> > 
> > Many thanks for the hints. Sounds promising. I shall test during the next
> > days.
> > 
> 
> I played around with the hints unfortunately without success. I had to find
> out that the device requires 64 Bytes outout in every case. The first Byte
> has a special meaning. So implemented a block setup and if tracing the
> serial lines by an USB control command there is regular activity (including
> the serial reply pin) now.
> 
> So the Castle Stack tries to send the USB data out without flush as fast as
> it is available. That is fine.
> 
> I meanwhile found out that the device will send data on the bulk endpoint
> to the USB host (my Iyonix) every 16ms even there is no data on the serial
> RX line of the device. The problem is that I am not obtaining this 16ms
> dummy data. There is a special issue with this data and this might be the
> reason for my problems. The data will be two Bytes only and not 64 Bytes as
> usual. The USB Specification is not precise in this point whether such
> packages should be accepted in Bulk mode or not.
> 
> If I am opening the input channel with a size > 65 I am getting an
> IO-Error. If I am opening the input channel with a size <= 65 the program
> will wait for ever independently of a timeout or usbtimeout parameter.
> 
> I assume the following is happening:
> 
> For the first 64 Bytes the device will either send a NAK or reply with the
> 2 Bytes of data. For the next 64 Byte request in the same USB frame it will
> simply send a Stall. That is not real ok but yes I still have the ability
> to request only 64 Bytes per frame and in this case the data rate is so
> small that one 64 Byte package per Frame shall be enough.
> 
> In this case the device will either NAK the request or send the two Bytes
> and yes I fear that the Iyonix is not recognizing this as a valid response
> due to the unprecise USB specification and will simply just ignore it for
> ever.
> 
> I now had a look into the USB source which was just published by ROOL. And
> yes there is a flag for a connection to an endpoint which lets you control
> whether short packages (this is the name for packages which are having not
> the full size) are accepted or not. This is fine.
> 
> 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.

Dave
---
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: