Am Donnerstag 19 Juli 2007 schrieb Alain Degreffe:
> I have a newbie question :-)
> 
> I would like to have to threads: 1 reading process and one writing
> process...
> 
> For the moment as soon I write to device, I begin to read the answer but it
> is not very efficient because the iso7816 don't give a real way to know if
> the write is finish or if the read will give an answer...
> 
> In the usb-serial classical implementation, the bulk read return all
> incoming characters and the callback function permit to write those
> characters into the tty device. In my case, the problem is the next one: to
> read character I must send a command to the device with a bulk write.. In
> the read call back, may I use the port stored in the context to call a bul
> write function to ask to the device to read ?

Yes, this no problem. You may submit URBs from a callback handler.
Just use GFP_ATOMIC.

> Second problem, the protocol of the device works like this: To read
> character, I must ( as I said before ) , send a command to read ( a bulk
> write message ) , after try to read one byte to know how much byte are
> waiting in the device buffer and finally bulk read the len given at the
> previous step...
> 
> So ideally, a thread dedicated to this sequence is the solution to the
> latency observed in the current implementation ( the smart routine is not
> magic and the cases to stop waiting are limited ) because the function wait
> during 200 round to be sure to read all datas...

A kernel thread is overkill for that.

You could use something like:

1. Send command via bulk
2. In callback of 1 - read the length byte
3. In callback of 2 - read data bytes
4. In callback of 3 - feed data to the tty layer

What exactly do you mean by command?
Does your device reply only when spoken to? In this case you can trigger
the sequence I described above in your write() method. If the device can send
data on its own, 4 should do also 1.

        Regards
                Oliver

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to