>>>>> "Werner" == Werner Almesberger <[email protected]> writes:
> 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.) But is it inverted or not? TTL-level RS232 is non-inverted (1=3V, 0=0V), while standard PC serial ports are inverted (1=-5V, 0=5V), with a switching threshold that might luckily be around +0.3 V (plus some hysteresis) to work with your board. Would one have to select this via some kernel options? >> 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. This is approximately what I had in mind. Your board reminds me off a single-chip USB-UART bridge, where the chip usually handles buffering and (optionally) flow control and bursts rather large amounts of coalesced data over the usb bus. In that case the corresponding linux drivers only communicate flow control settings down to the chip control regs (somewhat in my imagination, didn't have a very close look on this stuff for some time). >> 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: I dislike the compile-upload-run overhead involved with doing C-programming with cross-compilers. But that probably depends on the tools and scripts one uses. But then I guess user-space C programming is still much more fun than trying to debug a kernel module :) Thanks also for all the other details about mmc-port unbind etc. Might be handy the next time I try to control hardware via my Ben. I'd really like to help w/ the kernel driver, but I think I'm too swamped with work for at least another two months. The easiest approach *might* be to just copy from the existing mmc-uart Linux driver. Or, other idea: would it be possible to implement the mmc-uart protocol on the controller side, so Linux would work out-of-the-box ? cheers, David -- GnuPG public key: http://user.cs.tu-berlin.de/~dvdkhlng/dk.gpg Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40
pgpb0UnWiVmZn.pgp
Description: PGP signature
_______________________________________________ Qi Hardware Discussion List Mail to list (members only): [email protected] Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion
