PCD8544 LCD driver for msp430

August 16, 2012 4:21 pmLeave a Comment
Mock menu on the 3310 LCD

Example of a menu as it could look on the 3310 LCD. This is more or less what the example sourcecode gives you.

Recently I managed to get my hands on a LCD3310 module by Olimex. It consists of a LCD display together with a PCD8544 driver chip. After reading up on the PCD8544 and examining some of the example code that’s floating around out there, I finally managed to get it working with an msp430 and now I have assembled a pretty complete driver for this combo.

There were a few problems to overcome however. There seem to be two different versions of the PCD8544 floating around; one that is happily running at 84×48, and one that seems to be more recent that comes with a much bigger display buffer with the top left 84×48 mapped to the display. This more recent version also seems to offset the display by 5 pixels, making the bottom row 3 pixels high and the top pixels unusable. To overcome this problem if you have it on your display, add -DPCD8544_FIX_YALIGN to the compiler options and you should be good.

This driver currently implements software SPI. Support for hardware SPI on the controllers that support it is on its in the works.

Connecting the display

UEXT Connector

Olimex designed the UEXT connection, which is now open for anybody to use in their designs. Making an adapter to connect the display via UEXT to the msp430 is just about connecting a 10P IDC connector to two rows of five pin headers (or maybe even stackable pin headers). If you got another connection to your display, just make sure to hook up the lines accordingly.

Currently the pin mappings are hardcoded in the driver, but this will probably change eventually. However, for now it expects the following pins to be connected from the UEXT connector (or display) to the msp430:

  • D/_C on P2.0 (to SDA)
  • SDIN on P2.1 (to MOSI)
  • SCE on P2.2 (to SSEL)
  • SCK on P2.3 (to SCK)
  • RES on P2.4 (to SCL)
Besides these, you also need to connect +3.3V and Ground. Remember that all UEXT accessories are designed for 3.3V operation, you can read more about UEXT on Wikipedia.

Display mapping

The display is updated 8 pixel rows at a time and the communication is done over SPI with the addition of a D/C pin for data/command selection and a RES pin to reset the controller.

Image depicting addressing modes

PCD8544 Addressing modes: Horizontal (V=0) and Vertical (V=1).

The PCD8544 can use two adressing modes, horizontal and vertical. In horizontal mode, the next data byte will be inserted to the right of the current byte and wrap at the end of the line, while in vertical mode the next data byte would be inserted below the current byte, and it would wrap to the next column at the bottom of the display.

The driver however currently only operates in horizontal mode but this should be enough for most applications.

The driver

The display is initialized by a call to lcd_init(). From this point on you can use the lcd_cursor(row,col) method to position the insert position on the display. The lcd_draw_text(text,x,y) and lcd_draw_text_block(text,x,y,invert,width) methods can then be used to draw text to the display. In order to draw graphics or icons, you can either use lcd_draw_glyph(glyph,x,y) and lcd_tile_glyph(glyph,x,y,width) to draw from a predefined buffer or you can go hardcore with the lcd_write_byte(byte) method.

The main.c file contains working example code demonstrating how to build a simple menu like in the picture at the top of this post.

When the define PCD8544_FIX_YALIGN is set, virtual wrapping will be performed on all drawing operations to ensure that the data you write to the display shows up where it was intended to be.

The full documentation as well as the latest source code is available in the GitHub repository. It can be used standalone by including pcd8544.c and the header files in your project, and it is licensed under GNU GPL version 3.

______ ____ __ _

Relevant links: Documentation (GitHub) | Source Code (GitHub) | PCD8544 Wiki Page (NoccyLabs.info)

Posted in Hardware, MSP430, NoccyLabsTagged , , ,

MSP430 Mood Light Update

February 13, 2012 2:30 amLeave a Comment

Correction: It’s 18 bit, not 21 bit.

I just wanted to post an update on the RGB mood light I have been working on. I have optimized the code a whole lot, and it now runs smooth with a total of 6 bits per channel with a total of 18 bits color. That is 64 levels of intensity for each of the color channels.

Video recorded with my cellphone, hence the quality.

You can check the sourcecode out from the subversion repository at svn.noccy.com/mspdev where you can find the sourcecode in the projects/moodlight folder. It depends on libarduino to build for now, so make sure you run the start.sh script in the root or accommodate the dependencies accordingly. For Linux users, this would be:

