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!
Adding i2c devices to USB Audio 2.0 MC Dev Board
-
- Junior Member
- Posts: 6
- Joined: Mon Jan 02, 2012 6:32 pm
-
- Member
- Posts: 11
- Joined: Tue Aug 02, 2011 3:24 pm
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!
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!
-
Verified
- XCore Legend
- Posts: 1163
- Joined: Thu Dec 10, 2009 9:20 pm
- Location: Bristol, UK
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.
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.
Technical Director @ XMOS. Opinions expressed are my own
-
- Junior Member
- Posts: 6
- Joined: Mon Jan 02, 2012 6:32 pm
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
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
-
Verified
- XCore Legend
- Posts: 1163
- Joined: Thu Dec 10, 2009 9:20 pm
- Location: Bristol, UK
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)
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)
Technical Director @ XMOS. Opinions expressed are my own
-
Verified
- XCore Legend
- Posts: 1163
- Joined: Thu Dec 10, 2009 9:20 pm
- Location: Bristol, UK
It sounds like this configuration control would more naturally fit into Endpoint 0?
Technical Director @ XMOS. Opinions expressed are my own