Configuring high-speed serial ports with devc-ser8250

QNX Newsgroups (Archives) qdn.public.qnxrtp.installation
1

We have a 500,000 baud serial port board from Sealevel
Systems, which we are are attempting to run in a
PC/104 stack. This device has 63-byte FIFOs, but it
looks like an ordinary 8250-compatible device.

We need to receive data from a real-time device that blasts
data at us at 500,000 baud. Almost all the traffic is
receive; we send only at startup. There’s no software flow
control.

We’ve started up the serial driver with

devc-ser8250 -T14 -t14 -I25000 -u3 -c 16000000/16 3e8,10 &

That appears to work. But the interrupt load is heavy.

Are those good settings? Can we make
the -t value bigger than 14, since we have a bigger hardware
FIFO? Is the -I value reasonable?

[Why 500,000 baud. The SICK LMS laser rangefinder emits 500,000 baud
serial data. Unclear why they picked that baud rate. They sell
special ISA and PCI boards for that speed, but we’re using
a PC/104 stack.]

John Nagle
Team Overbot

2

In article <3FCC44FD.4010008@overbot.com>, nagle@overbot.com says…

We have a 500,000 baud serial port board from Sealevel
Systems, which we are are attempting to run in a
PC/104 stack. This device has 63-byte FIFOs, but it
looks like an ordinary 8250-compatible device.

We need to receive data from a real-time device that blasts
data at us at 500,000 baud. Almost all the traffic is
receive; we send only at startup. There’s no software flow
control.

We’ve started up the serial driver with

devc-ser8250 -T14 -t14 -I25000 -u3 -c 16000000/16 3e8,10 &

That appears to work. But the interrupt load is heavy.

Are those good settings? Can we make
the -t value bigger than 14, since we have a bigger hardware
FIFO?

No. To turn on 64 byte FIFO you probably need a special trick which depends on chip you are actually
using and devc-ser8250 is unaware of something special and more powerful than 16550 UART. Interrupt
load should be heavy on such a speed. Actually, if you were able to set up 64 byte depth FIFO, you
would get interrupts less often fired up, but processing (reading whole chunk of data byte by byte)
inside interrupt would become more heavy, so interrupt handler will take much more time to execute.
I agree it could give some advantage, but not too much.

Eduard.

Is the -I value reasonable?

[Why 500,000 baud. The SICK LMS laser rangefinder emits 500,000 baud
serial data. Unclear why they picked that baud rate. They sell
special ISA and PCI boards for that speed, but we’re using
a PC/104 stack.]

John Nagle
Team Overbot

3

ed1k <ed1k@humber.bay> wrote:
ek > In article <3FCC44FD.4010008@overbot.com>, nagle@overbot.com says…

We have a 500,000 baud serial port board from Sealevel
Systems, which we are are attempting to run in a
PC/104 stack. This device has 63-byte FIFOs, but it
looks like an ordinary 8250-compatible device.

We need to receive data from a real-time device that blasts
data at us at 500,000 baud. Almost all the traffic is
receive; we send only at startup. There’s no software flow
control.

We’ve started up the serial driver with

devc-ser8250 -T14 -t14 -I25000 -u3 -c 16000000/16 3e8,10 &

That appears to work. But the interrupt load is heavy.

Are those good settings? Can we make
the -t value bigger than 14, since we have a bigger hardware
FIFO?

ek > No. To turn on 64 byte FIFO you probably need a special trick which depends on chip you are actually
ek > using and devc-ser8250 is unaware of something special and more powerful than 16550 UART. Interrupt
ek > load should be heavy on such a speed. Actually, if you were able to set up 64 byte depth FIFO, you
ek > would get interrupts less often fired up, but processing (reading whole chunk of data byte by byte)
ek > inside interrupt would become more heavy, so interrupt handler will take much more time to execute.
ek > I agree it could give some advantage, but not too much.

ek > Eduard.

Yes, the number of bytes to transfer would be the same. The savings
are in fewer task swaps due to fewer interrupts. Yes, it is very worth
while doing.

The only advice I could give is to go grab the source to devc-8250,
find the relivant parts and modify them to work better with your chip.

Is the -I value reasonable?

[Why 500,000 baud. The SICK LMS laser rangefinder emits 500,000 baud
serial data. Unclear why they picked that baud rate. They sell
special ISA and PCI boards for that speed, but we’re using
a PC/104 stack.]

John Nagle
Team Overbot

–
Bill Caroselli – Q-TPS Consulting
1-(708) 308-4956 <== Note: New Number
qtps@earthlink.net

4

Great misery. Achieved 500,000 baud. Got instant data corruption
of flash disk. Apparently serial board corrupts ISA bus in
PC/104 stack at high speed.

John Nagle

Bill Caroselli wrote:

ed1k <> ed1k@humber.bay> > wrote:
ek > In article <> 3FCC44FD.4010008@overbot.com> >, > nagle@overbot.com > says…

We have a 500,000 baud serial port board from Sealevel
Systems, which we are are attempting to run in a
PC/104 stack. This device has 63-byte FIFOs, but it
looks like an ordinary 8250-compatible device.

We need to receive data from a real-time device that blasts
data at us at 500,000 baud. Almost all the traffic is
receive; we send only at startup. There’s no software flow
control.

We’ve started up the serial driver with

devc-ser8250 -T14 -t14 -I25000 -u3 -c 16000000/16 3e8,10 &

That appears to work. But the interrupt load is heavy.

Are those good settings? Can we make
the -t value bigger than 14, since we have a bigger hardware
FIFO?


ek > No. To turn on 64 byte FIFO you probably need a special trick which depends on chip you are actually
ek > using and devc-ser8250 is unaware of something special and more powerful than 16550 UART. Interrupt
ek > load should be heavy on such a speed. Actually, if you were able to set up 64 byte depth FIFO, you
ek > would get interrupts less often fired up, but processing (reading whole chunk of data byte by byte)
ek > inside interrupt would become more heavy, so interrupt handler will take much more time to execute.
ek > I agree it could give some advantage, but not too much.

ek > Eduard.

Yes, the number of bytes to transfer would be the same. The savings
are in fewer task swaps due to fewer interrupts. Yes, it is very worth
while doing.

The only advice I could give is to go grab the source to devc-8250,
find the relivant parts and modify them to work better with your chip.


Is the -I value reasonable?

[Why 500,000 baud. The SICK LMS laser rangefinder emits 500,000 baud
serial data. Unclear why they picked that baud rate. They sell
special ISA and PCI boards for that speed, but we’re using
a PC/104 stack.]

John Nagle
Team Overbot
\

5

I’ve used the Xtreme-104 Opto from ConnectTech with success,
at 1.2 MBit/s, by changing the crystal.
This was under DOS, and some small tweaks were necessary
to use the bigger FIFO.

John Nagle wrote:

Great misery. Achieved 500,000 baud. Got instant data corruption
of flash disk. Apparently serial board corrupts ISA bus in
PC/104 stack at high speed.

6

We ended up buying a dedicated one-port Ethernet to serial server, and
gave up trying to do this with the PC/104 stack and QNX.

John Nagle

John Nagle wrote:

Great misery. Achieved 500,000 baud. Got instant data corruption
of flash disk. Apparently serial board corrupts ISA bus in
PC/104 stack at high speed.

John Nagle

7

In article <bquka0$oei$1@inn.qnx.com>, nagle@downside.com says…

We ended up buying a dedicated one-port Ethernet to serial server, and
gave up trying to do this with the PC/104 stack and QNX.

Do you mean device like this:
http://www.lavalink.com/company/newsletter/05.03/link_05_03.html
If yes, do you use any driver which represents remote (ethernet) port like local /dev/serX on QNX
side? Or do you deal directly with socket (TCP/IP?) to receive stream?

eduard
at lavalink
dot com
:slight_smile:

John Nagle

John Nagle wrote:
Great misery. Achieved 500,000 baud. Got instant data corruption
of flash disk. Apparently serial board corrupts ISA bus in
PC/104 stack at high speed.

John Nagle

8

We’re using an industrial-grade unit from Sealevel, but
it’s the same concept. Sealevel uses documented protocols,
unlike LavaLink, with their proprietary “Lava Discovery
Protocol”.

We deal directly with the socket. Once the thing has
been configured (which requires a web browser), you
just read and write from the TCP connection.

John Nagle

ed1k wrote:

In article <bquka0$oei$> 1@inn.qnx.com> >, > nagle@downside.com > says…

We ended up buying a dedicated one-port Ethernet to serial server, and
gave up trying to do this with the PC/104 stack and QNX.


Do you mean device like this:
http://www.lavalink.com/company/newsletter/05.03/link_05_03.html
If yes, do you use any driver which represents remote (ethernet) port like local /dev/serX on QNX
side? Or do you deal directly with socket (TCP/IP?) to receive stream?

eduard
at lavalink
dot com
:slight_smile:

John Nagle

John Nagle wrote:

Great misery. Achieved 500,000 baud. Got instant data corruption
of flash disk. Apparently serial board corrupts ISA bus in
PC/104 stack at high speed.

John Nagle

9

In article <br3ha9$6v6$1@inn.qnx.com>, nagle@downside.com says…

We’re using an industrial-grade unit from Sealevel, but
it’s the same concept. Sealevel uses documented protocols,
unlike LavaLink, with their proprietary “Lava Discovery
Protocol”.

We deal directly with the socket. Once the thing has
been configured (which requires a web browser), you
just read and write from the TCP connection.

John Nagle

Thank you for the info. I was interested exactly in the conception. Lava currently doesn’t support
EtherSerial devices with baud rate more than 115200. Just for clarification, “Lava Discovery
Protocol” has nothing to do with carrying data. This protocol allows windows application (currently
only windows users have this service and I doubt we will support this feature for other platforms)
“Lava Port Manager” to discover EtherSerial devices on network and configure them (set IP address,
default baudrate etc.) All these settings could be setted up through web page or terminal from
serial link side. However, there is other proprietary protocol for carring data stream called LPP :slight_smile:
(for full “local port” emulation we have to add ioctl commands into traffic)
There will be raw connection in next release of firmware (exactly the mode which you’re using now)
and we also added few little things which we think would be useful for our customers.

Cheers,
Eduard


ed1k wrote:
In article <bquka0$oei$> 1@inn.qnx.com> >, > nagle@downside.com > says…

We ended up buying a dedicated one-port Ethernet to serial server, and
gave up trying to do this with the PC/104 stack and QNX.


Do you mean device like this:
http://www.lavalink.com/company/newsletter/05.03/link_05_03.html
If yes, do you use any driver which represents remote (ethernet) port like local /dev/serX on QNX
side? Or do you deal directly with socket (TCP/IP?) to receive stream?

eduard
at lavalink
dot com
:slight_smile:

John Nagle

John Nagle wrote:

Great misery. Achieved 500,000 baud. Got instant data corruption
of flash disk. Apparently serial board corrupts ISA bus in
PC/104 stack at high speed.

John Nagle
\