Adding i2c devices to USB Audio 2.0 MC Dev Board

Technical discussions related to any XMOS development kit or reference design. Eg XK-1A, sliceKIT, etc.
markgtr813
Junior Member
Posts: 6
Joined: Mon Jan 02, 2012 6:32 pm

Adding i2c devices to USB Audio 2.0 MC Dev Board

Post by markgtr813 »

I am working with the USB Audio 2.0 Multi-Channel dev board and have a question about adding some functionality to the provided demo code.

I would like to add a microcontroller to the i2c bus and provide mixer parameters (like audio channel mapping, mixer node values). Presently, the communication link is functioning. The problem I am experiencing is that I cannot find a good place to call I2cRegWrite() and I2cRegRead() without causing build failure (violating parallel usage rules) or interfering with the audio performance.

The microcontroller may either be be polled or provide an interrupt/data-ready signal to the XMOS. Currently it just polled.

The solution eludes me for two reasons: I am still working to understand the multi-core & multi-thread capabilities, and the flow of the provided demo code has been difficult to follow.

I would like to find out what suggestions or insight the XMOS professionals can offer. Thank you for your guidance!


sivakumar
Member
Posts: 11
Joined: Tue Aug 02, 2011 3:24 pm

Post by sivakumar »

HI,
You could learn about the parallel usage rules from this page.

http://www.xmos.com/published/xc_en?page=2

If you are getting the build error messages when you add the i2c function, make sure you don't use the function in more than one thread. Calling the function in 2 or more thread causes the ports to be used in more than 1 thread thereby breaking the thread disjoint rule.

You may download the tested i2c software component from https://github.com/xcore/sc_i2c

Keep your progress posted.

Cheers!
User avatar
Ross
XCore Expert
Posts: 968
Joined: Thu Dec 10, 2009 9:20 pm
Location: Bristol, UK

Post by Ross »

The the reference design code-based the i2c ports that are shared on the expansion connector are used to configure the CODEC and clock multiplier (called from audio.xc if my memory serves me correctly).

You need to device a safe way of accessing these ports (ideally using them in the same thread). If you really need to access them from separate threads you could guard access using a lock or similar.

You could always use separate ports if that is easier, especially if you are not using things like MIDI, S/PDIF etc.
markgtr813
Junior Member
Posts: 6
Joined: Mon Jan 02, 2012 6:32 pm

Post by markgtr813 »

Thanks Ross.

My solution right now has been to make a separate i2c bus using the 1-bit ports assigned to MIDI along with the thread assigned for it. Ideally I would like to find out where I can do frequent i2c communication within the original thread (the audio thread) so I can regain the MIDI I/O and thread. I would like to find out if doing so (i2c communication inside the audio thread) would make the audio thread incapable of continuous audio I/O.

Thanks,
Mark
User avatar
Ross
XCore Expert
Posts: 968
Joined: Thu Dec 10, 2009 9:20 pm
Location: Bristol, UK

Post by Ross »

You could quite easily upset the real-time performance of he audio thread (i.e. I2S) by adding I2C I should imagine.

I don't know who many channels you have or what sample frequencies you are running, you may be able to fit them in - ideally use XTA to time the I2C read/write and go from there.

(The PLL/CODEC config only occur and sample frequency change, so the I2S does not need to be running at these times so no issue there)
User avatar
Ross
XCore Expert
Posts: 968
Joined: Thu Dec 10, 2009 9:20 pm
Location: Bristol, UK

Post by Ross »

It sounds like this configuration control would more naturally fit into Endpoint 0?