I'm looking at using a TLV320AIC3254 controlled by a MSP430 microcontroller.
It seems that the AIC3254 has two types of interface:
Audio Data I/O Interface: can be left/right justified, I2S or DSP format.
Control Interface: I2C or SPI.
I assume that digital audio data cannot be transmitted via the I2C or SPI. How do you set up a MSP430 to use the digital audio interface?
Please do not move this thread. It already appears in the MSP430 Forum (http://e2e.ti.com/forums/p/7183/28072.aspx#28072) and should be in both since it straddles both topics.
Thanks!
Derek
MSP430 only has I2C/SPI interface as you have already noted. You would either bit bang an I2S on a MSP430 or use a DSP for audio data.
This may be a question better suited for the Audio forum:http://community.ti.com/forums/default.aspx?GroupID=21
Please post it there as well.
Unfortunately I do not have the processing power of a DSP in my low-power solution.
What I do have is the audio codec, which would sample mono speech at a low rate (eg, 8 ksamples/s), perform some compression in the miniDSP (eg, A-law/mu-law down to 8 bits/sample) and then send these data to an MCU to be packeted and transmitted by an RF chip (possibly using a CC430 device for both the MCU and RF chip). Larger MCUs include ADCs and DACs to do this (such as the FG4618 found on the experimenter board) but we're trying to reduce the chip count and size.
Is it easy to set up a bit bang I2S for one byte for symbol in an MCU? I've used the UARTs for RS232 interfaces and SPIs, but I've never written bit bang code. I presume the bit bang code could trigger a DMA via an interrupt to move the captured byte into a buffer.
As for forum locations, I previously put this post in the Audio Forum and a helpful moderator moved it here. The question straddles both topics so it belongs in both.
The digital audio interface on the AIC3254 is fairly simple (DSP-interface mode configuration, see AIC3254 datasheet, chapter 5.18.1.4):
* Bit clock: This signal can be generated by the AIC3254. Each bit of the audio data is available (ADC) or read (DAC) on the rising or falling edge (configurable) of this signal
* Data (DIN & DOUT): The left channel bits (e.g. 16, if configured for 16-bits) is put out on DOUT (ADC) or read from DIN (DAC) paced by Bit clock followed by the right channel data.
* Word clock: This behaves like a frame sync signal. The digital audio data starts for example after the falling edge (configurable) on the word clock. This signal can be generated by the AIC3254
A "bit-bang" implementation to read the ADC data may look like this:
* connect word clock to a general purpose input on the uC (GPI1)
* connect DOUT to a general purpose input on the uC (GPI2)
* hook an interrupt service routine (ISR) to the interrup generated by the word clock falling edge on GPI1
* connect an appropriate MCLK to the AIC3254 and configure the AIC3254 (via SPI or I2C) for the desired sample rate (e.g. 8kHz), signal path (mic in -> ADC -> miniDSP -> digital audio interface (DSP mode, Bit clock & Word clock master mode), etc.
--> the AIC3254 will start to convert audio data with the desired sample rate. It will trigger the interrupt service routine for each new audio frame (both channels - you can simply ignore the right channel).in the ISR (which will run 8000 times per second, in case of 8kHz sample rate), write code that reads the digital value of GPI2 and shifts this into a data word for the left channel:
Pseudo Code:
uint8 audio_data = 0;uint8 current_bit_number = 0;for (all 8 bits){ audio_data |= GPI2 << current_bit_number++; delay_for_one_BCLK_cycle(); // this just waits for the time it takes to transfer one bit from the codec (depends on BCLK frequency)}
Depending on the BCLK frequency and the sample rate, this will cause more or less load on the uC. The higher the BCLK frequency and the lower the sample rate, the less load.
Thanks for this. This is exactly the kind of confirmation I needed and it all makes sense to me.
Just to confirm, the DSP mode words are aligned to the falling edge of the word clock. The datasheet (SLAS549A) is ambiguous because the text states falling edge but the diagrams show the left word's MSB starting on the rising edge.
I presume that the AIC3254 could generate a bit clock (BCLK) and I could use this to trigger an ISR in the MCU to read the bit data and generate the word. Also, given that the word sizes for the audio digital I/O interface are 16, 20, 24 or 32 bits (Section 5.18.1) I would have to either read at least 16 bits or use the miniDSP to left-shift the compressed data so that it occupies the most significant 8 bits of the words and just read the first 8 bits and ignore the rest.
I did look but I could not find an application note describing how to interface audio codecs with MCUs. Does anyone know how easy it is to submit an application note to TI?
Thanks again,
DerekC I did look but I could not find an application note describing how to interface audio codecs with MCUs. Does anyone know how easy it is to submit an application note to TI?
Hi Derek -- I'm looking into this for you. Stay tuned!
It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change. - Charles Darwin
Derek,MSP430 has a new wiki. Here, everyone can contribute content while also hopefully using the information available. Would you be interested in posting an FAQ on How to Interface Audio Codecs with MCUs? You can post it here. Or would you be more interested in publishing an official application note?Regards,Nancy
The diagram is correct, the transmission starts with the rising edge. You can add an offset (in units of BCLK) to "delay" the data on DOUT.
It is possible to trigger an interrupt using BCLK - it'll be a significant load on the controller though. You can shift the bits with the miniDSP and read 8 bits only.
p.s. the pseudo code I suggested would result in a mirrored byte. It should be: audio_data |= GPI2 << (8-current_bit_number++);
Why would the triggering an interrupt from the BCLK be so onerous to the MCU? I'm planning to use a MCLK of 26 MHz, which will be 3250 cycles per 8 kHz sample. If the samples were 16 bit stereo that would mean the MCU has a maximum of 101 cycles to process each bit. The MCU only has to process the first 8 bits so the interrupt can be disabled after 8 bits and enabled at the start of the next word (as specified by the word clock). I would then copy the completed byte into a buffer ready for transmission.
For a low speed clock it is probably worthwhile entering a function triggered off the rising edge of the word clock and waiting for the first 8 bits. Of course the application should call the function promptly to avoid missing bits. Even if a delay is added to the start of the data it may not be possible to synchronise with the bit stream unless reception starts promptly.
I did notice the bit-order inversion. I assumed you meant "audio_data |= GPI2; audio_data <<= 1;"