$ svn checkout http://svn.noccy.com/mspdev/ mspdev
$ cd mspdev
$ ./start.sh
...Answer the questions...
$ cd projects/moodlight
$ make
..your device will be programmed..
The circuit is pretty self explanatory. The P1.1, P1.2 and P1.3 lines are hooked up to the collectors of three PNP or NPN diodes. The LEDs are then hooked up to +V via an resistor or directly depending on your LEDs. The remaining legs are then connected to the transistors base,  and the emitters to GND.
In a future version, P1.4 and upwards is going to be used for inputs, to control the light. I am also considering moving the LED pins away from the UART and SPI pins to allow it to be used with an RF-shield like the Air Booster Pack or be controlled from the pc.
  • main.c (Highlighted source)

Posted in MSP430Tagged ,

Knowing the chef, a lib430 update.

January 28, 2012 2:28 amLeave a Comment

If you have checked out the sourcecode for lib430 yet, you have probably already used the chef to build a library for your mcu of taste. However, if you use several different mcus, and would like to have it built for all of them we can use the buildall.sh script.

Also, you should not remember to call svn update frequently as there is a lot of work going on on the code all the time.

noccy@noccy-desktop:~/Development/mspdev/lib430$ ./buildall.sh
You must first create a file named MCUS and populate it with one microcontroller per line

So let’s create a MCUS file. Just use “cat > MCUS” if you are on *nix. Put in the mcus one per line and hit Ctrl-D when you are done.

noccy@noccy-desktop:~/Development/mspdev/lib430$ cat > MCUS
msp430g2553
msp430f2013
msp430g2452
^D

Calling on buildall will now call the chef to build for each of the controllers:

noccy@noccy-desktop:~/Development/mspdev/lib430$ ./buildall.sh
== Cooking for: msp430g2553 ==
      libair              : Failed          : See msp430g2553/libair.log
   ·· libarduino          : Successful      : (1 libraries, 1 headers)
   ·· libcomm             : Successful      : (1 libraries, 3 headers)
   ·· libcore             : Successful      : (0 libraries, 4 headers)
      libfat              : Failed          : See msp430g2553/libfat.log
      libhal              : Failed          : See msp430g2553/libhal.log
   ·· liblcd              : Successful      : (1 libraries, 1 headers)
      libmidi             : Failed          : See msp430g2553/libmidi.log
   ·· libsound            : Successful      : (0 libraries, 0 headers)
   :: 3 libraries and 9 headers have been installed.
== Cooking for: msp430f2013 ==
      libair              : Failed          : See msp430f2013/libair.log
      libarduino          : Failed          : See msp430f2013/libarduino.log
      libcomm             : Failed          : See msp430f2013/libcomm.log
   ·· libcore             : Successful      : (0 libraries, 4 headers)
      libfat              : Failed          : See msp430f2013/libfat.log
      libhal              : Failed          : See msp430f2013/libhal.log
   ·· liblcd              : Successful      : (1 libraries, 1 headers)
      libmidi             : Failed          : See msp430f2013/libmidi.log
   ·· libsound            : Successful      : (0 libraries, 0 headers)
   :: 1 libraries and 5 headers have been installed.
== Cooking for: msp430g2452 ==
      libair              : Failed          : See msp430g2452/libair.log
   ·· libarduino          : Successful      : (1 libraries, 1 headers)
      libcomm             : Failed          : See msp430g2452/libcomm.log
   ·· libcore             : Successful      : (0 libraries, 4 headers)
      libfat              : Failed          : See msp430g2452/libfat.log
      libhal              : Failed          : See msp430g2452/libhal.log
   ·· liblcd              : Successful      : (1 libraries, 1 headers)
      libmidi             : Failed          : See msp430g2452/libmidi.log
   ·· libsound            : Successful      : (0 libraries, 0 headers)
   :: 2 libraries and 6 headers have been installed.
noccy@noccy-desktop:~/Development/mspdev/lib430$

One thing you might notice is that some of the libraries doesn’t build for some of the microcontrollers. This can be sorted with custom #defines in the various libraries to adapt to the controller. This is where you come in. If you can get something working that wasn’t, your patches are more than welcome. I am a single developer, and this is a work in progress. So I hope you enjoy lib430!

Posted in lib430Tagged , ,

lib430 updates

January 25, 2012 5:54 pmLeave a Comment

lib430 has been updated together with all the skeleton files. Actually, the skeleton files updated first, causing the chef to fail at building the libraries altogether. But everything has been sorted. If you have other projects that depend on the skeleton makefiles (primarily common.mk) you should use SOURCEC in your include file to define the source files to compile, rather than SOURCES. As an added bonus, you can now use SOURCECPP and SOURCEASM to point to C++ and assembly files to compile.

