Non blocking read from streaming channel

Technical questions regarding the xTIMEcomposer, xSOFTip Explorer and Programming with XMOS.
User avatar
Posts: 13
Joined: Thu Feb 04, 2010 12:45 am

Non blocking read from streaming channel

Postby AkkiSan » Sun Jul 25, 2010 12:39 pm

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?

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

Postby f_petrini » Sun Jul 25, 2010 2:42 pm

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

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

Postby AkkiSan » Sun Jul 25, 2010 9:51 pm

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...


Who is online

Users browsing this forum: No registered users and 6 guests