* Inter-Character Delay
@ 2008-02-18 18:36 Robin Getz
2008-02-26 16:11 ` Robin Getz
2008-02-26 20:59 ` Chris Doré
0 siblings, 2 replies; 9+ messages in thread
From: Robin Getz @ 2008-02-18 18:36 UTC (permalink / raw)
To: linux-serial
It is quite common on many industrial serial devices which do not support
either software or hardware flow control to require a Inter-Character delay
longer than than the standard one, one and a half, or two stop bits.
A device where this long inter character delay is required are devices like
Point of Sale terminals, and devices that are talking to Modbus (Honeywell
SI-FTA implements a check on the inter-character gap).
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
I think I have seen similar things for some ARM devices, and other embedded
architectures. Today, we have done similar things in the driver (on hardware
that doesn't support it natively).
I'm not sure that bit periods are the best way to measure things, or
milliseconds. I guess it really doesn't matter, as long as everyone does it
the same way - which brings me to my next question:
Does anyone have a good idea of a standard way to expose this to userspace?
- grabbing 8 bits in the termios_p c_oflag isn't going to fit
- adding a new field in the termios structure seems like overkill
- adding backdoor ioctls for serial drivers seems like a bad idea.
Thoughts?
Thanks
-Robin
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Inter-Character Delay
2008-02-18 18:36 Inter-Character Delay Robin Getz
@ 2008-02-26 16:11 ` Robin Getz
2008-02-26 17:11 ` Russell King
2008-02-26 20:59 ` Chris Doré
1 sibling, 1 reply; 9+ messages in thread
From: Robin Getz @ 2008-02-26 16:11 UTC (permalink / raw)
To: Russell King, Alan Cox, Haavard Skinnemoen; +Cc: linux-serial
On Mon 18 Feb 2008 13:36, Robin Getz pondered:
> It is quite common on many industrial serial devices which do not
> support either software or hardware flow control to require a
> Inter-Character delay longer than than the standard one, one and a
> half, or two stop bits.
>
> A device where this long inter character delay is required are devices
> like Point of Sale terminals, and devices that are talking to Modbus
> (Honeywell SI-FTA implements a check on the inter-character gap).
>
> 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
>
> I think I have seen similar things for some ARM devices, and other
> embedded architectures. Today, we have done similar things in the driver
> (on hardware that doesn't support it natively).
>
> I'm not sure that bit periods are the best way to measure things, or
> milliseconds. I guess it really doesn't matter, as long as everyone does
> it the same way - which brings me to my next question:
>
> Does anyone have a good idea of a standard way to expose this to
> userspace?
> - grabbing 8 bits in the termios_p c_oflag isn't going to fit
> - adding a new field in the termios structure seems like overkill
> - adding backdoor ioctls for serial drivers seems like a bad idea.
>
> Thoughts?
ping.
Comments appreciated.
-Robin
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Inter-Character Delay
2008-02-26 16:11 ` Robin Getz
@ 2008-02-26 17:11 ` Russell King
2008-02-26 18:21 ` Robin Getz
0 siblings, 1 reply; 9+ messages in thread
From: Russell King @ 2008-02-26 17:11 UTC (permalink / raw)
To: Robin Getz; +Cc: Alan Cox, Haavard Skinnemoen, linux-serial
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.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Inter-Character Delay
2008-02-26 17:11 ` Russell King
@ 2008-02-26 18:21 ` Robin Getz
2008-02-26 19:18 ` Russell King
0 siblings, 1 reply; 9+ messages in thread
From: Robin Getz @ 2008-02-26 18:21 UTC (permalink / raw)
To: Russell King; +Cc: Alan Cox, Haavard Skinnemoen, linux-serial
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....
It also lacks the ability to work with pre-existing user space applications.
-Robin
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Inter-Character Delay
2008-02-26 18:21 ` Robin Getz
@ 2008-02-26 19:18 ` Russell King
2008-02-26 20:10 ` Robin Getz
0 siblings, 1 reply; 9+ messages in thread
From: Russell King @ 2008-02-26 19:18 UTC (permalink / raw)
To: Robin Getz; +Cc: Alan Cox, Haavard Skinnemoen, linux-serial
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.
> It also lacks the ability to work with pre-existing user space
> applications.
So one could say those applications are buggy.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Inter-Character Delay
2008-02-26 19:18 ` Russell King
@ 2008-02-26 20:10 ` Robin Getz
0 siblings, 0 replies; 9+ messages in thread
From: Robin Getz @ 2008-02-26 20:10 UTC (permalink / raw)
To: Russell King; +Cc: Alan Cox, Haavard Skinnemoen, linux-serial
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: Inter-Character Delay
2008-02-18 18:36 Inter-Character Delay Robin Getz
2008-02-26 16:11 ` Robin Getz
@ 2008-02-26 20:59 ` Chris Doré
2008-02-27 15:57 ` Robin Getz
1 sibling, 1 reply; 9+ messages in thread
From: Chris Doré @ 2008-02-26 20:59 UTC (permalink / raw)
To: linux-serial
If I read this correctly, the summary is that you:
1. Want to add functionality to the serial driver that supports an extra
feature (the delay register).
2. Would like to know what the best way is to expose this new functionality
to a user app.
3. Are NOT looking for a way to create the delay on hardware that does not
natively support it.
I don't have good answers for you, but perhaps this will help summarize and
clear up what you are really after.
..Chris
> -----Original Message-----
> From: linux-serial-owner@vger.kernel.org [mailto:linux-serial-
> owner@vger.kernel.org] On Behalf Of Robin Getz
> Sent: February 18, 2008 1:36 PM
> To: linux-serial@vger.kernel.org
> Subject: Inter-Character Delay
>
> It is quite common on many industrial serial devices which do not support
> either software or hardware flow control to require a Inter-Character
delay
> longer than than the standard one, one and a half, or two stop bits.
>
> A device where this long inter character delay is required are devices
like
> Point of Sale terminals, and devices that are talking to Modbus (Honeywell
> SI-FTA implements a check on the inter-character gap).
>
> 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
>
> I think I have seen similar things for some ARM devices, and other
embedded
> architectures. Today, we have done similar things in the driver (on
hardware
> that doesn't support it natively).
>
> I'm not sure that bit periods are the best way to measure things, or
> milliseconds. I guess it really doesn't matter, as long as everyone does
it
> the same way - which brings me to my next question:
>
> Does anyone have a good idea of a standard way to expose this to
userspace?
> - grabbing 8 bits in the termios_p c_oflag isn't going to fit
> - adding a new field in the termios structure seems like overkill
> - adding backdoor ioctls for serial drivers seems like a bad idea.
>
> Thoughts?
>
> Thanks
> -Robin
> -
> To unsubscribe from this list: send the line "unsubscribe linux-serial" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Inter-Character Delay
2008-02-26 20:59 ` Chris Doré
@ 2008-02-27 15:57 ` Robin Getz
2008-03-03 8:29 ` Tosoni
0 siblings, 1 reply; 9+ messages in thread
From: Robin Getz @ 2008-02-27 15:57 UTC (permalink / raw)
To: Chris Doré; +Cc: linux-serial
On Tue 26 Feb 2008 15:59, Chris Doré pondered:
> If I read this correctly, the summary is that you:
>
> 1. Want to add functionality to the serial driver that supports an extra
> feature (the delay register).
> 2. Would like to know what the best way is to expose this new functionality
> to a user app.
Yes - that about captures it.
-Robin
-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: Inter-Character Delay
2008-02-27 15:57 ` Robin Getz
@ 2008-03-03 8:29 ` Tosoni
0 siblings, 0 replies; 9+ messages in thread
From: Tosoni @ 2008-03-03 8:29 UTC (permalink / raw)
To: 'Robin Getz'; +Cc: linux-serial
Maybe a new parameter for the driver module, or a new entry in /proc would do it ?
> -----Original Message-----
> From: linux-serial-owner@vger.kernel.org
> [mailto:linux-serial-owner@vger.kernel.org]On Behalf Of Robin Getz
> Sent: Wednesday, February 27, 2008 4:57 PM
> To: Chris Doré
> Cc: linux-serial@vger.kernel.org
> Subject: Re: Inter-Character Delay
>
>
> On Tue 26 Feb 2008 15:59, Chris Doré pondered:
> > If I read this correctly, the summary is that you:
> >
> > 1. Want to add functionality to the serial driver that
> supports an extra
> > feature (the delay register).
> > 2. Would like to know what the best way is to expose this
> new functionality
> > to a user app.
>
> Yes - that about captures it.
>
> -Robin
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-serial" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2008-03-03 8:34 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-02-18 18:36 Inter-Character Delay Robin Getz
2008-02-26 16:11 ` Robin Getz
2008-02-26 17:11 ` Russell King
2008-02-26 18:21 ` Robin Getz
2008-02-26 19:18 ` Russell King
2008-02-26 20:10 ` Robin Getz
2008-02-26 20:59 ` Chris Doré
2008-02-27 15:57 ` Robin Getz
2008-03-03 8:29 ` Tosoni
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox