Preface

Currently OTA bootloading has not been support on Mac device yet. If we make some improvements, then Mac device can implement OTA bootloading.

Here all the test is base on the KBA: OTA bootloading with Connect.

https://www.silabs.com/community/wireless/proprietary/knowledge-base.entry.html/2018/04/26/ota_bootloading_with-ql8G

Please read it before you try Mac device OTA bootloading. Mac device do not have broadcast concept, so we modify the project in an unicast way.

Bootloader project

Here we use the on “Internal Storage Bootloader (single image on 1MB device) - for EFR32xG12”, nothing change.

Mac device project

Create project

The OTA server and client are binded together into one mac-device project. Keep in mind that you need to select the right radio configuration, mac-device sample is set to sub-G by default. We’ll flash one with regular J-Link, and use the other one for OTA bootloading, and we should make some difference between them, e.g. Change the hearbeat period.

Regular one:

#define EMBER_AF_PLUGIN_HEARTBEAT_BLINK_QS 1

OTA image one:

#define EMBER_AF_PLUGIN_HEARTBEAT_BLINK_QS 6

For the bootloading part, enable application bootloader on HAL, and enable the following plugins:

• Bootloader interface
• OTA Bootloader test common
• OTA Unicast Bootloader client
• OTA Unicast Bootloader server
• OTA Unicast Bootloader test

Modify project

Firstly, we need to copy linked file into project, to avoid modify on SDK common files.

Secondary, Mac device have different APIs about sending and receiving messages. So that we need to re-write some functions.

In ota-unicast-bootloader-client.c,

void emAfPluginOtaUnicastBootloaderClientIncomingMacMessageCallback(EmberIncomingMacMessage *message);
void emAfPluginOtaUnicastMacBootloaderClientEventHandler(void);
static void handleIncomingMacHandshake(EmberIncomingMacMessage *message);
static void sendMacHandshakeResponse(EmberNodeId serverId, uint8_t imageTag, uint8_t targetStatus);
static void handleIncomingMacImageSegment(EmberIncomingMacMessage *message);
static void sendMacImageSegmentResponse(EmberNodeId serverId, uint8_t imageTag, uint32_t segmentIndex, uint8_t targetStatus);
static void sendMacBootloadResponse(EmberNodeId serverId, uint8_t imageTag, uint8_t applicationStatus, bool accepted);
static void handleIncomingMacBootloadRequest(EmberIncomingMacMessage *message);

In ota-unicast-bootloader-server.c,

EmberStatus macSendMessage(EmberNodeId sid, EmberNodeId did, uint8_t *message, uint8_t length);

We encapsulate emberMacMessageSend in macSendMessage.

void emAfPluginOtaUnicastBootloaderServerIncomingMacMessageCallback(EmberIncomingMacMessage* message);
void emAfPluginOtaUnicastBootloaderServerMacMessageSentCallback(EmberStatus status, EmberOutgoingMacMessage *message);
static void handleMacSegmentResponse(EmberIncomingMacMessage *message);
static void handleMacHandshakeResponse(EmberIncomingMacMessage *message);

In flex-bookkeeping.c,

We put relevant callbacks into emberAfMacMessageSent and emberAfIncomingMacMessage.

void emberAfMacMessageSent(EmberStatus status, EmberOutgoingMacMessage* message)
{
  emAfPluginOtaUnicastBootloaderServerMacMessageSentCallback(status, message);
}

void emberAfIncomingMacMessage(EmberIncomingMacMessage* message)
{
  emAfPluginOtaUnicastBootloaderClientIncomingMacMessageCallback(message);
  emAfPluginOtaUnicastBootloaderServerIncomingMacMessageCallback(message);
}

For message sending, we use macSendMessage instead of emberMessageSend.

For incoming message, we put callbacks into emberAfIncomingMacMessage.

After doing all these modifications, the project have done. Just compile and load the hex file and image, then we can implement OTA bootloading.

The whole test project and test log please find in attached files, tested project use a macro define MAC_OTA. We tested on FlexSDK V2.4.0.0, with EFR32MG12P332F1024GL125(BRD4162A Rev A01).

Flashing the file to transmit it OTA

Here we flashing to internal storage, use following command.

commander flash --address 84000 mac-device_xg12_gbl.bin

Preparing the devices for bootloading

The next steps are CLI commands on the devices.

Preparing the storage

OTA client

bootloader init
bootloader flash-erase

OTA server

bootloader init
bootloader validate-image

Preparing the network

These commands are the usual ones to create and join to a network.

OTA client

join-commissioned 6 0x0001 0xf000 0 2

0x0001 is nodeid, 0xf000 is padid, 0 is Tx power, 2 is the channel.

We'll also need to set a bootloader tag:

bootloader set-tag 0xaa

OTA server

join-commissioned 6 0x0000 0xf000 0 2

Bootloading

Use the following commands on the OTA server:

bootloader unicast-set-target 0x0001

This will set the destination of the OTA packets to the 0x0001, which is the node id we set in the previous step.

With the next command, we're starting the OTA distribution itself:

bootloader unicast-distribute 102400 0xaa

Where 102400 is the size of the GBL image in bytes, while 0xaa is the tag we set up previously on the OTA client.

This starts the bootloading process. You should see get segment lines on the OTA server (i.e. reading segments from flash memory), and “incoming segment” lines on the OTA client. It should end with “image distribution completed, 0x00” on the server side and “Image download COMPLETED tag=0xAA size=102400” on the client side.

At this point, “bootloader validate-image” should return with “valid” on the client.

Next, we're going to request bootloading:

​To do that, use the following command on the OTA server:

bootloader unicast-request-bootload 1000 0xaa

Where 1000 is a timeout in ms, and 0xaa is the tag again.

Bootloading finished

It should immediately return with “bootload request completed” on OTA server side, OTA client  will verify and install the new image, then rebooting.

Many of the Silicon Labs EFR or EFM starter kits have an LCD screen. These screens can be monochrome or color displays but are mostly dot matrix LCDs. There are several ways to use the screens, but the majority of these rely on our platform middleware graphics library, the glib. In this knowledge base article we collected the tutorials of these options and also included some deep-dive articles in the pixel map formats and image conversion into said formats.

Options

Example code

It's almost always the easiest way to learn about something to check out a pre-written example. It is a good opportunity for the MCU board users, as most of the boards have an example code "glib" in the SDK. Unfortunately the wireless starter kit owners will have to port this example to their own boards, as currently there is no glib example in the SDKs of the wireless kits.

'Graphics' library over glib

The RAILTEST example for the radio MCU kits includes a so called 'Graphics' library. This library was created for the example code, however with limitation it can be used easily to display text on the LCD screen.

More details: Enable LCD screen on WSTK

Printf retargeting to LCD

Still a limited method, but almost the easiest way to print on the screen of any STK. The standard library printf function can be retargeted to the screen, making it your standard output.

More details: Printing on the WSTK LCD screen using printf

Using glib directly

Taking advantage all of its features, using the glib directly is the best way to draw on the LCD screen. Besides text, shapes, lines and even full bitmaps can be drawn. Compared to the previous methods, more expertise is required to use the library, however in return the result will be significantly better.

Refer to the API guide and see more details: Displaying on the LCD screen using glib

Deep-dive section

See the following articles about the pixel map format and custom font creation for the graphics library.

GLIB monochrome pixmap format

Creating monochrome bitmap files for LCD / GLIB using GIMP

Creating fonts using glib (forum topic)

This article intents to clear out the confusion about Callback Configuration in AppBuilder. What is a stub? Which tick to enable? What does "Is used?" mean? All these questions will be answered.

In a nutshell: tick "Is used?" to enable the Callback. Use "Stub?" to auto-generate the declaration of the Callback. Don't use "Stub?" in an existing project (generation will try to overwrite the flex-callbacks.c).

The Callback Configuration tab in the App Builder, shown on the picture above, can be a little bit confusing for the first time. Even if you got through what Callbacks are (basically built-in events for the Connect networking stack) and how to use them, this config screen with the "Stub?", "Is used?" columns can be challenging. First of all, it's good to know this tab changes several important files in the project, like the bookkeeping and the flex-callback-stubs.c, etc., but all in according to the settings we provide here. In a Connect based application, our code will be written in the flex-callbacks.c, while the flex-callback-stubs.c file collects all the callback functions that we don't use. The App Builder can pre-write the "stub", the declaration of the used callbacks in the flex-callbacks.c if you need it, but as it cannot append the source file, it will try to overwrite everything in it with blank functions. So here's a good rule-of-thumb on the usage of the checkboxes:

Starting a new project from scratch: "Is used?" AND "Stub?"

The flex-callbacks source file is not even generated yet. It's a good starting point to generate the empty functions. When turning on a Callback under the "Is used?" column, the App Builder automatically turns on the "Stub?" as well. It's recommended to leave it like this.

Editing Callback configuration after generation: "Is used?" only

