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?
Input Buffer from UART
-
- Junior Member
- Posts: 4
- Joined: Tue Mar 20, 2012 11:59 pm
-
- XCore Expert
- Posts: 754
- Joined: Thu Dec 10, 2009 6:56 pm
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
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
-
- XCore Expert
- Posts: 844
- Joined: Sun Jul 11, 2010 1:31 am
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.
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.
-
- Experienced Member
- Posts: 102
- Joined: Mon Feb 22, 2010 2:30 pm
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
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
-
- Junior Member
- Posts: 4
- Joined: Tue Mar 20, 2012 11:59 pm
Thanks for your help guys, Ill look into both using streamed channels and the implementation!
Regards,
Zog
Regards,
Zog