XMOS channels and ports

Technical questions regarding the XTC tools and programming with XMOS.
User avatar
pucur
Junior Member
Posts: 7
Joined: Thu Nov 30, 2017 9:22 am

XMOS channels and ports

Post by pucur »

Hello everyone,

I'm using a 4b port to indicate a bit rate and it works well, but now I need to use that port in another .xc file to indicate a 32bit rate. I've tried to make an "extern" and some other things, to somehow share that port with other files, but I always get an error. Does anyone know how to share it?
I've found that one solution is to use channels, but I'm really inexperienced, so it would be great if someone could help me with this.


Regards,
Filip
User avatar
Ross
Verified
XCore Legend
Posts: 1149
Joined: Thu Dec 10, 2009 9:20 pm
Location: Bristol, UK

Post by Ross »

You say "other file". Are you trying to access the port from another core?

What error do you have?
Technical Director @ XMOS. Opinions expressed are my own
User avatar
pucur
Junior Member
Posts: 7
Joined: Thu Nov 30, 2017 9:22 am

Post by pucur »

Hi Ross,

the port is on Tile1. I've placed inputselect.xc to Tile0 in "Makefile" with this line BUILD_OPTIONS += -DMQA_INPUT_SWITCHING -DMQA_I2S_INPUT -DINPUT_SWITCH_TILE=0
I did it because don't have any more space at Tile1.
In the folder: module_devkit_common -> Src are both files, devicehost.xc and inpuselect.xc. Ports are declared in devicehost.xc, but I'm also trying to toggle them in inpuselect.xc or to send the value of bitrate from inpuselect.xc to devicehost.xc and then there to set a value of port.

When I try with the extern out port p_bit_depth; (inpuselect.xc) where in devicehost.xs is on tile[1]: out port p_bit_depth = PORT_BIT_DEPTH; I get this message:

use of `p_bit_depth' violates parallel usage rules main.xc /module_usb_audio line 559 C/C++ Problem
User avatar
Ross
Verified
XCore Legend
Posts: 1149
Joined: Thu Dec 10, 2009 9:20 pm
Location: Bristol, UK

Post by Ross »

Pucur,

XC won't allow you to use the port from two cores - it is essentially "unsafe". Some ways you can deal with this:

- Access the port from one core only and use channels or an interface to interact with that core from other cores (this is the "XC" way and I suppose the purist xcore way)
- Use inline assembly to bypass the checks - you should use some sort of locking to ensure two cores will not access the port at the same time. Since this is an output port I guess you will be doing read-modify-write? This whole block should be locked some how to avoid race conditions and exceptions.
- Use C to do the above, C has no such checks, it's just C so allows you to do "unsafe" things.
Technical Director @ XMOS. Opinions expressed are my own
User avatar
CousinItt
Respected Member
Posts: 367
Joined: Wed May 31, 2017 6:55 pm

Post by CousinItt »

The GPIO library may help