Disclaimer: This page was created by D. Boyer.

All opinions expressed here are those of their author(s) and not of D. Raskovic

Handheld Media Player with Motion-Sensing Input

"Shake Player"

Devin Boyer

Department of Electrical and Computer Engineering

University of Alaska, Fairbanks

Fairbanks, Alaska 99775, USA

Project Description

My design project is a media player, which has the capability of playing many audio formats. It is based around a low-power MSP430 microprocessor from Texas Instruments, and utilizes a decoder chip from VLSI to decode media files in hardware. Data is retrieved from an SD card using the DOSOnChip media card interface from Wearablecom. An Analog Devices accelerometer is used to read user input, setting this device apart from all media players on the market that I am aware of. The design is expandable, including the possibility of attaching an LCD screen.

Component Selection

The first component that was selected was the MSP430. The original reason the MSP430 was considered was my previous experience with it. I had familiarity with the device from class work already completed, and some other extracurricular activities during the course of the semester. One concern in any portable device is the battery life, and the MSP430 line of devices is suited for low power applications. Because the heavy calculations (decoding audio) will be done off chip and in hardware, processing power was not a big concern; I judged the MSP430 at 8 MHz to be more than sufficient for the task. The MSP430 also includes many on-chip peripherals that I thought would aid in my design, such as its two UARTs. One of the big roles of the MSP430 is simply moving data, and being able to read the data from one UART while writing out the other seemed like a big benefit. Another factor that I used to select it was price - Texas Instrument's generous samples program allowed to me to get several MSP430 models at no cost for possible use in the project. I settled on the MSP430F169. It has a small footprint, and has DMA, which allows data to be moved out the UART without CPU intervention.

The decoder chip I selected was the VS1033, made by VLSI. One aspect of the decision that must be mentioned is the scarcity of decoders on the market. It is a somewhat niche item, so my choices were limited. The VS1033 seemed like a good choice from those available, however, because of its flexibility. It can decode a large number of formats, such as MP3, WMA, and MIDI. It has a built-in DAC, so things like volume control are included in the decoder. It communicates over ubiquitous SPI, and its output can be directly connected to headphones, making it seemingly perfect for my application.

I needed a relatively simple way to access data on an SD card, and the DOSOnChip seemed like a relatively easy way to do this. It offers the ability to interface with a FAT file system using simple commands over a UART interface. At the time, it was the only option other than simply connecting directly to the SD card, and the only viable way to get around having to write a FAT file system driver, a task I felt might expand the scope of the project unduly.

For input, I decided to experiment with the ADXL330, a three-axis accelerometer. The idea of controlling a device through movement seems to have caught on with the general public relatively recently, but it seems to becoming quite widespread. It is only a matter of time in my opinion for the click wheel to be superseded by the motion-sensor. A switch is used for the user to indicate he/she wishes to enter data, and then the analog outputs of the ADXL330 can be read by the ADC units on the MSP430 to decide which command the user wishes to invoke.

Power Considerations

Once I had the main components selected, this gives me an idea of what my power requirements will be. Power supplies are a game of trade-offs. I settled on several different power solutions.

The first selection was batteries. I decided on the Lithium-Ion Polymer (LIP) batteries, mostly because of form factor. The characteristic performance was more than sufficient for my needs, but I was hooked by the flat-pack shape. Batteries are rated in mAh, and as far as I'm concerned, bigger is better. I got the biggest battery available to me, 2000 mAh. I wished to meet the arbitrary active life of 10 hours, giving me a current budget of about 150 mA to be safe.

The second consideration was battery life. LIP batteries cannot be overcharged or over drained, as either is disastrous. At best doing so will destroy the battery, and at worse burn your house down. With the recent battery recalls at the forefront of my mind, I tried to find a solution that would allow me to get maximum performance out of the battery while protecting its longevity (and my house). I settled on a battery gas gauge from Texas Instruments, the BQ27010. It uses coulomb counting to give an accurate measure of many useful battery factors, such as charge left or time-to-empty.

The idea was to use the BQ27010 to watch for low battery conditions. The MSP430 could then power down the device, and bring itself into a low power mode, keeping an eye out for either a charging condition or for the low-battery condition to cease, allowing the device to run for weeks waiting for a recharge before damaging the battery.

The third consideration was charging. A simple charger, the MAX1555, was chosen. Charging is done through a USB connector on the board. The MAX1555 limits current draw, and will recharge the batter to peak capacity off of the USB bus's 5 V supply.

The fourth selection was voltage regulators. I needed three voltage levels for my project - 3.3, 2.5, and 6 volts. Most components either required 3.3 V, or at least tolerated it. The VS1033 decoder required a 2.5 V supply along with its 3.3 V VCC connection. The backlight for the possible LCD screen I had chosen required 6-7 V to function correctly. I tried to stick with switching regulators, as I felt the extra noise generated was more than made up by their higher efficiencies.

For the 3.3 V supply, I decided to go with two regulators. I wanted the ability for the MSP430 to disable the supply voltage for the rest of the components, so I needed a pair of 3.3 V switching regulators that had enable pins. I settled on the MCP1253-33X50 from Microchip, offered through their generous samples program. It is inductor-less and only requires 4 external components (2 resistors and 2 capacitors). It provides either 3.3 or 5.0 volts (selectable), and will source up to 120 mA of current. Even better, it offers a smooth transition from buck to boost operation, and would output a regulated 3.3 V from a source voltage between 2.0 V and 5.5 V, which is a bigger range than the battery is capable of providing. My design uses two, one configured to be always enabled, and this feeds the MSP430. The other uses a GPIO pin from the MSP430 to enable it, and this one powers the 3.3 V bus for the player.

