Tag: microcontroller

Posted on

Setting up the Launchpad MSP430 development environment on OSX

A series of stale wikis and forum posts complicate the setup for cross-compiling code on OSX Yosemite 10.10.4 and running it on a MSP430G2231 microcontroller. It’s not hard if you know what to do.

Today, the fastest way to get code running on an MSP430 is Energia, an Arduino-like environment with a specialty language and purpose-built IDE. It’s actively maintained and seems to just work which is more than can be said for anything else in this ecosystem.

If you want to write vanilla C with no magic you need to set up the toolchain and debugger yourself.

1. Install mspdebug with homebrew.

`brew install mspdebug`

If you launch mspdebug you won’t find any devices because you’re missing the usb driver.

2. Install the MSP430LPCDC-1.0.3b-Signed driver from the Energia site.

A restart is required. Afterward, try `sudo mspdebug rf2500` and you should be able to get a shell and see output like this:

Trying to open interface 1 on 006
Initializing FET...
FET protocol version is 30066536
Set Vcc: 3000 mV
Configured for Spy-Bi-Wire
Device ID: 0xf201
 Code start address: 0xf800
 Code size : 2048 byte = 2 kb
 RAM start address: 0x200
 RAM end address: 0x27f
 RAM size : 128 byte = 0 kb
Device: F20x2_G2x2x_G2x3x
Number of breakpoints: 2
fet: FET returned NAK
warning: device does not support power profiling
Chip ID data: f2 01 02

3. Install the pre-built open source gcc compiler from TI.

Download the msp430-gcc-opensource compiler for OSX.

You’ll have to create an account and swear you’re not Libyan, among other things. Install the compiler using the wizard and remember the destination path.

4. Create a project folder with some source code. There are some examples in <GCC_INSTALL_DIR>/examples/osx.

I tweaked one of the examples to work specifically for the MSP430G2231. Put them in the same folder.
blink.c
Makefile

5. Build the project with `make`. This should run some commands like this:

~/ti/gcc/bin/msp430-elf-gcc -I ~/ti/gcc/include -mmcu=msp430g2231 -O2 -g   -c -o blink.o blink.c
~/ti/gcc/bin/msp430-elf-gcc -I ~/ti/gcc/include -mmcu=msp430g2231 -O2 -g -L ~/ti/gcc/include blink.o -o msp430g2231.out

6. Copy the compiled program to the board.

`sudo mspdebug rf2500`
`prog msp430g2231.out`

7. Run the program with `run`. The red and green LEDs should alternate blinking.

Bonus fact: since the MSP430 has memory-mapped I/O, you can turn on the LEDs from the debugger with the `mw` command. Consult the appropriate header file in `<GCC_INSTALL_DIR>/include` to find the address of P1. For me, it’s 0x0021.

Posted on

Pong on the mc9s12c32

At the conclusion of UT’s embedded systems lab, EE445L, all student teams produce a final project of their own choosing. My partner (Tim) and I built a game system for playing Pong.

I designed the circuit schematic and wrote most of the software. Tim designed the PCB and assembled most of the hardware. Everything that could go wrong did, but we managed to build a fun little game.

The finished product

The interface is extremely intuitive. The potentiometers on either side of the screen control the paddles for each player. The code for the C32 is almost entirely C and was developed in Freescale’s CodeWarrior IDE.

The screen is an AGM1264 128×64 monochrome LCD. Professor Jonathan Valvano provides a useful driver for the c32 on his website. While the driver supports writing whole bitmaps, the memory layout of the LCD makes it very tricky to draw 2D shapes at arbitrary coordinates. I ended up using a 1-pixel ball because a 2×2 ball could require writes to 4 memory locations, a can of worms that I did not want to open.

But, if you’re interested in improving the game, you can draw to arbitrary pixels using the modulus arithmetic in drawBall(). It could easily be a jumping off point for a 2D graphics library supporting more interesting shapes. A word of warning: you will get a noticeable flicker when writing bitmaps quickly (we did 20 fps). The screen really isn’t built to draw every location continuously.

Edit: I had a conversation with another student who attributed the flicker to a call to LCD_Clear(0) in Valvano’s LCD_DrawImage routine. It’s there in LCD.c on line 383. I no longer have the hardware, but that would have been an easy fix to make.

Things that went wrong

  • The seventh wire in the ribbon cable was broken, resulting in garbage on LCD. I tracked this down with a multimeter and patience.
  • I forgot to right justify the 10-bit ADC inputs on the potentiometers. This should have been obvious when the values read were greater than 1023. The fix: ATDCTL5= channel + 0x80;
  • The original box we ordered was just barely too small. Tim measured the LCD’s bezel, rather than its slightly wider PCB. I didn’t double check it. We ended up using the obnoxiously large black box in the picture.
  • The black button unexpectedly employed negative logic. That is, pressing it opens the circuit. This was trivial to deal with in software, but annoying nonetheless.
  • The power switch broke. Our nice metal toggle switch broke into pieces when I bumped it on the table. I decided to short the wires in the interest of time.
  • Tim was unaware that capacitors may be polarized and soldered them in randomly. He is now very good with solder wick.
  • The potentiometers are a little longer than the screen is wide. It would be better to have a perfect 1:1 correspondence.
  • There is a strange bug with the LCD hardware or driver that causes a few pixels near the lower left corner to erroneously become dark. Hence the name, “Distortion Pong”. I tried to convince the TA it was feature, but I don’t think he bought it.

 

Check out the hastily written source.

This project wouldn’t have been possible without the technical guidance of Darryl Goodnight, Paul Landers, and Justin Capogna.

If this post tickled your fancy, check out my Java version of pong. The functionality is nearly identical, but the code is much nicer.