On Wed, Oct 17, 2001 at 09:13:22AM -0700, David Hollister wrote: > > 1. In the generic serial case, why is there not a read() entry point in the > tty_driver struct? I realize this is off-topic for this list, but if > somebody has an answer, I'd sure like to know how incoming serial data gets > to its final destination in user-land.
Look at read_bulk_callback(). In there, the data received from the device is passed up to the tty layer with the call tty_insert_flip_char(). The tty layer buffers the data and sends it to the user process when read() is called on the /dev node. > 2. For USB serial, the original plan was to use an interrupt-in endpoint for > incoming serial data. This way, the driver could pick up whatever is > available within a reasonable timeframe. The application code could > reassemble the incoming data into meaningful messages as it sees fit. Either interrupt or bulk would work. Bulk is traditionally used as it can hold more data per frame than interrupt (I think, need to go check the specs on that one...) > Questions 1 and 2 tie together for question 3... > > 3. What would be the advantages or disadvantages to using the interrupt-in > endpoint instead of a bulk-in endpoint? Since I don't quite understand how > incoming serial data gets transmitted up anyway, I'm not sure what the > mechanism is for using a bulk-in endpoint. I see where URBs are submitted > in the open routine, then again in the read_bulk_callback routine. Is this > analagous to, say, a series of blocking read() calls? A bulk read urb is posted to the device when open() is called. Then any data received from the device is sent up to the tty layer, where it then gets passed to the device when read() is called. The driver doesn't ask the device for data when read() is called, as that is not the tty model. After data is received, the bulk read urb is then resubmitted. This is only one way to create a "serial" to USB interface. Other companies have come up with other protocols / methods, each one weighing different benefits. See the io_edgeport for an example of a very complicated protocol that relies on having a lot of processing power in the device itself. Because of this it achieves very high data throughput for multiple ports at the same time. The trade off there is the cost of the device :) A very simple (cheap) interface would be something like the "generic" interface, which does not care about flow control or line settings at all, and just uses 2 bulk endpoints to send data in both directions. I hope this helped. And if you need any help with a Linux driver for your device, or more questions about the usb-serial interface, please let me know. thanks, greg k-h _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
