More help with Channels, trying to send tokens both ways

Technical questions regarding the XTC tools and programming with XMOS.
bearcat
Respected Member
Posts: 283
Joined: Fri Mar 19, 2010 4:49 am

More help with Channels, trying to send tokens both ways

Post by bearcat »

All, I am still not successfully been able to send control tokens across a channel in both directions. 2 L1's with a single XLINK between them. Here's my setup:

Single Streaming Channel:
Core 0 - May send three different custom application tokens (0x20-0x24) / data word. Then send two words.
Core 1 - Process tokens / data word, then receives above and returns 2 words.

The above works great. Core 0 can send tokens and data and Core 1 return data all day long. But now I need to occasionally send tokens back to Core 0 for special data. I do not have enough bandwidth to always send extra words, nor can I use a second channel since I only have a single link.
When I take the same code and replicate on the other core, I get an "illegal resource" trap on Core 0 just after processing a control token / data pair from Core 1. Everything works before sending the token from Core 1 to 0. The same code works from 0 to 1, but traps from 1 to 0. Here's a code snipet for the receive token code:

Code: Select all

        if (stestct(c_couple))
        {
            switch(sinct(c_couple))
            {
                case DSP_CT_FREQ :
                    ....
                    break;
         }
        c_couple :> temp; <-Traps here on Core 0
Any comments or suggestions?


bearcat
Respected Member
Posts: 283
Joined: Fri Mar 19, 2010 4:49 am

Post by bearcat »

Well, to answer my own post. My code snippet was not compete enough for the answer. Will post more complete code next time.

Well, I now know that XC will use the data type of the input variable to determine how many bytes to input from a channel using the :> operator. I had declared a short as the input variable for later processing as a short. But that causes only 2 bytes to be input, instead of the expected 4.

Working now.