short term contract lead for customized Fedora serial driver

[Lennart Sorensen]

On Thu, Nov 09, 2006 at 10:02:28AM -0500, bob wrote:
> I have a lead on a short term piece of work on a customization of a serial 
> kernel module to meet the specs below.
> 
> Contact me offlist if you think this is something you know how to do.
> 
> bob
> 
> =========== snip from client description of problem ==========
> > I have a C program in Linux that talks to slot machine which require a 
> > wakeup bit be set. The protocol requiers 1 start, 8 data, 1 wakeup, 1 
> > stop bit.
> >
> > Essentially I need the set or 127 characters to go out with the parity 
> > bit set to zero. In addition I need, at least, to be able to send out 
> > 0x00, 0x01, 0x80, 0x81 and 0x82 out with the parity bit set to 1. 
> > Ideally it would be transparent. The starting byte would have the 
> > wakeup (parity) bit set, the rest of the message would would not.
> >
> > I've not been able to use mark parity (does not work) so I am faking 
> > it by switching parity to emulate the wakeup bit.
> >
> > But this presents a timing problem occasionally. Some slots require an 
> > inter-byte delay of no more than 5ms. The partity switching is causing 
> > delays in the order of 6 to 8 ms.
> >
> > My guess is that the wakeup bit emulation built into the Linux kernel 
> > would be faster and the same basic idea would work but in under 5ms, 
> > making the problem disappear. I'm using Fedora Core 4 and would like 
> > the driver to be installable in FC5 and FC6 if possible.
> 
> ========= end snip ============

Hmm, well the reason it probably takes too long to change parity is that
you are actually changing a register in the serial chip.  Parity isn't
managed by software, it is usually managed by the serial port hardware
itself.  It is meant to detect errors on the serial line between two
ports, and it the software generally only cares if a parity error
occoured, not what the parity bit is.  At least that is my understanding
of the 8250/16550 register interface.  If I am right, then there
probably is no way to implement this type of messed up serial protocol
using a standard 8250 style serial port.  Then again maybe a PCI based
port would change settings faster than an isa/lpc based port does.

I assume you mean you use MARK to force parity bit to 1, and SPACE to
force parity bit to 0.  Or were you actually calculating the parity of
the current data and changing parity settings to ODD/EVEN to generate
the right parity bit for that case?  I guess you could try using
something like a Digi Neo 2 port PCI card, since at least register
access on a PCI card is usually pretty fast.  Maybe that would make your
method fast enough.  I really doubt the over head of accessing the
kernel to change the parity setting is really that high compared to the
kernel actually changing the register in hardware.

--
Len Sorensen
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists