Comments on: Serial overrun on Linux

By: Buxy rêve tout haut » Blog Archive » More fun with Linux and serial ports on slow hardware

Tue, 23 Jan 2007 15:10:34 +0000

[...] This is a never ending story for me. The first time I’ve had problems with Linux’s handling of serial UART dates back to 2005 (see my previous blog post on buffer overruns). At that time I could improve the situation by applying two patches (kernel-preempt and low latency). [...]

By: Buxy

Buxy — Sat, 22 Oct 2005 14:12:42 +0000

My cable is ok. I tested it physically as well as via software. The software handling the serial line can change RTS/DTR and read CTS/DSR/RNG/DCD. And I checked that changing RTS on one side changes CTS on the other side, etc.

By: Kurt Roeckx

Kurt Roeckx — Sat, 22 Oct 2005 12:25:20 +0000

Did you check that your cable actually supports hardware flow control? There are alot of cables out there with just 3 wires: RX, TX, signal ground. With those you can’t do hardware flow control. What you need is one that has 7 wires, but there are 2 types of those. One that connects the RTS/CTS localy back, one that doesn’t. Depending on how the serial port is set up, you need one of the 2 cables with 7 wires.

By: Buxy

Buxy — Sat, 22 Oct 2005 08:35:48 +0000

Of course, hardware flow control is activated ! Any serial device who must treat big chunks of data uses that.

By: Kurt Roeckx

Kurt Roeckx — Fri, 21 Oct 2005 22:10:30 +0000

Are you using some kind of flow control? Best would of course be hardware flow control, and it depends on the cable you have if you can use it or not.

By: Buxy

Buxy — Thu, 20 Oct 2005 06:12:11 +0000

The embedded device is a “serial-ethernet converter”. You can manage your serial port via TCP/IP. It’s used to remotely drive any serial device.

By: Anonymous

Anonymous — Thu, 20 Oct 2005 04:26:17 +0000

2.6 has several additional features which make it possible to shrink the kernel a good bit further than a 2.4 kernel. You have much more control over which components are included or not, even down to the basic stuff that you wouldn’t normally think to leave out.

Do you mind if I ask what the function of your embedded device is?

By: Buxy

Buxy — Wed, 19 Oct 2005 20:45:58 +0000

In reality, the hardware is not old … it’s quite new but it’s just built on an compatible i386 CPU. Why an i386 ? Because it’s cheap …

The UART is a 16550A so it has 16 bytes buffer luckily ! The DiskOnModule is connected on a 44pin IDE connector.

I’m still using 2.4.x because I have the feeling that it’s lighter than 2.6.x in an embedded context… and also because I have some custom module which have been written for linux 2.4.x and which may have to be ported if I need to switch to 2.6.x.

By: maks

maks — Wed, 19 Oct 2005 20:07:20 +0000

why do you use such old stuff?

if you want something better use the latest real time patch from ingo molnar.
the 0(1) scheduler 2.6 improved already a lot in this area and stock 2.6.13 and 2.6.14 have lots of low latency patches by him coming out directly of the -rt patchset,

what made you stick with something that ancient?

By: Robert McQueen

Robert McQueen — Wed, 19 Oct 2005 18:55:09 +0000

If this is a 16450 UART, which is likely given the processor of the machine, it only has one byte’s worth of buffer (or is it actually one bit? I can’t quite remember!), so if you’re running at 115kbps you need to service the serial interrupt exceedingly quickly indeed to not lose the byte. I used to use a 486 DX2 66MHz as a gateway box masquerading my LAN to an ISDN modem, and it had problems with running out of buffer when running the serial at 115kbps. I don’t know if it’s an option in your case, but I bought a pretty cheap ISA “fast” serial card which had a more modern 16650 UART, with 16 bytes of buffer, and the problems went away.

HTH,
Rob