horkan@m4.com said:
> Certainly not directly.... it's a limitation of the 16550A, not the
> OS.
> What are you trying to accomplish? There may be a better way.
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.
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.
We have access to dedicated hardware for higher-speed communication, and also
source code for the SCO Unix drivers for said, which we'll be porting at least
for in-house use (depending on the licensing arrangements we can talk them
into), but I'd like to make it possible to use simple RS232 devices on Profibus
if possible, at least at slow speeds.
Although I can try driving the 16550 directly, I'd also like to try to keep it
as generic as possible, by going through the kernel tty layer, so I can use
weird multiport cards and other architectures' serial ports if possible,
without having to rewrite hardware drivers for each. Also, it would mean that
if we abandon our hardware supplier and build our own RS485 cards to run at
decent speeds, all we have to provide is a tty driver.
As soon as I've finished putting together the proposals and associated
ramblings and pretty pictures, I'll make them available somewhere. Basically,
I'm looking at having up to the Profibus-FDL (link layer) level in the kernel,
with libraries or daemons handling the upper levels like DP and FMS. Anyone
who's interested, or just thinks I'm crazy, is welcome to get in touch.
> p.s. Use a newer kernel (I'm using 2.1.98) if you decide to check out
> the bizzare options - at least in my case, the timing seems much more
> consistent.
I thought Alan had been complaining recently that IRQ performance of recent
2.1 kernels was crap?
---- ---- ----
David Woodhouse David.Woodhouse@mvhi.com Office: (+44) 1223 812896
Project Leader, Process Information Systems Mobile: (+44) 976 658355
Axiom (Cambridge) Ltd., Swaffham Bulbeck, Cambridge, CB5 0NA, UK.
finger dwmw2@ferret.lmh.ox.ac.uk for PGP key.
-
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