Jump to content
Sign in to follow this  

[Energia Library] Nokia 1202 text terminal

Recommended Posts

I took the work I did with the Nokia 1202 and reworked it for an Energia C++ class.  A prerequisite for this is 9-bit SPI support, which I have achieved here: http://forum.43oh.com/topic/4060-energia-library-spi-fork-9-bit-support/


This Nokia1202 library requires the 9-bit SPI implementation to be installed in your home profile libraries/ directory alongside itself.  A copy of the 9-bit SPI (MSP430-only supported) implementation is here: SPI_9bit.zip


Git repo: https://github.com/spirilis/Nokia1202

Release: Nokia1202_v0_5.zip

Also see my pure C implementation for the MSP430 (usci code included): http://forum.43oh.com/topic/3932-nokia-1202-ste2007-skeleton-driver/


@@bluehash and I did a boosterpack (and he initially did a groupbuy which got me interested in the display) here- http://forum.43oh.com/topic/3724-43oh-nokia-1202-lcd-display-boosterpack/


The library treats the 96x68 display as a 16x8 text terminal (last page of 4 lines are ignored) which may be used in 2 modes -- Framebuffer-mode or Non-framebuffer-mode (default).  In framebuffer mode a 128-byte RAM buffer is maintained with the contents of each character on the display, the advantage of this is the screen can "scroll" correctly as one would expect to see a text terminal scroll.  Everything is moved up a line with a blank line at the bottom when scrolling occurs.


In non-framebuffer-mode, any overflow off the bottom of the display results in the cursor moving up to the origin (0,0) and overwriting whatever may have been there.  This implementation is substantially faster than framebuffer-mode particularly with scrolling, but may not be as visually pleasing to watch.  It also requires substantially less RAM.


Pic running in framebuffer mode (1 line scrolled off the display so far):



Pic running in non-framebuffer mode (overwriting the original text except some of the rightmost part):



I have found that the MSP430G2452 cannot run in framebuffer mode, I guess the RAM usage is too much for Energia so corruption occurs.  G2553 has no problem with it.


Code is overall a bit fat, compiles to ~4KB in framebuffer mode (~3KB in non-framebuffer-mode), I have not tried trimming it down although I am not certain what can be trimmed... the font data is worth about 582 bytes so the rest is code.


Library supports the use of a cursor which is updated with each operation.  Support for changing the contrast, inverting the display color (normally clear BG and dark text, can be dark BG and clear text), invoking PowerSave mode (~1-3uA power draw with screen blank and contents preserved), clearing the display and setting the cursor position.


Cursor vs. no-cursor operation is decided in the .begin() call and remains so for the rest of its use.


Backlight is not handled by this library as it's just an LED... you can manage it like any other LED using digitalWrite() or analogWrite() on its pin.


Normal ASCII characters from a space (0x20) to degree-symbol (0x7F) are supported, 0x80 is reserved as the "cursor" character. Three control chars are supported: \n (newline), \t (tab) and \b (backspace).  The .write() function processes all 3 accordingly, erasing & reprinting the cursor as needed and computing the next location for the cursor.  All other control chars (ASCII value <0x20) are ignored and all high-bit characters above 0x80 are converted into a space.


Framebuffer mode requires editing the library's Nokia1202.h file and uncommenting the following line:

/* Use framebuffer? */

By default it is disabled, making the cursor scroll back to the origin.

Font is a 5x7 font that came from @@RobG


Synopsis of functions:


^ SPI must be initialized by the user, before lcd.begin() is run.  The library is hardcoded to use SPI.transfer9() for its I/O so it expects the "SPI" object to be available and implements the .transfer9() function.

Nokia1202 lcd(<CSpin>);

^ Defines a Nokia 1202 LCD whose SPI Chip Select pin is located at <CSpin>, e.g. P2_0.  This goes in the global area, up near the top of the sketch (above setup() usually).  The rest of these examples run inside a function (setup() or loop() or anywhere else, not inside an interrupt handler though as the I/O functions are not reentrant).

lcd.begin(true, 15, 4);

^ Initializes the LCD display with cursor enabled, contrast setting of 15 (range 0-31, values above 31 are clamped to 31), tabstop is 4 characters.  Display cleared, all settings reset to default (invert=false, refreshrate=65Hz).


^ Puts the LCD in powersave mode and ensures the SPI chip select line is set HIGH in OUTPUT mode.


^ Clear display contents, move cursor to origin (0,0)

lcd.setCursor(0, 5);

^ Move cursor to (X,Y) position 0, 5 (beginning of the 6th line on the display)

lcd.print("I can print numbers: ");

^ Nokia1202 implements Print::write, providing support for the print*() functions just like Serial.

lcd.puts("Check me out.");

^ A simple string writer; this does not gain much performance over .print() and .println() in non-framebuffer-mode, but it gains substantial performance in framebuffer-mode as it suspends the use of _flush() in between individual character writes, waiting until the whole string has been processed before doing any SPI updates to the display.

No newline character is implicitly printed at the end however the user can insert newlines by including a "\n" inside the string.


^ Invert the display colors


^ Put the LCD into powersave (display goes blank, contents are preserved, power consumption drops to ~1-3uA) and then take it back out (resuming the display with previous contents shown).


Normal power consumption with the LCD on has been reported ~200uA without the backlight enabled.


^ Set contrast (called "Electric Volume" in STE2007 parlance).  Values 0-31 supported, clamped to 31 if supplied value is >31.


^ Supports altering the controller's refresh rate.  Default is 65Hz, supported values include 65, 70, 75, 80.  I have honestly never played with this.



Implement a function to write a glyph (maybe a 6x8 block, similar to existing characters) of the user's choosing at a specific location.  Framebuffer mode won't support retaining its contents (so its contents will be zeroed during a scroll) but that's fine.  It'll allow custom graphics and is probably better suited for non-framebuffer-mode applications anyhow.

Share this post

Link to post
Share on other sites

hm, found a couple bugs with cursor use with setCursor, fixing those...


edit: fixed, updated zip in first post with a v0.4 revision, also added a 2nd example that does an ADC reading on P1.0 and spits that out every second.  This example also exercises the backlight on P2.5 (default for the 1202 boosterpack) adjusting its analogWrite() duty cycle based on the ADC reading too.

Share this post

Link to post
Share on other sites

short update, released v0.5, only change is the ADCread test now uses "A1" for the analogRead() port instead of P1_0 (can tell how often I use energia... lol...).  Spits out A1(P1_1): as the port name in the LCD, and choosing P1.1 is smarter since P1.0 is connected to the red LED onboard.


Managed to get it working with a 6cm slide potentiometer I'm using in a project very soon.

Share this post

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

  • Create New...