libArduino is in the process of being improved with basic “uptime” functionality. This makes the micros() and millis() usable in your code. They will however count with a reduced granularity, which means that subsequent calls to the functions are likely to return the same value. This is done to preserve memory and make sure that the counters can run long enough. The main file has also been updated to remove external dependencies on libCore for wdt_halt().

libAir is moving as well. It is however not working yet. The drivers for the RFM70 and CC1101 radios are still very much in the works.

libLcd should be working with HD44780 displays, but I have been unable to test this code fully as I suspect my 16×2 LCD is broken. However, the HD44780 is not the only display out there, so more drivers are needed. Have you got some code to contribute perhaps? :) Make sure to put yourself as @author in the header files.

libComm currently implements a mostly working FIFO buffer, while the Software UART (suart) support is still untested. The Hardware UART (huart) implementation is not yet complete, and the same goes for SPI and I²C.

Please download it and have a go at it, and if possible feel free to pitch in. If you have code to contribute for any of the libraries, or would like to propose a new library for the collection just let me know.

Posted in lib430Tagged , , , ,

lib430

January 19, 2012 9:46 pmLeave a Comment

I have posted an update on G+ about libArduino on Google+ but I have not mentioned lib430 yet. If you were observant, the clues were to be found in the SVN repository and the build instructions. Either way it’s about time to officially tell you about lib430 and what it is. So here goes.

lib430 is not a library per se. It is a collection of libraries to cover all the most common areas. The one that is probably most interesting to anybody who is new to lib430 is libcomm which implements communication routines, both via hardware and software uart including SPI and I²C. The reason I am building it is because I would rather create proper building blocks before I start building stuff.

lib430 is licensed under a GNU GPL license, and is thus an open source project. What is important is that it remains a collection of modular and useful libraries, and as such it will hopefully grow to provide a reliable and efficient foundation for future MSP developers to build on.

How to get it.

Check it out from the Subversion repository:

$ svn checkout http://svn.noccy.com/mspdev mspdev

That part is simple enough. Once the checkout is done you can use the “svn update” command to keep it fresh.

How to build it.

The chef is ready to serve you a freshly compiled library to use. You need, however, first either…

  • Attach your Launchpad to the computer via USB and wait for the device to be ready. This is so that our magical voodoo-induced Makefiles will be able to detect your microcontroller.
  • Define the “MCU” environment variable. In bash you do that by either putting the variable before the command (f.ex. “MCU=msp430g2553 ./chef -b”) or exporting it (f.ex. “export MCU=msp430g2553 && ./chef -m msp430g2553 -b”.)
Once we know what we want, and the chef will serve it up:
$ ./chef -m msp430g2553 -b
== Cooking for: msp430g2553 ==
 :: libair: Installing
 :: libarduino: Installing
...

The -b switch will tell the script to build the library for the specified mcu (-m mcu). You can also delete old libraries with the -d switch. -p to package it into a tar.gz file or -a descriptive-name to create a patch file that you can contribute to the project if you don’t have write access to the Subversion repository.

How to use it.

If you have played with libraries in C earlier, you probably know this already. If not, I will introduce you gently into the beautiful world of libraries. First of all, libraries are nothing but archives (or compressed folders if you prefer) containing object files (.o). So, when you link with a library, you link with the object files in there.

As such, you can provide the library as an input file to the linker, or you can keep the files in a known location and use the -llib (lowercase “L”)switch to link to the library. Both of these alternatives do require you to use the -Ipath (capital “i”) option to specify the path where the include files can be found. If you have copied the include files and the library files (extension “.a”) into your project, a simple -I. will suffice. Otherwise you need to provide the path to where they are located on your filesystem.

The -l (lowercase”L”) alternative however requires you to provide yet another path, the location to where the library files can be found using the -Lpath argument. Without this the compiler won’t be able to find the libraries much less link them. Also, you strip the “lib” part of the files when specified with -l, so as such “libfoo.a” becomes “-lfoo”.

Making things easier for us are the makefiles that you can find in the skeleton folder. Copy the Makefile to your project folder, and modify the definitions appropriately:

# Source files and target binary, define your source files here to have them
# compiled, and define the target basename. An .elf binary will be created as
# well as a .hex file:
SOURCES = main.c database.c config.c
SOURCESA =
TARGET = mspov

include ../../skeleton/common.mk

LIBS = -L../../lib430/$(MCU)/lib
INCLUDES = -I../../lib430/$(MCU)/include
LIBS += -lair

Take notice to the fact that the include statement is defined before the library definitions. This is because the MCU variable will be in the include, and it is needed to find the appropriate paths for the LIBS and INCLUDES variables.

Now you know how to set up the building. Now how to actually use it. The best way to figure that part out for now is by looking at the include files. Doxygen will eventually be used to automate documentation building. Either way, once the code is in place,  just type “make” to build your project.

