On Sun, 22 Jul 2007, Alain Degreffe wrote: > Yes I know. > > In fact the device respond CMDERROR wich is more thant one byte > The command was just a simple RXCMD followed by a bulk_read 1 byte len, but > instead of giving a number between 0 and 255, The device send this string. > this mean that my command rxcdm is not supported by the device ( This > happens after some time... ) That's why I suspect and I think that the > polling spped is not well supported by the device... > > The sequence is normally: > > 1. sending RXCMD > 2. receiving 1 byte that give the len of data in the device buffer > If 2 = 0 back to step 1. > 3. receiving data with len = value from step 2 > 4. back to step 1
In step 3, does the data come over a bulk pipe? If it does, you can skip steps 1 and 2 entirely. Just go directly to step 3. > My problem happens suddenly at step 2 after some time ... (This sequence is > well supported during 10 to 60 seconds by fails after that...) > > So I repeat the question, may I slow down the polling ? Certainly; you can use a kernel timer. When the timer expires, submit the RXCMD URB. In the URB's completion routine, restart the timer. Be careful to avoid submitting after your disconnect() routine has returned. Alan Stern ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
