Hardware serial flow control signals (RTS/CTS), are seldom used in modern equipment which generally uses software flow control (XON/XOFF).
Having said that, A) When you DO need RTS/CTS you are screwed if you do NOT have those signals. B) RTS/CTS flow control indeed is far simpler at the software layer, since it is "out of band" signalling. My vote would be yes, try to support RTS/CTS even though it consumes precious i/o pins. Here's a pretty good resource. http://www.lammertbies.nl/comm/info/RS-232_flow_control.html I am showing my age by admitting to knowledge of this topic. RS-232 is *so* 1980s. ;) --- Ron K. Jeffries A curious fellow On Sun, Feb 6, 2011 at 11:10, Werner Almesberger <[email protected]> wrote: > David Kuehling wrote: >> will the Uart be usable with (non-inverted) TTL level interfaces, as >> present as debug port in many embedded designs (including the >> wikireader)? > > The current design operates at 3.3 V, like the rest of the Ben. It > should be able to drive most 5 V inputs. A 5 V output connected to > the UART board would inject a current of about 10-15 mA, which is > probably low enough not to cause trouble. (You could reduce this by > increasing R1.) > >> SW flow control can be used instead. Best would be if the corresponding >> code was part of the uart board firmware (and not part of the more >> latentcy-suffering linux driver). > > Hmm, maybe. In some cases, it may be desirable to be able to switch > flow control off entirely, in which case this would increase the > complexity of communication, because the TTY layer (i.e., the scary > part of Unix serial communication) would have to communicate the > change of flow control through the low-level driver. > >> Not that I demand that _you_ coded up a driver :) I guess a >> script-language (python/lua/forth?) test software would be sufficient to >> verify the spi interface works. > > I would do the proof-of-concept user space just in C. It's easy to > control the port pins. Scripting languages sometimes have problems > with such low-level things, and C also allows you to drive things > at the maximum speed the CPU is capable of, so you can find timing > issues you'd also have in the kernel. Here are some examples, in > increasing degree of complexity: > > http://projects.qi-hardware.com/index.php/p/ben-blinkenlights/source/tree/master/bbl/bbl.c > > http://projects.qi-hardware.com/index.php/p/f32xbase/source/tree/master/f32x/gpio-xburst.h > http://projects.qi-hardware.com/index.php/p/f32xbase/source/tree/master/f32x/gpio-xburst.c > > http://projects.qi-hardware.com/index.php/p/ben-wpan/source/tree/master/tools/lib/atben.c > > Important: before you try to take control of the 8:10 card, you need > to ask the kernel's MMC driver to step aside: > > echo jz4740-mmc.0 >/sys/bus/platform/drivers/jz4740-mmc/unbind > > I have an unfinished project that aims to provide some assistance > with obtaining/relinquishing access to the GPIOs: > > http://projects.qi-hardware.com/index.php/p/wernermisc/source/tree/master/libbb > > (Back when I did this, there was a kernel problem that prevented it > from working. This has been solved by now, but I haven't tried so > far to see if things work now and what else is needed. One item on > my post-wpan to do list :-) > > - Werner > > _______________________________________________ > Qi Hardware Discussion List > Mail to list (members only): [email protected] > Subscribe or Unsubscribe: > http://lists.en.qi-hardware.com/mailman/listinfo/discussion > _______________________________________________ Qi Hardware Discussion List Mail to list (members only): [email protected] Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion
