Skip site navigation (1)Skip section navigation (2) 
Date:      Tue, 17 May 2016 11:53:54 -0500
From:      Karl Denninger <karl@denninger.net>
To:        freebsd-usb@freebsd.org
Subject:   Oddity with ugen
Message-ID:  <b24c5a9a-cb18-c014-75ab-9b923853a70c@denninger.net>
next in thread | raw e-mail | index | archive | help 

[-- Attachment #1 --]
Consider the following snippet of code....

                sprintf(tmp, "/dev/usb/0.%d.1", x); /* Get input handle */
                _i = open(tmp, O_RDONLY|O_NDELAY);  /* Open it */
                if (_i < 0) {
                    syslog(LOG_WARNING, "Error opening USB input channel
(%d)", errno);
                } else {
                    y = 8;  /* Set buffer size */
                    if (ioctl(_i, USB_SET_RX_BUFFER_SIZE, &y) < 0) {
                        syslog(LOG_WARNING, "Error setting USB buffer");
                    }
                    y = 0;  /* Set timeout */
                    if (ioctl(_i, USB_SET_RX_TIMEOUT, &y) < 0) {
                        syslog(LOG_WARNING, "Error setting USB timeout
to zero")
;
                    }
                    y = 1;  /* Set short xfer ok */
                    if (ioctl(_i, USB_SET_RX_SHORT_XFER, &y) < 0) {
                        syslog(LOG_WARNING, "Error setting USB short XFER");
                    }
                }
                sprintf(tmp, "/dev/usb/0.%d.2", x); /* Get output handle */
                _o = open(tmp, O_WRONLY);   /* Open it */
                if (_o < 0) {
                    syslog(LOG_WARNING, "Error opening USB output
channel (%d)", errno);
                } else {
                    y = 8;  /* Set buffer size; low-speed device */
                    if (ioctl(_o, USB_SET_TX_BUFFER_SIZE, &y) < 0) {
                        syslog(LOG_WARNING, "Error setting USB TX buffer");
                    }
                    y = 0;  /* Set timeout */
                    if (ioctl(_o, USB_SET_TX_TIMEOUT, &y) < 0) {
                        syslog(LOG_WARNING, "Error setting USB TX timeout");
                    }
                }
              

Ok, we now have two open handles (we have previously ascertained that
the correct device is at the instance in question ("x") by checking its
vendor number, and we know it has two endpoints, one for input and one
for output.  We also know it is a low-speed device and thus
theoretically is limited to 8-character buffering.

So we start reading and writing and it mostly works. select() works on
the filehandles to know if we can read or write as expected, etc.

The format from the device is in the general form of a preamble byte
that is a flag, a length byte (for most of the preambles) and then up to
six bytes of data.  I read the data into a buffer (so if I get more than
one packet, or a packet and a part of a second one I'm ok) and then
whenever a read succeeds I parse through the buffer and empty it of
anything that's complete.

This is working reasonable well...... except for one problem.

Sometimes, without warning, select() will return a ready on the input
file handle and when you read you get the *last* packet of data you read
back.  You read it, you select() again, you get the same packet of data
again and again.  This can and does go on for a *long* time (sometimes
minutes!) but it does eventually clear on its own.  I *suspect* the
device itself is not actually re-sending the data, but it might be -- I
have no good way to be sure that I'm aware of.

In other words I get something like this:

select() returns ready on _i
bytes = read(_i, buffer, 8);

Buffer contains 4 bytes (and bytes = 4):  0x50, 0x02, 0x01, 0x04

select() once again returns ready on _i immediately (no delay)
bytes = read(_i, buffer, 8);

Buffer contains the same four bytes and bytes = 4 again, as if the
read() did not empty the buffer but read it and left the buffer contents
*and count* alone.

If this is a condition of some sort in the device or driver I've not
been able to figure out what it is, or how to force it to clear -- or to
prove whether it's in the device or the ugen driver.

Any ideas?

-- 
Karl Denninger
karl@denninger.net <mailto:karl@denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/

[-- Attachment #2 --]
0	*H
010
	`He0	*H
_0[0C)0
	*H
010	UUS10UFlorida10U	Niceville10U
Cuda Systems LLC10UCuda Systems LLC CA1"0 	*H
	Cuda Systems LLC CA0
150421022159Z
200419022159Z0Z10	UUS10UFlorida10U
Cuda Systems LLC10UKarl Denninger (OCSP)0"0
	*H
0
X@vkY
Tq/vE]5#֯MX\8LJ/V?5Da+
sJc*/r{ȼnS+w")ąZ^DtdCOZ ~7Q '@a#ijc۴oZdB&!Ӝ-<	?HN5y
5}F|ef゘"Vلio74zn">a1qWuɖbFeGE&3(KhixG3!#e_XƬϜ/,$+;4y'Bz<qT9_?rRUpn5
Jn&Rx/p Jyel*pN8/#9u/YPEC)TY>~/˘N[vyiDKˉ,^" ?$T8v&K%z8C @?K{9f`+@,|Mbia007++0)0'+0http://cudasystems.net:88880	U00	`HB0U0,	`HB
OpenSSL Generated Certificate0U-h\Ff Y0U#0$q}ݽʒm50U0karl@denninger.net0
	*H
Owbabɺx&Uk[(Oj!%pMQ0I!#QH}.>~2&D}<wm_>V6v]f>=Nn+8;q wfΰ/RLyUG#b}n!Dր_up|_ǰc/%ۥ
nN8:d;-UJd/m1~VނיnN I˾$tF1&}|?q?\đXԑ&\4V<lKۮ3%Am_(q-(cAeGX)f}-˥6cv~Kg8m~v;|9:-iAPқ6ېn-.)<[$KJtt/L4ᖣ^Cmu4vb{+BG$M0c\[MR|0FԸP&78"4p#}DZ9;V9#>Sw"[UP7100010	UUS10UFlorida10U	Niceville10U
Cuda Systems LLC10UCuda Systems LLC CA1"0 	*H
	Cuda Systems LLC CA)0
	`HeM0	*H
	1	*H
0	*H
	1
160517165354Z0O	*H
	1B@GlMKYl7-N.dfHH&ᣄczaa&쯵Ho0l	*H
	1_0]0	`He*0	`He0
*H
0*H
0
*H
@0+0
*H
(0	+710010	UUS10UFlorida10U	Niceville10U
Cuda Systems LLC10UCuda Systems LLC CA1"0 	*H
	Cuda Systems LLC CA)0*H
	1010	UUS10UFlorida10U	Niceville10U
Cuda Systems LLC10UCuda Systems LLC CA1"0 	*H
	Cuda Systems LLC CA)0
	*H
i}m)Nd_[KYDXs4z=|?{^E1MOr\*X(L<%/\(\^MZRSlLP3/γW҈CB8b·,T.~B*mX&^߈pjg/YUhH,K+
TS6ޞ3j*sGJ)pvEO+w/)	m~S`}[5^
J-&il	0AhآCim$wDƗ)}3F]A ]UL홋@T193̯(".09k/2]_pPr+U+
E}+6<ˣƊIGRSGs-d~v4@o;GjH!Q*J:jK<(7^y61Fe*C~A?ഔhɜFWqqnu`B

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b24c5a9a-cb18-c014-75ab-9b923853a70c>