Whenever your flex-callbacks source file already exists, there's no option to generate the stub of the newly selected callbacks. If you would do that, it would overwrite the whole source file with the empty stubs, deleting all your work so far. Therefore, if you are just adding a new callback to an existing project, tick the appropriate box under the "Is used?" column and remove the tick from the "Stub?" column. This way the App Builder will update the flex-callback-stubs file, as it is necessary to remove the pre-written stub's second instance, but will not touch the flex-callbacks at all. It's important to note that this way you have to write the callback declaration yourself at least, in order your code to compile. You can also just copy the declaration from the App Builder on the right.

Removing a Callback from the project: Untick "Is used?"

It's almost obvious, but worth to mention here: if you don't need a callback anymore, just untick the checkbox in the "Is used?" column next to its name. This will entirely disable the callback, adding it to the callback-stubs file and it will also try to remove it from the callbacks file. Naturally, you shouldn't let it do the latter, as it will result an empty callbacks file again, but everything else than the flex-callbacks.c can be updated.

问题

    怎样使用EFR32 Sub-GHz射频口的单端方式？

回答

     EFR32 wireless geckos 芯片的接收和发射的射频端口都是纯正的差分端口。然而他们可以用作更为简单的单端方式，这将可以使用更为简单的匹配网络，但在另外一方面将会牺牲一些射频性能。

接收端：

    对于单端接收，灵敏度预计下降6dB。未使用的管脚可以直接连到地。注意的是这也会影响到RFSENSE性能。

发射端：

    对于单端发射，输出功率预计下降3dB。而且谐波将会恶化。未使用的管脚可以直接连到地（节省电流）。

    相对于差分来说，单端匹配网络应使用一半的阻抗，同时差分巴伦可以去掉。

• 单端接收和发射的匹配可以使用未经更改的原始差分匹配的串联元件，也即接收匹配的串联电容和发射匹配的串联电感可以与原始的差分电路保持一致。
• 单端匹配中并联元件的阻抗应是原来的一半并连到地，也即接收匹配中的并联电感值用一半，发射匹配中的并联电容用两倍。因发射内部的电容很小，在Tx管脚处需加上额外的并联电容。
• 去掉巴伦，把单端匹配电路直接连到LPF的单端口。

1.Introduction

The purpose of this article is to introduce a new way to program/erase an EFR32/EFM32 device with batch file. In development stage, comparing with the general way to program device with GUI based Simplicity Commander or Flash programmer, the method bring out here can improve work efficiency.

In general, there are 4 tools for programming purpose.

1. Run project on Simplicity Studio(GUI)
2. Simplicity Commander(GUI)
3. Flash Programmer(GUI)
4. Run Simplicity Commander in a command line console.

The new method proposed here is based on type 4. We prepare a batch file to run the whole programming procedure.

2.The content of the batch file

The Simplicity Commander tool is located at following folder by default. "C:\SiliconLabs\SimplicityStudio\v4\developer\adapter_packs\commander".

If the path of installation is different, just change it accordingly in the batch file. If you prefer to program ".S37" file, just replace the ".hex" with  ".S37" in the batch file.

Create a flash.bat file for flash program.

@echo off

cd "%~dp0"

set filename=

for /f "delims=" %%i in ('dir /b /a-d *.hex') do (set filename=%filename%%%i)

echo %filename%

cd "C:\SiliconLabs\SimplicityStudio\v4\developer\adapter_packs\commander"

commander flash "%~dp0%filename%"

pause

Create a erase.bat file for flash erase.

@echo off

cd "C:\SiliconLabs\SimplicityStudio\v4\developer\adapter_packs\commander"

commander device pageerase --region @mainflash

pause

3.Flash program

Put the flash.bat file in the same directory that the hex file is located at.

Here takes  "C:\Users\ersu\SimplicityStudio\v4_workspace\dutycycle\GNU ARM v7.2.1 – Default" as an example. The directory should contain only one hex file in the folder. Just double click the flash.bat in Simplicity Studio IDE perspective, then it can program the hex file into the flash of the target device. If the program failed, you could check the J-Link connection with Simplicity Commander GUI tools. Keep in mind, it cannot program if the J-Link  is in debug status, need to exit debug mode first (disconnect the target).

It can be found in Simplicity Studio.

The output of flash program operation as shown below:

4.Flash erase

The erase.bat file can be put anywhere since it doesn’t need a hex file.

The output of erase operation as shown below

5.Advantage and disadvantage