Contributing.

You can contribute by providing patches. These patches should be sent to the lib430 list at https://groups.google.com/group/lib430. SVN write access can be arranged for contributors.

More Information.

  • Hyperlinked Markdown: lib430 README
  • Supported Compilers: GCC
  • Supported Microcontrollers: TI msp430 series
  • Language: C (GNU)

Posted in lib430Tagged , , ,

Syntax Highlight with Style

January 12, 2012 12:54 amLeave a Comment

To scratch an itch I have written a very handy syntax highlighting tool. You can find it at code.noccylabs.info/highlight where you can simply paste an URL in the box to have it served highlighted to you.

Posted in NoccyLabsTagged ,

PICkit2 vs. MSP430 Launchpad Revisited

December 13, 2011 8:22 amLeave a Comment

In my previous review I commented on the fact that the Launchpad came with a MSP430G2211 and MSP430G2231 microcontroller, both in DIP14 packaging, which made the stock setup a bit short on I/O pins. I am happy to inform you that the this is no longer true, as the new boards now come with the more powerful MSP430G2553 and MSP430G2452 microcontrollers in DIP20 packaging!

This means you will be getting a full 20 pins mcu at your disposal out of the box, as well as more easily available USI and USCI pins through some design changes on the board. It also comes with the male headers already soldered in place, which might be handy for some, but it makes it harder if you intend to jumper the Launchpad on to a breadboard using the female headers.

When it comes to actually writing code for the Launchpad, I personally must say that it keeps growing on me. The fact that msp430-gcc gives you the whole nine yards including the support to build libraries with the familiar gcc suite arguments makes it take the winning leap against the PICkit2. There are also a couple of additional things to note about the architecture of the MSP430, such as the fact that all I/O pins have built in pull-up/pull-down resistors, which makes the design and engineering of systems based on the MSP430 series controllers much easier.

Read more: http://www.43oh.com/2011/12/confirmed-ti-shipping-launchpads-with-msp430g2553-and-msp430g2452/

Posted in Hardware, MSP430Tagged ,

PICkit2 vs. MSP430 Launchpad on Linux

October 2, 2011 3:39 amLeave a Comment

I have been fiddling around a bit with microcontrollers lately. As the Arduino revolution still hasn’t hit Sweden, the first microcontroller I got my hands on was the PIC 16F690 that came with the PICkit2. Later, I discovered the MSP430 Launchpad that is available for the symbolic amount of $4.30. Being an avid Linux user, the solutions that came with these two kits didn’t quite work out of the box. Surely, there is always Wine, but this article will compare these two kits from a “native” standpoint in relation with Linux.

1. Hardware

When it comes to hardware compatibility both kits are winners. Plug and Play all the way. Some minor tweaks were needed with the udev configuration in order to make the programmers available without requiring superuser permissions, but besides that no special drivers or other madness was needed.

The included microcontrollers are fairly decent. The PICkit2 comes with a PIC16F690 mcu in a DIP-20 IC. The Launchpad instead comes with a MSP430G2210 in a DIP-14 IC, and a spare mcu included in the package. The downside of the Launchpad is the limited number of I/O on the included mcus, and therefore the winner when it comes to hardware is the PICkit2.

The PICkit2 programmer can also be used to program a variety of the PIC16 series mcus (although not all of them on the demo board as it only supports the 20-pin form factor – you can however wire it up on a solderless breadboard or buy additional demo boards with support for other PIC16 series microcontrollers), while the Launchpad with the mspdebug utility currently only supports a subset of the available MSP430 microcontrollers, namely the following: (this list seem to differ from the list of compatible microcontrollers provided by TI)

CC430F5133    MSP430F149    MSP430F2234   MSP430F2618   MSP430F5438A  
CC430F5137    MSP430F1611   MSP430F2274   MSP430F413    MSP430F5529   
CC430F6137    MSP430F1612   MSP430F2370   MSP430F4270   MSP430FG4618  
MSP430F1121   MSP430F169    MSP430F247    MSP430F47197  MSP430G2231   
MSP430F1232   MSP430F2013   MSP430F249    MSP430F5437   
MSP430F147    MSP430F2131   MSP430F2616   MSP430F5437A  
MSP430F148    MSP430F2132   MSP430F2617   MSP430F5438

The functionality provided on the boards is pretty similar. The PICkit comes with four leds, one button and one potentiometer that can not be disabled. The Launchpad instead comes with two leds that can be disabled with two jumpers, and two pushbuttons of which one acts as a reset button.

2. Programmer