The 2.5 V is a relatively low power draw, so I selected TPS71525 linear regulator from Texas Instruments, and traded efficiency for small board-footprint and simplicity in design. A more efficient choice would probably be the MCP1253-ADJ, which would allow me to select the output I need, and get many of the performance characteristics that I liked about the MCP1253-33X50.

For the backlight regulator, I selected the TPS61040, from Texas Instruments. It is intended for just this application. It requires quite a few external components, but efficient operation. Because my design lacks an LCD screen, it is disabled and not used.

Board Design

After components have been selected, I needed to do a board design. There are too many components (many of which are only available in small form factors) to use some form of prototyping; I decided that designing and ordering a professionally made PCB was the best choice available to me. I selected Eagle, from CadSoft, to do the design. It was selected because of its price (free) and the fact a library of components was available from one of my suppliers (Spark Fun Electronics). The program turned out to be very easy to use. First, I created a library and added all the parts I needed by hand that were missing from either the built-in libraries or the libraries provided by SFE. I then created a schematic, and then used the schematic to lay out a board. The size of the board was dictated by the size of the enclosure I got via OKW's generous samples program. The CAM files for the design were sent to 4PCB for fabrication.

Software

While the software has a lot of helper functions, the basic flow is fairly simple. First, the main function initializes up all the hardware to be used, and then it begins looping. The loop uses an enumerated variable, mode, to track its current state. The states I have defined are init, play, pause, stop, load_next, load_prev, and load. Init is the first (and default) mode. In it, basic stuff is taken care of so that the rest of the program can run smoothly. It takes care of business such as opening the root folder on the SD card, listing the files it contains, and selecting a file to begin playback. It then passes control onto load. Load takes care of the business of opening a file for reading and preparing the ports for transferring the data, which includes configuring DMA. After it is finished, it passes control onto play. Play actually takes care of playback. It uses a circular buffer to try and work out some of the DOSOnChip's peculiarities, and get a better average transfer rate out of it. DMA is used to transfer 32 bytes at a time from the circular buffer to the decoder chip when it requests data, and the DOSOnChip's buffer pointer is sufficiently far ahead. Pause, stop, load_next, and load_prev are all works in progress, and are a bit confined by the DOSOnChip's performance. For instance, loading another file turned out to be a treacherous task. Closing the file often took over 45 seconds, and occasionally never seemed to finish. I have no idea what was going on with the SD card, but the DOSOnChip kept the busy pin high, and that means its busy doing something. As a technology demo, the player reads its tilt when the button is pushed, and raises or lowers the volume to match.

Results

This design was a major learning process for me. Version 1 has many issues, some of which I could have only learned through experimenting with the components I selected, others that were simple mistakes that should be rectified in a future design.

The first huge hurdle was the speed the DOSOnChip was capable of providing. It seems like it would be sufficient for some applications, where throughput isn't as big a consideration as simplicity. For my needs, MP3's had to be encoded to 32 kbps in order to provide for smooth playback. 40 kbps MP3's would stutter. This pegs the read speed somewhere in between, which is far too low for day-to-day use as a data source for a media player. The major issue is that the DOC does not follow true SPI specs. It has an extra pin (BUSY) that tells whether the DOC is ready to transmit more data. Many clock cycles are spent waiting for this pin to go low so that more bytes can be read.

As I now know that the DOSOnChip does not provide enough bandwidth for my needs, connecting directly to the SD card seems like a better option. The SD card can communicate over SPI, and writing a read-only FAT implementation doesn't seem as daunting a task when faced with a solution that isn't fast enough for what I would like to do.

Another mistake is the input switch. I was hoping to power down all the regulators when the media player went into 'sleep' mode, and wait for a button push. However, in my schematics, the button is connected to the common 3.3 V bus, meaning it would be disabled too. Connecting it to the same source as the MSP430 would allow this to happen.

One of my regret's that I have is the under-utilization of the USB port. The data lines are unconnected, and it would have been nice to set it up so they were available to transfer data onto the SD card. As it is, the SD card has to be removed from the device and file transfers have to be completed using another device or SD card reader. There are several ways to go about this, and I am interested in exploring one for version 2 of this project.

The BQ27010 is not used at all, for several reasons. The most glaring one is a mistake I did while doing the library layout of the chip; it was done backwards. It is impossible to mount the chip on the board. Even if that wasn't a problem, the chip is not a good choice for many reasons. Its feature set is good, but it communicates using the single-wire HDQ serial protocol. According to Texas Instruments, the easiest way to connect an MSP430 to a HDQ device is by bit-banging the protocol using a timer, which is somewhat clumsy in my mind. A better choice would be a battery gas gauge that supports a common and easy to use protocol like SPI.

Even with these issues, the project as a whole was a success as a proof of concept. I was able to take off the shelf components, assemble them, and get songs to playback. While the final product is not nearly as feature filled as I would wish, I feel it is a good start.

Downloads

Several of the parts of this project are available here (some linkes removed):

• PDF Schematic

  • Eagle Files

  • Project from CrossWorks