Probably the most interesting aspect of this for me at least, was that when I was designing the (admittedly still rather crude) algorithm to determine how hard the pad had been hit, I needed to get the ADC samples off the chip so that I could experiment with algorithms offline and tweak their performance. I happen to have one of the rather wonderful Saleae USB logic analysers, and output all the ADC data as it receives it. Anyway, doing this I was able to get the samples back into my PC, and using python and pylot etc, plot handy graphs.
Here is how it’s done:
First, hook up the channels, and ground of course, onto the chip’s legs.
Start up logic, and start logging. Logic has selectable sample rates, and you’ll want something several times higher than the clock rate of the signal that you want to process. I normally take a look at what the clock signal looks like – for instance, the clock is not that clean at 4Mhz with a 500Khz I2C bit rate.
At 16Mhz it’s a bit better, and it’s probably ok.
Now set up the I2C logic analyser in logic, telling it which of the signals is SCL, and which is SDA. All being well, logic should now visually annotate your SDA trace with the start/stop events and the data bytes that are being transmitted
It’s time to export the data. Select export as a CSV file, and you’ll end up with a file containing data like this:
I2C has the advantage of dividing the data up into packets – though the not insignificant twin disadvantages of limited bitrate and the requirement to have something listening on the other end to ACK your packets. Logic saves its CSV files with a packet ID, which didn’t start from zero here because the first 81 packets were not acked by the second micro. In this case that second micro happened to be in the process of reading and verifying its non-volatile memory.
Now we’ve got the file, we can use python to pull it out the numbers and do something useful, using the packet IDs to group together packets and recover the data. In this instance, I want to pull out the six ADC channels that my device is listening to, and plot them before I start to think about how to trigger from them. Python is not my first language, and I tend to err on the verbose side, so please don’t judge. In keeping with the spirit of python, you can’t use my script until you’ve installed a module – in this case pylab. I can plot each of the six inputs, using different colors, to see how each of the piezo pickups reacts when I hit each of the pads with a drumstick once. Zoomed out, we see
And zoomed in to a single hit, we can see how each individual pad reacts. Knowing the sample rate (about 40kHz), we can even see how much time elapses before the piezo transducers under the other drum pads react – about ten samples, or about 250 microseconds. Sound travels about 8cm in that time, which is approximately the distance from one pad to the others. Which isn’t even slightly important really, but it’s nice to see the numbers more or less work out.
I2C Clock rate
We can see that the clock isn’t even able to rise to Vcc before it gets driven back down to ground. 500Khz is probably the maximum achievable clock rate on my setup, but this ceiling can be raised by using smaller pullup resistors. Conveniently, it looks like the circuit capacitance gets charged back up to about 60% or so of Vcc, and we can measure from the plot below that this takes about 1.2us, which gives a capacitance of about 0.1nF. The msp430 datasheet lists the input capacitance of the GPIO pins at 5pF, leaving quite a bit of stray capacitance to account for. Of course, stripboard is notorious for parasitic capacitance, so this is easy to hand-wave away. There’s 28pF in the scope’s input too, which may or may not matter.
At the clock rate that I run when not sitting on this bleeding data-rate edge – about 100kHz – things look much healthier.
Hope this tip comes handy in your debugging adventures.