dynamically changing select{} cases from another thread

Technical questions regarding the XTC tools and programming with XMOS.
Post Reply
georgeyates
Newbie
Posts: 1
Joined: Fri Aug 16, 2019 11:02 am

dynamically changing select{} cases from another thread

Post by georgeyates »

I was wondering if it is possible to change case conditions dynamically in one thread from another thread?

for example:
one thread would look something like that:

while(1){

select{
case <some cond>
<do something>
break;
case <some other cond>
<do something else>
break;
...
}

}

so i was wondering if it is possible to have another thread change the case conditions while the select block in the first thread waits on some set of initial conditions?
I.e can i somehow manage the case conditions that one thread waits for from another thread?
I need this because i need the system to react very accurately to the constantly changing stimuli, and if i introduce some case managing code to the same thread that waits on the stimuli, it may delay the reaction to the stimuli (say when condition fires during the time management code is executing) and will make it not perfectly real-time as required.

if anyone has some other suggestions on how to implement this, i'd appreciate hearing them


MuellerNick
Member++
Posts: 31
Joined: Fri Dec 11, 2009 9:33 am

Post by MuellerNick »

Are you using an interface or a chan?

Nick
User avatar
CousinItt
Respected Member
Posts: 360
Joined: Wed May 31, 2017 6:55 pm

Post by CousinItt »

Hi,

you can use guard conditions on events in select statements. The guard conditions are expressions that evaluate to a true or false state to enable or disable each event. See the chapter on event handling in the XMOS programming guide for more information.

These guards are executed in software, so the more complex they are, the slower they will be. A select statement responding to messages from another task can modify variables which form part of the guard expressions used in the same select statement. The response to an event in a select statement is delayed while it is handling another event. That's the nature of the beast. If guards and the associated code aren't quick enough for you, there may be alternatives such as clever port programming or sharing the work between more than one task, but try guards first. As the saying goes, premature optimisation is the root of all evil.
Post Reply