A question about channels and FIFOs

[kster59]

I have a serial art running at 2mbps on the xc1a board into a 32kbyte buffer which my application processes whenever it wants. The serial data input is constantly streaming and I never get a checksum error in over 100 mbytes at a time.

I use three threads. First collects uart data and sends to second thread. Second thread is a circular queue that stores data and sends it out. You want to request your data with a case select statement with a default option when data is not selected.

3mbps doesn't seem to work but I can do 2 no problem even without any handshaking.

[lilltroll]

What about http://www.xmos.com/applications/utilit ... ries/xfifo

or have you already start to eval. that ?

[jarnot]

Dear lilltroll,

You stated:

There is one pure XC way
use a
const struct

If you use a reference to that struct - you can skip the const in the function header, and perform read/write without the parallel usage error

My lack of experience in C (and hence XC) is a big hindrance here, but it seems that sharing memory on a core is the only efficient way of overcoming my timing/latency problem. The shared memory buffer needs to be written by one thread, and read by another (like the XFIFO example). Could you post the outline of a trivial example of showing how one thread can write to a variable, and another thread on the same core read it (in a multicore application) please?

Regards,

Robert Jarnot

[lilltroll]

See if you get this one:

http://www.xcore.com/forum/viewtopic.php?p=3217#p3217

I have a high-speed example as well - but not here on my laptop.

[jarnot]

Thanks for pointing me to the example, which is clear and makes sense. The problem, as pointed out by Folknology, is that I am allocating threads onto cores (fast input and modest speed output on one core, Ethernet on another, and I would like to use a third core in the future for additional tasks) and this prevents the solution in http://www.xcore.com/forum/viewtopic.php?f=10&t=420 from being something that I can adapt and use.

I can read in my 262,144 bit serial data frames at ~4 MHz (2 bits at a time) without difficulty, and perform some compression to halve their size, but moving the data to the Ethernet core takes sufficiently long that I miss the start of the next frame, thus processing every second data frame. Moving each frame to another thread on the same core seems like a waste of time -- it is an unnecessary memory to memory move which does not seem to solve anything. Moving the data blocks to one or more threads on another core seems to move the problem, not fix it in a clean way.

Being able to write to alternating memory areas in the thread which reads the 262,144 bit frames would solve the latency problem, but only if another thread could share those memory areas (and some additional control words to keep things synchronized as in the FIFO example). It seems that placing threads on cores forbids this kind of implementation, and I keep thinking that I am missing something important that leads to an 'obvious' solution.

[jarnot]

Problem resolved -- it turns out the that the actual hardware to which I was interfacing did not function quite as the documentation indicated, but my XMOS simulator for the hardware did correspond to the documentation. The end result was that with the real hardware in place the data capture thread had less than a microsecond to achieve the impossible, rather than the ~30 ms that I was expecting. With a simple change to the XC code the 30 ms was restored, and now I do not even need a thread to buffer the data on its way to the ethernet thread. All of the advice/suggestions posted on here have helped me improve my understanding of the strengths and limitations of the XMOS architecture, and I now have a much better feel for why the XMOS implementation is the way it is. Thanks for your help.