Microchip does offer an open source programmer, pk2cmd, that provides the same functionality as the PICkit2 programmer software does in Windows. As an added bonus, this programmer also compiles on Mac.

In the case of the Launchpad, there is no official effort to support Linux or any other platforms besides Windows for that matter. Programming the device is done using the open source community effort mspdebug which also offer step-by-step debugging as well as disassembly and memory dumping.

Microchip gets a gold star for providing an open source programmer, but from a usability standpoint the programming and debugging features provided by mspdebug makes this the winner.

3. The Code

The Microchip assembly language is very well supported by the gpasm software suite, all the examples that you can find in documentation as well as on the interwebs can be instantly compiled and tested. For the Launchpad, I still haven’t had a go at writing assembly language code.

Both kits do however support C; in the case of the PIC microcontrollers the Small Devices C Compiler (SDCC) does a fairly good job at creating binary blobs from standards compliant C code, while the Launchpad instead prefer a patched version of the Gnu C Compiler (GCC) aptly named msp430-gcc.

The PICkit2 with SDCC however does require a bit of digging in order to get full access to header files and similar to support I²C, UART etc.

Microchip also provides a C-compiler named HiTech C that works in Linux, but this is really crippleware with a limitation on the resulting code size based on the target device.

For Windows, the support comes with the MPLAB IDE that integrates the programmer with a C-based environment based around HiTech C. There is also a MPLABX IDE available as a beta that is built around the OpenSource IDE NetBeans, that works with SDCC as well as the other by Microchip supported programmers. For some reason, MPLABX feels much more heavy compared to the standalone NetBeans IDE, but this will hopefully change when it gets out of beta.

The winner here is yet again the Launchpad, but if Microchip decided to help bring SDCC up to speed as well continue their work on MPLABX the verdict is very likely to change.

Summary

Both platforms work flawlessly in Linux, but they leave a bit to wish for when it comes to support from the manufacturers. As for getting started, both the PICkit and the LaunchPad work pretty much out of the box, and both have got potent open source solutions to deliver the full potential even in Linux. The Launchpad however feels more mature when it comes to writing code in C, and also comes with powerful debugging functionality. The only thing the Launchpad falls behind with is the number of I/O the included microcontrollers come with, but on the other hand, with a pricetag of $4.30 it just can’t go wrong.

Posted in HardwareTagged , ,

TI’s new $4.30 LaunchPad is a complete development kit for harnessing the ultra-low power and 16-bit performance of MSP430™ Value Line MCUs

August 29, 2011 9:42 pmLeave a Comment

TI LaunchPadThe press release reads:

Dallas, TX (June 22, 2010) – Furthering its commitment to merge 16-bit MCU performance, ultra-low power and ultra-low cost to overcome shortcomings of 8-bit MCUs, Texas Instruments Incorporated (TI) (NYSE: TXN) today announced its new MSP430™ MCU Value Line LaunchPad development kit. For $4.30, the open source kit includes all of the hardware and software needed to easily launch designs based on TI’s MSP430 Value Line MCUs, which start at 25 cents and offer up to 10X performance and 10X battery life over 8-bit MCUs. LaunchPad supports rapid prototyping and development by allowing developers to quickly drop-in MSP430 Value Line MCUs to evaluate, program or debug devices. This flexibility allows developers to remove programmed devices to be placed on a custom board, or remain plugged into LaunchPad to leverage on-board buttons, LEDs and breakout pins for external components. For more information, including multiple production-ready open source projects, please visit www.ti.com/launchpadwiki-pr.

LaunchPad is compatible across the MSP430 MCU Value Line allowing developers to adapt to evolving design requirements in fast moving markets. MSP430 LaunchPad and Value Line MCUs provide a complete development environment to enable applications including 3D glasses, gaming controls, touch sensing, smoke/fire detectors, wireless networking and more. Additionally, since all MSP430 MCUs are code compatible, solutions developed using LaunchPad can be seamlessly migrated to any other MSP430 MCU for added scalability

This looks like quite the nifty little embedded project. And the price is just right to get things rolling.

Sources: newscenter.ti.com, TI Wiki, HackADay

Posted in HardwareTagged , , ,

The First Post

July 29, 2011 3:37 amLeave a Comment

I know What I’m going up against. There are a number of forums out there that are excellent. These are however places where people may be afraid to ask questions to avoid ridicule or snarky replies.

NoccyLabs is supposed to be quite the contrary.

We promote learning, and we love to learn ourselves. Focusing not only on microcontrollers and electronics, we will also cover topics on web design, security, and software development

Thanks to Emma for the logo. It wouldn’t be what it is without you.

Posted in Uncategorized