> 1) latency on rx chars becomes very high because we can process > incoming transfers only after a full 8 byte (or whatever the spi > transfer dimension is). For a 9600 this is too much.
There I would partly disagree. Fixing the spi driver clearly makes sense but the serial driver should be batching better. Is there a reason the driver couldn't adjust the size based upon the tty speed when getting a termios request ? > 2) even worse is that we can do flow control decision only on such boundary. For serial flow control it doesn't matter, its implicitly asynchronous and if you only turn the fifo on at high speed you response time will be reasonably bounded. > 3) this is not reliable: think of what happens if the actual SPI > transfer speed we get will be slower that the one we requested. We > won't be emptying the RX buffer fastly enough even if could. Consoles are not usually balanced for I/O. I grant you probably don't want to be using full fifo sized blocks but I'm not sure I understand why there is a problem below that ? Alan ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
