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
Blocking channels, timing issues
-
- New User
- Posts: 3
- Joined: Mon Jan 10, 2011 4:19 pm
-
- XCore Expert
- Posts: 754
- Joined: Thu Dec 10, 2009 6:56 pm
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).bartvanderlaan wrote: 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?
You can use interrupts, the architecture supports it.bartvanderlaan wrote: 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?
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.
-
- XCore Addict
- Posts: 169
- Joined: Fri Jan 08, 2010 12:13 am
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.
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.
Paul
On two occasions I have been asked, 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.
On two occasions I have been asked, 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.
-
- New User
- Posts: 3
- Joined: Mon Jan 10, 2011 4:19 pm
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?
Thanks a lot guys!
Bart
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.Bianco wrote:
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.
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?
Yes! That's it. Just needed to think the other way around. It works like a charm now!paul wrote: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.
Thanks a lot guys!
Bart
-
- XCore Expert
- Posts: 754
- Joined: Thu Dec 10, 2009 6:56 pm
Hello Bart,bartvanderlaan wrote: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
I live near Almelo.
Bianco