This is a writeup about a project, that I chose to do as course work for a course in university.
The idea stemmed from two things
- The course was about programming MSP430 microcontrollers
- I am fond of synthesizers and audio related devices
The goal was to make a device with which you could interact and it’d create a sound depending on these interactions.
So I made a quick “sketch” of the device in my mind and this is what I came up with:
The device would be a sort of a touchpad which would output sound depending on the x-y position of the user’s finger.
I’ll list a few considerations that were made during and after the making of the sketch:
The part I was most unsure and excited about was MTCH6102 which is a chip I’d seen previously when I’d researched various capacitive sensing devices and it piqued my interest since it’s at a very interesting price point for it’s feature set. It is a 15 channel x-y mapping capacitive touch sensor priced at around 2$ a piece in small quantities. It needs a matrix of specifically shaped copper and it can sense single-point touches on it with a quite high resolution (576*384 with a 9*6 copper matrix).
I also had another idea for the original board, which I soon abandoned - an SMPS power supply to provide the oomph for the whole board. The MCP1624 which I had a dabble with before, while doing a gameboy-type-of device (writeup soon to appear on this blog), seemed like a good candidate, but I decided it was a too risky endeavour, since the SMPS’s high frequency impulses might mess with the capacitive sensing device, so instead I opted for just an LDO (LD1117-3.3).
Initially having considered the MSP430F5510 with it’s plethora of peripherals and bells and whistles (most importantly USB and a hardware multiplier), for cost saving purposes I chose to use an MSP430G2553 as the main brain of the operation, which would handle the sound output and configure and use the touchpad controller.
For the DAC I chose the cheapest Farnell offering, which ended up being the AD56X1 series DAC; these have three options (X = 0/8bit; 1/10bit; 2/12bit) which are all simple three wire SPI DAC’s (MOSI, CLK, ~CS).
As the amp I chose LM4667 which seemed simple to incorporate into the design and could fulfill the duties of outputting sound directly to a pair of earphones.
As an additional feature I decided to add an FT230X chip to the device to provide a potential direct link to a PC for this device. Unfortunately the MCU I chose didn’t feature enough SPI lines, so I ended up using the same TX pin for both the DAC and the UART, which would make simultaneous operation practically impossible.
After these considerations I came up with a schematic (click to view full image):
After a bit of toiling I came up with a PCB for it (click to view full images):
NOTE: Due to DipTrace’s weird colour-handling, it might seem that the QR code is actually on the copper plane - it isn’t. The grid pattern continues under the QR code.
So that much for the hardware, now for the software side of things.
The microcontroller has six distinct ways with which to interact with the outside world - the pushbuttons, LEDs, GPIO header, FTDI chip (UART), DAC (SPI) and the touchpad controller (I2C).
The originally essential parts of the device were - the touchpad controller and the DAC, so, since the MSP430 had two serial peripherals, each got it’s own (DAC - USCI A for UART/SPI and touchpad - USCI B for SPI/I2C). The FTDI’s UART pins were piggybacked on USCI A’s pins, because it didn’t interfere with the SPI transmissions and, if UART transmission was required, the DAC’s chip select would ensure that no gibberish would be output via the Audio port.
The debugging of the device is supposed to be done with a TI Launchpad using it’s Spy-Bi-Wire interface. The GPIO header of the developed board has the ~reset, test, vcc and ground pins provided, so it’s easy to plug the board into the launchpad and develop code for it.
Additionally, UART and I2C headers are provided, so that a user can easily acces these interfaces with a logic analyzer.
Given the devices connected to the microcontroller, a set of drivers had to be developed (since the code was to be read by other people and easily modified):
I2C had to have four basic capabilities - read/write single byte, read/write multiple sequential bytes.
SPI had to be able to send a byte or multiple bytes and call a function after the transmission is done.
UART was very loosely defined and ended up being a close copy of the SPI driver, due to great similarities in the peripheral handling.
At first the development was a snap:
- The touchpad controller works pretty much right out of the box and doesn’t need much fine tuning, if the environment doesn’t change too much.
- The DAC was quick to get working too.
- The amplifier left a bit to be desired, since there’s quite a bit of noise in the output when there shouldn’t be, however I rack that up to my inexperience with analog audio circuit design.
- The FTDI chip works wonderfully, transmissions go through without difficulties.
First I developed the I2C drivers and attempted to get data out of the touchpad driver. After getting the data out, I was pleased to note, that the chip did indeed nicely track the finger position on the touchpad, so that was pleasing.
Second, a 30kHz DAC DDS sine generation test succeeded perfectly (based on a timer interrupt). A bit of additional byte modulation (AND with various numbers etc.) also worked great. After starting to add the touchpad management I ran into a few problems though. First - the touchpad seemed to be getting interference. The most annoying part was that it was dependent on the code being sent via SPI. If it was constantly varying information (i.e. audio), the touchpad controller seemed to be picking some of it up and falsely detecting touches.
Also of note - initially I wanted to set the I2C routine in a specific timer interrupt, however that ended up hogging far too many cycles (I desperately wanted to retain the OOP form of the code, so going the highly-optimized-and-specialized subroutine route wasn’t an option). Since the interrupt flags can also be accessed in the main loop, the touchpad readouts were relegated to the main loop and the information was gathered there.
So after running into difficulties with the originally intended mode of output, I tried UART transmissions - these seem to work great, if the transmissions are relatively rare.
Unfortunately due to time constraints I was unable to develop more of the software, but as-is the project is capable of at least outputting the touchpad X and Y coordinates via UART.
Here’s a link to a repository where a recent debug snapshot of the code is held (CCS project). Do take into account that it’s not even close to final and isn’t properly sanitized and also contains a fair bit of deprecated stuff.
- Decide whether to remove the DAC functionality from the project or if it can be appropriated in some way.
- Polish the algorithm for rock solid operation (the MTCH6102 intialisation seems to be a bit tricky - chip sometimes sits in solemn silence after power-on 🙂 ).
Considerations for a future attempt
- A more capable microcontroller would greatly increase the fun factor of this device (signal modulation really needs a hardware multiplier)
- Greater care should be exercised while routing the high-speed digital communications, the device might benefit from relegating the high speed switching stuff to a seperate pcb/a farther corner.
- More attention should be paid to the audio amplifier circuit design, to avoid the quiet, but noticeable noise while the output is idle.
And finally a few pictures of the actual device