I'm considering trying to run Profibus (see http://www.profibus.com/)
over standard serial ports. It runs at speeds run 9600 to 1.5M baud,
and obviously I'm looking at the lower end of that spectrum. If I put
a simple RS232-RS485 converter on the serial port, I need to be able
to manage two things:
1. As mentioned, send out 256 consecutive characters without a single
idle bit between them, and with less than 0.3% deviation over the
whole packet. I reckon I ought to be able to handle this if I can
keep the internal FIFO full.
Indeed. Have you tried this with a standard Linux kernel with a 16550A
and had trouble keeping it full? As long as you enable interrupts on
the IDE interface (insert standard warnings of potential hard disk
corruption if you have one of the brain-damaged IDE controller chips),
it will be difficult, but should be possible to keep the internal FIFO
full.
Unfortunately, the 16550A only gives an interrupt when the FIFO is empty
(and while the last character is in the shift register being clocked out
the serial port). That means that the OS has only one character time to
refill the FIFO. At 9600 bps, that translates to 10/9600, or a little
over a 1ms. While this is a little tight, as long as you don't have
device drivers hogging the interrupt level for long periods of time
(that's why enabling interrupts while doing IDE transfers is important),
it should be doable.
2. Detect a sequence of 33 idle bits (3 characters) before a packet,
without which received packets aren't valid. This one might be
more difficult, but it should still be possible, I hope.
Yes, this will be much harder. Depending on how exactly you need to
measure the 33 idle bits (i.e., is +/- 1 character time ok?), you may
very well need explicit kernel support, or access the chip directly
yourself.
There have been requests in the past for exact timestamping of when
packets arrive, for folks who want to do highly time-critical timings.
(Radio clocks, etc.) I've not been terribly thrilled with this idea
because of the kernel bloat that it engenders, but it's true the only
place where this sort of thing can be done is in the serial driver.
Assuming timing good to within 1/100th of a second is sufficient, it
wouldn't be that hard to add something like that into the tty layer.
I'm not at all thrilled of having the serial driver have to do
heavy-duty computation try capture sub-clock-tick time resolutions on a
per character basis inside the serial interrupt driver, though!
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html