NRF51822 with an accelerometer and an Oled display

The CJMCU-8223 is a small breakout board featuring an NRF51822 and an LIS3DH accelerometer. It is shown above attached to an SSD1306 Oled display. Programs are loaded on to it using an ST-Link debugger clone.

There are many different ways to program this chip but I decided to develop code for it using the online compiler at mbed.org. This environment allows you write and compile code within your browser. Compiled programs are dropped in to your downloads directory in the form of “hex” files. These downloads can then be written to your target MCU using your preferred debugger. The advantage of this approach is that you don’t have to set up a toolchain on your PC and, you can avail of lots of ready made libraries and example code.

This particular example provides two Gatt services over BLE. An LEDService allows a connected bluetooth device to control the blue LED on the breadboard. An accelerometer service allows the connected device read the accelerometer values (scaled up by a factor of 1000 to avoid floating point printing). The code for this example can be found via this link over at mbed.org.

When you compile this code, the hex file delivered to your PC needs to be uploaded to the NRF51822. This is done as follows:

In one command window (terminal) start openocd as shown here:

Leaving that window running, open a new one and run telnet entering the commands shown below.

Once you have done this, type reset into the telnet session and the board should start running.

You can interact with the board using BLE Scanner on your phone or maybe work with node.js or python to develop a PC based application.

If you need to do some debugging, it is possible to export the program from the mbed environment into a format that is compatible with a number of toolchains (including gcc/gdb). I have tried this and it works pretty well although you may need to disable interrupts on the MCU while doing this as the debugger can get confused if there is bluetooth activity during the debug session.

The STM32L031 with an SSD1306 OLED display

oled1

AliExpress supply a really tiny OLED display driven by an SSD1306 controller.
https://www.aliexpress.com/item/1pcs-0-96-white-0-96-inch-OLED-module-New-128X64-OLED-LCD-LED-Display-Module/32639731302.html

The actual display area is 25mm wide by 14mm high and has 128×64 pixels. Pixels can be white, yellow or black. The display connects to the host microcontroller over an I2C bus which greatly simplifies wiring.
stm32l031_ssd1306_circuit

Pixels are mapped to graphics memory as follows:
SSD1306GRAM

Each graphics memory byte controls a column of 8 pixels. 128 bytes cover a strip of 128×8 pixels or “a page” as its called in the data sheet. This display has 8 pages giving a resolution of 128×64 pixels. To set a particular pixel, you need to identify which page it is on and which byte and bit connects to it within this page. In theory you could then drive this pixel on or off as desired however there is a problem: graphics memory is written in byte-sized chunks so if you want to set a particular pixel, you need to read the byte connected to it, modify the bit in question and then write it back. Unfortunately, the I2C interface for the SSD1306 does not permit reading of graphics memory.
The Adafruit driver for this display gets around this problem by maintaining a copy of the graphics memory in the host MCU. It then updates the whole display when things change. This consumes a fair amount of RAM in the host MCU (128×8 = 1024 bytes) and is slow as the whole display must be updated if a single pixel changes.
My first attempt at controlling this display takes a different approach. The display is treated as a text only device capable of displaying 25×8 characters. Screen updates are carried out at page level i.e. 128 byte chunks are written at a time which corresponds to a single line of text. An I2C driver buffers this data and outputs to the display on an interrupt driven basis. This greatly reduces RAM consumption and speeds updates.

Programming and debugging


Openocd version 0.10 or later is required for the STM32L031. You may get this ready built for your OS or download the source and compile yourself. In my case, I downloaded the source from openocd.org. This was extracted and compiled as follows (as the root user):

apt-get install libusb-1.0-0-dev
./configure –enable-stlink –enable-maintainer-mode
make
make install

The STM32L031 was connected to the host PC using an ST-Link V2 clone and the debug/programming session was started this:

/usr/local/bin/openocd
-f /usr/local/share/openocd/scripts/interface/stlink-v2.cfg
-f /usr/local/share/openocd/scripts/target/stm32l0.cfg

GDB was then used to upload and test the program.

Source code

Source code is evolving and can be found here:
https://github.com/fduignan/stm32l031_examples