xCORE 200 MC: r_i2c violates parallel usage rules
Posted: Mon Apr 18, 2016 11:59 pm
Hi there,
I'm using the xCORE 200 MC audio design as the basis of a new audio board. The new audio board shares the I2C bus with the analog codecs (different codecs from the ones on the MC board).
My question is: how do I get the volume command (which comes in from endpoint0), to change registers in the codec?
The current problem is:
endpoint0 is on tile[XUD_TILE] but the i2c bus is on AUDIO_IO_TILE. So, the problem would appear to be solved by creating an interface where endpoint0 calls an interface method over to the AUIO_IO_TILE.
However, the thread that holds the reigns to r_i2c (the i2c ports), is the 'audio' thread because it's what calls AudioHWInit, etc.
But the audio thread doesn't seem to have a select {} that I can hook into to write the I2C bus.
I tried using another core to receive the new interface commands, but I get the r_i2c 'violates the parallel usage rules' error message because the audio thread still 'holds' onto r_i2c.
How can share the r_i2c object so that 2 threads can write to it (the audio thread when changing sample rate, and my i2c_message thread when messages come in from endpoint 0 ? ).
If I can't share, how about transferring ownership so that it's used for AudioHWInit at init time, but from then on, it's owned by the i2c_message thread?
Thanks,
-Caleb
I'm using the xCORE 200 MC audio design as the basis of a new audio board. The new audio board shares the I2C bus with the analog codecs (different codecs from the ones on the MC board).
My question is: how do I get the volume command (which comes in from endpoint0), to change registers in the codec?
The current problem is:
endpoint0 is on tile[XUD_TILE] but the i2c bus is on AUDIO_IO_TILE. So, the problem would appear to be solved by creating an interface where endpoint0 calls an interface method over to the AUIO_IO_TILE.
However, the thread that holds the reigns to r_i2c (the i2c ports), is the 'audio' thread because it's what calls AudioHWInit, etc.
But the audio thread doesn't seem to have a select {} that I can hook into to write the I2C bus.
I tried using another core to receive the new interface commands, but I get the r_i2c 'violates the parallel usage rules' error message because the audio thread still 'holds' onto r_i2c.
How can share the r_i2c object so that 2 threads can write to it (the audio thread when changing sample rate, and my i2c_message thread when messages come in from endpoint 0 ? ).
If I can't share, how about transferring ownership so that it's used for AudioHWInit at init time, but from then on, it's owned by the i2c_message thread?
Thanks,
-Caleb