A while ago, I spoke at Dorkbot PDX about using the Bus Pirate to explore devices with I2C interfaces. I’ve been remiss in posting my slides from that talk, so here they are:
I got my Bus Pirate today, just in time to talk to my project’s audio codec via I2C. It is no exaggeration to say the Bus Pirate saved me a metric crap-ton of time. In about ten minutes, I had the Bus Pirate hooked to the audio codec, figured out the text command interface, and started configuring the audio codec to interact with the microcontroller.
Here’s the Bus Pirate (red, foreground) hooked up to my audio prototype board (purple, in the background):
I’ve been through this before, the hard way. Bringing up new devices on the I2C bus can be tedious, and it’s hard to know what you’re doing wrong. Is my I2C peripheral driver bad? Or am I sending bad commands to the I2C device? Without a fancy logic analyzer, it’s hard to tell for sure. Now I can remove one variable from the process. I have a set of commands I *know* will correctly configure my audio codec, so later on, when I’m programming the microcontroller to do the configuration, I can rule out having a botched or malformed set of I2C configuration commands. Woo hoo!
Oh, wait. I still need to write an I2C driver for the STM32 microcontroller… Eeeew.
So that now I have the processor running full-blast at 120MHz, it’s time to get the audio stuff working. It didn’t take long, really. I just had to get the right multiplication and division factors in place, turn on the I2S peripheral and configure it (only two registers), and then enable the “alternate function” for the pins that I used to interface to the audio codec chip. And here’s what I get:
The 11.2896MHz MCLK signal, which is 256x the audio sampling rate (44.1kHz):
The 44.1kHz LRC (left/right clock) or frame clock:
Now to wire up the audio codec and try to speak with it via I2C. Perhaps I’ll start with my brand new Bus Pirate, then move on to doing it from the STM32.