Input Buffer from UART

Technical questions regarding the XTC tools and programming with XMOS.
zog
Junior Member
Posts: 4
Joined: Tue Mar 20, 2012 11:59 pm

Input Buffer from UART

Post by zog »

Hello guys,

On a traditional microprocessor there are interrupts that fire when an input arrives from the UART, and in that interrupt
there ussually is a procedure that puts the input from the UART into the buffer and the rest of the program can make
use of the input from the UART by reading the buffer.

On an xmos processor, when the input arrives through the UART of which the UART routine is on a separate thread,
the only way to pass data to another part of the program is through the use of a channel, however if that channel is used
to communicate the data to another part of the program and that part is NOT ready to read the input from the chennel due to
having to process data for some time, then the receiving thread that accepts input from the UART will stop receiving input
and the data will be lost.

Is there a way around the problem of receiving input from a UART and at the same time passing it to another function without
blocking the receiving functionality from a UART?


User avatar
Bianco
XCore Expert
Posts: 754
Joined: Thu Dec 10, 2009 6:56 pm

Post by Bianco »

Hi zog,

Each chanend has an 8-token buffer.
When you use streaming channels you can send up to 8 (8-bit) characters to a different thread without getting blocked. This will not work for regular (synchronized) channels.
You can have as many streaming channels between two threads on the same core but you have to be careful when you open streaming channels between threads on different cores/chips because the number of streaming channels you can have between them is limited.

Bianco
User avatar
segher
XCore Expert
Posts: 844
Joined: Sun Jul 11, 2010 1:31 am

Post by segher »

No data is ever lost on a channel (if the receiving channel end is actually
allocated and has its routing set up properly, of course). If you try to
send data, but the receiver is blocked, then the sender blocks until there
is room.

A channel end can not buffer much data; if you want to have more buffer
space, you'll have to do that yourself (buffer it in RAM). You can run that
buffer on a separate thread, man-in-the-middle style, it is transparent to
both endpoints that way.

Your buffer will still be a limited size, of course (since RAM size is limited!),
so you still have to think about what size buffer you need, and try to minimise
that. You should try to think about it as "streaming" data through some
pipeline, not as building packets that you hand over. RAM buffers are handy
if you need extra elasticity somewhere in the pipeline, but you should
try to design in a way that you do not need them.
User avatar
dan
Experienced Member
Posts: 102
Joined: Mon Feb 22, 2010 2:30 pm

Post by dan »

Hi Zog,

You may be interested to look at this github repo:

https://github.com/xcore/sc_multi_uart

This is an Ethernet to octo-UART reference design our guys are working on. See 'app_serial_to_ethernet_demo'. Basically we have 8 115.2K uart RX in one thread, 8 115.2K uart TX in another, and then another thread to manage these uarts (manage the buffering and runtime baud rate changes etc). Then the above is interfaced to the sc_xtcp stack.

- Dan
zog
Junior Member
Posts: 4
Joined: Tue Mar 20, 2012 11:59 pm

Post by zog »

Thanks for your help guys, Ill look into both using streamed channels and the implementation!

Regards,
Zog