On Mon, 21 May 2007 00:11:58 +0100 Bryan O'Donoghue bodonoghue@codehermit.ie wrote:
On Mon, 21 May 2007 00:23:42 +0200 Rodolfo Giometti giometti@enneenne.com wrote:
The problem is that the defice __is__ into configured state (USB cable is connected and /dev/ttyUSB0 is running) but nobody has opened the serial line (no minicom/kermit running).
So, I suppose, the above modification is useless...
For some reason I seem to fail to parse English occasionally I thought you'd said your device was in the configured state but, not physically connected to the HOST ! oops !
You are of course right checking for state configured would not fix your stall problem if the cable is connected to your PC but, this pseudo-code below would be a better improvement still... since we wouldn't even bother _trying_ to send unless the bus was in the configured state... which is what my warped mind was in fact attempting to get at.
if(data && state == STATE_CONFIGURED && retries < 10000L){ /* Blah */ }
You're still wrong about not having to deal with EP0 control requests after host enumeration, though. g_serial might let you away with it but, that's just g_serial's oddities I guess. There's no reason a host couldn't or wouldn't send you periodic get_status requests using g_serial or any other high level USB protocol and so theoretically if you don't respond to EP0 control requests the host can reset you ! I doubt any other driver then g_serial would let you away with this either !
I still think the fix is #1 above but, having re-read your email
#2 If on TX timeout you propagate an error code upwards to write_buffer, it should be sufficient I think. write_buffer should be smart enough to retry tx on the data that didn't get sent and eventually the __puts() function itself should just give-up !