IOT-OPEN.EU Reloaded Consortium partners proudly present the 2nd edition of the Introduction to the IoT book. The complete list of contributors is juxtaposed below.

ITT Group

TalTech

Riga Technical University

Silesian University of Technology

• Piotr Czekalski, Ph. D., Eng.
• Krzysztof Tokarz, Ph. D., Eng.

Tallinn University of Technology

IT Silesia

Technical Correction

• Eryk Czekalski

This book and its offshoots were prepared to provide a guide on how to use VREL NextGen Remote Access laboratories.

It contains a technical description of the hardware, a software guide, and hands-on labs with detailed scenarios for various levels of IoT students.

We (Authors) assume that a person willing to use VREL NextGen labs is already familiar with IoT on the engineering level: understands IoT concepts, knows IoT MCUs, sensors and actuators, understands communication principles and, most of all, has programming skills in C++ and Python.

This book is instantly updated online to catch up with the latest developments in software libraries and tools, so its printed edition is considered a collection edition only. Please always refer to the latest online version on Dokuwiki.

Enjoy the power of experiencing real hardware touch, even if done remotely, from your favourite study place.

This Book was implemented under the following projects:

• Cooperation Partnerships in higher education, 2022, IOT-OPEN.EU Reloaded: Education-based strengthening of the European universities, companies and labour force in the global IoT market, project number: 2022-1-PL01-KA220-HED-000085090,
• Horizon 2020 Research Innovation and Staff Exchange Programme (RISE) under the Marie Skłodowska-Curie Action, Programme H2020-EU.1.3.3. - Stimulating innovation by means of cross-fertilisation of knowledge, Grant Agreement No 871163: Reliable Electronics for Tomorrow’s Active Systems.

Erasmus+ Disclaimer
This project has been funded with support from the European Commission.
This publication reflects the views only of the author, and the Commission cannot be held responsible for any use which may be made of the information contained therein.

Copyright Notice
This content was created by the IOT-OPEN.EU Reloaded Consortium 2022-2025.
The content is Copyrighted and distributed under CC BY-NC Creative Commons Licence, free for Non-Commercial use.

In case of commercial use, please get in touch with IOT-OPEN.EU Reloaded Consortium representative.

The VREL NextGen distant laboratory with remote access allows one to work with real hardware (not a simulator) and experience real engineering problems. The web browser is all that is needed to interface the lab. Programming the IoT devices is done in the browser, and firmware uploads, restarts, etc., are all handled in the web browser as well. The device's state can be observed directly via video streaming, almost in real-time, and indirectly via the network (figure 2). One or more devices can be booked exclusively for a user. While booked, it is unavailable for other users, but several devices exist. Booking time is limited. Users can choose which laboratory and device to access, then book and use it. Technical documentation and hands-on laboratory scenarios are integrated with the user interface.

The VREL NextGen solution comprises one or more hosting servers that provide a user interface via www and several laboratories with hardware located across Europe, currently in Poland, Estonia and Latvia. Public instances are announced via the https://iot-open.eu website. Besides public instances, there are private ones for consortium HE partner's students only. Those servers and related hardware (lab nodes) are not publicly accessible. Public instances sometimes also share resources with consortium HE partner's activities.

It is a rule of thumb that a single laboratory usually shares common space and services. One should refer to the technical description to understand capabilities and physical limitations. Scenarios requiring more than one device can be implemented locally within the limits of the single laboratory composed of many programmable IoT nodes or across space, transferring data through the internet. This enables virtually unlimited integration capabilities using physically separated devices worldwide and integrates other devices and solutions, such as cloud providers' services.

The following chapters provide a manual for software and hardware. Laboratory scenarios are provided as per laboratory. Integration and local services such as access points, gateways and related technical information (network configuration, credentials, etc) are described per laboratory in the hardware section.

VREL NextGen software is a web-based, integrated solution for both IoT software developers (Users/Students) and system administrators (Administrators, Super Administrators). It can be used in one of the three aforementioned roles.
There are many public and private instances for internal purposes of the Consortium HE and SME Members. Use of the system requires user registration with a valid email address. A front-page view is present in figure 3.

In the following chapters, there is a manual on how to use the system:

• User's Guide,
• Admins's Guide.

[pczekalski]Do a user's guide

[pczekalski]Do an admin's guide The system has two kinds of administrators: the Super Admin, a built-in account, and any number of Laboratory Admins. To understand activities and relations, it is essential to recognise system-building components (figure {ref>vrelsoftware2}).

The Super Admin can create new Laboratory Admins by promoting the regular user's account or explicitly creating a new one.
The Super Admin can also create a laboratory (a group of administrators) and assign Administrator's (Administrators') accounts to it, remove admins and manage individual Users.

The Admin's role is to configure the system per laboratory and manage cohorts of students (Users) and individual devices. There can be many Admins in the system, and each can manage their own Users, Laboratories (called Group of Devices) and individual Devices.

Regular Admin has several scenarios:

• User management:
  • editing User's data,
  • delete the User's project files (Cleanup).
• Managing group of users:
  • creating and deleting user groups,
  • adding and removing users to and from the group.
• Managing a Group of Users in the context of the devices:
  • assign existing devices to the Group, removing device assignments from the User's Group.
• Managing Groups of Devices (Laboratory):
  • creating and deleting a Group of Devices (Laboratory),
  • managing individual Devices' assignment to the Group of Devices
• Configuring and managing individual Devices:
  • creating and editing a Device with detailed technical documentation, deleting the device,
  • cleaning up devices (deletes compilation targets),
• Managing User's bookings (per device).

Below there are some hints and important information:

