The screen that we watch TV on at home has build-in speakers, but, because it’s actually a computer display, hasn’t got an infrared receiver. This made it impossible to set the volume with the TV receiver remote. I recently bought some Stellaris LaunchPad development boards and figured this was the perfect opportunity to make something useful with one.
The idea is to receive and decode IR signals with a microcontroller and increase or decrease the volume with a digital volume control when the correct command is received. The inputs to the volume control come from the headphone out of the TV, the outputs go to a pair of active speakers.
I decided to build my circuit around a development board I recently bought from Texas Instruments for a discount price of €4.20. It’s a Stellaris LaunchPad, which sports an ARM Cortex-M4F (TI LM4F120H5QR) that can run at up to 80 MHz. There’s a build-in USB debug interface on the board, and in- and outputs are provided on two 2×10 headers.
In high school, I designed a few audio circuits and I had some TI PGA2310 chips lying around from back then. These are high quality 8-bit digital audio volume controllers with zero crossing detection. This means that they switch the volume when the audio signal is at 0V, so that there’s no audible pop from the speakers. For the infrared receiver, I used a Vishay TSOP38238, which has a built-in filter for reception of 38 kHz signals, the frequency at which most TV remotes work. I wanted to use a cheap 5V power brick to power this circuit, and the PGA2310 requires at least 4.5V as its positive supply, so splitting the 5V into ±2.5V was out of the question. Instead, a charge pump, the TI LM2662, is used to generate -5V. This IC requires just two external capacitors in order to invert its positive supply voltage to a negative output voltage. Those chips, with a healthy dose of LEDs sprinkled on top for user feedback form the hardware part of the circuit. You can find the schematic below.
The circuit was build on a dual-layer prototyping PCB I got on eBay. Most of the components are though hole, but I used SMDs whenever I could (e.g. for all the capacitors). The LaunchPad board plugs neatly on top of this. I added a small 3 pin header to the underside of the LauchPad in order to be able to use its on-off switch for the supply voltage. Below are a few pictures of the result. There are so many wires on the bottom of the board because all ground connections are tied to a central star ground connection.
Putting the hardware together only took a single evening. Getting the software for the microcontroller to work though, took me quite a bit longer. First of all I had to get the IDE setup, which is quite straightforward, but still takes a while. Luckily, I found a great set of tutorials on how to set up a toolchain, debugger and IDE for the Stellaris LaunchPad on linux on the Kernel Hacks blog. Unfortunately, I did not get the debugging working perfectly. In hindsight, it probably would have saved me a ton of time if I had.
The software itself consists of two parts: decoding incoming IR signals and setting the attenuation of the PGA2310. In order to correctly decode the IR signals, you have to know which protocol is used by the IR remote. Since I couldn’t find any information on my remote, I decided to use the IRMP library (site in German). This is a really nice, highly configurable piece of software that supports 30+ protocols, hash build in hooks for debugging, … Interfacing with the PGA2310 only required setting up the LaunchPad’s SPI module.
Although integrating IRMP, the SPI interfacing and the tiny bit of logic required in little time, the software would run haphazardly on the LaunchPad. After many evenings of debugging and trying different build options, it seemed that the problem was due to stack corruption. Switching to the linker script provided by eehusky on his GitHub repository solved the problem.
It took a few evenings, but: mission accomplished! The TV’s volume can now be changed with the IR remote. As you can see, the complete system is a neat little stack:
What I take away from this project is that there’s few reasons left to use 8-bit controllers for most projects. I used to use Microchip PIC chips, however, C compilers for PICs are notoriously buggy, so you are often forced to write in assembly. When using the 32-bit ARM Cortex-M chips you can still use assembly, but because you want to, not because the toolchain basically forces you to. With the current prices of 32-bit ARM microcontrollers (Farnell sells ARM Cortex-M0’s for €1.39), the only reason I can think of to use an 8-bit micro is if you really need one in a DIP package.