Multi-processing problem in startkit ADC example

All technical discussions and projects around startKIT
ahmet
Junior Member
Posts: 6
Joined: Sat Oct 29, 2016 3:05 pm

Multi-processing problem in startkit ADC example

Postby ahmet » Thu Nov 03, 2016 11:22 am

Hi everyone,

I am a newbie in multi-core processor programming. I'm trying to understand the performance of XMOS processors. I'm toggling some LEDs and watching the timing delays. I can see time delays when I use "print" function.

main function is;

Code: Select all

int main() {
    chan xscope_data_in;
    startkit_adc_if i_adc; //For triggering/reading ADC
    chan c_adc;

    par{
        on tile[0]:task1(); // LED toggle
        on tile[0]:task2(); // some LED animations
        on tile[0]: adc_task(i_adc, c_adc, 0, adc_sample);
        startkit_adc(c_adc);
        on tile[0]: app(i_adc);
    }
    return 0;
}
app function is;

Code: Select all

void app(client startkit_adc_if i_adc)
{
    timer t_loop;
    int loop_time;
    unsigned short adc_val[4] = {0, 0, 0, 0};
    t_loop :> loop_time; 
    loop_time += LOOP_PERIOD; //Set comparison to future time
    while (1) {
        select {
            case t_loop when timerafter(loop_time) :> void:
                i_adc.trigger(); //Fire the ADC!
                loop_time += LOOP_PERIOD; //Setup future time event
                break;
            case i_adc.complete(): //Notification from ADC server when aquisition complete
                i_adc.read(adc_val); //Get the values (and clear the notfication)
//                for(int i = 0; i < 4; i++){
//                    printstr("ADC chan ");
//                    printint(i);
//                    printstr(" = ");
//                    printint(adc_val[i]);
//                }
//                printchar('\n');
                break;
        }
    }
}
There is no problem if app function is like this. Bu when I uncomment print lines, processor can not perform LED toggle on time. According to the "task viewer", task1 : task2 : app : adc_task functions are running on different processor cores. If so, why these "print" functions cause trouble?
ahmet
Junior Member
Posts: 6
Joined: Sat Oct 29, 2016 3:05 pm

Postby ahmet » Thu Nov 03, 2016 3:34 pm

Ok. But I don't understand how a multi-core "hard real time" processor stuck during jtag/debug (xscope) communication? Why all cores stop, why doesn't a single core do this mission.
User avatar
mon2
XCore Legend
Posts: 1849
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Thu Nov 03, 2016 3:55 pm

multi-core "hard real time" process
The XMOS devices are 'logical cores' not hardware cores.

http://www.xmos.com/products/silicon#xcore

http://www.xmos.com/download/private/xC ... e(1.2).pdf

The above referenced methods will work fine to remove the raised issues. When implemented properly, the XMOS devices are quite unique and can only think of FPGA devices out ranking their performance. Each solution has pros and cons.

For XMOS, many available freeware IP for audio (they are the top of this game); parallel processing; USB 2.0 HS / LS; Ethernet (10/100/1000 Mbps); serial UARTs, etc. No charge compiler for code development / debugging.
ahmet
Junior Member
Posts: 6
Joined: Sat Oct 29, 2016 3:05 pm

Postby ahmet » Thu Nov 03, 2016 4:27 pm

Thank you mon2. Now, I got the point. Our company produces industrial control systems. We usually use FPGA or "classical" processors. I'm trying to find a processor family which could perform lots of math in ~1 millisecond. Filters, PID algorithms, ADC reading, motor driving etc. FPGAs are good for this work but it's an expensive solution in terms of firmware development and also processor prices. xCORE processors seem good to me. But the documentation is very scattered :)
User avatar
mon2
XCore Legend
Posts: 1849
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Thu Nov 03, 2016 4:48 pm

But the documentation is very scattered :)
Yes. However, XMOS is most definitely worth a deep review before discounting for alternative technology. XMOS is the middle ground between traditional microcontrollers and FPGA devices.

While not in the motor controller biz at this time, here are some quick URLs that may help:

https://www.xmos.com/support/boards?sub ... 825&page=1

https://www.xmos.com/support/boards?sub ... 825&page=5

The latest version of the XMOS processors is the XCORE-200 line. Recommend that you consider these devices for any custom design. Assorted kits are now available through Digikey, etc. that are based on the XCORE-200 series of processors. They offer Ethernet (Gigabit), USB 2.0, with or without onboard flash memory versions. A few new command features were also added to the XCORE-200 over the older XS-1 series.

http://www.xmos.com/products/silicon/xcore-200

XS1 details:
http://www.xmos.com/products/silicon/xcore/l-series

The website contains a wealth of information and Google searches will also assist in your learning curve. Be patient and believe the investment will be worth the effort.

Here are some teasers on XMOS based projects:

http://www.xmos.com/news/videos/17714

http://www.xcore.com/forum/viewtopic.php?t=2463&f=27

No RTOS used.

http://www.xcore.com/blog/sethu_jangala ... l-platform

As everything is software based (XC, C, assembly languages as compared to verilog / vhdl), the code development effort will be the largest investment. The CPU datasheets are quite refined and offer typical schematics for the power sequencing, flash hookup and also how to stitch other processors together. With XMOS you can stitch multiple processors together who will then communicate with each other using LVDS interfaces to sub-divide your tasks as required. Many options to explore.

Who is online

Users browsing this forum: No registered users and 0 guests