Blocking channels, timing issues

[bartvanderlaan]

Hello,

I'm working on an L2 which runs firmware based on the multichannel ref. design of XMOS.
My design has to put out the "level data" of all audio in and outputs on a display. I've managed to get this working for a couple of audio I/O's, but i'm now running into some timing issues it seems.

Basically, what i'm trying to do is send over the level data through a channel from a thread from now on called "sender" to a thread called "display" which is obviously controlling the display. I use a select statement in the display thread to see if there was any action on the channel.

Sender (fast thread) --> channel --> Display (select statement, do stuff with new data (slow thread))

Because the display thread is taking some time to write the new data to the screen, the channel get's blocked when I increase the number of audio I/O's I want to display and the rest of the system stalls.

From the documentation I've learned that there is no way to let the sender thread continue regardless if it was received on the other end, even without synchronizing them, is this correct?

Is there a way to receive the data from the channel in some kind of a interrupt manner, and put them in a local array in the display thread?

Somehow I need to find out how to receive (and maybe buffer?) data coming in through a channel in a thread which is also doing other slow stuff.

Thanks!

Bart

[Bianco]

From the documentation I've learned that there is no way to let the sender thread continue regardless if it was received on the other end, even without synchronizing them, is this correct?

Each chanend has a small buffer (8 tokens). You can send at least data with a size of 8 tokens (thats 8 bytes) before being blocked. This is on the same core, i believe you can send more when the destination is on a different node (like the second core on a L2) because the switch has some buffering too. It required using streaming chanends if you use XC (no synchronization).

Is there a way to receive the data from the channel in some kind of a interrupt manner, and put them in a local array in the display thread?

You can use interrupts, the architecture supports it.
For an example see my FreeRTOS port which uses a timer interrupt:
https://xcore.com/projects/freertos-port

I have the feeling that neither will solve anything and the solution is to increase the SPI speed to your display (this not? http://www.xmos.com/discuss/viewtopic.php?f=57&t=857) or to decrease the data send to the display driver.

[paul]

It is probably best to have some scheme where the displaying thread buffers up the values itself - so it pulls the values in sequentially, stores them then processes them.

This avoids you having to lock your audio level measurement sequence to your display output.

Another thing to consider is to make the display the controller of the communication e.g. the display requests the values, rather than having them pushed to it - meaning the other thread can do stuff while it is waiting for a request from the display thread for the next value.

[bartvanderlaan]

Hello,

You can use interrupts, the architecture supports it.
For an example see my FreeRTOS port which uses a timer interrupt:
https://xcore.com/projects/freertos-port

I have the feeling that neither will solve anything and the solution is to increase the SPI speed to your display (this not? http://www.xmos.com/discuss/viewtopic.php?f=57&t=857) or to decrease the data send to the display driver.

Thanks for thinking along and for your suggestions. Thinking about it, these solutions would always bite me in the end because the display has to do a lot of other stuff later on, so speeding it up is only a short term solution.

By the way, that's my old thread indeed! Good to get some feedback from another dutch member. May I ask you where you are located?

Another thing to consider is to make the display the controller of the communication e.g. the display requests the values, rather than having them pushed to it - meaning the other thread can do stuff while it is waiting for a request from the display thread for the next value.

Yes! That's it. Just needed to think the other way around. It works like a charm now!

Thanks a lot guys!

Bart

[Bianco]

Hello,

By the way, that's my old thread indeed! Good to get some feedback from another dutch member. May I ask you where you are located?

Bart

Hello Bart,

I live near Almelo.

Bianco