XMOS xCORE-USB sliceKIT

I have seen errors concerning lack of guarded statements before, and usually that occurs if an interface has been defined with functions that are not used in the select statement. When that occurs, I put a "case xyz():" and "break;" statements into the select portion of code, just as a stub until I get round to adding more code. Also, I've not currently encountered a situation where I will need to filter out events (I am sure it will happen to me eventually) so I've not used [[guarded]] so far as mentioned.

For training, it is worth checking with XMOS in case they are aware of any - not saying any training will be free or not (I have no idea) but perhaps they know of instructors who run courses from time to time. So far I have just relied on documentation, so probably I'm underusing bits of functionality.

The single best piece of advice I have, is that it is worth drawing out and defining your interfaces on a diagram with all the tasks you plan to use. I don't know what the diagram is called, but it is a typical message sequence type diagram I suspect. I used that method in three XMOS posts, click here for the link to the first post. The diagram was used in parts 2 and 3.

I would say stick with it, because it solves some problems that ordinarily might need dedicated hardware in a CPLD or FPGA, and those are not straightforward to use either, so this provides a good blend of features with C programming and the handful of extensions.

Hey Shabaz,

Thanks for the comment. I have had a really bad time with interfaces trying to add an extra interface to the AVB-DC application in an effort to pass data to the SPI task with in the MODULE_FLASH code. I kept getting a ton of errors about guarded statements until finally I chose to stick my added application code on the same core as the Module_flash code.

I have found the forums are some what helpful and standard peripheral stuff is pretty easy to get going but trying to modify large applications that have library dependents is a pain in the A%$. We are really concerned with choosing this platform for our project with little to no formal training available through XMOS. Whats worse is they don't seem to have a plan in place to do so.

I sat for about three days trying to mimic the interface example code with two tasks (clients) talking to a single server. I was unsuccessful as I stated above.

Have yo had a different experience with XMOS support?

Hi,

I am familiar with the task-to-task interface procedures (certainly am no expert) but I've not had a need to use the [[guarded]] modifier so far. As I understand, usage of the task-to-task interface should be no different with the [[guarded]] modifier, it just (a) provides the ability to 'filter out' some IPC, for example if a message has been received and is currently being processed and no additional such message is to be handled until the processing is complete, and (b) also provides the ability to create an interface that doesn't need to be fully used in select statements until you want to do so. This is all theoretical understanding - as mentioned, I've not used the [[guarded]] bit so far.

Is that what you're trying to do? Does your comms work without the modifier, but not with? What issue are you seeing?

Hey All,

Anyone using the Slicekit? I am having some issues with the .XC syntax. Can someone please explain how to use [[guarded]] on a task to task interface?

Congratulations all, I'm interested to learn more about this product. For some reason, I thought this roadtest was closing on the 15th, so unfortunately I wasn't in the running for this one :-)

again, you dont give your sample size N.

N is how many times you will measure your signal with ADC, before you do FFT
if N is two, you can measure DC and 250Hz power. N gives resolution to your fft, and only based on sample size and sampling frequency you can do some calculations, how much time will it take to make one.

Hi Linas,

Yep, I have made an equivocal question: sampling frequency → sampling rate of input signal. Via Shannon-Nyquist, the expected frequencies are below 250 Hz.

Thanks your remark!

Norbert

When you write question, you should supply all information.
FFT from 500Hz samplig can teke anywhere from 1ns to 10 years, question is sample size, or resolution of your FFT in Hz

With STM32F407 i was able to make 50,000 single point FFT for 128 point array, or around 1-5k full FFT, all in f32. This mcu should hae 4x more performance based on MIPS

Hi Steve,

What is your opinion, the XMOS xCore can be able to analyze the frequency components in real time? My expected terms of use: Short-time Fourier Transform in multichannel environment (optimal: 3 phases; at least 2 phases), the expected frequencies are below 250 Hz (sampling frequency: max. 500 Hz). It is possible with the xCore?

Thanks your answer!

Best regards,

Norbert Kovács

Hi Linas,

The clock is 500MHz, and there is a pipeline type structure (in this case 4 stages), meaning that the throughput will vary (e.g. due to pipeline stalls or intentionally due to instructions or I/O) depending on the actual instructions, and so the clock speed in MHz alone doesn't tell the entire story. As a result, if you're running computation only in a single core, the throughput will be anything from 125MIPS to 500MIPS, but 125MIPS will be guaranteed (500/4 = 125). This is under-using the device, since ideally you want to be using multiple XMOS cores, to get most use out of it. There are two separated tiles on the chip, which is how the 1000MIPS figure arises.

I can't find xMOS processor maximum clock frequency. i know, it does say 1000MIPS, but i am more interested in MHz, since i know that my application need high real time computation power, and can't be disassembled to share computation with other cores. That means, if single core can't do computation in real time, it is a bad day for me

I have been working with the XMOS General Purpose Slice Kit for a couple months now. There is a learning curve involved due to the "xc" language extensions and the hybrid architecture XMOS uses. I spent some time learning how their documentation is set up as well as going over their web site often. They seem to have recent updates and continuous additions to the information out there for developers. There have been some "a-ha" moments for subtle details which took some time to discover but for the most part it has been a fun process learning the XMOS world.

I have stayed at a fairly surface level, using some standard embedded protocols like SPI bus and I2C in an effort to move a personal project along but over all after some time I feel this platform will be very useful for special applications. XMOS has been responsive when we reached out to them and said hello as well as answered some questions when we have had them. There is a XMOS community which seems to have some good support. 

In the next six months my team will be using the XMOS for some heavy networking applications and I hope to become fluent with their platform. I hope to see XMOS grow in the coming years.

Steve

Very interesting and useful concept - a little like bridging the real-time divides between FPGA and microcontrollers by throwing cores at the problem. But I also suspect the learning curve might be a little steep to get the most out of it - especially for those who haven't worked with heavily multi-threaded code. Would be very interested in seeing what people end up applying this to.

- Gough

A 16 Core MCU , and I was a fan of Parallax propeller  

This is very interesting roadtest. I like high end arm's because i need lot of computation power, maybe this can be used for parallel signal processing