I thought I'd step in and clarify some things. I work at Technologic Systems and designed both the XUART hardware FPGA core and the xuartctl software a few years ago.
There seems to be confusion on what average response latency to expect out of the XUART hardware + software.
First off, the RX FIFO is so deep in the XUART hardware that we don't even need an interrupt for 90% of applications out there. This is why by default, the xuartctl server process simply polls at 100hz (10ms) -- even if all 8 possible channels are actively receiving data at 115200 baud the hardware is in no danger of FIFO overflow. In the polling mode, you can expect around 10ms latency before your app sees the RX data because thats how long it could be in the hardware RX FIFO before being consumed and sent out to pipes/sockets to downstream application code. Anything beyond 10ms is due to process competition for the CPU -- if you have other threads/processes wanting the CPU but you want to ensure your application still sees XUART serial data promptly, its a simple matter of setting process priorities. Its worth noting this latency is the norm for kernel serial drivers too, since they post their data to the kernel termios layer which holds on to
bytes and does not present them to userspace until after 10-100ms unless a not-well-known low latency mode ioctl() is run on the serial driver.
The XUART hardware and software can also be told to use IRQs. There really is only 2 reasons to use IRQs: 1) You are using baud rates above 115200, or 2) you need minimal or sub-10ms latency on RX characters. To use IRQs on the TS-7550, edit the /linuxrc and change the line that invokes the xuartctl server from "xuartctl --server" to "xuartctl --server --irq=29"
Once you start allowing the software to use IRQs, xuartctl starts paying attention to a couple extra parameters -- specifically, the "rlw=" (Receive low-water mark) and the "ithr=" (Idle-threshold). The "rlw=" arg takes a number between 1-255 is the the minimum number of RX characters in the RX FIFO that will be accumulated before sending an IRQ and waking up the hardware consumer process. When you enable irq's, it defaults to "1" meaning it will send an IRQ after every single RX character received. The "ithr=" argument is used to tune the number of bit-times the RX line has to be idle before sending an IRQ before the rlw= threshold is met.
The simple latency test we run as part of "xuartctl --test" is run with TX and RX looped back to each other. The test transmits a single character, waits to receive it on the rx line, then sends it again, over and over. This emulates a system with a 1 byte 0-latency request/response protocol and serves as our benchmark. The XUART polling at 100hz, predictably gives us approximately 100 request/response transactions per second, when using IRQs, we get approx 600 per second. When using the CPU internal uart with the low latency ioctl, we get 1500. A modern multi-ghz Linux-x86 PC on a motherboard (not USB) serial port gets 2000.
Why did we implemented XUART's in userspace over TCP? There are actually several reasons:
1) Talking to customers over the years I've found a very large portion of people use our boards as serial to network(TCPIP) converters, so I figured I'd save them some development by allowing that out-of-the-box.
2) Linux kernel version independence -- xuartctl doesn't need to be reworked when kernel innards APIs change.
3) Linux kernel serial port API deficiencies -- XUART hardware has features that cannot be represented in the normal serial API. 9-bit serial, timed idle/break, non-standard arbitrary baud rates, pipelined baud rate changes, etc...
4) Debuggability -- since we designed both the hardware and software, we had to debug both at the same time. This sort of design flow is much faster and efficient when you have good debug tools and don't have to worry about crashing/deadlocking the kernel.
5) As a userspace process, its priority can be tweaked lower if there are more important things to process than serial ports. A kernel driver is always on and interrupting at its full rate while its open.
6) Exportability -- xuartctl can export its serial ports to other UNIX machines across the internet to serve as virtual "local" serial ports since xuartctl.c compiles on any UNIX.
//Jesse Off
--- In
, Walter Marvin <> wrote:
>
> What actually occurs is that Technologic mmaps the xuart hardware into the Linux user space and then treats them as internal TCP servers.
> They have arranged the servers so as to support "raw" device mapping within Linux. What this does is cause excessive user space to kernel space context switches, especially since the xuart hardware can dribble in characters a few time. This causes non-linear latency responses when combined with other user space loads. The actual latency starts at about 2ms and increases in a non-linear fashion dependent on other load. This is really not that measurable with a simplistic program, but top is useful.
>
> If you want to use one xuart channel per serial line at 100 ms per packet, Technologics' system can probably handle that, but I would model it with some scripting and measure, just to be sure
>
>
>
> ________________________________
> From: mike ingle <>
> To:
> Sent: Wednesday, August 31, 2011 4:19 PM
> Subject: Re: [ts-7000] TS-7550 XUARTs
>
>
> Â
> Hi Walter,
>
> Am I right there there is no device driver, and that the userspace just mmaps the xuarts? Â For my application, latency won't be a problem, also very much a fixed line setup. Â What little I read on the xuart indicated that they expect about 100ms latency in their user space server (I would assume that I wouldn't be using their xuartctl server, instead directly reading and writing to the xuarts) . Â As long as It never ever drops characters, latency is OK. Â Given how few of these will be built, and the desire to run device test routines on the server, I think 8 uarts per 7550 is OK. Â my biggest concern is that the 7550 perform as described.
>
> best regards Mike
> On Aug 31, 2011, at 11:50 AM, Walter Marvin wrote:
>
> Â
> >
> >
> >The TS7500 and 7550 does NOT I repeat NOT have standard Linux serial device driver support. The User Space servers that Technologic supply limit the throughput and latency you achieve. Since your baud rate is the same on all channels and the through put is relatively low you might be able to get away with it. I would suggest you set up a demo with one 7550 and see if it works without delays.Â
> >
> >
> >
> >I had to modify the servers and finally write my own drivers to get 50 ms latency and line set up flexibility. If you go to a device driver, you might be able to multiplex the serial streams in hardware and limit the number of 7550's. I can help you with this.
> >
> >
> >
> >
> >
> >
> >________________________________
> >From: mike ingle <>
> >To:
> >Sent: Wednesday, August 31, 2011 2:34 PM
> >Subject: [ts-7000] TS-7550 XUARTs
> >
> >
> >Â
> >Hi all,
> >
> >I need to maintain communications with 80 devices overRS-232 serial (115k). Each device streams an approximately 120 byte packet every 100ms.
> >also the host, can send packets, and expect a response at any time. The packets are hex encoded with out of band start and stop characters.
> >
> >I am contemplating using 10 ts-7550s (with appropriate level shifters) to control the devices, and forward the data over ethernet. The intent would be to crack the serial packets (which include 2 crc32 checks) down to their 60byte binary size, buffer 10 or so serial packets per channel, (600bytes per ethernet packet) and send them on up to a host for logging and display.
> >
> >My data rate calculations show very modest ethernet usage (8 x 600 bytes/s).
> >
> >On the surface the ts-7550 looks like a nice fit for this. Anyone have any experience with the XUARTs , or better suggestions? Probably no more than 3 <80 channel systems> will be built.
> >
> >Best Regards Mike
> >
> >
> >
> >
> >
> >
>