Interrupts

Interrupts are a way to achieve concurrency when working with microcontrollers.

An interrupt allows us to “interrupt” the current execution of a program in order to do a different task. This is usually achieved by instructing the microcontroller to look for level changes (From high to low or from low to high) on a GPIO pin and executing a function when that happens.

Interrupt Service Routines (ISR)

ISRs are callback functions that are executed when an interrupt is triggered. They should be made very fast and simple, because they block the execution of other parts of the system.

They are special in that they can’t block execution waiting for a lock and then resume when the lock is available. If we try to hold a mutex within an ISR, the program will crash. For this reason, many ESP-IDF functions (e.g. ESP_LOG functions) can’t be used inside an ISR.

If you need a reminder about resistors in general, you can take a look at my resistors article.

Floating pins

Pull resistors are used to solve the problem of floating pins, so let’s briefly explain what that is.

In the following diagram, we have a simple IC (Integrated Circuit) that works with 5V and has a single GPIO (General Purpose Input/Output) pin:

In my previous article, we learned how to build a stand-alone library for esp-idf. In this article we are going to learn how to write unit tests for our code so we can have confidence it does what we want it to do.

There are a few ways we can go about unit testing code written for ESP32:

• Run tests directly on ESP32 board
• Run tests using an emulator
• Run tests on Linux host using mocks

We are going to learn how to write tests that can run on a Linux host, so it’s easy to plug them to a CI system.

In a previous post, we learned how to modularize software written with esp-idf. The article mentions how we can use the components folder to create different modules.

In this article, we are going to use that knowledge to build a stand-alone library that can live in an independent git repo and can be consumed by different projects.

Example project

ESP-IDF doesn’t support building libraries by themselves, so the only way we can make sure our library is built is by shipping the library with an example project that depends on our library.

Since we also want our library to be easily consumable by other projects, our repo should follow this layout:

1
2
3
4
5
6
7
8
9
10
11
12
13
library-root/
├─ CMakeLists.txt
├─ src/
│  ├─ library.cpp
│
├─ include/
│  ├─ library.hpp
│
├─ example/
│  ├─ CMakeLists.txt
│  ├─ main/
│     ├─ CMakeLists.txt
│     ├─ example.cpp

In a previous article we learned how to use ESP32 as a WiFi client. If you haven’t I recommend you take a look at that article, since there are some steps in common that I’m not going to cover in much depth here.

Initialize WiFi

When we are creating a client or and Access Point, we need to initialize NETIF and create the default event loop:

1
2
ESP_ERROR_CHECK(esp_netif_init());
ESP_ERROR_CHECK(esp_event_loop_create_default());

To initialize our WiFi interface as an Access Point, we need to call:

1
esp_netif_create_default_wifi_ap();

Some of the most popular databases out there (PostgreSQL, MySQL, MongoDB, etc) use b-trees for their indexes. In this article, we’re going to learn how they work and understand why they are used.

Files

Before we understand how databases store information, we need to understand how computers store information.

When we want to persist data, we use the file system API. This API allows us to open files for reading, writing or appending. When a file is opened, it’s loaded into memory. Once the data is in memory, we can access bytes sequentially or in any order we desire (Random Access).

I was reading some networking code and I stumbled into something that looked similar to this:

1
2
3
4
5
typedef struct __attribute__((__packed__)) {
  uint8_t a;
  uint16_t b;
  uint32_t c;
} some_t;

I had no idea what __attribute__((__packed__)) meant, so I did some digging and learned a bit about data alignment.

In this article, we are going to learn how to use NVS to store key-value pairs that persist even if our board is restarted.

What is NVS

NVS stands for Non-Volatile Storage. It’s a library that allows us to store key-value pairs in flash memory.

ESP-IDF projects partition the boards flash into different sections. Among these partitions, there is one where our application code lives and there is another section we can use to store any data we want. This section is called the data partition, and that’s what NVS uses for storage.

Flash models

Different development boards might come with different models of flash memory. I bought a cheap development board from my local electronics shop, and it didn’t include much information about the specs, so I didn’t really know what flash it uses.

Luckily, ESP-IDF comes with a tool we can use to get information about our flash memory:

1
esptool.py --port /dev/ttyUSB0 flash_id

The output for my board included this:

1
2
3
Manufacturer: 5e
Device: 4016
Detected flash size: 4MB

I have in the past written an article explaining how to send HTTP requests with Arduino. This time we’re going to learn how to do it using ESP-IDF.

This article is the result of my learnings from analyzing the official ESP HTTP client example.

ESP-NETIF

ESP-NETIF is ESP32’s abstraction for TCP/IP. It’s not too complicated to use, but it’s somewhat verbose. All applications that use it need to start by calling:

1
esp_netif_init();

This function should be called only once, when the application starts.

In my ESP32 journey, I’ve come to a point, where I want to be able to split my code into libraries and consume third-party libraries. In this article, I’m going to explore how to do this.

The project directory tree

ESP32 projects follow a folder structure:

1
2
3
4
5
6
7
8
9
10
11
12
project/
├─ components/
│  ├─ component1/
│  │  ├─ CMakeLists.txt
│  │  ├─ ...
│  ├─ component2/
│     ├─ CMakeLists.txt
│     ├─ ...
├─ main/
│  ├─ CMakeLists.txt
│  ├─ ...
├─ CMakeLists.txt