Split Port

[segher]

Threads share a core. There can be at most eight threads
per core. Some threads are running, some are waiting. The
threads are scheduled round-robin; waiting threads are skipped
over. No thread can be scheduled if it was scheduled less
than four cycles ago.

In normal mode, if a thread has to wait (say, it is inputting
from a channel but that channel has no input ready), the thread
switches to waiting, so it won't be scheduled until it is woken
up. In "fast mode", such a thread is scheduled over and
over with that same instruction until the instruction succeeds.
This is lower latency for that thread, but wastes execution
bandwidth (if there are other threads to run) and power.

[fullm3tal1991]

Threads share a core. There can be at most eight threads
per core. Some threads are running, some are waiting. The
threads are scheduled round-robin; waiting threads are skipped
over. No thread can be scheduled if it was scheduled less
than four cycles ago.

In normal mode, if a thread has to wait (say, it is inputting
from a channel but that channel has no input ready), the thread
switches to waiting, so it won't be scheduled until it is woken
up. In "fast mode", such a thread is scheduled over and
over with that same instruction until the instruction succeeds.
This is lower latency for that thread, but wastes execution
bandwidth (if there are other threads to run) and power.

Ok.
In my application i need to have screen et audio effects.
My program for simple audio effects without screen and button works.
when I add my buttons / screen thread, the audio doesn't work anymore. I think it's a timing problem. So I don't have the choice? I have to do the algorithme of the screen in the 2 core. Or is there an other solution? and in XDE, is there a tool to see the timing of threads?

[sethu_jangala]

in XDE, is there a tool to see the timing of threads?

There is timing analyzer (xTA) available in the xTIMEcomposer tool. You can find the manual from the following link:
XMOS Timing Analyzer Manual


Sethu.

[TSC]

I think it's a timing problem. So I don't have the choice? I have to do the algorithme of the screen in the 2 core.

Having had a quick look at your code, I think it's more likely you have a simple blocking problem. The standard channel communication operators <: and :> will block (wait for some event). A receive will block until the channel has a token. A transmit will block until the token is accepted. Each channel has a small buffer (4 bytes I believe), but that will soon become full and cause deadlock if your communication algorithm is faulty.

Read about guard statements. E.g.

Code: Select all

select {
  case <something>:
    // Respond to event.
    break;
  case <something else>:
   // Respond to event.
    break;
  default:
    // None of the previous cases were triggered.
    break;
}

These are useful if a logical core needs to respond to multiple incoming channels because the receiving thread will not block.

Then debug your code using the debugger and/or print statements. Find out where it's getting stuck and why.

Using the new terminology, most 2 tile XMOS microcontrollers have a total of 16 logical cores, or 16 threads in old-speak. Either way, you can call a total of 16 functions using par {} which will operate concurrently. See the example I gave in my previous post in this topic.

[fullm3tal1991]

Thanks a lot for the help, i will work on it and keep you in touch.

Rémi

[fullm3tal1991]

It's strange,
i'm currently doing the XTA tutorial,

when I try with the XK1 tutorial (without board) it's working, and I can run a timing configuration.

but when I do all the exactly same actions with a USB audio 2.0 mc project, i always have this error message



however the project has no errors. and I can upload it on the board with out any problems.
(it's the most simple project i can do => just light the leds on p_led ports XD)


and about this

The standard channel communication operators <: and :> will block (wait for some event). A receive will block until the channel has a token.

If I use simple channel, it will block,
but with streaming channel it won't block isn't it?

[segher]

With an XC "simple channel", the sending and the receiving
thread do some handshaking before and after the actual
transfer, making that transfer a synchronisation point in the
sense that both before and after the transfer both threads
agree on if the transfer has already happened or not. This
is quite useful: it is much easier to reason about. But it
is also slower, so sometimes you want to use a "streaming
channel" instead; this is just a hardware channel without
any handshaking generated by the compiler.

A hardware channel can block as well. If you try to input
from a channel that has no data available yet, your thread
waits until there is; and if you try to output to a channel
that does not have a free buffer, your threads waits until
the buffer has space.

[TSC]

segher is absolutely right, he is a real XMOS expert.

I just want to emphasize that changing a simple channel to a streaming channel will not give you a quick fix if your communications algorithm is fundamentally broken. Streaming channels are only for speeding up an already functioning application.

A looping thread, T1, sending data on a channel (simple or streaming) will eventually get stuck if the receiving thread, T2 doesn't keep accepting data from the channel. Why might T2 not be accepting data from the channel? Maybe it is waiting on a port event that won't ever happen, maybe it itself is sending data on another channel that is causing blocking behaviour. Then the whole system is deadlocked. When I started building my XMOS applications, I found it best to create my communications algorithms iteratively. Start simple, test it with the debugger and print statements, if it deadlocks, find out where and why. If it works, add the next bit, continue.

Useful material:
Responding to multiple inputs
Transactions and streams

[segher]

I just want to emphasize that changing a simple channel to a streaming channel will not give you a quick fix if your communications algorithm is fundamentally broken.

Absolutely! It also is much harder to make streaming channels
work correctly, esp. if you have more than one; and often
things won't be (significantly, or even measurably) faster
either -- it's like "fast mode" threads in that regard.

If your system doesn't behave as you think it should, it means
you don't understand your system, so making your system that
much more complicated is not going to help matters ;-)

[fullm3tal1991]

OK, thank you for all these explanations!
Now that I understand it all a little better, I'll redo my project properly.
Besides, I wonder if I'll still use the software release. It is very complete, but I still feel not master it and do not understand everything.

I think I'll make a homemade project that will allow me to understand everything:

On the same Core:
- One Logical core for I2C communication with the Codec
- One Logical core for DSP (audio effects)
- One Logical core to manage the display and buttons.

if there is too much computation time, I will do DSP or display in the 2nd Core.

Or the 2nd solution is to begin with the software release (which I can understand better now)


but I need only a few stuff in it. Right now, I don't want Spdif, Adat, Midi and Usb...
Is there a simple way to bypass the decoupler?
so just use

I2S / Audio Driver with 2 channels (audio in, audio out)
Homemade Mixer/Dsp with 2 channels (audio in, audio out) with all my effects in it.

PS : do you have any answers for my strange error message?