Chanend limit

Discussions about USB Audio on XMOS devices
maxter
Member
Posts: 14
Joined: Fri Jun 14, 2024 9:55 am

Chanend limit

Post by maxter »

I hit the chanend limit for a tile: one one tile in my project I have the USB stack with MIDI, ADAT (in) enabled, all on the same tile, on the same tile I need to add a task to drive some IO, and this task uses 2 chanends: 1 connected to the other tile to receive some data to drive the output and one connected to the MIDI task to receive the data on MIDI activity, to drive 2 LEDs.
With this configuration the compiler tells me that there aren't enough chanends on this tile.

I am fairly new to XC so I was wondering if it is possible to reduce the chanends used, by knowing that all those components (XUD, MIDI, ADAT) are on the same tile; or, would it be possible to remove the chanend I used to connect my task and the MIDI one and still have something I can use to drive those 2 LEDs?
User avatar
Ross
Verified
XCore Legend
Posts: 1070
Joined: Thu Dec 10, 2009 9:20 pm
Location: Bristol, UK

Post by Ross »

Could you provide a task diagram, photo of hand-drawn is fine, this would help us visualise and maybe come up with a solution.
Technical Director @ XMOS. Opinions expressed are my own
User avatar
Ross
Verified
XCore Legend
Posts: 1070
Joined: Thu Dec 10, 2009 9:20 pm
Location: Bristol, UK

Post by Ross »

I attach svg of a configuration of USB Audio you could also modify (recommend draw.io)
Untitled Diagram-1712835524237.drawio.png
usbaudio.drawio.svg.zip
You do not have the required permissions to view the files attached to this post.
Technical Director @ XMOS. Opinions expressed are my own
User avatar
fabriceo
XCore Addict
Posts: 222
Joined: Mon Jan 08, 2018 4:14 pm

Post by fabriceo »

Hi Maxter
yes you can certainly reduce the number of channels by sharing some memory location and flags across the Midi and your task being on the same tile.
But a channel is also a mean to trigger an action in a select case upon data reception, so you may also have to review your select case by enabling a "default" case which will continuously monitor some global variable to take actions that would have been triggered whiting a channel driven case.
Also you will soon realize when sharing memory across task that the compiler will throw a frustrating "parallel use" error.
And finally the compiler optimization may remove some code as you will hide the parallel usage.
Using C code instead of XC prevent the cross check of parallel usage. You could implement some cross-task routines in C and use them in XC.
Also this kind of code is working well:
int myglobalvar;
unsafe {
volatile int * unsafe ptr;
asm volatile("ldap %0,dp[myglobalvar]":"=r"(ptr));
if (*ptr) do-something-and-clear *ptr=0;
}

keep us posted
maxter
Member
Posts: 14
Joined: Fri Jun 14, 2024 9:55 am

Post by maxter »

Thanks for the schematics example, was very useful :)

Here attached there is my tasks' diagram.
task-diagram.drawio.png
Another option I was considering was to move the MIDI block to tile 0 (audio one), but since I run out of 1 pin ports I am not sure if it is possible to modify the MIDI block to use 4 pin-ports (for both RX & TX). Any insight on using 4-pin ports for the MIDI RX & TX lines? I see there is a define MIDI_RX_PORT_WIDTH which is expected to be set to 1 or 4, but I'm still confused whether it's for using pin 1 of a 4-pin port to drive the RX line or all 4 pins of a 4-pin port.
You do not have the required permissions to view the files attached to this post.