How to transport USB connect status to Application between two tiles Topic is solved

Sub forums for various specialist XMOS applications. e.g. USB audio, motor control and robotics.
Post Reply
susanyin0501
Active Member
Posts: 45
Joined: Thu Apr 20, 2017 9:00 am

How to transport USB connect status to Application between two tiles

Post by susanyin0501 »

Dear guys
In order to indicate USB connect status (active or unactive, insert or not) with LED on front panel. first we should get USB connect status, then transport it to front panel display.
I can get usb status and transport it to front panel, but noise generated when playback audio. what shall we do? would you please help us!
USB runs on tile 0 and front panel runs on tile 1 with xu224 chip. as they runs on different tiles, USB connect status is transported with chanend communication. In order to update connect status at any time, i get usb connected status from while loop in decouple( ), then sent it out with streaming chanend, and receive it on other tile.
by the way, we can not change usb library routine, no way to add channed parameter for chanend communication in UserHostActive( ), so set and get global variable ( g_usb_sync) on the same tile, then send it out.
2.png
set status,which comes from USB Lib
(215.01 KiB) Not downloaded yet
2.png
set status,which comes from USB Lib
(215.01 KiB) Not downloaded yet
1.png
sent status to tile 1
(191.45 KiB) Not downloaded yet
1.png
sent status to tile 1
(191.45 KiB) Not downloaded yet
3.png
get status from tile 0
(220.4 KiB) Not downloaded yet
3.png
get status from tile 0
(220.4 KiB) Not downloaded yet


View Solution
User avatar
infiniteimprobability
XCore Legend
Posts: 1126
Joined: Thu May 27, 2010 10:08 am
Contact:

Post by infiniteimprobability »

What is likely happening here is that the output to usb_sync is blocking because the other end is not consuming the token immediately. This will effectively put a delay in decouple and cause it to block which in turn will assert backpressure to audio and may result in i2s being stretched.

There are a few ways to solve this. You could:

- ensure the other end is always ready to receive (could be expensive as you may need to dedicate a thread)
- just do a outuint(usb_sync, flag) which will send a data token (rather than full ack'ed and synced transaction) and not block if the buffering between tiles is not full (it takes about 5 ints I think cross tiles). Even better only send it if it changes. You could have a static variable to check if it changes and only send when needed. The other end (receiving) can do a channel poll the channel but timing is much more relaxed. A channel poll can look something like:

Code: Select all

   select
        {
            case inuint_byref(usb_sync, flag):
            ...
            break;

            default: 
            break;
       }
As long as you empty this end more frequently than you fill the other then decouple will never be blocked.
Post Reply