The advantage is simple and fast, especially in scenarios that multi boards need to be programmed simultaneously. You only need double click the batch file and the erase or program operation started automatically.

The disadvantage is that you need to copy the batch file to the folder that the hex located at for each project.

Segger J-Link utilities are available for ARM based systems which means it works on Raspberry Pi  (regardless of model) Singe Board Computer. It becomes very handy if your WSTK is attached to a Raspberry Pi and you need to update the firmware of a radio board.

The J-Link tool available from Segger:

https://www.segger.com/downloads/jlink/#J-LinkSoftwareAndDocumentationPack

Select the ARM version and click on DOWNLOAD:

Accept the license agreement and download the install archive file (.tar.gz format). If there is no graphical environment running on the Raspberry Pi, maybe it is easier to download the install package on a PC then transfer the file to the SBC.

Extract the archive in a preferred directory and change the directory where the files extracted to.

Usually, is not a good practice to run the tool as root, but rather as a normal user. To achieve this, copy the 99-jlink.rules file to the /etc/udev/rules.d/ directory. Either reboot the system or issue the udevadm control --reload-rules && udevadm trigger command to immediately reload udev rules without reboot.

On older systems you may need to change the 99-jlink.rules file content like:

SUBSYSTEMS=="usb", ATTRS{idVendor}=="1366", ATTRS{idProduct}=="0105", MODE:="0666"

to make the tool work for non-root users.

Issue the ./JLinkExe commad to start the utility. The following screen should appear:

First, the appropriate device must be selected:

J-Link>device EFR32FG14XXXF256 (replace the device which the one matches your hardware)

Issue the command. In the next step specify the hardware settings (except the target interface, which is SWD) keep everything as its default value.

To erase the internal flash issue the erase command:

The firmware image (both .hex and .s37 files are supported) can be downloaded to the chip by the loadfile filename command (assuming the firmware is already copied to the appropriate directory on the Raspberry Pi):

Finally, issue the r (reset target) and g (go) command to execute the firmware:

Exit from J-Link by issuing qc command (close JLink connection and quit).

Additionally it is possible to automate the above process by creating a J-Link script, for example create a script like the one below:

erase
loadfile /home/pi/test_firmware.s37
r
g
qc

Save as test.jlink for example and call J-Link executable with the following parameters:

./JLinkExe -device EFR32FG14PXXXF256 -if SWD -speed 4000 -autoconnect 1 -CommanderScript /home/pi/test.jlink

The method above allows to update the firmware of the radio board even if the system is at a remote location.

The WSTK boards factory programmed to support 115200bps. This may no suitable for custom firmware thus there is a possibility to set the baud rate to customer specific value.

To change the VCOM speed first it is necessary to access the Admin console on the WSTK. Currently, two methods are supported:

• telnet (using Ethernet connection of the board, supported by all board contoller firmware versions)
• Simplicity Studio's Admin console access (supported with board controller firmware 1.1.1+ and recent Studio only)

The console commands are identical for both method.

Access through Ethernet network

To access the Admin console through telnet first need to connect the WSTK to an Ethernet network which provides DHCP server.

If the WSTK's built-in DHCP client was able to receive the address and network configuration was successful, the IP address will appear on the kit's LCD screen. 

Use that address to connect to the board by telnet program (you may need to enable / install telnet on - refer to your OS manual about details).

The Admin console accessible on port 4902 (replace the IP address with the one appears on your LCD screen):

telnet 10.5.146.86 4902

On successful connection the prompt WSTK> should appear.

Access from Simplicity Studio

To access the console from Simplicity Studio, only the USB port has to be connected. Select the required J-Link adapter, right-click on it and click on Launch console...

When the console appears Switch to the Admin tab at the top then click into the input text box at the bottom press Enter. The WSTK> prompt should appear.

Changing the baud rate of the Virtual COM port

By issuing the help command a few lines of help appears about the usage of the Admin console:

*************** Root commands ****************
aem           AEM commands   [ calibrate, current, dump, ... ]
boardid       Commands for board ID probe.   [ list, probe ]
dbg           Debug interface status and control   [ info, mode,]
dch           Datachannel control and info commands   [ message ]
discovery     Discovery service commands.   [ key ]
net           Network commands.   [ dnslookup, geoprobe, ip ]
pti           Packet trace interface status and control   [ config, disable, dump, ... ]
quit          Exit from shell
serial        Serial channel commands   [ vcom ]
sys           System commands   [ nickname, reset, scratch, ... ]
target        Target commands.   [ button, flashwrite, go, ... ]
time          Time Service commands   [ client, disable, server, ... ]
user          User management functions   [ login,]
WSTK>