1. User Groups bind Users and Devices: Users can book Devices if both are in the same group. The User can be a member of many groups. Groups typically reflect student groups (such as the Dean's group or laboratory team), and devices assigned to the group reflect module-related resources that are needed to perform lab work.
2. Admin-level access to the Bookings is possible via the Devices menu (then expand the group and the device and check for Bookings in the context menu).
3. Users' projects (source codes) can be cleaned up in the Users menu.
4. Laboratory compiled and temporary files can be cleaned up in the Devices' context (Devices menu).
5. Compiler service uses a single source file on the input, which is PlatformIO-based. Thus, all source codes constituting a project are single cpp (or other) files + platformio.ini files.

Device configuration is the most complex part of the administration process. It requires the correct configuration of the end node proxy service regarding the specification of the target IoT device it manages. It is a compilation service (figure 4) that executes compilation commands and execution.
The device configuration supports several configuration parameters, many of which may be redundant or unnecessary, to ensure flexibility among different IoT hardware. Commands to compile and upload firmware (or configuration) are Admin-defined. Besides common configuration parts such as name, location, and description, there are sections for:

• Device reset (reboot, restart)
• Code compilation, including check of the success with standardised return signalling to the system
• Code execution (i.e. firmware upload)

Each laboratory node is equipped with an ESP32-S3 double-core chip. Several peripherals, networks and network services are available for the user. The UI is necessary to observe results in the camera when programming remotely. Thus, a proper understanding of UI programming is essential to successfully using the devices.

The table 1 lists all hardware components of the SUT's ESP32-S3 node and hardware details such as connectivity, protocols, GPIOs, etc. Please note that some pins overlap because buses such as SPI and I2C are shared among multiple components.
The node is present in the figure 5 and reference numbers reflecting components in the table 1.

The MCU standing behind the laboratory node is a genuine ESP32-S3-DevKitM-1-N8 from Espressif ^[1], present in figure 6:

A suitable platformio.ini file for the correct code compilation is presented below. It does not contain libraries that need to be added regarding specific tasks and hardware used in particular scenarios. The code below presents only the typical section. Refer to the scenario description for details regarding case-specific libraries needed for the implementation:

platformio.ini

[env:esp32]
platform = espressif32
board = esp32-s3-devkitc-1
board_build.mcu = esp32s3
board_build.f_cpu = 240000000L
framework = arduino
platform_packages =
    toolchain-riscv32-esp @ 8.4.0+2021r2-patch5
lib_ldf_mode = deep+

Figure 7 represents SUT's VREL Next Gen IoT remote lab networking infrastructure and services. Details are described below.

If you're a SUT student or can access the campus network, you can also use 157.158.56.0/24 addresses.

The WiFi network, separated (no routing to and from the Internet) for IoT experimentation is available for all nodes:

• SSID: internal.IOT.NextGen
• PASS: IoTlab32768

A public, wired (157.158.56.0/24) network is available only for on-site students and from the SUT's campus network.

It is important to distinguish the network context and use the correct address. Integration services usually have two interfaces: one is available from the IoT WiFi network so nodes can access it, and the other IP address (from the public campus network) is available only for students directly connected to it.

There are currently two application layer services available:

• MQTT broker available on both addresses:
  • IP addresses: 192.168.91.5 (from internal IoT WiFi network), 157.158.56.57 (via the campus network);
  • Port: 1883 (TCP)
  • User: vrel
  • Pass: vrel2018
• CoAP server with 2 endpoints:
  • IP addresses: 192.168.91.5 (from internal IoT WiFi network), 157.158.56.57 (via the campus network);
  • Port: 5683 (UDP)
  • Endpoints:
    • GET method for

      coap://<ipaddress>/

      that brings you a secret code in the message's payload,

    • GET method for

      coap://<ipaddress>/hello

      that brings you a hello world welcome message in the payload.

Know the hardware
The following scenarios explain the use of hardware components and services that constitute the laboratory node. It is intended to seamlessly introduce users to IoT scenarios where using sensors and actuators is an intermediate step, and the main goal is to use networking and communication. Besides IoT, those scenarios can be utilised as a part of the Embedded Systems Modules.

Advanced techniques
In the following scenarios, we will focus on advanced programming techniques, such as asynchronous programming and timers.

IoT programming
In the following scenarios, you will write programs interacting with other devices, services, and networks, which are pure IoT applications.

Alphanumerical LCD is one of the most popular output devices in the Embedded and IoT. Using LCD with predefined line organisation (here, 2 lines, 16 characters each) is as simple as sending a character's ASCII code to the device. This is so much simpler than in the case of the use of dot-matrix displays, where it is necessary to use fonts. The fixed organisation LCD has limits; here, only 32 characters can be presented to the user simultaneously. ASCII presents a limited set of characters, but many LCDs can redefine character maps (how each letter, digit or symbol looks). This way, it is possible to introduce graphics elements (i.e. frames), special symbols and letters.

In this scenario, you will learn how to handle easily LCD to present information and retrieve it visually with a webcam.

Familiarise yourself with a hardware reference: this LCD is controlled with 6 GPIOs as presented in the “Table 1: ESP32-S3 SUT Node Hardware Details” on the hardware reference page.
You are going to use a library to handle the LCD. It means you need to add it to your platformio.ini file. Use the template provided in the hardware reference section and extend it with the library definition:

lib_deps = adafruit/Adafruit LiquidCrystal@^2.0.2

• C/C++ Language Embedded Programming Fundamentals
• ESP32 General Information
• Optical Output Devices
• SUT ESP32 Laboratory Node Hardware Reference

Draw “Hello World” in the upper line of the LCD and “Hello IoT” in the lower one.

Check if you can see a full LCD in your video stream. Book a device and create a dummy Arduino file with void setup()… and void loop()….

= Step 1 = Include the library in your source code:

#include <Adafruit_LiquidCrystal.h>

= Step 2 = Declare GPIOs controlling the LCD, according to the hardware reference:

#define LCD_RS 2
#define LCD_ENABLE 1
#define LCD_D4 39
#define LCD_D5 40
#define LCD_D6 41
#define LCD_D7 42

= Step 3 = Declare a static instance of the LCD controller class and preconfigure it with appropriate control GPIOs:

static Adafruit_LiquidCrystal lcd(LCD_RS, LCD_ENABLE, LCD_D4, LCD_D5, LCD_D6, LCD_D7);

= Step 4 = Initialise class with display area configuration (number of columns, here 16 and rows, here 2):

lcd.begin(16,2); 

= Step 5 = Implement your algorithm. The most common class methods that will help you are listed below:

• .clear() - clears all content;
• .setCursor(x,y) - set cursor, writing will start there;
• .print(contents) - prints text in the cursor location; note there are many overloaded functions, accepting various arguments, including numerical.

You should be able to see “Hello World” and “Hello IoT” on the LCD now.

Project information

This Intellectual Output was implemented under the Erasmus+ KA2.
Project IOT-OPEN.EU Reloaded – Education-based strengthening of the European universities, companies and labour force in the global IoT market.
Project number: 2022-1-PL01-KA220-HED-000085090.

Erasmus+ Disclaimer
This project has been funded with support from the European Commission.
This publication reflects the views of only the author, and the Commission cannot be held responsible for any use that may be made of the information contained therein.

Copyright Notice
This content was created by the IOT-OPEN.EU Reloaded consortium, 2022,2024.
The content is Copyrighted and distributed under CC BY-NC Creative Commons Licence, free for Non-Commercial use.

VREL NExtGen laboratory node is equipped with b/w, ePaper module. It is a dot matrix display with a native resolution of 250×122 pixels. It has 64kB display memory and is controlled via SPI. The ePaper display presents data even if powered off, so don't be surprised that finishing your application does not automatically clean up the display, even if you use some other code later. To clean up the display, one has to clear the screen explicitly.

Familiarise yourself with a hardware reference: this ePaper is controlled with 6 GPIOs as presented in the “Table 1: ESP32-S3 SUT Node Hardware Details” on the hardware reference page.
You are going to use a library to handle the ePaper drawing. It means you need to add it to your platformio.ini file. Use the template provided in the hardware reference section and extend it with the library definition:

lib_deps = zinggjm/GxEPD2@^1.5.0

• C/C++ Language Embedded Programming Fundamentals
• ESP32 General Information
• Optical Output Devices
• SUT ESP32 Laboratory Node Hardware Reference

To generate an array of bytes representing an image, it is easiest to use an online tool, e.g.:

• https://javl.github.io/image2cpp/

Present an image on the screen and overlay the text “Hello World” over it.

Check if you can see a full ePaper Display in your video stream. Book a device and create a dummy Arduino file with void setup()… and void loop()….

Prepare a small bitmap (e.g. 60×60 pixels) and convert it to the byte array with b/w settings.
Sample project favicon you can use is present in Figure 9:

Remember to include the source array in the code when drawing an image.
The corresponding generated C array for the logo in Figure 9 (horizontal 1 bit per pixel, as suitable for ePaper Display) is present below:

// 'logo 60', 60x60px
const unsigned char epd_bitmap_logo_60 [] PROGMEM = {
0xff, 0xff, 0xff, 0x80, 0x1f, 0xff, 0xff, 0xf0, 0xff, 0xff, 0xf8, 0x00, 0x01, 0xff, 0xff, 0xf0, 
0xff, 0xff, 0xc0, 0x00, 0x00, 0x3f, 0xff, 0xf0, 0xff, 0xff, 0x01, 0xff, 0xf8, 0x0f, 0xff, 0xf0, 
0xff, 0xfc, 0x0f, 0xff, 0xff, 0x03, 0xff, 0xf0, 0xff, 0xf8, 0x3f, 0xff, 0xff, 0xc1, 0xff, 0xf0, 
0xff, 0xe0, 0xff, 0xff, 0xff, 0xf0, 0x7f, 0xf0, 0xff, 0xc3, 0xff, 0xff, 0xff, 0xfc, 0x3f, 0xf0, 
0xff, 0x87, 0xff, 0xf0, 0xff, 0xfe, 0x1f, 0xf0, 0xff, 0x0f, 0xfe, 0x00, 0x07, 0xff, 0x0f, 0xf0, 
0xfe, 0x1f, 0xf8, 0x7f, 0xe1, 0xff, 0x87, 0xf0, 0xfc, 0x3f, 0xe3, 0xff, 0xfc, 0x7f, 0xc3, 0xf0, 
0xfc, 0x7f, 0x8f, 0xff, 0xff, 0x1f, 0xe3, 0xf0, 0xf8, 0xff, 0x3f, 0xff, 0xff, 0xcf, 0xf1, 0xf0, 
0xf1, 0xfe, 0x7f, 0xff, 0xff, 0xe7, 0xf8, 0xf0, 0xf1, 0xfc, 0xff, 0xff, 0xff, 0xf3, 0xf8, 0xf0, 
0xe3, 0xf9, 0xff, 0xfc, 0x7f, 0xf9, 0xfc, 0x70, 0xe3, 0xf3, 0xff, 0xfc, 0x0f, 0xfc, 0xfc, 0x70, 
0xc7, 0xf7, 0xff, 0xff, 0xc3, 0xfe, 0xfe, 0x30, 0xc7, 0xe7, 0xff, 0xff, 0xf1, 0xfe, 0x7e, 0x30, 
0xcf, 0xef, 0xff, 0xff, 0xfc, 0xff, 0x7f, 0x30, 0x8f, 0xcf, 0xff, 0xff, 0xfe, 0x7f, 0x3f, 0x10, 
0x8f, 0xdf, 0xff, 0xff, 0xff, 0x3f, 0xbf, 0x10, 0x9f, 0x9f, 0xff, 0xff, 0xff, 0x3f, 0x9f, 0x90, 
0x9f, 0x9f, 0xff, 0xff, 0xff, 0x9f, 0x9f, 0x90, 0x1f, 0xbf, 0xff, 0xff, 0xff, 0x9f, 0xdf, 0x80, 
0x1f, 0xbf, 0xff, 0xf9, 0xff, 0xdf, 0xdf, 0x80, 0x1f, 0xbf, 0xff, 0xe0, 0x7f, 0xcf, 0xdf, 0x80, 
0x1f, 0x3f, 0xff, 0xe0, 0x7f, 0xcf, 0xcf, 0x80, 0x1f, 0x3f, 0xff, 0xc0, 0x3f, 0xcf, 0xcf, 0x80, 
0x1f, 0xff, 0xff, 0xc0, 0x3f, 0xff, 0xff, 0xf0, 0x1f, 0xff, 0xff, 0xe0, 0x7f, 0xff, 0xff, 0xf0, 
0x1f, 0xff, 0xff, 0xe0, 0x7f, 0xff, 0xff, 0xf0, 0x1f, 0xff, 0xff, 0xf9, 0xff, 0xff, 0xff, 0xf0, 
0x1f, 0xff, 0xff, 0xff, 0xff, 0xff, 0xfd, 0xf0, 0x9f, 0xff, 0xff, 0xff, 0xff, 0xff, 0xfd, 0xf0, 
0x9f, 0xff, 0xff, 0xff, 0xff, 0xff, 0xf9, 0xf0, 0x8f, 0xff, 0xff, 0xf9, 0xfc, 0x03, 0xf0, 0x10, 
0x8f, 0xff, 0xff, 0xf9, 0xf8, 0x01, 0xe0, 0x10, 0xcf, 0xff, 0xff, 0xf9, 0xf0, 0xf0, 0xf9, 0xf0, 
0xc7, 0xff, 0xff, 0xf9, 0xf3, 0xfc, 0xf9, 0xf0, 0xc7, 0xff, 0xff, 0xf9, 0xe3, 0xfc, 0x79, 0xf0, 
0xe3, 0xff, 0xff, 0xf9, 0xe3, 0xfc, 0x79, 0xf0, 0xe3, 0xff, 0xff, 0xf9, 0xe3, 0xfc, 0x79, 0xf0, 
0xf1, 0xff, 0xff, 0xf9, 0xe3, 0xfc, 0x79, 0xf0, 0xf1, 0xff, 0xff, 0xf9, 0xf3, 0xfc, 0x79, 0xf0, 
0xf8, 0xff, 0xff, 0xf9, 0xf1, 0xf8, 0xf9, 0xf0, 0xfc, 0x7f, 0xff, 0xf9, 0xf8, 0x61, 0xf8, 0xc0, 
0xfc, 0x3f, 0xff, 0xf9, 0xfc, 0x03, 0xf8, 0x00, 0xfe, 0x1f, 0xff, 0xf9, 0xff, 0x0f, 0xfe, 0x10, 
0xff, 0x0f, 0xff, 0xff, 0xff, 0xff, 0xff, 0xf0, 0xff, 0x87, 0xff, 0xff, 0xff, 0xff, 0xff, 0xf0, 
0xff, 0xc3, 0xff, 0xff, 0xff, 0xff, 0xff, 0xf0, 0xff, 0xe0, 0xff, 0xff, 0xff, 0xff, 0xff, 0xf0, 
0xff, 0xf8, 0x3f, 0xff, 0xff, 0xff, 0xff, 0xf0, 0xff, 0xfc, 0x0f, 0xff, 0xff, 0xff, 0xff, 0xf0, 
0xff, 0xff, 0x01, 0xff, 0xff, 0xff, 0xff, 0xf0, 0xff, 0xff, 0xc0, 0x00, 0x00, 0x00, 0x00, 0x00, 
0xff, 0xff, 0xf8, 0x00, 0x00, 0x00, 0x00, 0x00, 0xff, 0xff, 0xff, 0x80, 0x00, 0x00, 0x00, 0x00
};
 
// Total bytes used to store images in PROGMEM = 496
const int epd_bitmap_allArray_LEN = 1;
const unsigned char* epd_bitmap_allArray[1] = {
	epd_bitmap_logo_60
};

= Step 1 = Include necessary libraries.

#include <SPI.h>
#include <GxEPD2.h>
#include <GxEPD2_BW.h>
//Fonts
#include <Fonts/FreeMonoBold12pt7b.h>

The code above also includes a font to draw text on the ePaper Display. There are many fonts one can use, and a non-exhaustive list is present below (files are located in the Adafruit GFX Library, subfolder Fonts):

   FreeMono12pt7b.h
   FreeMono18pt7b.h
   FreeMono24pt7b.h
   FreeMono9pt7b.h
   FreeMonoBold12pt7b.h
   FreeMonoBold18pt7b.h
   FreeMonoBold24pt7b.h
   FreeMonoBold9pt7b.h
   FreeMonoBoldOblique12pt7b.h
   FreeMonoBoldOblique18pt7b.h
   FreeMonoBoldOblique24pt7b.h
   FreeMonoBoldOblique9pt7b.h
   FreeMonoOblique12pt7b.h
   FreeMonoOblique18pt7b.h
   FreeMonoOblique24pt7b.h
   FreeMonoOblique9pt7b.h
   FreeSans12pt7b.h
   FreeSans18pt7b.h
   FreeSans24pt7b.h
   FreeSans9pt7b.h
   FreeSansBold12pt7b.h
   FreeSansBold18pt7b.h
   FreeSansBold24pt7b.h
   FreeSansBold9pt7b.h
   FreeSansBoldOblique12pt7b.h
   FreeSansBoldOblique18pt7b.h
   FreeSansBoldOblique24pt7b.h
   FreeSansBoldOblique9pt7b.h
   FreeSansOblique12pt7b.h
   FreeSansOblique18pt7b.h
   FreeSansOblique24pt7b.h
   FreeSansOblique9pt7b.h
   FreeSerif12pt7b.h
   FreeSerif18pt7b.h
   FreeSerif24pt7b.h
   FreeSerif9pt7b.h
   FreeSerifBold12pt7b.h
   FreeSerifBold18pt7b.h
   FreeSerifBold24pt7b.h
   FreeSerifBold9pt7b.h
   FreeSerifBoldItalic12pt7b.h
   FreeSerifBoldItalic18pt7b.h
   FreeSerifBoldItalic24pt7b.h
   FreeSerifBoldItalic9pt7b.h
   FreeSerifItalic12pt7b.h
   FreeSerifItalic18pt7b.h
   FreeSerifItalic24pt7b.h
   FreeSerifItalic9pt7b.h

= Step 2 = Declare GPIOs and some configurations needed to handle the ePaper display properly:

#define GxEPD2_DRIVER_CLASS GxEPD2_213_BN
#define GxEPD2_DISPLAY_CLASS GxEPD2_BW
#define USE_HSPI_FOR_EPD
#define ENABLE_GxEPD2_GFX 0
 
#define SPI_SCLK_PIN 18
#define SPI_MOSI_PIN 15
 
#define EPAPER_SPI_DC_PIN 13
#define EPAPER_SPI_CS_PIN 10
#define EPAPER_SPI_RST_PIN 9
#define EPAPER_BUSY_PIN 8
 
#define SCREEN_WIDTH 250
#define SCREEN_HEIGHT 122
#define MAX_DISPLAY_BUFFER_SIZE 65536ul 
#define MAX_HEIGHT(EPD) (EPD::HEIGHT <= MAX_DISPLAY_BUFFER_SIZE / (EPD::WIDTH / 8) ? EPD::HEIGHT : MAX_DISPLAY_BUFFER_SIZE / (EPD::WIDTH / 8))

= Step 3 = Declare hardware SPI controller and ePaper display controller:

static SPIClass hspi(HSPI);
 
static GxEPD2_DISPLAY_CLASS<GxEPD2_DRIVER_CLASS, MAX_HEIGHT(GxEPD2_DRIVER_CLASS)> display(GxEPD2_DRIVER_CLASS(/*CS=*/ EPAPER_SPI_CS_PIN, /*DC=*/ EPAPER_SPI_DC_PIN, /*RST=*/ EPAPER_SPI_RST_PIN, /*BUSY=*/ EPAPER_BUSY_PIN));

You can also declare a message to display as an array of characters:

static const char HelloWorld[] = "Hello IoT!";

= Step 4 = Initialise SPI and, on top of that, the ePaper controller class:

    hspi.begin(SPI_SCLK_PIN, -1, SPI_MOSI_PIN, -1);
    delay(100);
    pinMode(EPAPER_SPI_CS_PIN, OUTPUT);
    pinMode(EPAPER_SPI_RST_PIN, OUTPUT);
    pinMode(EPAPER_SPI_DC_PIN, OUTPUT);
    pinMode(EPAPER_BUSY_PIN,INPUT_PULLUP);
    delay(100);
    digitalWrite(EPAPER_SPI_CS_PIN,LOW);
    display.epd2.selectSPI(hspi, SPISettings(4000000, MSBFIRST, SPI_MODE0));
    delay(100);
    display.init(115200);
    digitalWrite(EPAPER_SPI_CS_PIN,HIGH);    

= Step 5 = Set display rotation, font and text colour:

digitalWrite(EPAPER_SPI_CS_PIN,LOW);
display.setRotation(1);
display.setFont(&FreeMonoBold12pt7b);
display.setTextColor(GxEPD_BLACK);

then get the external dimensions of the string to be printed:

int16_t tbx, tby; uint16_t tbw, tbh;
display.getTextBounds(HelloWorld, 0, 0, &tbx, &tby, &tbw, &tbh);
 
uint16_t x = ((display.width() - tbw) / 2) - tbx;
uint16_t y = ((display.height() - tbh) / 2) - tby;

= Step 6 = Then display contents of the image and the text in the ePaper display:

display.setFullWindow();
display.firstPage();
do
  {
    display.drawImage((uint8_t*)epd_bitmap_logo_60,0,0,60,60);
    display.setCursor(x, y);
    display.print(HelloWorld);
  }
while (display.nextPage());
digitalWrite(EPAPER_SPI_CS_PIN,HIGH);

You should be able to see an image and a text on the ePaper Display.

Project information

This Intellectual Output was implemented under the Erasmus+ KA2.
Project IOT-OPEN.EU Reloaded – Education-based strengthening of the European universities, companies and labour force in the global IoT market.
Project number: 2022-1-PL01-KA220-HED-000085090.

Erasmus+ Disclaimer
This project has been funded with support from the European Commission.
This publication reflects the views of only the author, and the Commission cannot be held responsible for any use that may be made of the information contained therein.

Copyright Notice
This content was created by the IOT-OPEN.EU Reloaded consortium, 2022,2024.
The content is Copyrighted and distributed under CC BY-NC Creative Commons Licence, free for Non-Commercial use.

This scenario presents how to use the OLED display. Our OLED display is an RGB (16bit colour, 64k colours) 1.5in, 128×128 pixels. The OLED chip is SSD1351, and it is controlled over the SPI interface using the following pin configuration:

• SPI_MOSI=15,
• SPI_CLK=18,
• SPI_DC=13,
• SPI_CS=11,
• SPI_RST=12.

As usual, there is no need to program SPI directly; instead, it should be handled by a dedicated library. In addition to the protocol communication library and display library, we will use a graphic abstraction layer for drawing primitives such as lines, images, text, circles, and so on:

lib_deps = adafruit/Adafruit SSD1351 library@^1.2.8

Note that the graphics abstraction library (Adafruit GFX) is loaded automatically because of the

lib_ldf_mode = deep+

declaration in the platformio.ini. You can also add it explicitly, as below:

lib_deps = 
    adafruit/Adafruit SSD1351 library@^1.3.2
    adafruit/Adafruit GFX Library@^1.11.9

• C/C++ Language Embedded Programming Fundamentals
• ESP32 General Information
• Optical Output Devices
• SUT ESP32 Laboratory Node Hardware Reference

To generate an array of bytes representing an image in 565 format, it is easiest to use an online tool, e.g.:

• https://javl.github.io/image2cpp/

Draw a text on the OLED display and an image of your choice (small, to fit both text and image).

Perhaps you will need to use an external tool to preprocess an image to the desired size (we suggest something no bigger than 100×100 pixels) and another tool (see hint above) to convert an image to an array of bytes.

Check if you can see a full OLED Display in your video stream. Book a device and create a dummy Arduino file with void setup()… and void loop()….

Prepare a small bitmap and convert it to the byte array for 16-bit colour settings.
Sample project favicon you can use is present in Figure 9:

Remember to include the source array in the code when drawing an image. The corresponding generated C array for the logo in Figure 11 is too extensive to present here in the textual form, so below it is just the first couple of pixels represented in the array, and full contents you can download here: ZIPed archive with a C file containing all pixel data of the image .

const uint16_t epd_bitmap_logo_60 [] PROGMEM = {
	0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 
	0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xf7be, 0xbdd7, 0x8430, 0x5aeb, 0x39c7, 0x2104, 0x1082, 0x0020, 0x0020, 0x1082, 
	0x2104, 0x39c7, 0x5aeb, 0x8430, 0xbdd7, 0xf7be, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff,
....
 
....
	0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000
};
 
// Array of all bitmaps for convenience. (Total bytes used to store images in PROGMEM = 3616)
const int epd_bitmap_allArray_LEN = 1;
const uint16_t* epd_bitmap_allArray[1] = {
	epd_bitmap_logo_60
};

= Step 1 = Include necessary libraries:

#include <Arduino.h>
#include <Adafruit_GFX.h>
#include <Adafruit_SSD1351.h>
#include <SPI.h>
//Fonts
#include <Fonts/FreeMono9pt7b.h>

The code above also includes a font to draw text on the OLED Display. There are many fonts one can use, and a non-exhaustive list is present below (files are located in the Adafruit GFX Library, subfolder Fonts):

   FreeMono12pt7b.h
   FreeMono18pt7b.h
   FreeMono24pt7b.h
   FreeMono9pt7b.h
   FreeMonoBold12pt7b.h
   FreeMonoBold18pt7b.h
   FreeMonoBold24pt7b.h
   FreeMonoBold9pt7b.h
   FreeMonoBoldOblique12pt7b.h
   FreeMonoBoldOblique18pt7b.h
   FreeMonoBoldOblique24pt7b.h
   FreeMonoBoldOblique9pt7b.h
   FreeMonoOblique12pt7b.h
   FreeMonoOblique18pt7b.h
   FreeMonoOblique24pt7b.h
   FreeMonoOblique9pt7b.h
   FreeSans12pt7b.h
   FreeSans18pt7b.h
   FreeSans24pt7b.h
   FreeSans9pt7b.h
   FreeSansBold12pt7b.h
   FreeSansBold18pt7b.h
   FreeSansBold24pt7b.h
   FreeSansBold9pt7b.h
   FreeSansBoldOblique12pt7b.h
   FreeSansBoldOblique18pt7b.h
   FreeSansBoldOblique24pt7b.h
   FreeSansBoldOblique9pt7b.h
   FreeSansOblique12pt7b.h
   FreeSansOblique18pt7b.h
   FreeSansOblique24pt7b.h
   FreeSansOblique9pt7b.h
   FreeSerif12pt7b.h
   FreeSerif18pt7b.h
   FreeSerif24pt7b.h
   FreeSerif9pt7b.h
   FreeSerifBold12pt7b.h
   FreeSerifBold18pt7b.h
   FreeSerifBold24pt7b.h
   FreeSerifBold9pt7b.h
   FreeSerifBoldItalic12pt7b.h
   FreeSerifBoldItalic18pt7b.h
   FreeSerifBoldItalic24pt7b.h
   FreeSerifBoldItalic9pt7b.h
   FreeSerifItalic12pt7b.h
   FreeSerifItalic18pt7b.h
   FreeSerifItalic24pt7b.h
   FreeSerifItalic9pt7b.h

= Step 2 = Add declarations for GPIOs, colours (to ease programming and use names instead of hexadecimal values) and screen height and width. To recall, the OLED display in our lab is square: 128×128 pixels, 16k colours (16-bit 565: RRRRRGGGGGGBBBBB colour model):

//Test configuration of the SPI
#define OLED_SPI_MOSI_PIN 15  //DIN
#define OLED_SPI_SCLK_PIN 18  //CLK
#define OLED_SPI_CS_PIN 11 
#define OLED_SPI_DC_PIN 13
#define OLED_SPI_RST_PIN 12
#define SCREEN_WIDTH 128
#define SCREEN_HEIGHT 128
 
// Color definitions
#define	BLACK           0x0000
#define	BLUE            0x001F
#define	RED             0xF800
#define	GREEN           0x07E0
#define CYAN            0x07FF
#define MAGENTA         0xF81F
#define YELLOW          0xFFE0  
#define WHITE           0xFFFF

= Step 3 = Declare an SPI communication and OLED controller objects:

static SPIClass hspi(HSPI);
static Adafruit_SSD1351 tft = Adafruit_SSD1351(SCREEN_WIDTH, SCREEN_HEIGHT, &hspi, OLED_SPI_CS_PIN, OLED_SPI_DC_PIN, OLED_SPI_RST_PIN);

= Step 4 = Initialise the SPI communication object and the OLED controller object. Then clear the screen (write all black):

   pinMode(OLED_SPI_CS_PIN, OUTPUT);
   hspi.begin(OLED_SPI_SCLK_PIN, -1, OLED_SPI_MOSI_PIN, -1);
   delay(50);
   digitalWrite(OLED_SPI_CS_PIN,LOW);
   tft.begin();
   delay(100);
   tft.fillScreen(BLACK);

= Step 5 = Draw a bitmap around the centre part of the screen (screen is 128x128px); please mind that OLED_SPI_CS_PIN must be LOW (OLED SPI device controller selected) before executing the following code:

  tft.drawRGBBitmap(48,48, epd_bitmap_logo_60, 60, 60);

= Step 6 = Drop some additional text on the screen:

  tft.setFont(&FreeMono9pt7b);
  tft.setTextSize(1);
  tft.setTextColor(WHITE);
  tft.setCursor(0,10);
  tft.println("Hello IoT");

Some remarks regarding coordinates:

• setFont sets the base font later used for printing. The font size is given in the font name, so in the case of the FreeMono9pt7b, the base font size is 9 pixels vertically,
• setTextSize sets a relative font scaling; assuming the base font is 9 pixels, setTextSize(2) will scale it up to 200% (18 pixels); there is no fractal calling here :(,
• setTextColor controls the colour of the text: as we have a black screen (fillScreen(BLACK)), we will use white here, but any other colour is valid,
• setCursor(X,Y) sets the text location; note the upper-left corner is 0.0, but that relates to the lower-left corner of the first letter. So, to write in the first line, you need to offset it down (Y-coordinate) by at least font size (relative, also regarding text size calling, if any).

Besides the functions presented above, the controller class has several other handy functions (among others):

• drawPixel(x,y, colour) draws a pixel in x,y coordinates of the colour colour,
• drawCircle(x,y, radius, colour) draws a circle in x,y coordinates with colour colour and specified radius (in pixels),
• drawLine(x1,y1, x2,y2, colour) draws a line starting from x1,y1 and finished in x2,y2 with given colour - to draw straight (horizontal or vertical) lines there is a faster option:
  • drawFastHLine(x,y, w, colour) draws horizontal line that starts from x,y and of the length w with given colour,
  • drawFastVLine(x,y, h, colour) draws vertical line that starts from x,y and of the length h with given colour,
• drawRect(x,y, w,h, colour) draws a rectange starting in x,y of the width and height w and h and with given colour (no fill),
• drawTriangle(x1,y1, x2,y2, x3,y3, colour) draws a triangle using 3 vertexes and of given colour (no fill),

You should see the image and the text in the video stream.

The screen is black even if I write to it. What to do?: Check if you have initialised an SPI communication object and pulled the “chip select” GPIO down to LOW before drawing. Follow the code example in this manual: it does work!

Project information

This Intellectual Output was implemented under the Erasmus+ KA2.
Project IOT-OPEN.EU Reloaded – Education-based strengthening of the European universities, companies and labour force in the global IoT market.
Project number: 2022-1-PL01-KA220-HED-000085090.

Erasmus+ Disclaimer
This project has been funded with support from the European Commission.
This publication reflects the views of only the author, and the Commission cannot be held responsible for any use that may be made of the information contained therein.

Copyright Notice
This content was created by the IOT-OPEN.EU Reloaded consortium, 2022,2024.
The content is Copyrighted and distributed under CC BY-NC Creative Commons Licence, free for Non-Commercial use.

A Smart LED stripe (also referenced as Digital LED or NEOPIXEL) is a chain of connected LEDs, commonly RGB, but other combinations such as RGBWW (Red+Green+Blue+Warm White+Cold White) or WWA (Warm White+Cold White+Amber) exist. They are controlled with just one pin/GPIO. GPIO drives a first LED in a chain and the LED relays configuration to the next one, and so on.
The most common type of LED stripes is WS2812B (RGB). Initially LED Stripes were powered with 5V, but that limits the length of the chain up to some 1-2m (because of the voltage drop), so nowadays LED stripes powered with 12V and even 24V are getting more and more popular.

In this scenario you will learn how to control a small LED RGB Stripe, composed of 8 Smart (Digital) LEDs.

Familiarise yourself with a hardware reference: this LED Stripe is controlled with a single GPIO (GPIO 34), as presented in the “Table 1: ESP32-S3 SUT Node Hardware Details” on the hardware reference page. To control a WS2812B LED stipe, we will use a library:

lib_deps = freenove/Freenove WS2812 Lib for ESP32@^1.0.5

There are at least two ways (algorithms) to implement this task:

• using dummy blocking (delay(…);) calls in the void loop(); and,
• using a timer (see advanced scenario below).

• C/C++ Language Embedded Programming Fundamentals
• ESP32 General Information
• SUT ESP32 Laboratory Node Hardware Reference
• Optical Output Devices
• ADV1: Using timers to execute code asynchronously

Implement a rainbow of colours flowing through the LED Stripe.

When booking a device, ensure the LED stripe is visible in the camera.

Below, we provide a sample colour configuration that does not reflect the desired effect that should result from the exercise. It is just for instructional purposes. You need to invent how to implement a rainbow effect yourself. = Step 1 = Include necessary library:

#include "Freenove_WS2812_Lib_for_ESP32.h"

= Step 2 = Declare configuration and a controller class:

#define WLEDS_COUNT    8
#define WLEDS_PIN     34
#define WLEDS_CHANNEL  0
 
static Freenove_ESP32_WS2812 stripe = Freenove_ESP32_WS2812(WLEDS_COUNT, WLEDS_PIN, WLEDS_CHANNEL, TYPE_GRB);

= Step 3 = To switch a particular LED, use the following function:

  stripe.setLedColorData(1,60,0,0); //light Red of the 2nd LED
  stripe.show(); //Writes colours to the LED stripe

Parameters are: setLedColorData(int index, u8 r, u8 g, u8 b);.

If you want to set all LEDs in the stripe to the same colour, there is a handy function: setAllLedsColorData(u8 r, u8 g, u8 b);.
Remember to use the show(); function afterwards.

Observe the flow of the colours via the stripe.

I cannot see the colour via the video camera - everything looks white…: Try to lower the LED's brightness.

Project information

This Intellectual Output was implemented under the Erasmus+ KA2.
Project IOT-OPEN.EU Reloaded – Education-based strengthening of the European universities, companies and labour force in the global IoT market.
Project number: 2022-1-PL01-KA220-HED-000085090.

Erasmus+ Disclaimer
This project has been funded with support from the European Commission.
This publication reflects the views of only the author, and the Commission cannot be held responsible for any use that may be made of the information contained therein.

Copyright Notice
This content was created by the IOT-OPEN.EU Reloaded consortium, 2022,2024.
The content is Copyrighted and distributed under CC BY-NC Creative Commons Licence, free for Non-Commercial use.

— MISSING PAGE — — MISSING PAGE —

You will learn how to control a standard miniature servo in this scenario. Standard miniature, so-called “analogue” servo is controlled with a PWM signal of 50Hz with a duty cycle between 1 ms (rotate to 0) and 2 ms (rotate to 180 degrees), where 1.5 ms corresponds to 90 degrees.

A servo has a red arrow presenting the gauge's current position.

The servo is an actuator. It requires a time to operate. So, you should give it time to operate between consecutive changes of the control PWM signal (requests to change its position). Moreover, because of the observation via camera, too quick rotation may not be observable at all depending on the video stream fps. A gap of 2s between consecutive rotations is usually a reasonable choice.

To ease servo control, instead of use of ledc we will use a dedicated library:

ib_deps = dlloydev/ESP32 ESP32S2 AnalogWrite@^5.0.2

This library requires minimum setup but, on the other hand, supports, i.e. fine-tuning of the minimum and maximum duty cycle as some servos tend to go beyond 1ms and above 2ms to achieve a full 180-degree rotation range. It is usually provided in the technical documentation accompanying the servo.

• C/C++ Language Embedded Programming Fundamentals
• ESP32 General Information
• SUT ESP32 Laboratory Node Hardware Reference
• PWM
• Actuators

Rotate the servo to the following angles: 0, 90, 180, 135, 45 and back to 0 degrees.

Check if the servo is in the camera view. The servo is controlled with GPIO 37.

Write your application all in the setup() function, leaving loop() empty.

= Step 1 = Include servo control library, specific for ESP32 and declare GPIO, minimum and maximum duty cycle values:

#include <Servo.h>
#define SRV_PIN 37

MG 90 servos that we use in our lab are specific. As mentioned above, to achieve a full 180-degree rotation range, their minimum and maximum duty cycle timings go far beyond standards. Here, we declare minimum and maximum values for the duty cycle (in microseconds) and a PWM control channel (2):

#define PWMSRV_Ch     2
#define srv_min_us  550
#define srv_max_us 2400

= Step 2 = Define a servo controller object:

static Servo srv;

= Step 3 = Initialise parameters (duty cycle, channel, GPIO):

srv.attach(SRV_PIN, PWMSRV_Ch,srv_min_us, srv_max_us);

50Hz frequency is standard, so we do not need to configure it.

= Step 4 = Rotating a servo is as easy as writing the desired angle to the controller class, e.g.:

srv.write(SRV_PIN,180);
delay(2000);

How do I know minimum and maximum values for the timings for servo operation?: Those parameters are provided along with servo technical documentation, so you should refer to them. Our configuration reflects the servos we use (MG90/SG90), and as you can see, it goes far beyond the standard servo rotation control that is a minimum of 1000us and a maximum of 2000us. Using standard configuration, your servo won't rotate at full 180 degrees but at a shorter rotation range.

Observe the red arrow to rotate accordingly. Remember to give the servo some time to operate.

Project information

This Intellectual Output was implemented under the Erasmus+ KA2.
Project IOT-OPEN.EU Reloaded – Education-based strengthening of the European universities, companies and labour force in the global IoT market.
Project number: 2022-1-PL01-KA220-HED-000085090.

Erasmus+ Disclaimer
This project has been funded with support from the European Commission.
This publication reflects the views of only the author, and the Commission cannot be held responsible for any use that may be made of the information contained therein.

Copyright Notice
This content was created by the IOT-OPEN.EU Reloaded consortium, 2022,2024.
The content is Copyrighted and distributed under CC BY-NC Creative Commons Licence, free for Non-Commercial use.

— MISSING PAGE — — MISSING PAGE —

Digital potentiometer DS1803 is an I2C-controlled device that can digitally control the potentiometer.
Opposite to the physical potentiometers, there are no movable parts.
DS1803 has two digital potentiometers controlled independently. We use just one with the lower cardinal number (index 0). In our example, it is a 100k spread between GND and VCC, and its output is connected to the ADC (analogue to digital converter) input of the ESP32 MCU. This way, the potentiometer's wiper is controlled remotely via the I2C bus.
The device's I2C address is 0x28, and the ADC input GPIO pin is 7.
The digital potentiometer in our laboratory node forms then a loopback device: it can be set (also read) via I2C, and the resulting voltage can be measured on the separate PIN (ADC) 15. This way, it is possible, e.g. to draw a relation between the potentiometer setting and ADC readings to check whether it is linear or forms some other curve.

Reading of the ADC is possible using the regular analogRead(pin) function.

To implement this scenario, it is advised to get familiar with at least one of the following scenarios first:

• EMB5: Using LCD Display,
• EMB6: Using ePaper display,
• EMB7: Using OLED display.

They enable you to present the data on the display (i.e. readings).

To handle communication with the DS1803 digital potentiometer, we use bare I2C programming. For this reason, we need to include only the I2C protocol library:

#include <Wire.h>

Below, we present a sample control library that you need to include in your code:

enum POT_LIST {POT_1 = 0xA9, POT_2=0xAA, POT_ALL=0xAF}; //We have only POT_1 connected
typedef enum POT_LIST POT_ID;
 
//Prototypes
void setPotentiometer(TwoWire&  I2CPipe, byte potValue, POT_ID potNumber);
byte readPotentiometer(TwoWire& I2CPipe, POT_ID potNumber);
 
//Implementation
void setPotentiometer(TwoWire& I2CPipe, byte potValue, POT_ID potNumber)
 {  
  I2CPipe.beginTransmission(DS1803_ADDRESS);
  I2CPipe.write(potNumber);
  I2CPipe.write(potValue);  
  I2CPipe.endTransmission(true);
 };
 
byte readPotentiometer(TwoWire& I2CPipe, POT_ID potNumber) //reads selected potentiometer
 {
  byte buffer[2];  
  I2CPipe.requestFrom(DS1803_ADDRESS,2);
  buffer[0]=I2CPipe.read();
  buffer[1]=I2CPipe.read();
  return (potNumber==POT_1?buffer[0]:buffer[1]);
 };

• C/C++ Language Embedded Programming Fundamentals
• ESP32 General Information
• SUT ESP32 Laboratory Node Hardware Reference
• TWI (I2C)
• DS1803 documentation (external link)

Iterate over the potentiometer settings, read related voltage readings via ADC, and present them in graphical form (as a plot). As the maximum resolution is 256, you can use a plot of 256 points or any other lower value covering all ranges. Present graph (plot) on either ePaper or OLED display, and while doing the readings, you should present data in the LCD (upper row for a set value, lower for a reading of the ADC).

Check if you can see all the displays. Remember to use potentiometer 1 (index 0) because only this one is connected to the ADC input of the ESP32 MCU. In these steps, we present only how to handle communication with a digital potentiometer and how to read the ADC input of the MCU. Methods for displaying the measurements and plotting the graph are present in other scenarios. Remember to include the functions above in your code unless you want to integrate them with your solution.

Below, we assume that you have embedded functions handling operations on the digital potentiometer as defined above in your source file. Remember to add Wire.h include!

= Step 1 = Define I2C bus GPIOs: clock (SCL) uses GPIO 4 and data (SDA) GPIO 5. ADC uses GPIO 7. Digital potentiometer chip DS1803 uses 0x28 I2C address. All definitions are present in the following code:

#define SCL 4
#define SDA 5
#define POT_ADC 7
#define DS1803_ADDRESS 0x28

= Step 2 = Declare an array of readings that fits an OLED display. Adjust for ePaper resolution (horizontal) if using it. OLED is 128×128 pixels:

static int16_t aGraphArray[128]; 

= Step 3 = Include functions present in the PREREQUISITES section. = Step 4 = Initialise the I2C bus and configure ADC's GPIO as input:

  Wire.begin(SDA,SCL);
  delay(100);
  pinMode(POT_ADC, INPUT);

= Step 4 = Read the loopback characteristics of the digital potentiometer to ADC loop and store it in the array:

for(byte i=0; i<128; i++)
  { 
    setPotentiometer(I2CPipe, 2*i, POT_1); 
    aGraphArray[i]=analogRead(POT_ADC);
  }

= Step 5 = Display on the OLED. Assume the following handler to the pointer to the display controller class:

SSD1306Wire& display

More information in the scenario EMB7: Using OLED display. Note, ADC measures in the 12-bit mode (we assume such configuration, adapt factor if using other sampling resolution), so values stored in an aGraphArray array are between 0 and 4095.

 float factor = 63./4095.;
 for(byte x=0;x<128;x++)
  {
    int16_t y=63-round(((float)aGraphArray[x])*factor);
    display.setPixel(x,y);
  }
  display.display();

A relation between the potentiometer set value and ADC reading should be almost linear from 0V up to about 3V. It becomes horizontal because the ESP32 chip limits the ADC range to 3V, so going beyond 3V (and due to the electronic construction as in figure 15 it may go to about 3.3V) gives no further increase but rather a reading of the 4096 value (which means the input voltage is over the limit). For this reason, your plot may be finished suddenly with a horizontal instead of linearity decreasing function. It is by design. ADC input of the ESP32 can tolerate values between 3V and 3.3V. The linear correlation mentioned above is never perfect, either because of the devices' implementation imperfection (ESP32's ADC input and digital potentiometer output) or because of the electromagnetic noise. There are many devices in our lab room.

The ADC readings are changing slightly, but I have not changed the potentiometer value. What is going on?: The ADC in ESP32 is quite noisy, mainly when using WiFi parallelly. Refer to the Coursebook and ESP32 documentation on how to increase measurement time that will make internally many readings and return to you an average. Use the analogSetCycles(cycles) function to increase the number of readings for the averaging algorithm. The default is 8, but you can increase it up to 255. Note that the higher the cycles parameter value, the longer the reading takes, so tune your main loop accordingly, particularly when using an asynchronous approach (timer-based). Eventually, you can implement low-pass filters yourself (in the software).

Project information

This Intellectual Output was implemented under the Erasmus+ KA2.
Project IOT-OPEN.EU Reloaded – Education-based strengthening of the European universities, companies and labour force in the global IoT market.
Project number: 2022-1-PL01-KA220-HED-000085090.

Erasmus+ Disclaimer
This project has been funded with support from the European Commission.
This publication reflects the views of only the author, and the Commission cannot be held responsible for any use that may be made of the information contained therein.

Copyright Notice
This content was created by the IOT-OPEN.EU Reloaded consortium, 2022,2024.
The content is Copyrighted and distributed under CC BY-NC Creative Commons Licence, free for Non-Commercial use.

In this scenario, we will introduce a popular DHT11 sensor. The DHT series covers DHT11, DHT22, and AM2302. Those sensors differ in accuracy and physical dimensions but can all read environmental temperature and humidity. This scenario can be run stand-alone to read weather data in the laboratory nodes' room. The DHT11 sensor is controlled with one GPIO (in all our laboratory nodes, it is GPIO 47) and uses a proprietary protocol.

Air temperature and humidity can be easily read using a dedicated library. Actually, you need to include two of them, as presented below:

  lib_deps = 
             adafruit/DHT sensor library@^1.4.6
	     adafruit/Adafruit Unified Sensor@^1.1.9

Sensor readings can be sent over the network or presented on one of the node's displays (e.g. LCD), so understanding how to handle at least one of the displays is essential:

• EMB5: Using LCD Display,
• EMB6: Using ePaper display,
• EMB7: Using OLED display.

It is also possible to present the temperature as the LED colour changes with a PWM-controlled LED or LED stripe. Their usage is described here:

• EMB8: Controlling Smart LED stripe
• EMB9A: Use of RGB LEDs.

A good understanding of the hardware timers is essential if you plan to use asynchronous programming (see note below). Consider getting familiar with the following:

• ADV1: Using timers to execute code asynchronously.

• C/C++ Language Embedded Programming Fundamentals
• ESP32 General Information
• SUT ESP32 Laboratory Node Hardware Reference

In this scenario, we only focus on reading the sensor (temperature and humidity). Information on how to display measurements is part of other scenarios that you should refer to to create a fully functional solution (see links above).

Present the current temperature, and humidity on any display (e.g. LCD). Remember to add units (C, %Rh).

A general check to see if you can see the chosen display in the camera field of view is necessary. No other actions are required before starting development.

The steps below present only interaction with the sensor. Those steps should be supplied to present the data (or send it over the network) using other scenarios accordingly. = Step 1 = Include the DHT library and related sensor library.

#include <Adafruit_Sensor.h>
#include <DHT.h>

= Step 2 = Declare type of the sensor and GPIO pin:

#define DHTTYPE DHT11   // DHT 11
#define DHTPIN 47

= Step 3 = Declare controller class and variables to store data:

static DHT dht(DHTPIN, DHTTYPE,50);
static float hum = 0;
static float temp = 0;
static boolean isDHTOk = false;

= Step 4 = Initialise sensor (mind the delay(100); after initialisation as the DHT11 sensor requires some time to initialise before one can read the temperature and humidity:

  dht.begin();
  delay(100);

= Step 5 = Reat the data and check whether the sensor works OK. In the case of the DHT sensor and its controller class, we check the correctness of the readings once the reading is finished. The sensor does not return any status but checks if the reading is okay. This can be done by comparing the readings with the NaN (not a number) value, each separately:

   hum = dht.readHumidity();
   temp = dht.readTemperature();
   (isnan(hum) || isnan(temp))?isDHTOk = false:isDHTOk = true;

The observed temperature is usually between 19 and 24C, with humidity about 40-70%, depending on the weather. On rainy days, it can even go higher.

If you ever notice the temperature going beyond 25C, please drop a note to the administrators: it means that our air conditioning is faulty and needs maintenance .

I've got NaN (Not a Number) readings. What to do?: Check if GPIO is OK (should be D22), check if you initialised controller class and most of all, give the sensor some recovery time (at least 250ms) between consecutive readings.

Project information

This Intellectual Output was implemented under the Erasmus+ KA2.
Project IOT-OPEN.EU Reloaded – Education-based strengthening of the European universities, companies and labour force in the global IoT market.
Project number: 2022-1-PL01-KA220-HED-000085090.

Erasmus+ Disclaimer
This project has been funded with support from the European Commission.
This publication reflects the views of only the author, and the Commission cannot be held responsible for any use that may be made of the information contained therein.

Copyright Notice
This content was created by the IOT-OPEN.EU Reloaded consortium, 2022,2024.
The content is Copyrighted and distributed under CC BY-NC Creative Commons Licence, free for Non-Commercial use.

The temperature-only sensor DS18B20 uses a 1-wire protocol. “1-wire” applies only to the bidirectional bus; power and GND are on separate pins. The sensor is connected to the MCU using GPIO 6 only. Many devices can be connected on a single 1-wire bus, each with a unique ID. DS18B20 also has a water-proof metal enclosure version (but here, in our lab, we use a plastic one) that enables easy monitoring of the liquid's temperature.

To handle operations with DS18B20, we will use a dedicated library that uses a 1-wire library on a low level:

  lib_deps = 
             milesburton/DallasTemperature@^3.11.0

Sensor readings can be sent over the network or presented on one of the node's displays (e.g. LCD), so understanding how to handle at least one of the displays is essential:

• EMB5: Using LCD Display,
• EMB6: Using ePaper display,
• EMB7: Using OLED display.

A good understanding of the hardware timers is essential if you plan to use asynchronous programming (see note below). Consider getting familiar with the following:

• ADV1: Using timers to execute code asynchronously.

• C/C++ Language Embedded Programming Fundamentals
• ESP32 General Information
• SUT ESP32 Laboratory Node Hardware Reference
• 1-Wire

In this scenario, we present how to interface the 1-wire sensor, DS18B20 (temperature sensor).

Read the temperature from the sensor and present it on the display of your choice. Show the reading in C. Note that the scenario below presents only how to use the DS18B20 sensor. How to display the data is present in other scenarios, as listed above. We suggest using an LCD (scenario EMB5: Using LCD Display).

Update reading every 10s. Too frequent readings may cause incorrect readings or faulty communication with the sensor. Remember, the remote video channel has its limits, even if the sensor can be read much more frequently.

Check if your display of choice is visible in the FOV of the camera once the device is booked.

The steps below present only interaction with the sensor. Those steps should be supplied to present the data (or send it over the network) using other scenarios accordingly. = Step 1 = Include Dallas sensor library and 1-Wire protocol implementation library:

#include <OneWire.h>
#include <DallasTemperature.h>

= Step 2 = Declare the 1-Wire GPIO bus pin, 1-Wire communication handling object, sensor proxy and a variable to store readings:

#define ONE_WIRE_BUS 6
static OneWire oneWire(ONE_WIRE_BUS);
static DallasTemperature sensors(&oneWire);
static float tempDS;

= Step 3 = Initialise sensors' proxy class:

  sensors.begin();

= Step 4 = [pczekalski][✓ ktokarz, 2024-04-22] check if you don't need to call sensors.requestTemperatures(); before the code below Read the data:

  if (sensors.getDeviceCount()>0)
  {
    tempDS = sensors.getTempCByIndex(0);
  }
  else
  {
    // Sensors not present (broken?) or 1-wire bus error
  }

Remember not to read the sensor too frequently. 10s between consecutive readings is just fine.
Devices in the 1-Wire bus are addressable either by index (as in the example above) or by their address.
Some useful functions are present below:

• DallasTemperature::toFahrenheit(tempDS) - converts temperature in C to F,
• sensors.getAddress(sensorAddress, index) - reads device address given by uint8_t index and stores it in DeviceAddress sensorAddress.

The library can make non-blocking calls, which can also be implemented using timers, as presented in the scenario ADV1: Using timers to execute code asynchronously.

The observable temperature is usually within the range of 19-24C. If you find the temperature much higher, check your code, and if that is okay, please contact our administrator to inform us about the faulty AC.

Project information

This Intellectual Output was implemented under the Erasmus+ KA2.
Project IOT-OPEN.EU Reloaded – Education-based strengthening of the European universities, companies and labour force in the global IoT market.
Project number: 2022-1-PL01-KA220-HED-000085090.

Erasmus+ Disclaimer
This project has been funded with support from the European Commission.
This publication reflects the views of only the author, and the Commission cannot be held responsible for any use that may be made of the information contained therein.

Copyright Notice
This content was created by the IOT-OPEN.EU Reloaded consortium, 2022,2024.
The content is Copyrighted and distributed under CC BY-NC Creative Commons Licence, free for Non-Commercial use.

It is advised to use timers that periodically execute a function to handle repeating tasks. Hardware timers work parallel to the CPU and consume few CPU resources. ESP32-S3 has 4 hardware timers, but each timer can execute multiple handlers. You can think about these handlers as they are interrupted handling functions, but instead of externally triggered interrupts, those are initiated internally by the hardware timer.
The idea of using the timer is to encapsulate a piece of compact code that can be run virtually asynchronously and executed is a precisely-defined time manner. In this scenario, we use a timer to update the LCD screen periodically. We choose a dummy example where Timer 1 is used to increment a value of the byte type, and Timer 2 reads this value and writes it on the LCD. Naturally, a collision may occur whenever two processes are to access a single memory block (variable). It is critical when both processes (tasks, asynchronous functions) are writing to it. However, in our example, the handler executed by Timer 1 only writes to the variable, while Timer 2 only reads from it. In this scenario, there is no need to use mutexes (semaphores). A scenario with a detailed description of when to use mutexes is beyond the scope of this example.

To implement this scenario, it is necessary to get familiar with at least one of the following scenarios first:

• EMB5: Using LCD Display.

A standard LCD handling library is attached to the platformio.ini, and it is the only library needed. Timers are integrated into the Arduino framework for ESP32.

lib_deps = adafruit/Adafruit LiquidCrystal@^2.0.2 

• C/C++ Language Embedded Programming Fundamentals
• ESP32 General Information
• SUT ESP32 Laboratory Node Hardware Reference
• ESP32 Hardware Timers

Present on the LCD current value of the byte variable; update the LCD every 3 seconds using a timer. Use another timer to increase this variable every 1 second.

Check LCD visibility in the camera FOV. You may also disable LED if it interferes with the camera video stream, as described in the scenario EMB9A: Use of RGB LEDs.

We used to separate tasks, but for this case, complete code is provided in chunks, including LCD handling. It presents relations on where particular parts of the code should be located when using timers and how timing relates between components.

= Step 1 = Include libraries:

#include <Arduino.h>
#include <Adafruit_LiquidCrystal.h>

= Step 2 = Define LCD configuration pins (see details and explanation in the scenario: EMB5: Using LCD Display):

#define LCD_RS 2
#define LCD_ENABLE 1
#define LCD_D4 39
#define LCD_D5 40
#define LCD_D6 41
#define LCD_D7 42

= Step 3 = Declare variables and classes (timers):

volatile byte i = 0;
hw_timer_t *Timer1 = NULL;
hw_timer_t *Timer2 = NULL;
static Adafruit_LiquidCrystal lcd(LCD_RS, LCD_ENABLE, LCD_D4, LCD_D5, LCD_D6, LCD_D7);

Above, we declare two separate timers: Timer1 and Timer2 as pointers. They are initialised later in the setup code.

= Step 4 = Declare constants that define how frequently timers will be calling handlers:

const int baseFrequency = 80; //MHz
const int interval1 = 1000000;  // Interval in microseconds = 1s
const int interval2 = 3000000;  // Interval in microseconds = 3s

The base frequency for the timers in ESP32 is 80 MHz. Each timer counts in microseconds, so we define 2 intervals: 1s (1000000us) for the counter increase and 3s (3000000us) for the LCD update routine.

= Step 5 = Declare and implement functions that are timer handles: timer calls the bound function every execution period:

void IRAM_ATTR onTimer1() //handler for Timer1
{
    i++;
}
 
void IRAM_ATTR onTimer2() //handler for Timer2
{
  lcd.clear();
  lcd.setCursor(0,0);
  lcd.print(i);
}

= Step 6 = Configure timers, start LCD and enable timers. Note the correct order: LCD have to be ready when the timer calls LCD.write(…);:

void setup(){
  //Timer1 config
  Timer1 = timerBegin(0, baseFrequency, true);
  timerAttachInterrupt(Timer1, &onTimer1, true);
  timerAlarmWrite(Timer1, interval1, true);
 
  //Timer2 config
  Timer2 = timerBegin(1, baseFrequency, true);
  timerAttachInterrupt(Timer2, &onTimer2, true);
  timerAlarmWrite(Timer2, interval2, true);
 
  //start LCD
  lcd.begin(16,2);
  lcd.clear();
 
  //start both timers
  timerAlarmEnable(Timer1);
  timerAlarmEnable(Timer2);
}

In the code above, Timer1 = timerBegin(0, baseFrequency, true); creates a new timer bound to the hardware timer 0 (first, timers are zero-indexed). The last parameter causes the timer to count up (false counts down) internally, as every timer has its counter (here 64-bit).
Following, timerAttachInterrupt(Timer1, &onTimer1, true); attaches function onTimer1 (by its address, so we use & operator) to the Timer1 to be executed periodically.
Then we define how frequently the execution of the function above will occur: timerAlarmWrite(Timer1, interval1, true);. The last parameter causes the timer to reload after each execution automatically. Timers can also trigger an action only once (you need to set up the last parameter to false). In our example, we wish continuous work, so we use true.
Note that at this moment, timers are not executing the handlers yet; the last step is required: timerAlarmEnable(Timer1);. This step is separated from the other configuration steps because the LCD has to be initialised before timers can use the LCD.

= Step 7 = This way, a main loop is empty: everything runs asynchronously, thanks to the timers. As suggested above, when timer handlers require long or unpredictable execution time (e.g. external communication, waiting for the reply), handlers should set a flag that is read in the main loop to execute the appropriate task and then clear the flag.

void loop()
{
 
}

On the LCD screen, you should see values starting from number 3, then 6, 9, 12 and so on (=3 every 3 seconds). Note, as byte has a capacity of 256 (0…255), the sequence changes in the following increments once it overflows.

How many timers can I use?: ESP32-S3 has 4 hardware timers. You may trick this limitation by using smart handlers that have, e.g., an internal counter and internally execute every N-th cycle. This helps to simulate more timers in a software way.

Project information

This Intellectual Output was implemented under the Erasmus+ KA2.
Project IOT-OPEN.EU Reloaded – Education-based strengthening of the European universities, companies and labour force in the global IoT market.
Project number: 2022-1-PL01-KA220-HED-000085090.

Erasmus+ Disclaimer
This project has been funded with support from the European Commission.
This publication reflects the views of only the author, and the Commission cannot be held responsible for any use that may be made of the information contained therein.

Copyright Notice
This content was created by the IOT-OPEN.EU Reloaded consortium, 2022,2024.
The content is Copyrighted and distributed under CC BY-NC Creative Commons Licence, free for Non-Commercial use.

— MISSING PAGE — — MISSING PAGE — — MISSING PAGE — — MISSING PAGE — — MISSING PAGE — — MISSING PAGE — — MISSING PAGE — — MISSING PAGE — — MISSING PAGE —

Each laboratory node is equipped with an STM32WB55 chip. Several peripherals, networks and network services are available for the user. The UI is necessary to observe results in the camera when programming remotely. Thus, a proper understanding of UI programming is essential to successfully using the devices.

The table 2 lists all hardware components of the SUT's STM32WB55 node and hardware details such as connectivity, protocols, GPIOs, etc. Please note that some pins overlap because buses such as SPI and I2C are shared among multiple components.
The node is present in the figure 5 and reference numbers reflecting components in the table 2.

A suitable platformio.ini file for the correct code compilation is presented below. It does not contain libraries that need to be added regarding specific tasks and hardware used in particular scenarios. The code below presents only the typical section. Refer to the scenario description for details regarding case-specific libraries needed for the implementation:

platformio.ini

[env:nucleo_wb55rg_p]
platform = ststm32
framework = arduino
board = nucleo_wb55rg_p
lib_ldf_mode = deep+

[ktokarz][✓ ktokarz, 2024-04-21]Rozważ dodanie do platformio.ini sekcji lib_ldf_mode = deep+

• [Scenario Short Code]: [Scenario name] Laboratory scenario template. To be removed in the final version

Know the hardware
The following scenarios explain the use of hardware components and services that constitute the laboratory node. It is intended to seamlessly introduce users to IoT scenarios where using sensors and actuators is an intermediate step, and the main goal is to use networking and communication. Besides IoT, those scenarios can be utilised as a part of the Embedded Systems Modules.

• STM_5: Using LCD Display How do you use LCD (component 5)?
• STM_6: Using ePaper display How do you use the ePaper display (component 6)?
• STM_7: Using OLED display How do you use an OLED display (component 7)?
• STM_8: Controlling Smart LED stripe How do you use the Smart LED stripe (component 8)?
• STM_9A: Use of RGB LEDs How do you use RGB LED (component 9A)?
• STM_10: Controlling standard servo How do you control a standard miniature servo (component 10)?
• STM_1A: Use of fan How do you control a FAN (component 1A)?
• STM_1B: Reading environmental data with a Bosch integrated sensor How do you use pressure and environmental integrated sensor (component 1B)?
• STM_2: Using a digital potentiometer How do you use a digital potentiometer (component 2)?
• STM_3: Use of integrated temperature and humidity sensor How do you use temperature and humidity integrated sensors (component 3)?
• STM_4: 1-Wire Temperature Sensor How do you use a temperature-only sensor (component 4)?
• STM_9B: Reading colour sensor How do you use light and colour intensity sensors (component 9B)?

IoT programming
In the following scenarios, you will write programs interacting with other devices, services, and networks, which are pure IoT applications.

• STM_IoT_1: Reading MAC address of the WiFi Presenting MAC address of the WiFi interface
• STM_IoT_2: Connecting to the WiFi Access Point and presenting IP Connecting to the WiFi Access Point and presenting IP
• STM_IoT_3: Connecting to the MQTT broker and publishing data Connecting to the MQTT broker and publishing data
• STM_IoT_4: Connecting to the MQTT broker and subscribing to the topic Connecting to the MQTT broker and subscribing to the data
• STM_IoT_5: BLE Beacon Publishing a CoAP service
• STM_IoT_6: BLE Communication with characteristics Connecting to the CoAP service
• STM_IoT_7: BLE Communication with indications Setting-up BT Beacon
• IoT_8 Scanning nearby BT devices

[ktokarz][✓ ktokarz, 2024-03-29]Prośba - zamień URLe do EMB9A i EMB9B żeby URL odpowiadał treści/tematowi zadania
Advanced techniques
In the following scenarios, we will focus on advanced programming techniques, such as asynchronous programing and timers.

[ktokarz]Add IoT scenarios

Alphanumerical LCD is one of the most popular output devices in the Embedded and IoT. Using LCD with predefined line organisation (here, 2 lines, 16 characters each) is as simple as sending a character's ASCII code to the device. This is so much simpler than in the case of the use of dot-matrix displays, where it is necessary to use fonts. The fixed organisation LCD has limits; here, only 32 characters can be presented to the user simultaneously. ASCII presents a limited set of characters, but many LCDs can redefine character maps (how each letter, digit or symbol looks). This way, it is possible to introduce graphics elements (i.e. frames), special symbols and letters.

In this scenario, you will learn how to handle easily LCD to present information and retrieve it visually with a webcam.

Familiarise yourself with a hardware reference. LCD of this type can be connected to the microcontroller with 8 or 4 lines of data, RS - register select, R/#W - read/write, and EN - synchronisation line. In our lab equipment, the LCD is controlled with 6 GPIOs. We use 4 lines for data and because We don't read anything from the LCD the R/#W is connected to the ground. Details can be found in Table 1: STM32WB55 Node Hardware Details on the STM32 laboratory hardware reference page. You are going to use a library to handle the LCD. It means you need to add it to your platformio.ini file. Use the template provided in the hardware reference section and extend it with the library definition:

lib_deps = arduino-libraries/LiquidCrystal@^1.0.7

• C/C++ Language Embedded Programming Fundamentals
• STM32
• Optical Output Devices
• SUT STM32 Laboratory Node Hardware Reference

Draw “Hello World” in the upper line of the LCD and “Hello IoT” in the lower one.

Check if you can see a full LCD in your video stream. Book a device and create a dummy Arduino file with void setup()… and void loop()….

= Step 1 = Include the library in your source code:

#include <LiquidCrystal.h>

= Step 2 = Declare GPIOs controlling the LCD, according to the hardware reference:

const int rs = PC5, en = PB11, d4 = PB12, d5 = PB13, d6 = PB14, d7 = PB15;

= Step 3 = Declare an instance of the LCD controller class and preconfigure it with appropriate control GPIOs:

LiquidCrystal lcd(rs, en, d4, d5, d6, d7);

= Step 4 = Initialise class with display area configuration (number of columns, here 16 and rows, here 2):

lcd.begin(16, 2);

= Step 5 = Implement your algorithm. The most common class methods that will help you are listed below:

• .clear() - clears all content;
• .setCursor(x,y) - set cursor, writing will start there;
• .print(contents) - prints text in the cursor location; note there are many overloaded functions, accepting various arguments, including numerical.

A simple example can be the Hello World:

lcd.print("hello, world!");

You should be able to see “Hello World” and “Hello IoT” on the LCD now.

Project information

This Intellectual Output was implemented under the Erasmus+ KA2.
Project IOT-OPEN.EU Reloaded – Education-based strengthening of the European universities, companies and labour force in the global IoT market.
Project number: 2022-1-PL01-KA220-HED-000085090.

Erasmus+ Disclaimer
This project has been funded with support from the European Commission.
This publication reflects the views of only the author, and the Commission cannot be held responsible for any use that may be made of the information contained therein.

Copyright Notice
This content was created by the IOT-OPEN.EU Reloaded consortium, 2022,2024.
The content is Copyrighted and distributed under CC BY-NC Creative Commons Licence, free for Non-Commercial use.

VREL NExtGen laboratory node is equipped with b/w, ePaper module. It is a dot matrix display with a native resolution of 250×122 pixels. It has 64kB display memory and is controlled via SPI. The ePaper display presents data even if powered off, so don't be surprised that finishing your application does not automatically clean up the display, even if you use some other code later. To clean up the display, one has to clear the screen explicitly.

Familiarise yourself with a hardware reference: this ePaper is controlled with 6 GPIOs as presented in the “Table 1: STM32WB55 Node Hardware Details” on the hardware reference page.
You are going to use a library to handle the ePaper drawing. It means you need to add it to your platformio.ini file. Use the template provided in the hardware reference section and extend it with the library definition:

lib_deps = zinggjm/GxEPD2@^1.5.0

• C/C++ Language Embedded Programming Fundamentals
• STM32
• Optical Output Devices
• SUT STM32 Laboratory Node Hardware Reference

To generate an array of bytes representing an image, it is easiest to use an online tool, e.g.:

• https://javl.github.io/image2cpp/

Present an image on the screen and overlay the text “Hello World” over it.

Check if you can see a full ePaper Display in your video stream. Book a device and create a dummy Arduino file with void setup()… and void loop()….

Prepare a small bitmap (e.g. 64×64 pixels) and convert it to the byte array with b/w settings.
Sample project favicon you can use is present in Figure 11:

Remember to include the source array in the code when drawing an image.
The corresponding generated C array for the logo in Figure 22 (horizontal 1 bit per pixel, as suitable for ePaper Display) is present below:

// 'logo64', 64x64px
const unsigned char epd_bitmap_logo_64 [] PROGMEM = {
0xff, 0xff, 0xff, 0xf0, 0x01, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00, 0x00, 0x1f, 0xff, 0xff, 
0xff, 0xff, 0xfc, 0x00, 0x00, 0x03, 0xff, 0xff, 0xff, 0xff, 0xf0, 0x1f, 0xff, 0x80, 0xff, 0xff, 
0xff, 0xff, 0xc0, 0xff, 0xff, 0xf0, 0x3f, 0xff, 0xff, 0xff, 0x83, 0xff, 0xff, 0xfc, 0x1f, 0xff, 
0xff, 0xff, 0x0f, 0xff, 0xff, 0xff, 0x07, 0xff, 0xff, 0xfc, 0x3f, 0xff, 0xff, 0xff, 0xc3, 0xff, 
0xff, 0xf8, 0x7f, 0xff, 0xef, 0xff, 0xe1, 0xff, 0xff, 0xf0, 0xff, 0xff, 0xe8, 0xff, 0xf0, 0xff, 
0xff, 0xe1, 0xff, 0xff, 0xfe, 0x5f, 0xf8, 0x7f, 0xff, 0xc3, 0xff, 0xff, 0xff, 0xf7, 0xfc, 0x3f, 
0xff, 0xc7, 0xff, 0xff, 0xff, 0xf3, 0xfe, 0x3f, 0xff, 0x8f, 0xff, 0xff, 0xff, 0xfe, 0xff, 0x1f, 
0xff, 0x1f, 0xff, 0xff, 0xff, 0xfe, 0xff, 0x8f, 0xff, 0x1f, 0xff, 0xff, 0xff, 0xff, 0x7f, 0x8f, 
0xfe, 0x3f, 0xff, 0xff, 0xff, 0xff, 0xbf, 0xc7, 0xfe, 0x3f, 0xff, 0xff, 0xff, 0xff, 0xdf, 0xc7, 
0xfc, 0x7f, 0xff, 0xff, 0xff, 0xff, 0xcf, 0xe3, 0xfc, 0x7f, 0xff, 0xff, 0xff, 0xff, 0xf7, 0xe3, 
0xf8, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xf3, 0xf8, 0xff, 0xff, 0xff, 0xff, 0xff, 0xfb, 0xf1, 
0xf8, 0xff, 0xff, 0xff, 0xff, 0xff, 0xfb, 0xf1, 0xf9, 0xff, 0xff, 0xff, 0xff, 0xff, 0xfb, 0xf9, 
0xf1, 0xff, 0xff, 0xff, 0xff, 0xff, 0xf9, 0xf9, 0xf1, 0xff, 0xff, 0xff, 0xff, 0xff, 0xfd, 0xf8, 
0xf1, 0xff, 0xff, 0xff, 0x9f, 0xff, 0xfd, 0xf8, 0xf1, 0xff, 0xff, 0xfe, 0x07, 0xff, 0xfd, 0xf8, 
0xf1, 0xff, 0xff, 0xfe, 0x07, 0xff, 0xfd, 0xf8, 0xf1, 0xfc, 0x00, 0x1c, 0x03, 0xff, 0xfc, 0xf8, 
0xf1, 0xfc, 0x00, 0x1c, 0x03, 0xfe, 0xfe, 0xf8, 0xf1, 0xff, 0xff, 0xfe, 0x07, 0xfe, 0xff, 0xf8, 
0xf1, 0xff, 0xff, 0xfe, 0x07, 0xfd, 0xfd, 0xf8, 0xf1, 0xff, 0xff, 0xff, 0x9f, 0xfd, 0xfd, 0xf8, 
0xf1, 0xff, 0xff, 0xff, 0xff, 0xfb, 0xfd, 0xf8, 0xf1, 0xff, 0xe1, 0xff, 0xff, 0xfb, 0xfd, 0xf9, 
0xf1, 0xff, 0x80, 0x7f, 0xff, 0xfb, 0xf9, 0xf9, 0xf1, 0xff, 0x00, 0x3f, 0xff, 0xf7, 0xfb, 0xf1, 
0xf1, 0xfe, 0x3f, 0x3f, 0xff, 0xef, 0xf3, 0xf1, 0xf1, 0xfe, 0x7f, 0x1f, 0xff, 0xcf, 0xff, 0xf3, 
0xf1, 0xfc, 0x7f, 0x9f, 0xff, 0x5f, 0xef, 0xe3, 0xf1, 0xfc, 0x7f, 0x9f, 0xfe, 0xbf, 0xcf, 0xe3, 
0xf1, 0xfc, 0xff, 0x9f, 0xe9, 0xff, 0xef, 0xc7, 0xf1, 0xfc, 0x7f, 0x9f, 0xef, 0xff, 0xbf, 0xc7, 
0xf1, 0xfe, 0x7f, 0x9f, 0xff, 0xff, 0x3f, 0x8f, 0xf1, 0xfe, 0x3f, 0x1f, 0xff, 0xfe, 0xff, 0x8f, 
0xf1, 0xff, 0x00, 0x3f, 0xff, 0xfe, 0xff, 0x1f, 0xf1, 0xff, 0x80, 0x7f, 0xff, 0xf9, 0xfe, 0x3f, 
0xf1, 0xff, 0xc1, 0xff, 0xff, 0xe7, 0xfc, 0x7f, 0xf1, 0xff, 0xff, 0xff, 0xfe, 0x9f, 0xf8, 0x7f, 
0xf1, 0xff, 0xff, 0xff, 0xe8, 0xff, 0xf0, 0xff, 0xf1, 0xff, 0xff, 0xbf, 0xef, 0xff, 0xe1, 0xff, 
0xf1, 0xff, 0xff, 0x9f, 0xff, 0xff, 0xc3, 0xff, 0xf1, 0xfe, 0x00, 0x0f, 0xff, 0xff, 0x07, 0xff, 
0xf1, 0xfe, 0x00, 0x03, 0xff, 0xfc, 0x1f, 0xff, 0xf1, 0xfc, 0x7f, 0x9f, 0xff, 0xf0, 0x3f, 0xff, 
0xf1, 0xfc, 0xff, 0x9f, 0xff, 0x80, 0xff, 0xff, 0xf1, 0xfc, 0xff, 0x9f, 0xc0, 0x03, 0xff, 0xff, 
0xf1, 0xfc, 0x7f, 0x9f, 0xc0, 0x1f, 0xff, 0xff, 0xf1, 0xfe, 0x7f, 0xff, 0xc0, 0xff, 0xff, 0xff, 
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff
};

= Step 1 = Include necessary libraries and the definition of the font.

// Epaper Display libraries
#include <GxEPD2.h>
#include <GxEPD2_BW.h>
// Fonts
#include <Fonts/FreeMonoBold12pt7b.h>

The code above includes a font to draw text on the ePaper Display. There are many fonts one can use, and a non-exhaustive list is present below (files are located in the Adafruit GFX Library, subfolder Fonts):

   FreeMono12pt7b.h
   FreeMono18pt7b.h
   FreeMono24pt7b.h
   FreeMono9pt7b.h
   FreeMonoBold12pt7b.h
   FreeMonoBold18pt7b.h
   FreeMonoBold24pt7b.h
   FreeMonoBold9pt7b.h
   FreeMonoBoldOblique12pt7b.h
   FreeMonoBoldOblique18pt7b.h
   FreeMonoBoldOblique24pt7b.h
   FreeMonoBoldOblique9pt7b.h
   FreeMonoOblique12pt7b.h
   FreeMonoOblique18pt7b.h
   FreeMonoOblique24pt7b.h
   FreeMonoOblique9pt7b.h
   FreeSans12pt7b.h
   FreeSans18pt7b.h
   FreeSans24pt7b.h
   FreeSans9pt7b.h
   FreeSansBold12pt7b.h
   FreeSansBold18pt7b.h
   FreeSansBold24pt7b.h
   FreeSansBold9pt7b.h
   FreeSansBoldOblique12pt7b.h
   FreeSansBoldOblique18pt7b.h
   FreeSansBoldOblique24pt7b.h
   FreeSansBoldOblique9pt7b.h
   FreeSansOblique12pt7b.h
   FreeSansOblique18pt7b.h
   FreeSansOblique24pt7b.h
   FreeSansOblique9pt7b.h
   FreeSerif12pt7b.h
   FreeSerif18pt7b.h
   FreeSerif24pt7b.h
   FreeSerif9pt7b.h
   FreeSerifBold12pt7b.h
   FreeSerifBold18pt7b.h
   FreeSerifBold24pt7b.h
   FreeSerifBold9pt7b.h
   FreeSerifBoldItalic12pt7b.h
   FreeSerifBoldItalic18pt7b.h
   FreeSerifBoldItalic24pt7b.h
   FreeSerifBoldItalic9pt7b.h
   FreeSerifItalic12pt7b.h
   FreeSerifItalic18pt7b.h
   FreeSerifItalic24pt7b.h
   FreeSerifItalic9pt7b.h

= Step 2 = Declare GPIOs and some configurations needed to handle the ePaper display properly:

// The epaper display's model is selected
#define GxEPD2_DRIVER_CLASS GxEPD2_213_BN 
#define GxEPD2_DISPLAY_CLASS GxEPD2_BW
 
// Definition of GPIOs except SPI pins
#define EPAPER_DC_PIN D4
#define EPAPER_CS_PIN D1
#define EPAPER_RST_PIN D5
#define EPAPER_BUSY_PIN D7
 
// Definition of the size of the buffer
#define MAX_DISPLAY_BUFFER_SIZE 65536ul 
#define MAX_HEIGHT(EPD) (EPD::HEIGHT <= MAX_DISPLAY_BUFFER_SIZE / (EPD::WIDTH / 8) ? EPD::HEIGHT : MAX_DISPLAY_BUFFER_SIZE / (EPD::WIDTH / 8))

= Step 3 = Declare ePaper display controller:

static GxEPD2_DISPLAY_CLASS<GxEPD2_DRIVER_CLASS, MAX_HEIGHT(GxEPD2_DRIVER_CLASS)> display(GxEPD2_DRIVER_CLASS(/*CS=*/ EPAPER_CS_PIN, /*DC=*/ EPAPER_DC_PIN, /*RST=*/ EPAPER_RST_PIN, /*BUSY=*/ EPAPER_BUSY_PIN));

You can also declare a message to display as an array of characters:

static const char HelloWorldMsg[] = "Hello IoT World!";

= Step 4 = Configure GPIOs and initialise the ePaper controller class. It uses the standard SPI connection.

    pinMode(EPAPER_CS_PIN, OUTPUT);
    pinMode(EPAPER_RST_PIN, OUTPUT);
    pinMode(EPAPER_DC_PIN, OUTPUT);
    pinMode(EPAPER_BUSY_PIN,INPUT_PULLUP);
 
    digitalWrite(EPAPER_CS_PIN,LOW);
    display.epd2.selectSPI(SPI, SPISettings(4000000, MSBFIRST, SPI_MODE0));
    \\ Delay here is to ensure a stable CS signal before SPI data sending
    delay(100);  
    display.init(115200);
    digitalWrite(EPAPER_CS_PIN,HIGH);    

= Step 5 = Set display rotation, font and text colour:

digitalWrite(EPAPER_SPI_CS_PIN,LOW);
display.setRotation(1);
display.setFont(&FreeMonoBold12pt7b);
display.setTextColor(GxEPD_BLACK);

then get the external dimensions of the string to be printed and calculate the starting point (x, y) for the centred text:

int16_t tbx, tby; uint16_t tbw, tbh;
display.getTextBounds(HelloWorldMsg, 0, 0, &tbx, &tby, &tbw, &tbh);
 
uint16_t x = ((display.width() - tbw) / 2) - tbx;  //center in x arrow
uint16_t y = ((display.height() - tbh) / 4) - tby; //one fourth from the top

= Step 6 = Then display the contents of the image and the text in the ePaper display:

display.setFullWindow();
display.fillScreen(GxEPD_WHITE);
display.setCursor(x, y);
display.print(HelloWorldMsg);
display.display(true);
display.drawImage((uint8_t*)epd_bitmap_logo_64,0,0,64,64);
digitalWrite(EPAPER_SPI_CS_PIN,HIGH);

You should be able to see an image and a text on the ePaper Display.

Project information

This Intellectual Output was implemented under the Erasmus+ KA2.
Project IOT-OPEN.EU Reloaded – Education-based strengthening of the European universities, companies and labour force in the global IoT market.
Project number: 2022-1-PL01-KA220-HED-000085090.

Erasmus+ Disclaimer
This project has been funded with support from the European Commission.
This publication reflects the views of only the author, and the Commission cannot be held responsible for any use that may be made of the information contained therein.

Copyright Notice
This content was created by the IOT-OPEN.EU Reloaded consortium, 2022,2024.
The content is Copyrighted and distributed under CC BY-NC Creative Commons Licence, free for Non-Commercial use.

This scenario presents how to use the OLED display connected to the STM32WB55 SoC. Our OLED display is an RGB (16bit colour, 64k colours) 1.5in, 128×128 pixels. The OLED chip is SSD1351, and it is controlled over the SPI interface using the pin configuration as described in STM32 node Hardware Reference in Table 1 STM32WB55 Node Hardware Details.

There is no need to program SPI because the display is connected to the hardware SPI directly, which is handled by a library built in the STMDuino. We will use an SSD1351 display library, and a graphic abstraction layer for drawing primitives such as lines, images, text, circles, and so on:

lib_deps =
  adafruit/Adafruit SSD1351 library@^1.3.2
  adafruit/Adafruit GFX Library@^1.11.9

Note that the graphics abstraction library (Adafruit GFX) can be loaded automatically if the

lib_ldf_mode = deep+

declaration in the platformio.ini is set.

• C/C++ Language Embedded Programming Fundamentals
• STM32
• Optical Output Devices
• SUT STM32 Laboratory Node Hardware Reference

To generate an array of bytes representing an image in 565 format, it is easiest to use an online tool, e.g.:

• https://javl.github.io/image2cpp/

Draw a text on the OLED display and an image of your choice (small, to fit both text and image).

Perhaps you will need to use an external tool to preprocess an image to the desired size (we suggest something no bigger than 100×100 pixels) and another tool (see hint above) to convert an image to an array of bytes.

Check if you can see a full OLED Display in your video stream. Book a device and create a dummy Arduino file with void setup()… and void loop()….

Prepare a small bitmap and convert it to the byte array for 16-bit colour settings.
Sample project favicon you can use is present in Figure 22:

Remember to include the source array in the code when drawing an image. The corresponding generated C array for the logo in Figure 24 is too extensive to present here in the textual form, so below it is just the first couple of pixels represented in the array, and full contents you can download here: ZIPed archive with a file containing all pixel data of the image .

const uint16_t epd_bitmap_logo64 [] PROGMEM = {
	0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 
	0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xf7be, 0xbdd7, 0x8430, 0x5aeb, 0x39c7, 0x2104, 0x1082, 0x0020, 0x0020, 0x1082, 
	0x2104, 0x39c7, 0x5aeb, 0x8430, 0xbdd7, 0xf7be, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff,
....
 
....
	0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000
};

= Step 1 = Include necessary libraries:

// Libraries
#include <Arduino.h>
#include <Adafruit_GFX.h>
#include <Adafruit_SSD1351.h>
 
// Fonts
#include <Fonts/FreeMono9pt7b.h>
 
// Here you can also include the file with the picture
#include "epd_bitmap_logo64.cpp"

The code above also includes a font to draw text on the OLED Display. There are many fonts one can use, and a non-exhaustive list is present below (files are located in the Adafruit GFX Library, subfolder Fonts):

   FreeMono12pt7b.h
   FreeMono18pt7b.h
   FreeMono24pt7b.h
   FreeMono9pt7b.h
   FreeMonoBold12pt7b.h
   FreeMonoBold18pt7b.h
   FreeMonoBold24pt7b.h
   FreeMonoBold9pt7b.h
   FreeMonoBoldOblique12pt7b.h
   FreeMonoBoldOblique18pt7b.h
   FreeMonoBoldOblique24pt7b.h
   FreeMonoBoldOblique9pt7b.h
   FreeMonoOblique12pt7b.h
   FreeMonoOblique18pt7b.h
   FreeMonoOblique24pt7b.h
   FreeMonoOblique9pt7b.h
   FreeSans12pt7b.h
   FreeSans18pt7b.h
   FreeSans24pt7b.h
   FreeSans9pt7b.h
   FreeSansBold12pt7b.h
   FreeSansBold18pt7b.h
   FreeSansBold24pt7b.h
   FreeSansBold9pt7b.h
   FreeSansBoldOblique12pt7b.h
   FreeSansBoldOblique18pt7b.h
   FreeSansBoldOblique24pt7b.h
   FreeSansBoldOblique9pt7b.h
   FreeSansOblique12pt7b.h
   FreeSansOblique18pt7b.h
   FreeSansOblique24pt7b.h
   FreeSansOblique9pt7b.h
   FreeSerif12pt7b.h
   FreeSerif18pt7b.h
   FreeSerif24pt7b.h
   FreeSerif9pt7b.h
   FreeSerifBold12pt7b.h
   FreeSerifBold18pt7b.h
   FreeSerifBold24pt7b.h
   FreeSerifBold9pt7b.h
   FreeSerifBoldItalic12pt7b.h
   FreeSerifBoldItalic18pt7b.h
   FreeSerifBoldItalic24pt7b.h
   FreeSerifBoldItalic9pt7b.h
   FreeSerifItalic12pt7b.h
   FreeSerifItalic18pt7b.h
   FreeSerifItalic24pt7b.h
   FreeSerifItalic9pt7b.h

= Step 2 = Add declarations for GPIOs, colours (to ease programming and use names instead of hexadecimal values) and screen height and width. To recall, the OLED display in our lab is square: 128×128 pixels, 16k colours (16-bit 565: RRRRRGGGGGGBBBBB colour model):

// Pins definition for OLED 
#define SCLK_PIN     D13 // It also works with STM numbering style PB_13
#define MOSI_PIN     D11 // It also works with STM numbering style PB_15
#define MISO_PIN     D12 // It also works with STM numbering style PB_14
#define OLED_DC_PIN  D4
#define OLED_CS_PIN  D2  // Doesn't work with STM numbering style
#define OLED_RST_PIN D10 //
 
// Colours definitions
#define	BLACK         0x0000
#define	BLUE          0x001F
#define	RED           0xF800
#define	GREEN         0x07E0
#define CYAN          0x07FF
#define MAGENTA       0xF81F
#define YELLOW        0xFFE0  
#define WHITE         0xFFFF
 
// Screen dimensions
#define SCREEN_WIDTH  128
#define SCREEN_HEIGHT 128

= Step 3 = Declare an OLED controller objects:

Adafruit_SSD1351 oled = Adafruit_SSD1351(SCREEN_WIDTH, SCREEN_HEIGHT, &SPI, OLED_CS_PIN, OLED_DC_PIN, OLED_RST_PIN);

= Step 4 = Initialise the OLED controller object. Then clear the screen (write all black):

  pinMode(OLED_CS_PIN, OUTPUT);
  pinMode(OLED_RST_PIN, OUTPUT);
  oled.begin();
  oled.fillRect(0, 0, 128, 128, BLACK);

= Step 5 = Draw a bitmap in the left top corner of the screen (screen is 128x128px). The OLED library handles the OLED_CS_PIN automatically.

  oled.drawRGBBitmap(0,0, epd_bitmap_logo64, 64, 64);

= Step 6 = Write some additional text in the middle of the screen:

  oled.setFont(&FreeMono9pt7b);
  oled.setTextSize(1);
  oled.setTextColor(WHITE);
  oled.setCursor(10,80);
  oled.println("Hello IoT");

Some remarks regarding coordinates:

• setFont sets the base font later used for printing. The font size is given in the font name, so in the case of the FreeMono9pt7b, the base font size is 9 pixels vertically,
• setTextSize sets a relative font scaling; assuming the base font is 9 pixels, setTextSize(2) will scale it up to 200% (18 pixels); there is no fractal calling here :(,
• setTextColor controls the colour of the text: as we have a black screen (fillScreen(BLACK)), we will use white here, but any other colour is valid,
• setCursor(X,Y) sets the text location; note the upper-left corner is 0.0, but that relates to the lower-left corner of the first letter. So, to write in the first line, you need to offset it down (Y-coordinate) by at least font size (relative, also regarding text size calling, if any).

Besides the functions presented above, the controller class has several other handy functions (among others):

• drawPixel(x,y, colour) draws a pixel in x,y coordinates of the colour colour,
• drawCircle(x,y, radius, colour) draws a circle in x,y coordinates with colour colour and specified radius (in pixels),
• drawLine(x1,y1, x2,y2, colour) draws a line starting from x1,y1 and finished in x2,y2 with given colour - to draw straight (horizontal or vertical) lines there is a faster option:
  • drawFastHLine(x,y, w, colour) draws horizontal line that starts from x,y and of the length w with given colour,
  • drawFastVLine(x,y, h, colour) draws vertical line that starts from x,y and of the length h with given colour,
• drawRect(x,y, w,h, colour) draws a rectange starting in x,y of the width and height w and h and with given colour (no fill),
• drawTriangle(x1,y1, x2,y2, x3,y3, colour) draws a triangle using 3 vertexes and of given colour (no fill),

You should see the image and the text in the video stream.

The screen is black even if I write to it. What to do?: Check if you have done all the steps shown in the example. Check if you used proper GPIOs to control the OLED display. Follow carefully the code example in this manual: it does work!

This Intellectual Output was implemented under the Erasmus+ KA2.
Project IOT-OPEN.EU Reloaded – Education-based strengthening of the European universities, companies and labour force in the global IoT market.
Project number: 2022-1-PL01-KA220-HED-000085090.

Erasmus+ Disclaimer
This project has been funded with support from the European Commission.
This publication reflects the views of only the author, and the Commission cannot be held responsible for any use that may be made of the information contained therein.

Copyright Notice
This content was created by the IOT-OPEN.EU Reloaded consortium, 2022,2024.
The content is Copyrighted and distributed under CC BY-NC Creative Commons Licence, free for Non-Commercial use.

A Smart LED stripe is a chain of connected digital LEDs (also referenced as NEOPIXEL) which can be individually controlled. The stripe in our lab equipment consists of eight RGB LEDs. There exist also other colour configurations such as RGBWW (Red+Green+Blue+Warm White+Cold White) or WWA (Warm White+Cold White+Amber). They are controlled with just one pin/GPIO. GPIO sends the digital signal to the first LED in a chain and the LED passes data to the next one, and so on.
The most common type of LED stripes is WS2812B (RGB). Initially LED Stripes were powered with 5V, but that limits the length of the chain up to some 1-2m (because of the voltage drop), so nowadays LED stripes powered with 12V and even 24V are getting more and more popular.

In this scenario, you will learn how to control a small LED RGB Stripe, composed of 8 Smart (Digital) LEDs with STM32 SoC.

Familiarise yourself with a hardware reference on the LED Stripe. It is controlled with a single GPIO (D8 in Arduino style naming, or PC_12 in Nucleo style naming), as presented in the “Table 1: STM32WB55 Node Hardware Details” on the hardware reference page. To control a WS2812B LED stipe, we will use a library:

adafruit/Adafruit NeoPixel@^1.12.0

There are at least two ways (algorithms) to implement this task:

• using the blocking (delay(…);) function calls in the void loop(); or,
• using a timer (see advanced scenario).

• C/C++ Language Embedded Programming Fundamentals
• STM32
• SUT STM32 Laboratory Node Hardware Reference
• Optical Output Devices

Implement a rainbow of colours flowing through the LED Stripe.

When booking a device, ensure the LED stripe is visible in the camera.

Below, we provide a sample colour configuration that does not reflect the desired effect that should result from the exercise. It is just for instructional purposes. You need to invent how to implement a rainbow effect yourself. = Step 1 = Include necessary library:

#include "Adafruit_NeoPixel.h"

= Step 2 = Declare configuration and a controller class:

#define NEOPIXEL_PIN D8  //Arduino numbering D8, STM numbering PC_12
#define NUMPIXELS 8      //How many LEDs are attached
 
Adafruit_NeoPixel strip(NUMPIXELS, NEOPIXEL_PIN, NEO_GRB + NEO_KHZ800);

The strip class definition contains the number of pixels, the pin for transmission, and the type of LEDs. In our laboratory LEDs use Green Red Blue format of data and 800kHz data transmission frequency. = Step 3 = To switch a particular LED, use the function setPixelColor();. It accepts parameters of different types.

void setPixelColor(uint16_t n, uint8_t r, uint8_t g, uint8_t b);
void setPixelColor(uint16_t n, uint32_t c);

If you use the first version you give the LED number as the first parameter and then three colour values for red, green and blue colour intensity as the number in the 0-255 range.
If you use the second version you give the LED number as the first parameter and a 32-bit version of the colour information. To convert three RGB bytes to 32-bit value you can use the function Color();:

static uint32_t Color(uint8_t r, uint8_t g, uint8_t b);

The setPixelColor(); sets the appropriate data in the internal buffer of the class object. Sending it to the LED stripe requires the usage of the show(); function afterwards.
The different versions of the setPixelColor(); function can look like in the following code:

strip.setPixelColor(0, strip.Color(10, 0, 0)); // Red
strip.setPixelColor(1, 0, 10, 0);              // Green
strip.setPixelColor(2, 0, 0, 10);              // Blue
strip.setPixelColor(3, 0x000F0F0F);            // White
strip.show();                           // Update strip 

Observe the flow of the colours via the stripe.

I cannot see the colour via the video camera - everything looks white…: Try to lower the LED's brightness.

Project information

This Intellectual Output was implemented under the Erasmus+ KA2.
Project IOT-OPEN.EU Reloaded – Education-based strengthening of the European universities, companies and labour force in the global IoT market.
Project number: 2022-1-PL01-KA220-HED-000085090.

Erasmus+ Disclaimer
This project has been funded with support from the European Commission.
This publication reflects the views of only the author, and the Commission cannot be held responsible for any use that may be made of the information contained therein.

Copyright Notice
This content was created by the IOT-OPEN.EU Reloaded consortium, 2022,2024.
The content is Copyrighted and distributed under CC BY-NC Creative Commons Licence, free for Non-Commercial use.

— MISSING PAGE — — MISSING PAGE —

You will learn how to control a standard miniature servo with the STM32 System on Chip. Standard miniature analogue servo is controlled with a PWM signal of frequency 50Hz with a duty cycle period between 1 ms (rotate to 0) and 2 ms (rotate to 180 degrees), where 1.5 ms corresponds to 90 degrees. Some servos have other duty cycle minimum and maximum values, always refer to the documentation.

A servo has a red arrow presenting the gauge's current position.

The servo is an example of a physical actuator. It requires some time to operate and change the position. Please give it time to set a new position between consecutive changes of the control PWM signal. Moreover, because of the observation via camera, too quick rotation may not be observable at all depending on the video stream fps. A gap of 2s between consecutive rotations is usually a reasonable choice.

A good understanding of the PWM signal and duty cycle is necessary. In this scenario, we use built-in timers to control the PWM hardware channels of the STM32WB55 chip. In this case, we do not use any external library; instead, we use the hardware timer library built in the Arduino Core STM32 framework for STM32WB55 (stm32duino)^[2] so that no additional external libraries will be included in the project.
Some servos tend to go below 1 ms and above 2 ms to achieve a full 180-degree rotation range. For example, the servo in our laboratory (MG90/SG90) accepts values starting from 500 ms, and ending at 2500 ms. If there is a need for a high accuracy of rotation, it is possible to fine-tune the minimum and maximum duty cycle values.

• C/C++ Language Embedded Programming Fundamentals
• STM32
• Actuators
• SUT STM32 Laboratory Node Hardware Reference
• PWM

Rotate the servo to the following angles: 0, 90, 180, 135, 45 and back to 0 degrees.

In the laboratory equipment, the servo and the fan are connected to the same hardware timer instance. It means that both elements use the same base frequency of the PWM signal. If you use a fan and servo in the same project the frequency of the PMW signal needs to match the servo requirements.
The hardware timer library implements functions which allow us to control the duty cycle of the PWM signal and express it in different formats, including percentages. In the case of setting the PWM duty cycle expressed in percentages, the minimum value is 0, and the maximum is 100. We can also express the duty cycle in microseconds which is easier to calculate for the servo.

Write your application all in the setup() function, leaving loop() empty.

= Step 1 = Include Arduino and timer libraries, specific to STM32. The servo is controlled with GPIO PA_10 (the PA_10 name is the STM Nucleo naming convention). Define the pin name constant.

#include "Arduino.h"
#include <HardwareTimer.h>
#define SERVO_PWM_PIN PA0

We will also need some variables:

// PWM variables definitions
TIM_TypeDef *SRVInstance;        //General hardware instance
uint32_t channelSRV;             //2 channel for the servo
HardwareTimer *MyTimServo;       //Hardware Timer class for Servo PWM

= Step 2 = The hardware timer library uses internal timer modules and allows us to define channels attached to the timer. Channels represent the output pins connected to the hardware elements. Our laboratory board uses the same timer to control the servo and fan. In this example, we will use one channel for the servo only setting the proper PWM frequency of the timer. The channel connected to the servo controls the PWM duty cycle.

Create the timer instance type based on the servo pin:

TIM_TypeDef *SRVInstance = (TIM_TypeDef *)pinmap_peripheral(digitalPinToPinName(SERVO_PWM_PIN), PinMap_PWM);

Define the channel for servo:

channelSRV = STM_PIN_CHANNEL(pinmap_function(digitalPinToPinName(SERVO_PWM_PIN), PinMap_PWM));

Instantiate HardwareTimer object. Thanks to 'new' instantiation, HardwareTimer is not destructed when setup() function is finished.

MyTimServo = new HardwareTimer(SRVInstance);

Configure and start PWM

MyTimServo->setPWM(channelSRV, SERVO_PWM_PIN, 50, 5); // 50 Hertz, 5% dutycycle.

= Step 3 = MG 90 servos that we use in our lab are specific. As mentioned above, to achieve a full 180-degree rotation range, their minimum and maximum duty cycle timings go far beyond standards. We will create a function for calculating the duty cycle for the servo with the angle as the input parameter.

void fSrvSet(int pAngle)
{
  if (pAngle<0) pAngle=0;        //check boudaries of angle
  if (pAngle>180) pAngle=180;
  int i_srv=500+(200*pAngle)/18; //minimal duty cycle is 0,5ms, maximal 2,5ms
  MyTimServo->setCaptureCompare(channelSRV, i_srv, MICROSEC_COMPARE_FORMAT);  //modify duty cycle
};

= Step 4 = Rotating a servo is as easy as calling our function with the desired angle as the parameter, e.g.:

fSrvSet(90);
delay(2000);

How do I know minimum and maximum values for the timings for servo operation?: Those parameters are provided along with servo technical documentation, so you should refer to them. Our configuration reflects the servos we use (MG90/SG90), and as you can see, it goes far beyond the standard servo rotation control that is a minimum of 1000us and a maximum of 2000us. Using standard configuration, your servo won't rotate at full 180 degrees but at a shorter rotation range. Would it be possible to control the servo and fan with the same program?: Yes, but you have to remember that servo has very strict timing requirements. Because both elements share the same timer, they also share the same frequency which must be set according to the servo requirements.

Observe the red arrow to rotate accordingly. Remember to give the servo some time to operate.

Project information

This Intellectual Output was implemented under the Erasmus+ KA2.
Project IOT-OPEN.EU Reloaded – Education-based strengthening of the European universities, companies and labour force in the global IoT market.
Project number: 2022-1-PL01-KA220-HED-000085090.

Erasmus+ Disclaimer
This project has been funded with support from the European Commission.
This publication reflects the views of only the author, and the Commission cannot be held responsible for any use that may be made of the information contained therein.

Copyright Notice
This content was created by the IOT-OPEN.EU Reloaded consortium, 2022,2024.
The content is Copyrighted and distributed under CC BY-NC Creative Commons Licence, free for Non-Commercial use.

— MISSING PAGE — — MISSING PAGE —

Digital potentiometer DS1803 is an I2C-controlled device that digitally controls the resistance between the outputs as in a real turning potentiometer.
While in the turning potentiometers, there are wipers which are moving from minimal to a maximal value, in digital potentiometers there are no movable parts. Everything is implemented in a silicon.
DS1803 has two digital potentiometers controlled independently. We use just one with the lower cardinal number (index 0). In our example, it is a 100k spread between GND and VCC, and its output is connected to the ADC (analogue to digital converter) input of the STM32 SoC. This way, the potentiometer's electronic wiper is controlled remotely via the I2C bus.
The device's I2C address is 0x28, and the ADC input GPIO pin is 7.
The digital potentiometer in our laboratory node forms then a loopback device: it can be set (also read) via I2C, and the resulting voltage can be measured on the separate PIN (ADC) 15. This way, it is possible, e.g. to draw a relation between the potentiometer setting and ADC readings to check whether it is linear or forms some other curve.

Reading of the ADC is possible using the regular analogRead(pin) function. In STM32WB55 there are 16 analogue inputs, and the potentiometer is connected to the pin A4 (PC_3 in Nucleo numbering).

To implement this scenario, it is advised to get familiar with at least one of the following scenarios first:

• STM_5: Using LCD Display,
• STM_6: Using ePaper display,
• STM_7: Using OLED display.

They enable you to present the data on the display (i.e. readings).

To handle communication with the DS1803 digital potentiometer, we use bare I2C programming. For this reason, we need to include only the I2C protocol library:

#include <Wire.h>

Below, we present a sample control library that you need to include in your code:

enum POT_LIST {POT_1 = 0xA9, POT_2=0xAA, POT_ALL=0xAF}; //We have only POT_1 connected
typedef enum POT_LIST POT_ID;
 
//Prototypes
void setPotentiometer(TwoWire&  I2CDev, byte potValue, POT_ID potNumber);
byte readPotentiometer(TwoWire& I2CDev, POT_ID potNumber);
 
//Implementation
void setPotentiometer(TwoWire& I2CDev, byte potValue, POT_ID potNumber)
 {  
  I2CDev.beginTransmission(DS1803_ADDRESS);
  I2CDev.write(potNumber);
  I2CDev.write(potValue);  
  I2CDev.endTransmission(true);
 };
 
byte readPotentiometer(TwoWire& I2CDev, POT_ID potNumber) //reads selected potentiometer
 {
  byte buffer[2];  
  I2CDev.requestFrom(DS1803_ADDRESS,2);
  buffer[0]=I2CDev.read();
  buffer[1]=I2CDev.read();
  return (potNumber==POT_1?buffer[0]:buffer[1]);
 };

• C/C++ Language Embedded Programming Fundamentals
• STM32
• SUT STM32 Laboratory Node Hardware Reference
• TWI (I2C)
• DS1803 documentation (external link)

Iterate over the potentiometer settings, read related voltage readings via ADC, and present them in graphical form (as a plot). As the maximum resolution of the potentiometer is 256, you can use a plot of 256 points or any other lower value covering all ranges. Present graph (plot) on either ePaper or OLED display, and while doing the readings, you should present data in the LCD (upper row for a set value, lower for a reading of the ADC).

Check if you can see all the displays. Remember to use potentiometer 1 (index 0) because only this one is connected to the ADC input of the ESP32 MCU. In steps 1-3, we present how to handle communication with a digital potentiometer and how to read the ADC input of the MCU. Methods for displaying the measurements and plotting the graph are presented in steps 4 and 5. Remember to include the functions above in your code unless you want to integrate them with your solution.

Below, we assume that you have embedded functions handling operations on the digital potentiometer as defined above in your source file. Remember to include the Wire.h library.

= Step 1 = Define ADC pin and Digital potentiometer chip DS1803 I2C address. All definitions are present in the following code:

#define POT_ADC A4
#define DS1803_ADDRESS 0x28

= Step 2 = Declare an array of readings that fits an OLED display. Adjust for ePaper resolution (horizontal) if using it. OLED is 128×128 pixels:

static int16_t aGraphArray[128]; 

= Step 3 = Include functions present in the PREREQUISITES section.

= Step 4 = Initialise the I2C bus and configure ADC's GPIO as input. Change the ADC resolution to 12-bits.

  Wire.begin();
  pinMode(POT_ADC, INPUT);
  analogReadResolution(12);

= Step 4 = Perform the loop that sets 128 values (scaled to the range 0 to 256) on the potentiometer's output and read the value back from the digital potentiometer via ADC input. Store readings in the array:

for(byte i=0; i<128; i++)
  { 
    setPotentiometer(Wire, 2*i, POT_1); 
    aGraphArray[i]=analogRead(POT_ADC);
  }

= Step 5 = Display on the OLED. Assume the following handler to the pointer to the display controller class:

Adafruit_SSD1351 oled

More information on OLED display is in the scenario STM_7: Using OLED display. Note, ADC measures in the 12-bit mode (we assume such configuration, adapt factor if using other sampling resolution), so values stored in an aGraphArray array are between 0 and 4095.

 float factor = 128./4095.;
 for(byte x=0;x<128;x++)
  {
    int16_t y=128-round(((float)aGraphArray[x])*factor);
    display.setPixel(x,y);
  }
  display.display();

A relation between the potentiometer set value and ADC reading should be almost linear from 0V up to the maximum. The linear correlation is never perfect, either because of the devices' implementation imperfection (STM32's ADC input and digital potentiometer output) or because of the electromagnetic noise. There are many devices in our lab room.

The ADC readings are changing slightly, but I have not changed the potentiometer value. What is going on?: The ADC in ESP32 is quite noisy, mainly when using WiFi parallelly. Refer to the Coursebook and ESP32 documentation on how to increase measurement time that will make internally many readings and return to you an average. Use the analogSetCycles(cycles) function to increase the number of readings for the averaging algorithm. The default is 8, but you can increase it up to 255. Note that the higher the cycles parameter value, the longer the reading takes, so tune your main loop accordingly, particularly when using an asynchronous approach (timer-based). Eventually, you can implement low-pass filters yourself (in the software).

Project information

This Intellectual Output was implemented under the Erasmus+ KA2.
Project IOT-OPEN.EU Reloaded – Education-based strengthening of the European universities, companies and labour force in the global IoT market.
Project number: 2022-1-PL01-KA220-HED-000085090.

Erasmus+ Disclaimer
This project has been funded with support from the European Commission.
This publication reflects the views of only the author, and the Commission cannot be held responsible for any use that may be made of the information contained therein.

Copyright Notice
This content was created by the IOT-OPEN.EU Reloaded consortium, 2022,2024.
The content is Copyrighted and distributed under CC BY-NC Creative Commons Licence, free for Non-Commercial use.

In this scenario, we will introduce a popular DHT11 sensor. The DHT series covers DHT11, DHT22, and AM2302. Those sensors differ in accuracy and physical dimensions but can all read environmental temperature and humidity. This scenario can be run stand-alone to read weather data in the laboratory nodes' room. The DHT11 sensor is controlled with one GPIO (in all our laboratory nodes, it is GPIO D22 or PB_2 in Nucleo-style numbering) and uses a proprietary protocol.

Air temperature and humidity can be easily read using a dedicated library. You need to include two of them, as presented below:

  lib_deps = 
             adafruit/DHT sensor library@^1.4.6

Sensor readings can be sent over the network or presented on one of the node's displays (e.g. LCD), so understanding how to handle at least one of the displays is essential:

• STM_5: Using LCD Display,
• STM_6: Using ePaper display,
• STM_7: Using OLED display,

It is also possible to present the temperature as the LED colour change with a PWM-controlled LED or LED stripe. Their usage is described here:

• STM_8: Controlling Smart LED stripe,
• STM_9A: Use of RGB LEDs.

• C/C++ Language Embedded Programming Fundamentals
• STM32
• SUT STM32 Laboratory Node Hardware Reference

In this scenario, we only focus on reading the sensor (temperature and humidity). Information on how to display measurements is part of other scenarios that you should refer to to create a fully functional solution (see links above).

Present the current temperature, and humidity on any display (e.g. LCD). Remember to add units (C, %Rh).

A general check to see if you can see the chosen display in the camera field of view is necessary. No other actions are required before starting development.

The steps below present only interaction with the sensor. Those steps should be supplied to present the data (or send it over the network) using other scenarios accordingly.

= Step 1 = Include the DHT library and related sensor library.

#include <DHT.h>

= Step 2 = Declare type of the sensor and GPIO pin:

#define DHTTYPE DHT11   // DHT 11
#define DHTPIN 47

= Step 3 = Declare controller class and variables to store data:

static DHT dht(DHTPIN, DHTTYPE, 50);
static float hum = 0;
static float temp = 0;
static boolean isDHTOk = false;

= Step 4 = Initialise sensor (mind the delay(100); after initialisation as the DHT11 sensor requires some time to initialise before one can read the temperature and humidity:

  dht.begin();
  delay(100);

= Step 5 = Reat the data and check whether the sensor works OK. In the case of the DHT sensor and its controller class, we check the correctness of the readings once the reading is finished. If something is wrong the sensor library returns the reading as NaN. To check if the value read is OK, compare the readings with the NaN (not a number) text, each separately:

   hum = dht.readHumidity();
   temp = dht.readTemperature();
   (isnan(hum) || isnan(temp))?isDHTOk = false:isDHTOk = true;

The observed temperature is usually between 19 and 24C, with humidity about 40-70%, depending on the weather. On rainy days, it can even go higher.

If you ever notice the temperature going beyond 25C, please drop a note to the administrators: it means that our air conditioning is faulty and needs maintenance .

I've got NaN (Not a Number) readings. What to do?: Check if GPIO is OK (should be D22), check if you initialised controller class and most of all, give the sensor some recovery time (at least 250ms) between consecutive readings.

Project information

This Intellectual Output was implemented under the Erasmus+ KA2.
Project IOT-OPEN.EU Reloaded – Education-based strengthening of the European universities, companies and labour force in the global IoT market.
Project number: 2022-1-PL01-KA220-HED-000085090.

Erasmus+ Disclaimer
This project has been funded with support from the European Commission.
This publication reflects the views of only the author, and the Commission cannot be held responsible for any use that may be made of the information contained therein.

Copyright Notice
This content was created by the IOT-OPEN.EU Reloaded consortium, 2022,2024.
The content is Copyrighted and distributed under CC BY-NC Creative Commons Licence, free for Non-Commercial use.

The temperature-only sensor DS18B20 uses a 1-wire protocol. “1-wire” applies only to the bidirectional bus; power and GND are on separate pins. The sensor is connected to the MCU using GPIO D0 only (PA_3 in Nucleo numbering). Many devices can be connected on a single 1-wire bus, each with a unique ID. Except plastic version, which we have in our laboratory (enclosure TO-92) DS18B20 also comes in a water-proof metal enclosure version that enables easy monitoring of the liquid's temperature.

To handle operations with DS18B20, we will use a dedicated library that uses a 1-wire library on a low level:

  lib_deps = milesburton/DallasTemperature@^3.11.0

Sensor readings can be sent over the network or presented on one of the node's displays (e.g. LCD), so understanding how to handle at least one of the displays is essential:

• STM_5: Using LCD Display,
• STM_6: Using ePaper display,
• STM_7: Using OLED display.

• C/C++ Language Embedded Programming Fundamentals
• STM32
• SUT STM32 Laboratory Node Hardware Reference
• 1-Wire

In this scenario, we present how to interface the 1-wire sensor, DS18B20 (temperature sensor).

Read the temperature from the sensor and present it on the display of your choice. Show the reading in Celsius degrees. Note that the scenario below presents only how to use the DS18B20 sensor. How to display the data is present in other scenarios, as listed above. We suggest using an LCD (scenario STM_5: Using LCD Display).

Update reading every 10s. Too frequent readings may cause incorrect readings or faulty communication with the sensor. Remember, the remote video channel has its limits, even if the sensor can be read much more frequently.

Check if your display of choice is visible in the FOV of the camera once the device is booked.

The steps below present only interaction with the sensor. Those steps should be supplied to present the data (or send it over the network) using other scenarios accordingly.

= Step 1 = Include Dallas sensor library and 1-Wire protocol implementation library:

#include <OneWire.h>
#include <DallasTemperature.h>

= Step 2 = Declare the 1-Wire GPIO bus pin, 1-Wire communication handling object, sensor proxy and a variable to store readings:

#define ONE_WIRE_BUS D0
static OneWire oneWire(ONE_WIRE_BUS);
static DallasTemperature sensors(&oneWire);
static float tempDS;

= Step 3 = Initialise sensors' proxy class:

  sensors.begin();

= Step 4 = Read the data:

  sensors.requestTemperatures();  
  if (sensors.getDeviceCount()>0)
  {
    tempDS = sensors.getTempCByIndex(0);
  }

Remember not to read the sensor too frequently. 10s between consecutive readings is just fine.
Devices in the 1-Wire bus are addressable either by index (as in the example above) or by their address.
Some useful functions are present below:

• DallasTemperature::toFahrenheit(tempDS) - converts temperature in C to F,
• sensors.getAddress(sensorAddress, index) - reads device address given by uint8_t index and stores it in DeviceAddress sensorAddress.

The observable temperature is usually within the range of 19-24C. If you find the temperature much higher, check your code, and if that is okay, please contact our administrator to inform us about the faulty AC.

I've got constant readings of value 85.0. What to do?: Check if GPIO is OK (should be D0), check if you initialised controller class and call the function sensors.requestTemperatures();. Give the OneWire bus and the sensor some recovery time (at least 250ms) between consecutive readings.

Project information

This Intellectual Output was implemented under the Erasmus+ KA2.
Project IOT-OPEN.EU Reloaded – Education-based strengthening of the European universities, companies and labour force in the global IoT market.
Project number: 2022-1-PL01-KA220-HED-000085090.

Erasmus+ Disclaimer
This project has been funded with support from the European Commission.
This publication reflects the views of only the author, and the Commission cannot be held responsible for any use that may be made of the information contained therein.

Copyright Notice
This content was created by the IOT-OPEN.EU Reloaded consortium, 2022,2024.
The content is Copyrighted and distributed under CC BY-NC Creative Commons Licence, free for Non-Commercial use.

— MISSING PAGE — — MISSING PAGE — — MISSING PAGE — — MISSING PAGE — — MISSING PAGE — — MISSING PAGE — — MISSING PAGE — — MISSING PAGE —

The main module is a controller development board (controller board) equipped with the AVR ATmega2561 microcontroller. In addition to the microcontroller, the board consists of several peripherals, voltage stabilizer, connectors, JTAG programmer, Ethernet, SD memory card slot. The controller board has the following features:

• ATmega2561-16AU microcontroller
  • 8-channel 10-bit A/D converter
  • 256 kB Flash memory (program memory)
  • 4kB EEPROM memory (data memory)
  • 6 channel programmable PWM
• Integrated JTAG programmer (based on FTDI2232)
• 14,7456 MHz clock
• Ethernet module with RJ45 connector
• SD memory card slot
• Status LED (PB7)and Power LED
• Programmable button (PC2) and reset button
• All Atmega signals available on three connectors (1: ports D, B, E; 2: ports G, C, A; 3: port F with ADC I/O lines)
• 2,1 mm power socket
• Automatic power switch USB or external power supply
• Built-in voltage stabilizer, with 5 V and 3,3 V output

Controller module

The module is equipped with a AC/DC rectifier circuit and a LDO voltage stabilizer (with low dropout) -an external feeder with voltage stabilization is not needed. The module can be powered with a step down transformer with an output voltage which is greater than 6 volts and lower than 15 volts. In order to reduce power losses it is recommended to use power supply between 6-9V. The POWER LED signalizes a connected feed (“POWER” description on the board). All ATmega2561 signals are available on three connectors on the edge of the board. Connectors pin assignment is described in the next part of this instruction. It includes full descriptions of ATmega2561 pins and their alternative functions. The module is equipped with a microprocessor reset circuit (when power on) and a reset button for a microprocessor restart. A microprocessor can be programmed with an on-board JTAG programmer over USB or with an ISP interface. To the seventh pin of port B (named as PB7) the status LED (described as PB7 on the board) is connected. This LED can be used as a status indicator of application software. Low state on PB7 pin causes the status LED to be lit. The module is equipped with SD memory card slot, where it can be used as a standard microSD memory card. The memory card is connected to the microcontroller via the ISP interface and can be used to store data where data must be maintained even if the power supply is removed.

Components on the Controller board

The User Interface module is designed for simple tasks and basic process control. Module has three push-buttons and three LEDs, which can be used as digital inputs and outputs of microcontroller. Additionally to simple LEDs the module is equipped with 7-segment indicator, graphical LCD display, alphanumeric LCD outputs and a buzzer. User Interface module is handy to use along with other modules enabling to control the output device behavior, like motors and display the sensor readings.

Module features:

• Three LEDs: green, yellow and red;
• Three push-buttons;
• 7-segment indicator;
• Graphical LCD;
• Alphanumeric LCD connector;
• Buzzer;

User Interface module is connected to Controller module to ports PA/PC/PG, which includes the 8-pin ports PA and PC and 6-pin port PG.

User Interface module is equipped with three buttons S1, S2, S3 which are connected to ports PC0, PC1, PC2 accordingly. The other end of buttons are connected through the resistors to ground (logical 0). LED1, LED2 and LED3 on the module are connected to the ports PC3, PC4, PC5 accordingly. The anodes of LEDs are connected to the supply (logical 1).

Schematics of buttons and LEDs

User Interface module is equipped with 7-segment indicator, which is connected to the microcontroller ports through the driver A6275. Driver data bus (S-IN) is connected to pin PC6, clock signal (CLK) to the pin PC7 and latch signal (LATCH) to pin PG2.

Schematics of 7-segment indicator

The graphical LCD display on the module is connected to port PA. In parallel the same port has external connector where all pins are aligned according to the standard 2 x 16 alphanumeric LCD 4 bit control. The user can choose whether to use the graphical or alphanumeric LCD. It is not possible to use both at the same time. The graphical LCD's background lighting can be logically controlled by the software. The back-light intensity of the alphanumeric LCD is regulated with on-board resistor and graphical LCD back-light can be controlled by the software. Both LCD displays are connected to port PA but only one at a time can be used. When selecting the alphanumeric LCD the jumper should be removed to avoid random control of graphical LCD background light.

Schematics of LCD

The buzzer is connected with controller board's pin PG5 and with Vcc. It's possible to generate sound with Robotic Homelab library or with your own software.

Schematics of buzzer

Combo module is used in this remote Laboratory to power the motors and connect external sensors.

Combo module is able to drive following motors:

• 4 x DC motors
• 1 x Stepper
• 2 x Servomotor

Connect following sensors:

• 4 x analog
• 4 x digital
• 2 x coder
• 8x digital inputs trough parallel to serial converter

Use the following communication interfaces:

• UART (3,3 or 5 V )
• ZigBee / Bluetooth / RFID / WiFi / GPS wireless communication module

Combo board with XBee module

Combo board is connected with controller using PA-PB-PC-PD-PE-PF ports. DC and stepper motor feeds come from external power cord, servo motors feed comes trough 5V voltage regulator also from external power cord. Motors power circuit is separated from controller's power circuit. If external power feed is correctly connected to the Combo board the green PWR led will lit.

DC motors is connected to the DC group of pins. Every pair of pins can control 1 dc motor, thus it's possible to manipulate 4 dc motors. Combo board uses bd6226fp H-bridge to control dc motors. It's possible to manipulate some other device, what can be controlled digitally and it's current is smaller than 1 A and voltage does not exceed 18 V, beside dc motor with DC pins (Piezoelectric generator, relay etc).

DC motor connection scheme

Servo is connected to Servo group of pins. Ground wire is connected to the GND pin which is the pin nearest to the board edge. It's possible to use 2 servomotors at once. Signal pins on the Combo module is directly connected to the controller's timer's output pins.

Servomotor connection scheme

Combo module has 4 ADC input pins, every ADC input pin forms a group with Vcc (+5 V) and ground which is marked as GND, that makes them ideal to use to connect analog sensors.

Analog sensor inputs scheme

Combo module has 4 groups of pins where to connect digital sensors. Every group consist of +5 V also called Vcc, ground also called GND and signal pin.

Digital sensor connecting scheme

Combo module has with 8 input pins parallel in serial out shift register 74HC/HCT165, what is able to read in 8 digital signals and convert it to 8 bit digital number. Those inputs are suitable for line follower applications.

Shift register connection scheme, odd pins are on top