On Tue 26 Feb 2008 14:18, Russell King pondered: > On Tue, Feb 26, 2008 at 01:21:18PM -0500, Robin Getz wrote: > > On Tue 26 Feb 2008 12:11, Russell King pondered: > > > On Tue, Feb 26, 2008 at 11:11:58AM -0500, Robin Getz wrote: > > > > ping. > > > > > > > > Comments appreciated. > > > > > > ascii-xfr does inter-line and inter-character delays without > > > requiring any kernel modifications - used it with some dumb boot > > > loaders which required 'mem deposit <address> <word>' to be sent > > > slowly to the target. > > > > Thanks for the pointer. > > > > Solving the problem in userspace (with tcdrain and udelay) when some > > hardware can do the same thing with zero overhead - doesn't seem like > > the most efficient way to do things.... > > I know of no serial hardware which can insert arbitary delays inbetween > characters. In the original message I sent: > Some hardware manufactures have seen this need, and added it to their UART > controllers - Atmel's AT32AP7000 has added this and called it a > "Timeguard" (Don't ask me why). The "timeguard delay" is controlled between > 0 and 255 Bit Periods. > > http://www.atmel.com/dyn/resources/prod_documents/doc32003.pdf Others have done the same - more will be doing soon - it is pretty trivial in the hardware (counter which extends the stop bit, and a 8-bit register). > > It also lacks the ability to work with pre-existing user space > > applications. > > So one could say those applications are buggy. I'm not sure I understand - existing applications which don't support the overhead of doing everything in userspace are buggy? Which means that if you want to be able to receive console messages on these older serial terminals - we need to put the delay in printk, rather than the serial driver? -Robin - To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