To change the Virtual COM port baud rate to 9600bps issue the following command:
serial vcom config speed 9600
There is also possible to set handshaking method by issuing the serial vcom config handshake ... command.

This article describes the format of monochrome (1-bit, black and white) pixmap that can be used with various LCDs including the one attached to BRD4001A WSTK.

In case of monochrome images one pixel need one bit to store thus on one byte 8 pixels can be stored. Due to the limited flash memory of the MCUs it is straightforward to optimize memory occupation of a picture and minimize wasted space. To achieve this, GLIB packs the bits of the image to eliminate unused memory spots.

The following example will use a 9 column wide and 9 row tall picture to show how the pixel data transformed to GLIB pixmap format. The picture we will transform to GLIB pixmap is a smiley:

In a GLIB pixmap the pixels are black and white however, the image can be normal or inverted so it may better to reference pixel state as "on" and "off" where "off" means the pixel matches with the background color while "on" means pixel has foreground color. In the picture above column 0  / row 0 spot is "off" and column 2 / row 0 is "on". Bit value "0" corresponds to "off" state, "1" represents "on".

The (0;0) coordinate of the pixmap is in the upper-left corner. The example image is 9 bit wide thus a row obviously not possible to store in 1 byte (8 bits) thus the last pixel of the first row pushed to the next byte. The pixels of the next rows are shifted to fill the space in the consecutive bytes as the figure below shows.

This way the 9-bit row patterns are arranged into 8-bit bytes. The whole image needs 81 bits but this does not exactly fit into integer number of bytes so, there will be unused bits in the last byte (seven unused bits marked with "X" in the left side figure and their values are irrelevant).

Pixel (0;0) of the picture is bit 0 of byte 0 of the image data, (1;0) is byte 0 / bit 1, (9;0) is byte 1 / bit 0, (0;1) is byte 1 / bit 1, and so on. Based on this the data bytes are:

0b01111100 -> 0x7c
0b00000100 -> 0x04
0b00000101 -> 0x05
...

The whole data array should look like this:

unsigned char smiley[] = {
  0x7C, 0x04, 0x05, 0x4C, 0x19, 0xB0, 0x68, 0x4E, 0x41, 0x7C, 0x00
};

To use the created pixmap issue the GLIB GLIB_drawBitmap() API call. Further reading on using GLIB can be found in Displaying on the LCD screen using glib.

Article Creating monochrome bitmap files for LCD / GLIB using GIMP shows how to create monochrome GLIB pixmaps with GIMP using the plug-in developed for that purpose.

This article shows how to create monochrome icons / bitmaps to display on the LCD attached to the developer boards.

Since The GLIB pixmap format is not standard and additional plug-in has to be installed in GIMP (the plug-in is attached to this article). In GIMP Edit -> Preferences find the Plug-in folder and copy the attached GIMP plug-in to this directory then restart GIMP (on Linux the file attribute of the plug-in must be set to executable).

First create a new image, set the required size (width and height).

Edit the image - preferably use only black and white color as the color depth of the LCD display on the WSTK is 1 bit.

By default the color mode of the image is RGB for a newly created picture. This must be changed to indexed to be processable by the plugin thus change it: Image -> Mode -> Indexed.

Select Use black and white (1-bit) palette:

From File menu choose Export GLIB pixmap... to save the pixmap files:

Select the appropriate folder for the files (it is a good practice to create a directory in the Studio project to store the pixmaps and export the files to that folder directly) and choose a suitable name for the picture (don't add file extension it will be generated by the plug-in):

Press OK to save the C and header files - be careful, there is no confirmation the existing files will be overwritten.

The plug-in creates a file with .c extension which contains the actual image data and a file with extension .h containing two defines for the image width and height. Files, defines and the data array named based on the Output name. For example if the Output name is thermometer a header file named thermometer.h will be created containing THERMOMETER_WIDTH and THERMOMETER_HEIGHT defines and a C file named thermometer.c containing thermometer_bits array.

To use the pixmaps created with GIMP simply include the header file in the project, for example:

#include "thermometer.h"

The header files must be in the include path - it may need to add the pixmap folder in project properties.

The created pixmap can be used by the GLIB_drawBitmap() GLIB API function:

GLIB_drawBitmap(&glibContext, 0, 0, THERMOMETER_WIDTH, THERMOMETER_HEIGHT, thermometer_bits);

For further reference of using GLIB library see the Displaying on the LCD screen using glib knowledge base article.

Detailed description of GLIB pixmap format can be found in GLIB monochrome pixmap format.

Introduction

GLIB is a graphics library that can be used to draw pixels, common shapes, text or bitmaps to a display connected to an MCU. GLIB treats the display as a matrix of pixels which is a model of the physical display. This matrix is exposed to GLIB via an API called DMD (Dot Matrix Display). To draw something on a physical display, the user application needs to provide GLIB with a single implementation of the DMD interface. Sample DMD implementations are provided for the displays that are connected to the Silicon Labs Starter Kits and the Silicon Labs Development Kits.

References

Detailed description is available in the Software documentation of your device. See the same for the Giant Gecko here for your reference.

For an extensive feature showcase, please see MCU example “SLSTKxxxxx_glib” for your MCU development kit in Simplicity Studio.

Initialization

First, glib needs several libraries to be included to work, such as display.h for display specific settings, dmd.h for the Dot Matrix Display library and glib.h for the graphics library itself. The graphics library uses a context for each display. This context must be defined before using glib with

static GLIB_Context_t glibContext;

All the previously listed libraries must be initialized to enable drawing on the screen, by calling the followings:

EMSTATUS status;

/* Initialize the display module. */
status = DISPLAY_Init();
if (DISPLAY_EMSTATUS_OK != status) {
  while (1) ;
}

/* Initialize the DMD module for the DISPLAY device driver. */
status = DMD_init(0);
if (DMD_OK != status) {
  while (1) ;
}

/* Initialize the glib context */
status = GLIB_contextInit(&glibContext);
if (GLIB_OK != status) {
  while (1) ;
}

Drawing on the screen

Drawing usually consist of three steps. First, if we do not want to overlap the previously displayed content and/or are not partially rewriting the display, we should clear it first by calling GLIB_clear(&glibContext). The next step is to set the display content in the context by drawing something on the screen with GLIB_drawXXXX() where XXXX can stand for String, Bitmap, Circle, etc. After the content is set, the last step is to update the display using the DMD driver using DMD_updateDisplay().

glibContext.backgroundColor = White;
glibContext.foregroundColor = Black;
GLIB_clear(&glibContext);
GLIB_setFont(&glibContext, (GLIB_Font_t *)&GLIB_FontNormal8x8);
snprintf(str, MAX_STR_LEN, "  EFM32 GLIB \nNormal 8x8 font");
GLIB_drawString(&glibContext, str, strlen(str), 5, 5, 0);
DMD_updateDisplay();

In the above example a welcome text is written on the screen. First, we set the back- and foreground colors in the glibContext to white and back respectively. Then, as mentioned before, a screen clear is performed. Before calling the GLIB_drawString() function, the font is set to normal in the context and the string is put together into one character array. The GLIB_drawString() is called with the context, string and its length, along with the X and Y coordinate of the text and with the opaque setting last. The example displays the following on a Giant Gecko STK board:

Updating parts of the screen

When not all the information is outdated on the screen, partial update can be used. In this case do not clear the screen, as then all screen content will be lost. GLIB_clearRegion should be used instead, after setting the clipping region with the GLIB_setClippingRegion() function. This function needs a rectangle as an input, this will be the area the GLIB_clearRegion will clear out. After the clear is complete, you can draw in this territory by providing the appropriate X and Y coordinates to the draw function.

if (refresh) {
  GLIB_setClippingRegion(&glibContext, &upperArea);
  GLIB_clearRegion(&glibContext);
  msgYOffset = 2;
} else {
  GLIB_setClippingRegion(&glibContext, &lowerArea);
  GLIB_clearRegion(&glibContext);
  msgYOffset = 7;
}

/* Update only the current message region using msgYOffset */
GLIB_resetClippingRegion(&glibContext); //reset the clipping region to default
GLIB_applyClippingRegion(&glibContext); //application is not included in the resetting
sprintf(text, "Message from %d,\nRSSI: %d dBm", message->source, message->rssi);
GLIB_drawString(&glibContext, text, strlen(text), X_BORDER,
  Y_BORDER + (glibContext.font.fontHeight + glibContext.font.lineSpacing) * msgYOffset, 0);
//print to the upper or lower area using msgYOffset

/* Update display */
DMD_updateDisplay();
refresh = !refresh;

The above example shows a way to display incoming messages alternately in the upper and the lower part of the screen. A previously defined upper and lower area clipping region is cleared and the upper or lower message is displayed using the predefined screen borders and the available font height and line spacing in the glib context.