The project is built around the HC-06 bluetooth module and the Stellaris LaunchPad from TI, an inexpensive ARM developer kit. Building an ECG is a great way to learn about instrumentation amplifiers, a type of differential amplifier used for its extremely high common mode rejection ratio (CMRR). Please be sure to keep in mind that there are a myriad of safety issues and regulation concerns for medical device, and there is no doubt that an ECG is considered a medical device. Sadly, [Nuclearrambo’s] post does not include all of the code and design files you need to build the system, which is understandable considering this is a medical device. That being said, he provides a lot of information about building high-quality ECG instrumentation and the web interface.

It would be great if [Nuclearrambo] could post the Android application code and Stellaris LaunchPad code. Even with these omissions, this post is still worth reading. Designing medical devices requires a lot of know-how, but who knows, maybe your next project can save your life!

There’s so much affordable dev hardware out there these days that you can do a lot without even touching a soldering iron. This is a prime example. Texas Instruments software Engineer [Jordan Wills] recently completed this wirelessly controlled marble labyrinth.

Marble mazes like this are a popular targets for electronic tinkering. We’ve seen smartphones used as the controller, and others that dispense chocolate candy. This time around [Jordan] stuck with the store-bought game to simplify the build. A coworker helped by swapping the two control knobs with servo motors. These interface with a Stellaris Launchpad that has a SensorHub booster pack (shield) and CC2533 radio transceiver module. The same hardware makes up the remote unit as well. This turns the remote into an air mouse by reading the gyroscope, accelerometer, and magnetometer from the booster pack.

He doesn’t specifically mention it in his project log, but we think the magnetometer is used to sync orientation between the base unit and the user remote. Even though the board for the base unit is mounted at 90 degrees compared to how you hold the remote, you should still be able to adjust for the readings in code, right?

He’s using a 320×240 display which we ourselves have tried out with this board. It’s plenty fast enough to push image data in parallel, but if you’re looking for full motion video and audio we would have told you tough luck. [Vinod’s] math shows that it is possible with a bit of file hacking. First off, since the source file is widescreen he gets away with only writing to a 320×140 set of pixels at 25 fps. The audio is pushed at 22,400 bytes per second. This leaves him very few cycles to actually do anything between frames. So he encoded the clip as a raw file, interlacing the video and audio information so that the file can be read as a single stream. From the demo after the break it looks and sounds fantastic!

The Stellaris logic analyzer is based upon this earlier build that took code from a SUMP comparable Arduino logic analyzer and ported it to the much faster and more capable Stellaris Launchpad with an ARM Cortex 4F processor.

This build turns the Launchpad into a 10 MHz, 8-channel logic analyzer with a 16 kB buffer comparable with just about every piece of software thanks to the SUMP protocol. Even though the ARM chip in the Launchpad isn’t 5 Volt tolerant, only pins 0 and 1 on Port B are limited to 3.6 Volts. All the other pins on Port B are 5 Volt tolerant.

Not a bad piece of work to turn a Launchpad that has been sitting on your workbench into a useful tool.

[Sultan Qasim] wrote in to tell us about the work he’s been doing on the Stellarino library. It’s goal is to break down the coding barriers present for those looking to move from Arduino to ARM. This is accomplished by facilitating Wiring-stlye code for the Stellaris Launchpad ARM development board.

Right off the bat [Sultan] mentions that the interface is Wiring-like, but is not compatible with it. This means you can’t just plop your existing sketches into a C file and get them to work with the addition of a simple include file. But what it does do is provide access to the functions to which seasoned Arduino users have grown accustomed. You can see some examples above, including analogWrite(), digitalRead(), and a simple delay function.

We had a quick look at the library. It uses StellarisWare components which are stored in the ROM of the chip (these are all preceded by ‘ROM_’). The one thing missing is the UARTstudio library which apparently carries a license incompatible with GPL.

His first improvement with this project was to spin his own audio input board. It has a standard headphone jack for input and a few passive components to shift the signals to rest nicely within the ADC measurement range. The shield has two double pin headers and a group of four stand offs to serve as legs. This way it plugs into the female headers on the bottom of the Launchpad and provides a stable base for the assembly.

The second portion of the setup is an LCD booster pack for the hardware. Kentec manufactures this 3.5″ 320×240 LCD (EB-LM4F120-L35) complete with a resistive overlay making it touch sensitive. The increase in resolution, and availability of different colors gave [Jordan] plenty to work on. Since this add-on is designed for the Launchpad and has a driver library already available he was able to focus on adapting the FFT output for display and adding in new features. Don’t miss seeing what he’s accomplished in the clip after the break.

Using newlib instead of glibc offers the option of compiling C code that includes system calls common when coding for computers but which are rare in embedded systems. Using something like printf is generally avoided because of the overhead associated with it. But these processors are getting so fast and have so much RAM that it may be useful in certain cases. We briefly thought about implementing malloc for creating a linked list when working on our STM32 snake game. [Brandon’s] work here makes the use of that command possible.

The process starts by adding labels for the beginning and end of the stack/heap. This makes it possible for functions to allocate memory. After taking care of the linker script changes you must implement a few system call functions like _sbrk.