Non blocking read from streaming channel

Technical questions regarding the XTC tools and programming with XMOS.
User avatar
AkkiSan
Member
Posts: 13
Joined: Thu Feb 04, 2010 12:45 am

Non blocking read from streaming channel

Post by AkkiSan »

How can one implement a non-blocking (or timeout) read of a streaming channel?

Can I check the amount of data available in the buffer before actually reading from it?
Can this read be aborted somehow?

I have one thread controlling a display (bare glass panel).
It reads its data from a buffer and is busy >95% of the time.
Because XC does not support sharing a buffer across different threads,
the only other option was receiving new data during the last 5% of
time available.

I already implemented a stream that feeds chunks of buffer data to the
LCD-thread during that time. Working fine and fast so far...

But if no data is available, the thread blocks.
At least the vertical sync (or any other "timeout") should abort immediately.


How can I solve this?


AS


User avatar
f_petrini
Active Member
Posts: 43
Joined: Fri Dec 11, 2009 8:20 am

Post by f_petrini »

There's no way of finding out if there's data available but you can make a non-blocking read.

If you add a default case to a select block the default case will execute if no other case is executed.
This block will read from the channel if there's data available, otherwise it just falls through.

Code: Select all

select
{
    case chan :> data:
        // Process data
        break;
    default:
        // Do nothing
        break;
}
See the "Programming XC on XMOS Devices" document in section A.8.5 "Selection Statements".
User avatar
AkkiSan
Member
Posts: 13
Joined: Thu Feb 04, 2010 12:45 am

Post by AkkiSan »

Great, thank you!
This is exactly what I was looking for!

Just to make this complete for others:
On some revisions of the XS1 architecture, it is not possible to input data of size less than 32
bits from a streaming channel in the guard of a select statement.

(C.4, Programming XC...)
The compiler did not like my quick and dirty byte transfers, coming in from a
high-speed UART (minimum of 16bit required for guarded statement).
Anyway, after discovering that the streaming channel transfer of 1000 32bit values needs
the same time as 1000 8bit data types (~40.64us), I had two good reasons for
changing the code...


AS