GATT is the Generic Attribute Profile, and it provides the structure that makes Bluetooth Low Energy (BLE) devices exchange meaningful information. Without GATT, Bluetooth radios would simply move bits back and forth with no agreed format or interpretation. With GATT, devices can communicate in a predictable and understandable language.

Think of Bluetooth radios as two people speaking to each other in a room. The radio waves allow them to talk, but without a common language, the exchange is useless. GATT provides that common language. It defines the vocabulary, grammar, and sentence structure. Instead of random binary, we get clear messages like Heart Rate equals 78 bpm, Battery equals 92 percent, or Light Switch equals ON.

Because of GATT, devices from different manufacturers are able to interoperate. A Polar heart rate strap can connect to a Peloton bike. A Samsung phone can read temperature from a medical sensor. An Apple Watch can control Philips Hue smart lights. These devices do not share hardware, companies, or operating systems, yet they can cooperate because GATT defines a universal structure for exposing and accessing data.

Once you understand GATT, Bluetooth becomes far less mysterious. Communication becomes a matter of reading or writing values in a small structured database. Debugging becomes logical. BLE app development becomes straightforward. And building your own IoT device becomes achievable, even for beginners.

In this article, we’ll walk through GATT in depth. You’ll learn how devices organize data into services and characteristics, how phones discover and read values, how notifications deliver real time updates, and how embedded and Android code interact with GATT. By the end, you’ll be able to design a GATT database, understand BLE logs, and confidently build BLE applications.

Prerequisites

Before you continue, you should have a basic understanding of:

• What Bluetooth is at a high level (no deep protocol knowledge needed)

• How mobile apps connect to external devices (Android, iOS, or embedded)

• Very basic programming concepts (variables, functions, objects)

You’ll also need:

• A smartphone or laptop with Bluetooth Low Energy support

• A BLE-compatible development board or device (optional, but helpful if you want to try the code examples)

• A BLE debugging/scanning app such as nRF Connect, LightBlue, or BLE Scanner

If you’re completely new to BLE, don’t worry – this article walks through each concept step-by-step.

Table of Contents

• What is GATT?

• What Are Services and Why Do They Matter?

• What are Characteristics and How Do They Work?

• How to Design a GATT Profile for a Smart Plant Monitor

• Conclusion

What is GATT?

GATT stands for Generic Attribute Profile. It is the structured communication model used by Bluetooth Low Energy devices to exchange data in a clear and organized format.

GATT defines how data is stored, formatted, accessed, updated, and transmitted across BLE connections. Without GATT, Bluetooth devices would only exchange unstructured binary information that has no consistent meaning. With GATT, devices can share values such as battery percentage, heart rate, temperature readings, and status commands in a well-defined way.

GATT Client and Server Roles

All communication in BLE occurs between two roles. The GATT Server owns and exposes the data. The GATT Client requests, reads, writes, or subscribes to that data. The Server holds a database of values that the Client interacts with. A smartwatch usually acts as a GATT Server because it holds sensor values. A smartphone usually acts as a GATT Client because it retrieves that information.

These roles can switch depending on the task. For example, during a firmware update, the phone acts as the GATT Server providing firmware blocks and the wearable acts as the GATT Client requesting them.

Services, Characteristics, and UUIDs

The GATT Server stores its data in a structured database made up of Services and Characteristics. A Service is a container that groups related information. A Characteristic is a single data value inside a service.

For example, the Battery Service contains the Battery Level characteristic. The Heart Rate Service contains the Heart Rate Measurement characteristic.

All services and characteristics are identified using UUID values so that every device knows how to locate them. Standard Bluetooth SIG defined services such as Heart Rate and Battery use 16 bit UUIDs. Custom proprietary features use 128 bit UUIDs.

Example GATT Database Layout

Here is a conceptual breakdown of a simple GATT database layout:

Service: Battery Service (UUID 0x180F)
    Characteristic: Battery Level (UUID 0x2A19)
    Example value: 92 percent

Example: Reading a GATT Characteristic from Android

When a phone connects to a BLE device and acts as the client, it performs a sequence of steps. It connects to the device, discovers services, finds the characteristic of interest, and reads or subscribes to its value.

The following complete Java example shows an Android app acting as a GATT Client, discovering services and reading the battery level.

public class BleGattClientManager {

    private BluetoothGatt bluetoothGatt;

    private final BluetoothGattCallback gattCallback = new BluetoothGattCallback() {

        @Override
        public void onConnectionStateChange(BluetoothGatt gatt, int status, int newState) {
            if (newState == BluetoothProfile.STATE_CONNECTED) {
                Log.d(TAG, "Connected to device. Discovering services.");
                gatt.discoverServices();
            }
        }

        @Override
        public void onServicesDiscovered(BluetoothGatt gatt, int status) {
            UUID BATTERY_SERVICE_UUID =
                    UUID.fromString("0000180F-0000-1000-8000-00805F9B34FB");
            UUID BATTERY_LEVEL_UUID =
                    UUID.fromString("00002A19-0000-1000-8000-00805F9B34FB");

            BluetoothGattService service = gatt.getService(BATTERY_SERVICE_UUID);
            if (service != null) {
                BluetoothGattCharacteristic characteristic =
                        service.getCharacteristic(BATTERY_LEVEL_UUID);
                if (characteristic != null) {
                    gatt.readCharacteristic(characteristic);
                }
            }
        }

        @Override
        public void onCharacteristicRead(BluetoothGatt gatt,
                                         BluetoothGattCharacteristic characteristic,
                                         int status) {
            if (status == BluetoothGatt.GATT_SUCCESS) {
                int batteryValue = characteristic.getIntValue(
                        BluetoothGattCharacteristic.FORMAT_UINT8, 0);
                Log.d(TAG, "Battery Level: " + batteryValue + " percent");
            }
        }
    };

    public void connect(Context context, BluetoothDevice device) {
        bluetoothGatt = device.connectGatt(context, false, gattCallback);
    }
}

This Java class represents a Bluetooth Low Energy GATT client that connects to a BLE device and reads the battery level characteristic. The class holds a BluetoothGatt object that represents the active BLE connection. The BluetoothGattCallback handles events during the connection lifecycle.

When the device connection state changes and the new state indicates that the device is connected, the callback triggers service discovery by calling gatt.discoverServices().

After the services are discovered, the callback receives onServicesDiscovered, where two standard UUIDs are defined: the Battery Service with UUID 0000180F-0000-1000-8000-00805F9B34FB and the Battery Level characteristic with UUID 00002A19-0000-1000-8000-00805F9B34FB. The client retrieves the Battery Service using gatt.getService, then retrieves the Battery Level characteristic using getCharacteristic.

If both objects are found, the client calls gatt.readCharacteristic, which sends a read request to the server. When the server responds, onCharacteristicRead is invoked. If the response is successful, the characteristic value is extracted using getIntValue as an unsigned 8 bit integer at offset zero, producing a percentage from zero to one hundred. This value is printed to the log.

The connect method initiates the connection by calling device.connectGatt, which begins the communication and links all callbacks.

In summary, the flow is simple: connect to the device, discover services, locate the Battery Service, read the Battery Level characteristic, and print the result. This code shows the core pattern of how a BLE client interacts with a GATT server to request information.

Android as a GATT Server

The Android device can also act as a GATT Server. This is useful when the phone needs to expose its own characteristics that other BLE devices read or write, such as setup information, commands, or configuration data.

Below is a complete example of a custom GATT Server written in Java. It exposes a custom service and a custom characteristic that allows a BLE client to read and write values.

public class BleGattServerManager {

    private BluetoothGattServer gattServer;

    private final UUID SERVICE_UUID =
            UUID.fromString("12345678-1234-5678-1234-56789abcdef0");

    private final UUID CHARACTERISTIC_UUID =
            UUID.fromString("abcdef01-1234-5678-1234-56789abcdef0");

    private final BluetoothGattServerCallback serverCallback =
            new BluetoothGattServerCallback() {

        @Override
        public void onConnectionStateChange(BluetoothDevice device,
                                            int status,
                                            int newState) {
            Log.d(TAG, "Device connected: " + device.getAddress());
        }

        @Override
        public void onCharacteristicReadRequest(BluetoothDevice device,
                                                int requestId,
                                                int offset,
                                                BluetoothGattCharacteristic characteristic) {

            byte[] value = "HELLO_ANDROID_SERVER".getBytes(StandardCharsets.UTF_8);
            gattServer.sendResponse(device, requestId,
                    BluetoothGatt.GATT_SUCCESS, offset, value);
        }

        @Override
        public void onCharacteristicWriteRequest(BluetoothDevice device,
                                                 int requestId,
                                                 BluetoothGattCharacteristic characteristic,
                                                 boolean preparedWrite,
                                                 boolean responseNeeded,
                                                 int offset,
                                                 byte[] value) {

            String received = new String(value, StandardCharsets.UTF_8);
            Log.d(TAG, "Client wrote value: " + received);

            gattServer.sendResponse(device, requestId,
                    BluetoothGatt.GATT_SUCCESS, offset, value);
        }
    };

    public void startServer(Context context) {
        BluetoothManager bluetoothManager =
                (BluetoothManager) context.getSystemService(Context.BLUETOOTH_SERVICE);

        gattServer = bluetoothManager.openGattServer(context, serverCallback);

        BluetoothGattService customService =
                new BluetoothGattService(SERVICE_UUID,
                        BluetoothGattService.SERVICE_TYPE_PRIMARY);

        BluetoothGattCharacteristic customCharacteristic =
                new BluetoothGattCharacteristic(
                        CHARACTERISTIC_UUID,
                        BluetoothGattCharacteristic.PROPERTY_READ |
                        BluetoothGattCharacteristic.PROPERTY_WRITE,
                        BluetoothGattCharacteristic.PERMISSION_READ |
                        BluetoothGattCharacteristic.PERMISSION_WRITE
                );

        customService.addCharacteristic(customCharacteristic);
        gattServer.addService(customService);
    }
}

This Java class implements a Bluetooth Low Energy GATT Server on Android, meaning it exposes a service and characteristic that another BLE device can read or write.

The class holds a BluetoothGattServer instance which is created when the server starts. Two UUIDs are defined, one for the custom service and one for the custom characteristic. The BluetoothGattServerCallback handles incoming events from any remote BLE client that connects to this server.

When a device connects, onConnectionStateChange logs the connection. When a client sends a read request on the characteristic, onCharacteristicReadRequest responds by sending back a static string value, in this case the bytes of the text HELLO_ANDROID_SERVER, using sendResponse with a success status.

When the client writes data to the characteristic, onCharacteristicWriteRequest converts the incoming byte array to a string, logs what was written, and returns a success response to acknowledge that the server accepted the new value.

The startServer method initializes the GATT Server by requesting the BluetoothManager, opening the server, creating a custom primary service, and adding a characteristic to that service with both read and write properties and permissions. The service is then registered on the server through addService, which makes it available to any BLE client that connects.

In summary, this code demonstrates how an Android device can behave like a BLE peripheral and expose a custom readable and writable characteristic that other devices can interact with. This forms the foundation for features like configuration setup, provisioning, remote control commands, or device to device communication.

This example shows that GATT is simply a structured database of readable and writable values that represent meaningful application behavior. Whether the task is battery level reporting, real time health monitoring, remote control of smart devices, or secure provisioning, the exchange always follows this same pattern.

Understanding GATT at this level is the foundation for all Bluetooth Low Energy engineering and problem solving.

What Are Services and Why Do They Matter?

Services as Capability Containers

A Service in GATT is a logical container that groups related data. A single Bluetooth device can expose many services, and each service focuses on one capability or functional category.

For example, a smartwatch may expose a Heart Rate Service, a Battery Service, a Current Time Service, and a Device Information Service. A smart bulb may expose a Lighting Control Service with characteristics to change brightness and color. A medical thermometer may expose a Health Thermometer Service that continuously streams temperature values.

Services exist to separate different categories of information so that any client device can immediately understand what functions are available and how to interact with them.

A service does not hold raw values itself. Instead, it organizes characteristics, which contain the actual data elements. The service only defines the grouping and the type of behavior associated with that group. This design makes BLE communication extremely scalable. Applications only need to know which service to target, then they can discover and manipulate the characteristics inside it.

Standard vs Custom Services

Bluetooth SIG defines many standard services for interoperability. For example, the Battery Service exposes battery level in a characteristic called Battery Level. The Heart Rate Service exposes heart rate values so that any fitness application can subscribe to it. These standard services allow devices from different manufacturers to work together without custom integration.

Anyone building a custom device can also define their own original service using a 128 bit UUID. The structure is the same whether it is standard or custom.

Example: A Device with Multiple Services

Below is an example representation of a device that exposes two services at the same time:

Service: Battery Service (UUID 0x180F)
    Characteristic: Battery Level (UUID 0x2A19)
    Current value: 92 percent

Service: Heart Rate Service (UUID 0x180D)
    Characteristic: Heart Rate Measurement (UUID 0x2A37)
    Current value: 78 bpm

An Android phone acting as a client can discover these services and then interact with characteristics inside them. Discovery is always the first step after establishing a BLE connection.

Discovering Services in Android

The following example shows how to list all available services and log them in Java.

@Override
public void onServicesDiscovered(BluetoothGatt gatt, int status) {
    for (BluetoothGattService service : gatt.getServices()) {
        Log.d(TAG, "Service discovered: " + service.getUuid().toString());
    }
}

This method is called automatically after the BLE client has finished discovering all services exposed by the remote GATT server. When a connection is established, the client initiates a service discovery procedure, and once the server responds with the complete list of available services, the Android stack triggers onServicesDiscovered.

Inside this callback, the code iterates through every BluetoothGattService returned by gatt.getServices(), which represents all services implemented by the connected device. For each service in that list, the code prints its UUID to the log. This output helps developers inspect what services exist on the device, confirm that expected services such as Heart Rate, Battery, or a custom service are present, and identify the correct UUIDs needed for reading or writing characteristics later.

This method is especially useful during development or debugging, because it allows you to verify that a device correctly exposes its GATT database and that the client can access the list of services before attempting to interact with any characteristics.

Notifications for Continuously Changing Data

Once the service is found, the next step is to read or subscribe to its characteristics. Some characteristics contain static or rarely changing values, which makes direct reads appropriate. Others, such as heart rate or temperature, change continuously, and should use notifications.

Why Notifications Matter in Services

Notifications allow a device to receive updates automatically whenever the value changes instead of repeatedly reading the characteristic. This reduces energy usage and latency, which is essential for wearables and sensors.

Below is a Java example showing how to enable notifications for the Heart Rate Measurement characteristic:

private void enableHeartRateNotifications(BluetoothGatt gatt) {

    UUID HEART_RATE_SERVICE_UUID =
            UUID.fromString("0000180D-0000-1000-8000-00805F9B34FB");
    UUID HEART_RATE_MEASUREMENT_UUID =
            UUID.fromString("00002A37-0000-1000-8000-00805F9B34FB");

    BluetoothGattService service = gatt.getService(HEART_RATE_SERVICE_UUID);
    if (service != null) {
        BluetoothGattCharacteristic characteristic =
                service.getCharacteristic(HEART_RATE_MEASUREMENT_UUID);

        if (characteristic != null) {
            gatt.setCharacteristicNotification(characteristic, true);

            BluetoothGattDescriptor descriptor =
                    characteristic.getDescriptor(
                            UUID.fromString("00002902-0000-1000-8000-00805F9B34FB")
                    );

            if (descriptor != null) {
                descriptor.setValue(BluetoothGattDescriptor.ENABLE_NOTIFICATION_VALUE);
                gatt.writeDescriptor(descriptor);
            }
        }
    }
}

Enabling Notifications in Android

This method enables notifications for the Heart Rate Measurement characteristic so that the device can push new values automatically whenever the heart rate changes.

It begins by defining the UUIDs for the Heart Rate Service and the Heart Rate Measurement characteristic. Using gatt.getService, it retrieves the Heart Rate Service from the connected device. If that service exists, it locates the Heart Rate Measurement characteristic within it. Once the characteristic is found, the method enables local notification handling on the Android side using setCharacteristicNotification, which prepares the client to receive asynchronous updates.

But enabling local notifications is not enough. The BLE specification requires writing to a special descriptor called the Client Characteristic Configuration Descriptor, identified by UUID 00002902-0000-1000-8000-00805F9B34FB, so that the remote device also knows the client wants updates. The method retrieves this descriptor, sets its value to ENABLE_NOTIFICATION_VALUE, and writes it using writeDescriptor, which sends a request over the air to the server telling it to start sending notifications.

After this sequence completes, updates begin arriving automatically in the onCharacteristicChanged callback whenever the heart rate changes, without needing repeated read requests.

This is the preferred BLE pattern for continuous sensor data such as heart rate, temperature, step count, or motion values because it saves power and provides real time responsiveness.

When the device begins sending notifications, updates are received in the callback below. The values arrive whenever they change, making this very efficient for streaming.

@Override
public void onCharacteristicChanged(BluetoothGatt gatt,
                                    BluetoothGattCharacteristic characteristic) {

    UUID HEART_RATE_MEASUREMENT_UUID =
            UUID.fromString("00002A37-0000-1000-8000-00805F9B34FB");

    if (characteristic.getUuid().equals(HEART_RATE_MEASUREMENT_UUID)) {
        int flag = characteristic.getProperties();
        int format;
        if ((flag & 0x01) != 0) {
            format = BluetoothGattCharacteristic.FORMAT_UINT16;
        } else {
            format = BluetoothGattCharacteristic.FORMAT_UINT8;
        }
        int heartRate = characteristic.getIntValue(format, 1);
        Log.d(TAG, "Heart Rate: " + heartRate + " bpm");
    }
}

This method is called automatically whenever the Bluetooth device sends a notification indicating that the value of a characteristic has changed.

In this example, the method handles updates to the Heart Rate Measurement characteristic. The code first checks whether the characteristic that triggered the callback matches the Heart Rate Measurement UUID 00002A37-0000-1000-8000-00805F9B34FB, ensuring that only relevant updates are processed.

The heart rate data can be encoded in either one or two bytes, depending on the flags defined in the characteristic properties. The method reads these flags and determines the correct format to use when decoding the heart rate value. If the least significant bit is set, the heart rate uses a 16 bit format. Otherwise, it uses a single 8 bit format.

After selecting the appropriate format, the method extracts the heart rate value using getIntValue, beginning at offset 1 because byte 0 contains the flags.

Finally, the value is printed to the log as beats per minute. This method is typically called repeatedly, such as once per second, so the log receives live heart rate updates in real time.

This approach demonstrates how notifications deliver continuous sensor data without repeatedly polling the device, which reduces latency and power usage for both the client and server.

This example demonstrates how the client retrieves real time sensor data using subscription instead of polling. The same mechanism is used for air quality sensors, smart home lighting brightness notifications, industrial temperature monitors, and more.

To summarize this section, a Service is a structured container that organizes related data and is essential for exposing abilities and functionality over BLE. Understanding how to discover and interact with services is the first major step toward building or debugging real Bluetooth applications.

What Are Characteristics and How Do They Work?

The Role of a Characteristic

If a Service is a folder, then a Characteristic is a file inside that folder that actually holds the content. In GATT, the Characteristic is where the real data lives. Almost everything your application cares about will eventually be read from, written to, or subscribed to on a characteristic.

The Four Parts of a Characteristic

A characteristic is more than just a single number. It has four important parts. First, it has a UUID that identifies what it represents. It also has a value that stores the actual bytes. Then it has properties that describe what operations are allowed, such as read, write, or notify. And finally, it has permissions that control who can access it and under what security level. Understanding these pieces is the key to working confidently with BLE.

The UUID tells you what kind of data is inside the characteristic. For example, a standard Battery Level characteristic uses the UUID 0x2A19 and always contains a single byte that represents a percentage from zero to one hundred. A Heart Rate Measurement characteristic uses UUID 0x2A37 and packs heart rate and flags into a structured format. Custom characteristics use 128 bit UUIDs that developers define themselves.

The value is simply a sequence of bytes. On the wire, Bluetooth does not know about integers, floats, or strings. It only sees bytes. On the Android side, the BluetoothGattCharacteristic class helps interpret those bytes as different types. It provides helper methods such as getIntValue, getFloatValue, and getStringValue so that you can decode the data more easily.

The properties of a characteristic describe what kind of operations the client can perform. The most common properties are Read, Write, Notify, and Indicate.

Read means a client can ask the server to return the current value. Write means a client can send a new value to the server. Notify means the server can send updates to the client whenever the value changes. Indicate is similar to Notify, but with an extra confirmation. A characteristic may have one or many properties combined.

Permissions are related but slightly different. They focus on access control and security. For example, a characteristic may require encryption or authenticated pairing before it can be read or written. The Android BluetoothGattCharacteristic object contains these permission flags so that the stack enforces them correctly.

Example: Defining a Custom LED Characteristic

Let’s walk through a concrete example. Imagine a custom device that exposes a characteristic to control an LED state. The LED should be either ON or OFF. The characteristic needs to support both read and write, because the client may want to read the current state and also change it.

On the Android GATT Server side, you would define such a characteristic like this:

UUID SERVICE_UUID =
        UUID.fromString("12345678-1234-5678-1234-56789abcdef0");
UUID LED_CHAR_UUID =
        UUID.fromString("abcdef01-1234-5678-1234-56789abcdef0");

BluetoothGattService ledService =
        new BluetoothGattService(SERVICE_UUID,
                BluetoothGattService.SERVICE_TYPE_PRIMARY);

BluetoothGattCharacteristic ledCharacteristic =
        new BluetoothGattCharacteristic(
                LED_CHAR_UUID,
                BluetoothGattCharacteristic.PROPERTY_READ |
                BluetoothGattCharacteristic.PROPERTY_WRITE,
                BluetoothGattCharacteristic.PERMISSION_READ |
                BluetoothGattCharacteristic.PERMISSION_WRITE
        );

// Initial value
ledCharacteristic.setValue("OFF".getBytes(StandardCharsets.UTF_8));
ledService.addCharacteristic(ledCharacteristic);
gattServer.addService(ledService);

This code defines a custom GATT Service and a custom GATT Characteristic on an Android device acting as a Bluetooth Low Energy GATT Server.

Two UUIDs are created using UUID.fromString, one representing the custom service and the other representing the characteristic that belongs to that service. A new BluetoothGattService instance is then created, marked as a primary service to indicate that it is a main functional component rather than a secondary helper service.

Inside that service, a BluetoothGattCharacteristic object is created using the second UUID, and it’s configured to allow both reads and writes by a remote BLE client. The property flags indicate that a client can request the current value and can also send updates, and the permission flags define that both operations are permitted.

The characteristic is given an initial value of the string "OFF" encoded as bytes, which might represent the current state of a remote controlled LED, device mode, or some other configuration setting.

The characteristic is then added to the service, and finally the fully defined service is added to the GATT server using gattServer.addService, making it visible to any BLE client that connects.

At this point, another device can read the value "OFF" or write a new value such as "ON", which the server could then use to trigger real behavior, such as toggling actual hardware.

Handling Reads and Writes on the Server

Server-Side Handlers

On the GATT Server side, you must also respond to read and write requests. This happens inside BluetoothGattServerCallback.

private final BluetoothGattServerCallback serverCallback =
        new BluetoothGattServerCallback() {

    @Override
    public void onCharacteristicReadRequest(BluetoothDevice device,
                                            int requestId,
                                            int offset,
                                            BluetoothGattCharacteristic characteristic) {

        byte[] currentValue = characteristic.getValue();
        gattServer.sendResponse(device,
                requestId,
                BluetoothGatt.GATT_SUCCESS,
                offset,
                currentValue);
    }

    @Override
    public void onCharacteristicWriteRequest(BluetoothDevice device,
                                             int requestId,
                                             BluetoothGattCharacteristic characteristic,
                                             boolean preparedWrite,
                                             boolean responseNeeded,
                                             int offset,
                                             byte[] value) {

        String received = new String(value, StandardCharsets.UTF_8);
        Log.d(TAG, "LED characteristic write: " + received);

        characteristic.setValue(value);

        if ("ON".equalsIgnoreCase(received)) {
            turnLedOn();
        } else if ("OFF".equalsIgnoreCase(received)) {
            turnLedOff();
        } else {
            Log.e(TAG, "Unhandled case!");
            return;
        }

        if (responseNeeded) {
            gattServer.sendResponse(device,
                    requestId,
                    BluetoothGatt.GATT_SUCCESS,
                    offset,
                    value);
        }
    }
};

This callback handles read and write requests coming from a remote BLE client interacting with the custom LED characteristic on the GATT Server.

When a client performs a read operation, onCharacteristicReadRequest is triggered. The method retrieves the current stored value from the characteristic using getValue() and returns it to the client by calling sendResponse with a success status. This means whatever value was last set, such as "ON" or "OFF", is sent back to the requesting device.

When a client performs a write operation, onCharacteristicWriteRequest is called. The method converts the incoming byte array into a string so that the server can interpret the command. It logs the received text, sets the new value into the characteristic using setValue, and then checks whether the string equals "ON" or "OFF". Depending on the value, it calls either turnLedOn() or turnLedOff(), which would typically control real hardware or trigger an action inside the application.

If the client requested a response, the server sends back a confirmation by calling sendResponse with GATT_SUCCESS, acknowledging that the write completed successfully. This callback demonstrates how interactive BLE control works: the server receives a command, updates internal state, performs a real action, and reports status back to the client.

Here, the server reads whatever value is stored in the characteristic upon a read request and sends it back to the client. When the client writes a new value, the server decodes the bytes as a string and updates internal state, including physical behavior like toggling the LED.

Reading and Writing from the Client

Client-Side Handlers

On the client side, a typical Android app needs to read and write to this same characteristic. The code for the client looks similar to what we saw in earlier sections, but now it uses the custom UUIDs.

Reading a Custom Characteristic (Client)

Reading the LED state from the client:

public void readLedState(BluetoothGatt gatt) {
    UUID SERVICE_UUID =
            UUID.fromString("12345678-1234-5678-1234-56789abcdef0");
    UUID LED_CHAR_UUID =
            UUID.fromString("abcdef01-1234-5678-1234-56789abcdef0");

    BluetoothGattService service = gatt.getService(SERVICE_UUID);
    if (service != null) {
        BluetoothGattCharacteristic ledChar = service.getCharacteristic(LED_CHAR_UUID);
        if (ledChar != null) {
            gatt.readCharacteristic(ledChar);
        }
    }
}

@Override
public void onCharacteristicRead(BluetoothGatt gatt,
                                 BluetoothGattCharacteristic characteristic,
                                 int status) {
    if (status == BluetoothGatt.GATT_SUCCESS) {
        UUID LED_CHAR_UUID =
                UUID.fromString("abcdef01-1234-5678-1234-56789abcdef0");
        if (LED_CHAR_UUID.equals(characteristic.getUuid())) {
            String value = new String(characteristic.getValue(), StandardCharsets.UTF_8);
            Log.d(TAG, "LED state is: " + value);
        }
    }
}

This code shows how a Bluetooth Low Energy client reads the current state of a custom LED characteristic from a GATT server. The readLedState method begins by defining the UUIDs for the custom service and the LED characteristic so that the client knows exactly where to look inside the server’s GATT database.

It retrieves the service using gatt.getService, and if the service exists, it retrieves the LED characteristic using getCharacteristic. If that characteristic is found, the client calls readCharacteristic, which sends a read request to the remote device over BLE. Once the server responds, the callback method onCharacteristicRead is triggered.

This method first checks that the read was successful by confirming that the status equals GATT_SUCCESS. It then verifies that the characteristic being read is indeed the LED characteristic by comparing UUIDs. If it matches, the code converts the characteristic’s byte array into a string, which contains either "ON" or "OFF", and logs the current state.

This flow demonstrates how a BLE client reads stored values from a peripheral device and responds when the server returns the data, forming the basis for real world interactions such as checking the status of a smart light, a switch, or any sensor value exposed through a custom characteristic.

Writing to a Custom Characteristic (Client)

Writing a new LED state from the client:

public void writeLedState(BluetoothGatt gatt, String newState) {
    UUID SERVICE_UUID =
            UUID.fromString("12345678-1234-5678-1234-56789abcdef0");
    UUID LED_CHAR_UUID =
            UUID.fromString("abcdef01-1234-5678-1234-56789abcdef0");

    BluetoothGattService service = gatt.getService(SERVICE_UUID);
    if (service != null) {
        BluetoothGattCharacteristic ledChar = service.getCharacteristic(LED_CHAR_UUID);
        if (ledChar != null) {
            ledChar.setValue(newState.getBytes(StandardCharsets.UTF_8));
            gatt.writeCharacteristic(ledChar);
        }
    }
}

@Override
public void onCharacteristicWrite(BluetoothGatt gatt,
                                  BluetoothGattCharacteristic characteristic,
                                  int status) {
    if (status == BluetoothGatt.GATT_SUCCESS) {
        Log.d(TAG, "LED state write completed");
    }
}

This code demonstrates how a Bluetooth Low Energy client sends a command to update the LED state on a GATT server device.

The writeLedState method begins by defining the UUIDs for the custom service and LED characteristic, then retrieves the service from the connected GATT server. If the service is found, it accesses the LED characteristic inside it.

Once the characteristic is obtained, the new LED state, which will typically be the string "ON" or "OFF", is converted into a byte array and placed into the characteristic with setValue. The method then calls writeCharacteristic, which sends a write request to the remote device to update the stored value.

When the server processes the write and returns a response, the callback method onCharacteristicWrite executes. If the status indicates success, the code logs that the write completed. At this point, the server code on the other side can take action based on the new state, such as turning a real LED on or off.

This flow illustrates how clients modify values on a BLE peripheral and how acknowledgment is handled once the operation finishes, forming a typical example of device control over GATT.

This combination of server definitions and client interactions shows how characteristics are the real workhorses of GATT. Every meaningful piece of data flows through them. Reads, writes, and notifications all operate at the characteristic level.

Notifications and CCCD

Notifications are simply a special property on a characteristic. When enabled, the server can push new values to the client without the client asking every time. To support notifications, a characteristic needs the Notify property and usually a descriptor called the Client Characteristic Configuration Descriptor, often referred to as CCCD, with UUID 0x2902.

On the server side, you would update the value and call notifyCharacteristicChanged. On the client side, you set characteristic notification to true and write the descriptor with ENABLE_NOTIFICATION_VALUE. The code pattern is almost identical regardless of the type of data, which makes it easy to reuse once you understand it.

By this point, you can see that a characteristic is not just a static field. It is a complete unit of behavior. It defines what data exists, how it is represented, who can access it, and how it updates. Once you’re comfortable designing characteristics and manipulating them in Java, you’re very close to mastering practical BLE development.

How to Design a GATT Profile for a Smart Plant Monitor

To make GATT feel real, let’s design a complete profile for a simple but realistic device: a smart plant monitor.

Imagine a small BLE sensor that you stick into a flower pot. It measures soil moisture, reports its own battery level, and allows you to configure how often it sends updates. A phone app connects to it, reads the current moisture level, shows the battery percentage, and lets the user adjust the reporting interval.

We’ll design both sides in terms of GATT. First, we’ll decide which services and characteristics we need. Then, we’ll see how an Android device can act as a client. For teaching purposes, we’ll also show how Android could act as the server, although in a real product the plant monitor would normally be an embedded device.

Designing the GATT Profile

We need three logical pieces of information:

1. Soil moisture percentage – this is dynamic sensor data.

2. Battery level – this is standard, so we can reuse the Battery Service.

3. Reporting interval configuration – this is a setting that the client writes and the device uses.

We can express this with one custom service plus the standard Battery Service.

Profile plan:

Custom Service: Plant Monitor Service
    UUID: 12345678-1234-5678-1234-56789abc0001

    Characteristic: Soil Moisture
        UUID: 12345678-1234-5678-1234-56789abc0002
        Properties: Read, Notify
        Permissions: Read
        Format: uint8 (0 to 100 percentage)

    Characteristic: Reporting Interval
        UUID: 12345678-1234-5678-1234-56789abc0003
        Properties: Read, Write
        Permissions: Read, Write
        Format: uint16 (seconds)

Standard Service: Battery Service
    UUID: 0000180F-0000-1000-8000-00805F9B34FB

    Characteristic: Battery Level
        UUID: 00002A19-0000-1000-8000-00805F9B34FB
        Properties: Read, Notify (optional)
        Permissions: Read
        Format: uint8 (0 to 100 percentage)

Now we know exactly what exists inside the device. A client can connect, look for the Plant Monitor Service and Battery Service, and then interact with these three characteristics.

Implementing the GATT Server

In a real hardware product, the plant monitor would be written in embedded C or C++. But for learning, we can simulate the server on Android itself. This’ll help you understand how the server side works.

First, we’ll create the services and characteristics.

public class PlantMonitorGattServer {

    private BluetoothGattServer gattServer;

    private final UUID PLANT_SERVICE_UUID =
            UUID.fromString("12345678-1234-5678-1234-56789abc0001");
    private final UUID MOISTURE_CHAR_UUID =
            UUID.fromString("12345678-1234-5678-1234-56789abc0002");
    private final UUID INTERVAL_CHAR_UUID =
            UUID.fromString("12345678-1234-5678-1234-56789abc0003");

    private final UUID BATTERY_SERVICE_UUID =
            UUID.fromString("0000180F-0000-1000-8000-00805F9B34FB");
    private final UUID BATTERY_LEVEL_UUID =
            UUID.fromString("00002A19-0000-1000-8000-00805F9B34FB");

    // Simulated state
    private int currentMoisture = 55;      // percentage
    private int reportingIntervalSec = 60; // seconds
    private int batteryLevel = 87;         // percentage

    private BluetoothGattCharacteristic moistureCharacteristic;
    private BluetoothGattCharacteristic intervalCharacteristic;
    private BluetoothGattCharacteristic batteryLevelCharacteristic;

This class represents a Bluetooth Low Energy GATT Server that pretends to be a smart plant monitor device. It holds a BluetoothGattServer instance that will expose services and characteristics to any BLE client that connects.

Several UUIDs are defined to identify the custom Plant Monitor Service and its characteristics, as well as the standard Battery Service and Battery Level characteristic.

The custom Plant Monitor Service has two characteristics: one for soil moisture and one for the reporting interval. The Battery Service uses the standard UUIDs defined by the Bluetooth SIG so that any client can recognize and parse it.

The class also keeps some simulated internal state: currentMoisture starts at 55 percent, reportingIntervalSec is set to 60 seconds, and batteryLevel is set to 87 percent. These values act like sensor readings and configuration stored inside the device.

Finally, it declares three BluetoothGattCharacteristic fields that will later point to the actual moisture, interval, and battery level characteristics once they are created and added to their respective services.

These fields make it easy for the server to update values and send notifications later – for example, when moisture changes or when the battery level drops.

Next, we’ll set up the server and define the services and characteristics.

    public void startServer(Context context) {
        BluetoothManager bluetoothManager =
                (BluetoothManager) context.getSystemService(Context.BLUETOOTH_SERVICE);

        gattServer = bluetoothManager.openGattServer(context, serverCallback);

        // Plant Monitor Service
        BluetoothGattService plantService =
                new BluetoothGattService(
                        PLANT_SERVICE_UUID,
                        BluetoothGattService.SERVICE_TYPE_PRIMARY
                );

        moistureCharacteristic = new BluetoothGattCharacteristic(
                MOISTURE_CHAR_UUID,
                BluetoothGattCharacteristic.PROPERTY_READ |
                BluetoothGattCharacteristic.PROPERTY_NOTIFY,
                BluetoothGattCharacteristic.PERMISSION_READ
        );

        intervalCharacteristic = new BluetoothGattCharacteristic(
                INTERVAL_CHAR_UUID,
                BluetoothGattCharacteristic.PROPERTY_READ |
                BluetoothGattCharacteristic.PROPERTY_WRITE,
                BluetoothGattCharacteristic.PERMISSION_READ |
                BluetoothGattCharacteristic.PERMISSION_WRITE
        );

        // Set initial values
        moistureCharacteristic.setValue(new byte[]{(byte) currentMoisture});
        intervalCharacteristic.setValue(intToTwoBytes(reportingIntervalSec));

        // For notifications, add CCCD descriptor
        BluetoothGattDescriptor moistureCccd = new BluetoothGattDescriptor(
                UUID.fromString("00002902-0000-1000-8000-00805F9B34FB"),
                BluetoothGattDescriptor.PERMISSION_READ |
                BluetoothGattDescriptor.PERMISSION_WRITE
        );
        moistureCharacteristic.addDescriptor(moistureCccd);

        plantService.addCharacteristic(moistureCharacteristic);
        plantService.addCharacteristic(intervalCharacteristic);

        // Battery Service
        BluetoothGattService batteryService =
                new BluetoothGattService(
                        BATTERY_SERVICE_UUID,
                        BluetoothGattService.SERVICE_TYPE_PRIMARY
                );

        batteryLevelCharacteristic = new BluetoothGattCharacteristic(
                BATTERY_LEVEL_UUID,
                BluetoothGattCharacteristic.PROPERTY_READ |
                BluetoothGattCharacteristic.PROPERTY_NOTIFY,
                BluetoothGattCharacteristic.PERMISSION_READ
        );

        batteryLevelCharacteristic.setValue(new byte[]{(byte) batteryLevel});

        BluetoothGattDescriptor batteryCccd = new BluetoothGattDescriptor(
                UUID.fromString("00002902-0000-1000-8000-00805F9B34FB"),
                BluetoothGattDescriptor.PERMISSION_READ |
                BluetoothGattDescriptor.PERMISSION_WRITE
        );
        batteryLevelCharacteristic.addDescriptor(batteryCccd);

        batteryService.addCharacteristic(batteryLevelCharacteristic);

        gattServer.addService(plantService);
        gattServer.addService(batteryService);
    }

    private byte[] intToTwoBytes(int value) {
        byte[] data = new byte[2];
        data[0] = (byte) (value & 0xFF);
        data[1] = (byte) ((value >> 8) & 0xFF);
        return data;
    }

This method starts the Bluetooth Low Energy GATT server and builds the full GATT database for the smart plant monitor.

It first obtains the BluetoothManager from the Android system and uses it to open a BluetoothGattServer, passing in a callback that will handle read, write, and notification events from connected clients.

Then it creates the custom Plant Monitor Service using the PLANT_SERVICE_UUID and marks it as a primary service.

Inside this service it defines two characteristics. The moisture characteristic is created with the MOISTURE_CHAR_UUID and given the properties Read and Notify, meaning a client can read the current soil moisture and also subscribe to notifications when it changes. It is read only, so it uses a read permission. The reporting interval characteristic is created with the INTERVAL_CHAR_UUID and uses both Read and Write properties so that a client can check the current interval and update it. It uses both read and write permissions.

The code sets the initial values for these characteristics: the moisture characteristic gets the current moisture percentage stored as a single byte, and the interval characteristic gets a two byte representation of the reporting interval using the helper method intToTwoBytes, which splits a 16 bit integer into low and high bytes.

To allow notifications for moisture, it adds a Client Characteristic Configuration Descriptor (CCCD) with a standard UUID 0x2902 and read or write permissions, then attaches this descriptor to the moisture characteristic. Both characteristics are added to the plant service.

Next, the method creates the standard Battery Service as another primary service using the well-known battery UUID. It defines the Battery Level characteristic with read and notify properties and read permission.

The initial battery level is stored as a single byte. Just like with moisture, it adds a CCCD descriptor to support notifications and attaches it to the battery characteristic. The battery characteristic is then added to the battery service.

Finally, the method registers both the plant service and the battery service with the GATT server using addService, which makes them visible to any BLE client that connects. As a small utility, the intToTwoBytes method at the end converts a 16 bit integer into a two element byte array with the least significant byte first, which is a common way to encode integers in BLE characteristics.

Now we’ll implement the callback to handle read, write, and notification logic.

    private final BluetoothGattServerCallback serverCallback =
            new BluetoothGattServerCallback() {

        @Override
        public void onConnectionStateChange(BluetoothDevice device,
                                            int status,
                                            int newState) {
            Log.d(TAG, "Device connection state: " + newState);
        }

        @Override
        public void onCharacteristicReadRequest(BluetoothDevice device,
                                                int requestId,
                                                int offset,
                                                BluetoothGattCharacteristic characteristic) {

            if (characteristic.getUuid().equals(MOISTURE_CHAR_UUID)) {
                moistureCharacteristic.setValue(new byte[]{(byte) currentMoisture});
                gattServer.sendResponse(device, requestId,
                        BluetoothGatt.GATT_SUCCESS, offset,
                        moistureCharacteristic.getValue());
            } else if (characteristic.getUuid().equals(INTERVAL_CHAR_UUID)) {
                intervalCharacteristic.setValue(intToTwoBytes(reportingIntervalSec));
                gattServer.sendResponse(device, requestId,
                        BluetoothGatt.GATT_SUCCESS, offset,
                        intervalCharacteristic.getValue());
            } else if (characteristic.getUuid().equals(BATTERY_LEVEL_UUID)) {
                batteryLevelCharacteristic.setValue(new byte[]{(byte) batteryLevel});
                gattServer.sendResponse(device, requestId,
                        BluetoothGatt.GATT_SUCCESS, offset,
                        batteryLevelCharacteristic.getValue());
            } else {
                gattServer.sendResponse(device, requestId,
                        BluetoothGatt.GATT_FAILURE, offset, null);
            }
        }

        @Override
        public void onCharacteristicWriteRequest(BluetoothDevice device,
                                                 int requestId,
                                                 BluetoothGattCharacteristic characteristic,
                                                 boolean preparedWrite,
                                                 boolean responseNeeded,
                                                 int offset,
                                                 byte[] value) {

            if (characteristic.getUuid().equals(INTERVAL_CHAR_UUID)) {
                int newInterval = ((value[1] & 0xFF) << 8) | (value[0] & 0xFF);
                reportingIntervalSec = newInterval;
                Log.d(TAG, "New reporting interval: " + reportingIntervalSec + " sec");

                intervalCharacteristic.setValue(value);
            }

            if (responseNeeded) {
                gattServer.sendResponse(device, requestId,
                        BluetoothGatt.GATT_SUCCESS, offset, value);
            }
        }

        @Override
        public void onDescriptorWriteRequest(BluetoothDevice device,
                                             int requestId,
                                             BluetoothGattDescriptor descriptor,
                                             boolean preparedWrite,
                                             boolean responseNeeded,
                                             int offset,
                                             byte[] value) {

            if (descriptor.getCharacteristic().getUuid().equals(MOISTURE_CHAR_UUID)) {
                Log.d(TAG, "Moisture notifications enabled");
            } else if (descriptor.getCharacteristic().getUuid().equals(BATTERY_LEVEL_UUID)) {
                Log.d(TAG, "Battery notifications enabled");
            }

            if (responseNeeded) {
                gattServer.sendResponse(device, requestId,
                        BluetoothGatt.GATT_SUCCESS, offset, value);
            }
        }
    };
}

This callback handles all the important server side events for the smart plant monitor GATT Server, including connection changes, characteristic reads and writes, and descriptor writes for notifications.

When a device connects or disconnects, onConnectionStateChange is called and simply logs the new connection state so you can see when a client appears or disappears. The core logic lives in onCharacteristicReadRequest, which is invoked whenever a BLE client performs a read on one of the server’s characteristics.

The method checks which characteristic is being read by comparing its UUID. If it’s the moisture characteristic, it refreshes the characteristic value with the current moisture percentage, then responds with GATT_SUCCESS and the encoded value. If it’s the interval characteristic, it encodes the current reporting interval into two bytes using intToTwoBytes and sends that back. If it’s the battery level characteristic, it encodes the current battery percentage into a single byte and returns it. If the UUID does not match any known characteristic, the server responds with GATT_FAILURE, which tells the client that the request could not be fulfilled.

The onCharacteristicWriteRequest method handles writes from the client. In this implementation, only the reporting interval characteristic is writable. When a write targets this characteristic, the code decodes the two byte value sent by the client into an integer by reconstructing it from the low and high bytes. It updates the internal reportingIntervalSec field, logs the new interval, and stores the received bytes in the characteristic so that future reads return the updated value. If the client requested a response, the server sends back a success status and echoes the written value.

Finally, onDescriptorWriteRequest is called when a client writes to a descriptor, typically the Client Characteristic Configuration Descriptor that controls notifications. The code checks whether the descriptor belongs to the moisture or battery characteristic and logs that notifications have been enabled for the corresponding data source. If a response is needed, it sends back GATT_SUCCESS.

Altogether, this callback turns the server into a live plant monitor that can answer real time read requests, accept configuration updates, and honor notification subscriptions for moisture and battery level.

We now have a fully functioning GATT Server that supports read and write operations, and can also send notifications for moisture and battery when needed.

To simulate notifications, the server can periodically update values and call notifyCharacteristicChanged:

public void simulateSensorUpdate(BluetoothDevice device) {
    // Simulate moisture dropping slightly
    currentMoisture = Math.max(0, currentMoisture - 1);
    moistureCharacteristic.setValue(new byte[]{(byte) currentMoisture});
    gattServer.notifyCharacteristicChanged(device, moistureCharacteristic, false);
}

This method simulates a live update to the soil moisture sensor and demonstrates how a GATT Server sends notifications to a connected BLE client.

It decreases the current moisture reading by one percent, ensuring the value never falls below zero using Math.max. After adjusting the simulated value, the method stores the updated moisture value inside the moisture characteristic using setValue, which prepares the new data to be transmitted.

It then calls notifyCharacteristicChanged, which sends a BLE notification packet to the specified connected device, telling the client that the characteristic value has changed and delivering the new moisture reading immediately.

The final parameter false indicates that this is a notification rather than an indication, which means the server does not require an acknowledgment from the client. This method would typically be called on a timer or triggered by real sensor hardware, allowing the client application to receive continuous updates in real time without repeatedly polling the server.

Implementing the GATT Client in Java

On the Android client side, we connect to the plant monitor, discover services, then interact with the three characteristics.

First, we’ll discover the services and store references.

public class PlantMonitorClient {

    private BluetoothGatt bluetoothGatt;

    private final UUID PLANT_SERVICE_UUID =
            UUID.fromString("12345678-1234-5678-1234-56789abc0001");
    private final UUID MOISTURE_CHAR_UUID =
            UUID.fromString("12345678-1234-5678-1234-56789abc0002");
    private final UUID INTERVAL_CHAR_UUID =
            UUID.fromString("12345678-1234-5678-1234-56789abc0003");

    private final UUID BATTERY_SERVICE_UUID =
            UUID.fromString("0000180F-0000-1000-8000-00805F9B34FB");
    private final UUID BATTERY_LEVEL_UUID =
            UUID.fromString("00002A19-0000-1000-8000-00805F9B34FB");

    public void connect(Context context, BluetoothDevice device) {
        bluetoothGatt = device.connectGatt(context, false, gattCallback);
    }

    private final BluetoothGattCallback gattCallback = new BluetoothGattCallback() {

        @Override
        public void onConnectionStateChange(BluetoothGatt gatt,
                                            int status,
                                            int newState) {
            if (newState == BluetoothProfile.STATE_CONNECTED) {
                Log.d(TAG, "Connected. Discovering services.");
                gatt.discoverServices();
            }
        }

        @Override
        public void onServicesDiscovered(BluetoothGatt gatt, int status) {
            Log.d(TAG, "Services discovered.");

            // Read current moisture and battery once
            readMoisture(gatt);
            readBatteryLevel(gatt);

            // Enable notifications
            enableMoistureNotifications(gatt);
        }

This class represents the Bluetooth Low Energy client side of the smart plant monitor example. It holds a BluetoothGatt reference that represents the active connection to the BLE server device.

Several UUID constants are defined so the client knows how to find the Plant Monitor Service and its characteristics for moisture and reporting interval, as well as the standard Battery Service and Battery Level characteristic.

The connect method starts the BLE connection by calling device.connectGatt, passing in the Android Context, a flag indicating no automatic reconnection, and a BluetoothGattCallback instance that will receive connection and data events.

Inside the callback, onConnectionStateChange is called whenever the connection state changes. When the new state indicates that the device is connected, the client logs this and calls discoverServices to request the full list of GATT services from the server.

Once the service discovery procedure completes, onServicesDiscovered is triggered. In this method, the client logs that services have been discovered, then immediately reads the current values of the moisture and battery level using helper methods readMoisture and readBatteryLevel, and finally enables notifications for moisture updates using enableMoistureNotifications.

Together, these steps mean that as soon as the client connects to a plant monitor device, it learns what services are available, fetches one time snapshots of important values, and subscribes to real time updates for the most important sensor – which in this case is soil moisture.

Now, we’ll define methods for reading moisture and battery.

        private void readMoisture(BluetoothGatt gatt) {
            BluetoothGattService service = gatt.getService(PLANT_SERVICE_UUID);
            if (service != null) {
                BluetoothGattCharacteristic ch =
                        service.getCharacteristic(MOISTURE_CHAR_UUID);
                if (ch != null) {
                    gatt.readCharacteristic(ch);
                }
            }
        }

        private void readBatteryLevel(BluetoothGatt gatt) {
            BluetoothGattService service = gatt.getService(BATTERY_SERVICE_UUID);
            if (service != null) {
                BluetoothGattCharacteristic ch =
                        service.getCharacteristic(BATTERY_LEVEL_UUID);
                if (ch != null) {
                    gatt.readCharacteristic(ch);
                }
            }
        }

        @Override
        public void onCharacteristicRead(BluetoothGatt gatt,
                                         BluetoothGattCharacteristic characteristic,
                                         int status) {
            if (status == BluetoothGatt.GATT_SUCCESS) {
                if (MOISTURE_CHAR_UUID.equals(characteristic.getUuid())) {
                    int moisture = characteristic.getIntValue(
                            BluetoothGattCharacteristic.FORMAT_UINT8, 0);
                    Log.d(TAG, "Soil moisture: " + moisture + " percent");
                } else if (BATTERY_LEVEL_UUID.equals(characteristic.getUuid())) {
                    int battery = characteristic.getIntValue(
                            BluetoothGattCharacteristic.FORMAT_UINT8, 0);
                    Log.d(TAG, "Battery level: " + battery + " percent");
                } else if (INTERVAL_CHAR_UUID.equals(characteristic.getUuid())) {
                    int interval = characteristic.getIntValue(
                            BluetoothGattCharacteristic.FORMAT_UINT16, 0);
                    Log.d(TAG, "Reporting interval: " + interval + " sec");
                }
            }
        }

These methods handle reading values from the smart plant monitor GATT Server. The readMoisture method retrieves the Plant Monitor Service using its UUID, then looks up the soil moisture characteristic inside it. If the characteristic is found, it sends a read request using gatt.readCharacteristic, which asks the server to return the current moisture value.

The readBatteryLevel method behaves the same way but targets the standard Battery Service and Battery Level characteristic. When the server responds to either read request, the callback onCharacteristicRead is triggered. The method first checks whether the read was successful by confirming that the status equals GATT_SUCCESS. It then determines which characteristic was read by comparing UUIDs.

If the response is for the moisture characteristic, it decodes the value from a single byte into an integer percentage and logs it. If it is the battery characteristic, it similarly extracts the single byte battery percentage and logs that value. If the interval characteristic was read, it decodes two bytes into a 16 bit integer and logs the reporting interval in seconds.

This read flow provides the client with a snapshot of the current sensor and configuration values immediately after connecting, before monitoring changes through notifications.

Next, we’ll enable notifications for moisture so that the app receives updates when it changes.

        private void enableMoistureNotifications(BluetoothGatt gatt) {
            BluetoothGattService service = gatt.getService(PLANT_SERVICE_UUID);
            if (service != null) {
                BluetoothGattCharacteristic ch =
                        service.getCharacteristic(MOISTURE_CHAR_UUID);
                if (ch != null) {
                    gatt.setCharacteristicNotification(ch, true);

                    BluetoothGattDescriptor descriptor =
                            ch.getDescriptor(UUID.fromString(
                                    "00002902-0000-1000-8000-00805F9B34FB"));

                    if (descriptor != null) {
                        descriptor.setValue(
                                BluetoothGattDescriptor.ENABLE_NOTIFICATION_VALUE);
                        gatt.writeDescriptor(descriptor);
                    }
                }
            }
        }

        @Override
        public void onCharacteristicChanged(BluetoothGatt gatt,
                                            BluetoothGattCharacteristic characteristic) {
            if (MOISTURE_CHAR_UUID.equals(characteristic.getUuid())) {
                int moisture = characteristic.getIntValue(
                        BluetoothGattCharacteristic.FORMAT_UINT8, 0);
                Log.d(TAG,
                        "Soil moisture update: " + moisture + " percent");
            }
        }
    };

This code enables live moisture updates through notifications and handles them when they arrive.

The enableMoistureNotifications method first retrieves the Plant Monitor Service, then obtains the moisture characteristic using its UUID. If the characteristic is available, it calls setCharacteristicNotification with true, which tells the Android BLE stack to start listening for notifications on that characteristic.

But enabling notification support locally is not enough because the GATT specification requires that the client also write to the associated descriptor known as the Client Characteristic Configuration Descriptor, or CCCD, identified by the standard UUID 0x2902. The method retrieves this descriptor, sets its value to ENABLE_NOTIFICATION_VALUE, and writes it using writeDescriptor, which sends a request over the air to the server to enable notifications on the device side. Once this configuration is complete, updates are delivered whenever the characteristic value changes.

The onCharacteristicChanged callback is triggered automatically each time the server pushes a new moisture reading. The method checks that the changed characteristic is the moisture characteristic by comparing UUIDs, extracts the soil moisture percentage from a single byte using getIntValue, and logs the updated value. This allows the client app to receive real time sensor readings without constantly polling the server, which saves energy and improves responsiveness for applications such as plant monitoring dashboards or notification alerts.

Finally, the client can write a new reporting interval, for example changing from 60 seconds to 30 seconds.

    public void writeReportingInterval(int newIntervalSec) {
        if (bluetoothGatt == null) return;

        BluetoothGattService service =
                bluetoothGatt.getService(PLANT_SERVICE_UUID);
        if (service != null) {
            BluetoothGattCharacteristic ch =
                    service.getCharacteristic(INTERVAL_CHAR_UUID);
            if (ch != null) {
                byte[] data = new byte[2];
                data[0] = (byte) (newIntervalSec & 0xFF);
                data[1] = (byte) ((newIntervalSec >> 8) & 0xFF);
                ch.setValue(data);
                bluetoothGatt.writeCharacteristic(ch);
            }
        }
    }
}

This method allows the BLE client to update the reporting interval setting on the smart plant monitor by writing a new value to the interval characteristic on the GATT Server.

It first checks whether the bluetoothGatt object is valid, since no write can occur before a connection is established. It retrieves the Plant Monitor Service using its UUID and then looks up the reporting interval characteristic inside that service.

If the characteristic exists, the method converts the new interval value from an integer into a two byte array, placing the least significant byte first and the most significant byte second, which is the common little endian format used in Bluetooth characteristics. It sets this byte array as the characteristic’s new value and then calls writeCharacteristic, which sends a write request over the air to the server. When the server processes the command in its corresponding write request handler, it will update its internal interval value and acknowledge the change.

This method demonstrates how configuration settings are written from a BLE client to a BLE device, enabling interactive control of behavior instead of only reading sensor values.

With this design, our smart plant monitor system is complete. The GATT Server exposes well-defined services and characteristics. The Android client connects, discovers, reads, writes, and subscribes to notifications. The concept is always the same: services group features. Characteristics hold data and behavior. Clients manipulate characteristics. Servers store and protect them.

Once you can design and code such a profile end to end, you are effectively using GATT the way real products do. The same pattern scales to complex devices like glucose monitors, smart locks, smart glasses, and industrial sensors.

Conclusion

GATT is the foundation that makes Bluetooth Low Energy communication understandable and reliable. It transforms raw radio signals into meaningful structured information through the use of services and characteristics. Once you understand that every BLE device exposes a database of values that a client can read, write, or subscribe to, the entire system becomes logical instead of mysterious.

Whether you are reading heart rate from a smartwatch, checking the battery level of wireless earbuds, controlling a smart bulb, or configuring an industrial sensor, the interaction always happens through GATT characteristics inside services.

By examining both sides of the communication, the GATT Server and the GATT Client, and by walking through real Java code examples for reading, writing, and receiving notifications, you now have the practical knowledge needed to build and debug real BLE applications. You saw how to define custom services and characteristics, how to interpret data formats, how to enable notifications for dynamic sensor updates, and how to organize a complete device profile using a realistic example in the plant monitor project.

Everything in Bluetooth Low Energy development begins with understanding GATT at this level. Once you are comfortable designing and interacting with services and characteristics, you can confidently move into more advanced topics such as secure pairing and bonding, throughput tuning using MTU and connection interval, power optimization, OTA firmware updates, and tools like nRF Connect and HCI log analysis.

The best way to strengthen what you learned is to build something hands on. Even a simple read and write test project will help the concepts become intuitive.

Mastering GATT is the first major step toward professional Bluetooth development. Every complex system built with BLE, from consumer wearables to medical devices and smart home automation, sits on top of this technology. Now that you understand the structure and communication model, you are ready to explore more sophisticated capabilities and create your own applications with confidence.

An embedded system typically goes through a simple but powerful cycle:

1. Sense – Gather information from the environment using sensors.

2. Process – Use software logic to decide what to do with the data.

3. Act – Trigger a response, like turning on a motor or lighting an LED.

Each project begins with a use case – a specific goal like brewing coffee or controlling a car’s fuel injection. From that, engineers define system requirements, which are split into:

• Hardware (for example, microcontrollers, sensors, actuators)

• Software (what we call embedded software)

This handbook focuses on the software side of embedded systems: how we write code to make embedded systems intelligent. Embedded software runs on resource-constrained devices like microcontrollers, which may have just a few kilobytes of memory. The software might need to be highly efficient, reliable, and often capable of working in real-time.

But embedded software isn't just about writing code – it’s also about understanding:

• How hardware works

• How to manage memory and power

• How to handle timing and communication

• How to build robust, fail-safe systems

While embedded systems development isn’t typically research-focused in most industry roles, it demands a broad skill set, from low-level programming to system-level design. What makes this field especially exciting is how it brings together diverse domains like machine learning, digital signal processing (DSP), and control systems, all of which can be applied directly in real-world devices.

In this article, I’ll give you:

• A high-level overview of what embedded software involves

• Key concepts every developer should know

• A tour of commonly used tools and frameworks

• Resources to help you learn and understand basics.

Whether you're just curious or planning a career in embedded systems, this guide is your launchpad.

Table of Contents

• HW Layer: Microcontroller

• Firmware Design and Tools

• Tools and Concepts for Embedded Development

• Bare Metal, RTOS, and Embedded Operating Systems

• Designing Drivers for Embedded Systems

• Security in Embedded Systems

• Debugging and Forensics in Embedded Systems

• Automation and Testing in Embedded Systems

• Where to Go from Here

This article offers a broad overview of embedded firmware development, but it doesn’t cover every aspect, particularly advanced software architecture frameworks or comprehensive lists of open source software and tools. Where appropriate, I have included external resources that were valuable in expanding my own understanding.

Prerequisites

You don’t need to be an expert to follow this guide, but some prior knowledge will help you get the most out of it:

• Basic C or C++ programming**:** Familiarity with functions, pointers, and memory concepts is helpful.

• Computer architecture fundamentals**:** Understanding what a CPU does, how memory works, and basic instruction execution will make embedded concepts clearer.

• Electronics basics (optional): Knowing how sensors, resistors, or microcontrollers interact at a circuit level is useful but not mandatory.

• Comfort with the command line**:** Especially for working with build systems, compilers, and flashing tools.

This guide is ideal for students, engineers, or hobbyists looking to deepen their understanding of how software interacts with hardware in real-world systems.

With that, let’s start from the ground up, hardware. Throughout this guide, most examples will reference ARM Cortex-M microcontrollers, as they are among the most commonly used in the embedded world.

HW Layer: Microcontroller

One of the most important knowledge blocks in embedded firmware development is understanding how a microcontroller (MCU) works and how it connects to sensors, actuators, and other microcontrollers.

If you’re familiar with basic computer architecture (like instruction sets and memory organization), that knowledge translates well to embedded systems. In fact, Computer System Organization, often taught in computer science and electrical engineering programs, is a great foundation for understanding microcontrollers.

What is a Microcontroller?

A microcontroller is a compact computing unit that includes:

• A CPU (Central Processing Unit or Microprocessor)

• Memory (Flash and RAM)

• Peripherals (for I/O, timers, communication, and so on)

In essence, it's a tiny computer-on-a-chip, optimized for specific control tasks like reading sensors or driving motors.

By contrast, a microprocessor is just the CPU. It requires external memory and peripherals to function. Microcontrollers are self-contained and better suited for embedded applications.

For example, this reference manual for the STM32F4 series (from STMicroelectronics) provides detailed documentation on not just the CPU but each peripheral’s functionality and the register map.

Instruction Set Architecture (ISA)

A microprocessor executes a series of instructions defined by its Instruction Set Architecture (ISA). ISA as defined by ARM is a part of the abstract model of a computer that defines how the CPU is controlled by the software. The ISA acts as an interface between the hardware and the software, specifying both what the processor is capable of doing as well as how it gets done.

For example:

• ARMv7 – used in ARM Cortex-M3.

• ARMv7E – used in Cortex-M4 and M7.

Many vendors (for example, STMicroelectronics, NXP, TI) manufacture MCUs that support ARM ISAs but include their own peripheral sets. Understanding the ISA is essential for low-level coding and interpreting assembly instructions.

This ARMv7-M architecture reference manual provides more details on v7 Architecture.

Memory in Microcontrollers

Most microcontrollers typically feature two types of memory:

• Flash – Stores your code and read-only data.

• RAM – Used during program execution to hold:

  • The heap (for dynamic memory)

  • The stack

  • The .data and .bss sections (initialized/uninitialized global/static variables)

Later sections have resources that go deeper into memory mapping and how these regions interact during runtime.

Clock and Power Management

Microcontrollers are digital logic devices built from:

• Combinatorial logic – Logic gates that evaluate outputs instantly

• Sequential logic – Relies on clocks to move through states

The clock tree distributes timing signals across the CPU and peripherals. MCUs often support multiple clock sources (internal RC, external crystal, PLL), and use prescalers to drive components at different frequencies.

For power-sensitive applications, MCUs offer multiple low-power modes:

• Sleep – CPU off, timers and peripherals are mostly active, memory is retained

• Deep Sleep – CPU off, most clocks off, memory is retained, wake-up is slower than sleep, power consumption is lower than Sleep

• Standby – CPU off, few interrupts are active, everything else is powered down, memory is not retained. Lowest power mode.

These modes reduce power consumption by turning off clocks and disabling unused peripherals. Designing the system to switch in and out of low-power states effectively is a core skill in embedded software development.

This article talks about Clock Trees and Oscillators for the ARM Cortex microcontrollers.

Interrupts

Interrupts let MCUs react to asynchronous events, like button presses or sensor signals.

An interrupt temporarily pauses normal code execution to run a dedicated handler. After it’s serviced, the CPU resumes its previous task. They are vital for:

• Fast event response

• Reduced polling

• Efficient power use (for example, waking from sleep)

Timers

Timers are built-in peripherals used to track time or generate events.

Common uses are:

• Implementing software delays

• Creating precise software timers

• Waking up from low-power modes

Mastering timers helps with real-time behavior and precise event scheduling.

Communication Protocols

Microcontrollers often need to talk to other devices via built-in communication peripherals:

• UART (Universal Asynchronous Receiver/Transmitter): Serial communication between two devices, great for logs and debugging.

• I²C (Inter-Integrated Circuit): Two wire protocol for talking to sensors and EEPROMs.

• SPI (Serial Peripheral Interface): High Speed, full-duplex protocol for devices like Flash or displays.

• USB (Universal Serial Bus): Complex but widely used for PCs, data acquisition and HID devices.

Here’s a figure showing multiple peripherals connected to a MCU:

DMA or Direct Memory Access is an important peripheral which can be used to transfer data to/from memory without CPU involvement. It improves performance and allows the CPU to perform other tasks or enter low power mode to reduce power consumption.

This article provides a good overview of the communication protocols I2C, UART and SPI.

We’ve now covered the essential building blocks of microcontroller hardware – from memory and clocks to interrupts and communication buses.

Next, we’ll explore the software principles and tools that bring these microcontrollers to life, including compilers, debuggers, and embedded development frameworks.

Firmware Design and Tools

Designing Embedded Software

Even though embedded systems operate under unique hardware constraints, software design principles are still crucial. Applying them thoughtfully becomes even more important when memory, CPU cycles, and responsiveness are limited.

Most Embedded firmware projects begin with a structured design approach:

1. Understand the problem statement

2. List assumptions

3. Define use cases

4. Define system and software requirements

5. Create high-level architecture

6. Drill down to detailed design and implementation

If you’re new to software design, check out my article on design principles.

Here’s a figure showing the five blocks of software design:

Using Design Patterns

Once you're designing individual components, design patterns help you write scalable and maintainable code. Here are some common patterns in embedded systems:

• Publisher-Subscriber (Observer) – Useful for decoupling event producers and consumers (for example, sensor data being broadcast to multiple modules).

• Singleton – Ensures only one instance of a module or resource manager exists (for example, for drivers or HAL layers).

• Adapter – Translates between incompatible interfaces (for example, wrapping platform-specific code into a portable application layer).

• State Machine – Represents system behavior as transitions between states (for example, Bluetooth states: IDLE → SCANNING → CONNECTING → CONNECTED → DISCONNECTED).

Design patterns often need to be adapted for memory and timing constraints, but the core concepts remain highly relevant.

There are lot of great resources on design patterns – here are a few that helped me:

1. Book: Head-first Design patterns - A great book to get understand the concept of design patterns

2. Book: Design Patterns: Elements of Reusable Object-Oriented Software

3. Course: Object-Oriented Programming and Design Patterns in C#

4. Article on HSM: Hierarchical State Machine Overview (Barr Group)

Programming Languages for Embedded Systems

While any language can theoretically be used if it compiles to machine code, in practice, three dominate the embedded world:

• C – The industry standard. Provides deterministic behavior and low-level access, making it ideal for memory and timing-sensitive code.

• C++ – Adds object-oriented features while maintaining control. Once considered risky in embedded due to synthesized code and overhead, it’s now widely adopted where systems benefit from abstraction and modularity.

• Rust – A memory-safe alternative gaining traction in safety-critical and open-source embedded development.

Languages like Python (via MicroPython or CircuitPython) are used in educational or prototyping contexts but are not suitable for production due to performance and memory overhead.

Some resources on programming languages that might be helpful to understand concepts:

1. The Embedded Rust Book

2. C Programming Language by K&R

3. Inside the C++ Object model – There are a lot of books and lectures on C++, but for embedded, understanding the object model benefits a lot.

Data Structures Matter

Embedded systems require careful data handling due to strict memory and timing constraints. Mastering core data structures is essential:

• Arrays – fixed-size data.

• Linked Lists – Common in software timers, queues.

• Stacks and Queues – Task scheduling, event management and data storage.

• Bitfields/Flags – Memory efficient state representation.

• Binary Trees – Used in routing tables or decision logic.

You'll often build event queues, circular buffers, or timer lists, all of which rely on these foundational structures.

There are a lot of resources for understanding data structures, but I have found this one to be helpful for learning and practicing: GeeksForGeeks DSA Tutorial. And here’s a full course on DSA if you want to dive deeper.

Bit Manipulation: A Core Embedded Skill

Unlike general-purpose software, embedded systems often require low-level access to registers and require precise bit control:

• Setting and clearing individual bits

• Using bitwise operators like AND (&), OR (|), XOR (^)

• Bit masking and shifting (<<, >>)

Mastering bit hacks is essential for writing hardware drivers or manipulating control registers.

This resource provides a good number of examples for bit manipulation: Stanford Bit Hacks.

Tools and Concepts for Embedded Development

Cross Compilation

Embedded code is compiled on a host (like your PC) for a target architecture using cross-compilers.

To do this, you need:

• A compiler (for example, arm-none-eabi-gcc for ARM Cortex-M) that compiles high level language code into Assembly language instructions.

• A linker to layout and combine object files.

• A Makefile or build system to organize and automate compilation, linking and binary creation.

Here’s an example to compile a main.c to create a main.elf that can be flashed on the device:

arm-none-eabi-gcc main.c -o main.elf

A Makefile is a script used by the make build automation tool to compile and link programs to create a binary. It defines how to build your program from source files, manages compilation order based on dependencies and defines commands to complete the build.

For example, lets write a Makefile for building a project for an ARM Cortex-M4 target that has three source files: a main.c, utils.c, and sensor.c

CC = arm-none-eabi-gcc
CFLAGS = -c -mcpu=cortex-m4 -mthumb -Wall -O2
LDFLAGS = -mcpu=cortex-m4 -mthumb
TARGET = main.elf
OBJS = main.o utils.o sensor.o
SRC = main.c utils.c sensor.c

$(TARGET): $(OBJS)
    $(CC) $(OBJS) -o $(TARGET)

main.o: main.c
    $(CC) $(CFLAGS) main.c

utils.o: utils.c
    $(CC) $(CFLAGS) utils.c

sensor.o: sensor.c
    $(CC) $(CFLAGS) sensor.c

clean:
    rm -f *.o *.elf

In the above makefile, here’s a description of the flags:

• -mcpu=cortex-m4: Targets the ARM Cortex-M4 processor.

• -mthumb: Enables Thumb instruction set, which is used by ARM Cortex-M series.

• -Wall: Enables all common warnings.

• -O2: Optimization level 2 for balance between performance and code size.

Makefiles can seem intimidating, but they’re just scripts that define how to build your program from source. Once you understand the basics, they’re a huge productivity booster.

A linker script tells the linker (ld) how to organize the program in memory where to place code, data, stack, heap, and so on. It's crucial for embedded systems because you're working with limited memory and specific memory-mapped hardware.

Here’s an example of a simple linker script for a STM32F4 microcontroller:

/* STM32F4 Cortex‑M4 Simple Linker Script */

ENTRY(Reset_Handler)

/* Define memory regions based on STM32F4 datasheet */
MEMORY
{
  FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 1024K
  RAM   (rwx): ORIGIN = 0x20000000, LENGTH = 128K
}

/* Section layout */
SECTIONS
{
  /* Interrupt vectors and code go into Flash */
  .isr_vector :
  {
    KEEP(*(.isr_vector))    /* Keep vector table (reset, etc.) */
  } > FLASH

  .text :
  {
    *(.text*)               /* All code */
    *(.rodata*)             /* Read-only data */
    . = ALIGN(4)
    _etext = .             /* End of code (used for data init) */
  } > FLASH

  /* Initialized data: load from Flash, run in RAM */
  .data : AT(_etext)
  {
    _sdata = .            /* Start of .data in RAM */
    *(.data*)
    . = ALIGN(4)
    _edata = .            /* End of .data */
  } > RAM

  /* Uninitialized data (zero-filled) */
  .bss :
  {
    _sbss = .
    *(.bss*)
    *(COMMON)
    . = ALIGN(4)
    _ebss = .
  } > RAM

  /* Define stack end (top of RAM) */
  _estack = ORIGIN(RAM) + LENGTH(RAM);
}

Descriptions of the above file:

• MEMORY: Defines your microcontroller’s memory layout – 1 MB Flash and 128 KB SRAM.

• ENTRY(Reset_Handler): Sets the reset handler as the program entry point.

• .isr_vector and **.**text: Code sections placed in Flash. .isr_vector must use KEEP() so it's not removed during linking.

• .data : AT(_etext): Loads initialized variables from Flash but places them in RAM.

• **.**bss: Zero-initialized data, allocated in RAM

• _estack: Defines the initial stack pointer using the end of RAM.

Here are some sources to understand Makefiles, cross-compilation, and Linkers. And just note that using Makefile in a project is the best way to learn and master Makefiles:

1. Makefiles:

   • GNU Make Manual

   • Makefile Tutorial

   • In Pyjama Makefile Article

2. Linker Scripts:

   • Interrupt Blog on Linker Scripts

   • Intro to Linker Files – Medium

Flashing the Binary

Once you’ve compiled your code into a binary file, the next step is to flash it into the target microcontroller’s non-volatile memory via SWD (Serial Wire Debug) or JTAG. Flashing tools like OpenOCD, ST-Link, J-Link, or vendor-specific utilities manage this process.

What Is Flashing?

Flashing is the process of writing a compiled firmware image (typically a .bin or .hex file) into the microcontroller’s Flash memory. This enables the embedded system to retain and run your code even after power is removed.

The flashing tool communicates with the microcontroller over SWD or JTAG to:

• Halt the MCU (if needed)

• Access the internal flash controller

• Erase the relevant flash sectors

• Write the binary data to specific memory addresses

• Verify that the data was written correctly

OpenOCD (Open On-Chip Debugger) is a powerful, open-source utility that facilitates debugging and flashing of ARM-based microcontrollers. It supports a wide variety of hardware interfaces and microcontroller families, including STM32.

OpenOCD provides:

• Flashing capabilities for .elf, .bin, and .hex files

• Debugging via GDB (GNU’s open source debugger) integration

• Support for multiple debug probes (J-Link, ST-Link, CMSIS-DAP)

• Scripting via configuration files for board-specific and target-specific setups

A simple command to flash a binary using OpenOCD might look like this:

bashCopyEditopenocd -f interface/stlink.cfg -f target/stm32f4x.cfg -c "program main.elf verify reset exit"

This tells OpenOCD to:

• Use the ST-Link interface

• Load the STM32F4 target configuration

• Program main.elf into flash

• Verify it was written correctly

• Reset the MCU

• Exit the session

For a detailed walkthrough, check out: OpenOCD Deep Dive – Kickstart Embedded

Bare Metal, RTOS, and Embedded Operating Systems

When writing embedded software, you can approach the problem in three main ways, each with its own trade-offs:

1. Bare-Metal Programming

2. Real-Time Operating Systems (RTOS) (like FreeRTOS, Zephyr)

3. Embedded Operating Systems (like Embedded Linux)

The best choice depends on your use case, application’s complexity, hardware constraints, and real-time needs.

Most Modern 32-bit microcontrollers (for example, STM32, NXP, Renesas) come with vendor-provided development tools that include:

• HAL (Hardware Abstraction Layer) libraries

• Startup code and linker scripts

• Peripheral drivers

• Sometimes even middleware like USB, BLE, or file system stacks

These tools (like STM32Cube Config Tools) simplify setup and peripheral configuration, helping you get started quickly, without needing to write low-level code manually.

Benefits of HALs:

• Rapid prototyping and development

• Clean, reusable APIs for peripherals

• Great for onboarding and small teams

Drawbacks:

• Code bloat – HALs support many edge cases and configurations, which can inflate your binary size

• Extra latency – HAL often inserts unnecessary layers that reduce performance.

For performance-critical systems, developers often replace HAL drivers with custom, low-level implementations.

Bare-Metal Programming

Bare-metal programming is the most direct and lightweight approach. There’s no OS, and your code runs directly on the hardware with full control.

Typical setup includes:

• Include the correct header files, especially MCU and peripheral-specific headers provided by the vendor’s HAL (Hardware Abstraction Layer).

• Implement a main() function with an infinite loop (while(1))

• Perform all hardware initialization before entering the loop

• Use Interrupts to handle asynchronous events.

• Continuously check and control inputs/outputs inside the loop

This assumes your toolchain provides startup code and memory setup from the vendor.

#include "MCU_Header.h"

int main(void) {
    /* Initialize the MCU and the peripherals */
    init_clock();
    init_peripherals();

    /* runs in a loop forever */
    while (1) {
        // Task 1 : Read sensor data
        read_sensor(); 
        // Task 2 : Update the actuator based on the sensor data
        update_actuator(); 
    }
}

How does it run?

When the device powers on or resets, the startup code provided by the vendor is executed first. This code:

• Initializes the reset vector

• Copies initialized data from Flash to RAM

• Zeros out the .bss section (for uninitialized global/static variables)

• Calls your main() function

After calling main(), the system enters an infinite loop where your logic runs. The only other context switch occurs when an interrupt is triggered, briefly diverting control to an Interrupt Service Routine (ISR), after which it returns to the main loop.

When to use it:

• Simpler applications (for example, blinking LEDs, reading sensors)

• Ultra-low-power or ultra-low-latency needs

• When every byte of Flash and RAM matters

Pros:

• Minimal memory usage

• Maximum control

• Great for learning

Cons:

• No built-in task management or scheduling

• Can become hard to maintain for complex systems

This resource provides good details and example on Bare Metal Programming. For more details, this book is great as well: ARM Baremetal Ebook.

Real-Time Operating Systems (RTOS)

A Real-Time Operating System (like FreeRTOS, Zephyr) adds lightweight multitasking capabilities to your embedded application. It allows you to split your software into independent tasks that run concurrently and communicate through queues, semaphores, or message passing.

RTOS kernels often support different scheduling strategies like:

• Rate Monotonic Scheduling (RMS) – Tasks with shorter periods get higher priority

• Earliest Deadline First (EDF) – Tasks are prioritized based on impending deadlines

Example use cases:

• A drone where sensor data, motor control, and telemetry need to run in parallel

• A medical device where timing is critical for safety

• Rockets

Typical RTOS features:

• Task scheduling

• Timers

• Inter-task communication

• Interrupt handling integration

• Power management

Pros:

• Modular code structure with tasks

• Easier to scale as complexity grows

• Deterministic execution (when configured correctly)

Cons:

• Slightly higher memory footprint than bare-metal

• Learning curve for scheduling and priority tuning

RTOS Scheduling techniques are interesting – this part of the docs talks about Zephyr scheduling.

Embedded Operating Systems

Sometimes an embedded system is powerful enough to run a full-fledged OS like Embedded Linux, Android Things, or Windows IoT Core. This is common on devices with a display, networking stack, or file system.

It’s best used when the system requires multitasking, user interfaces, file systems, or network stacks, and when there’s plenty of processing power (for example, ARM Cortex-A).

Think of:

• Smart home hubs

• Automotive infotainment

• Industrial gateways

This table provides a high level methodology for choosing the right type of OS based on your application:

To understand OS fundamentals, this is a great book: Operating System Concepts and this is a great course: UC Berkeley: CS162.

So far, we’ve looked at how embedded applications are structured, whether using bare-metal loops, RTOS multitasking, or full operating systems. But regardless of which execution model you choose, your software ultimately needs to interact with the hardware.

This is where driver development comes in. Drivers form the crucial link between your code and the peripherals it controls, whether it's reading temperature, blinking an LED, or transmitting data over SPI. Let’s take a closer look at how to design robust, portable drivers for embedded systems.

Designing Drivers for Embedded Systems

When working with embedded software, one of the most practical and common tasks you’ll encounter is driver development.

A driver is a piece of software that enables the microcontroller (MCU) to interface with a hardware peripheral. This could be a temperature sensor, a motor controller, a display, or even a wireless module.

Drivers act as a bridge between your hardware and the application logic. They abstract away the raw register-level programming so that higher-level code can use clear function calls like read_temperature() or start_motor().

What Goes Into a Driver?

A typical embedded driver will include:

• Configuration – Setting up the peripheral with initial parameters (for example, baud rate for UART)

• Initialization – Preparing the peripheral for use, including enabling clocks and interrupts

• Calibration (if needed) – Adjusting the peripheral based on specific environment or use case

• Register Access – Reading from and writing to hardware registers (if applicable)

• Power Management – Enabling/disabling the peripheral to save power or putting the peripheral into a low power mode

• Interrupt Management – Handling asynchronous events triggered by the peripheral

Here’s a simplified view of a sensor driver API:

void sensor_init(void);
void sensor_calibrate(void);
float sensor_read_temperature(void);
void sensor_sleep(void);
void sensor_write(uint8_t reg, uint8_t value); // Assumption : 8 bit register address and 8 bit data value

The actual implementation might involve:

• Register definitions from the peripheral’s datasheet

• Bit manipulations for control and status registers

• Interrupt Service Routines (ISRs)

• Timing and delay management

Platform Abstraction: Why It Matters

One of the most important principles in driver design is decoupling the application from the platform. This makes your code easier to:

• Port to different MCUs

• Adapt for similar hardware (for example, different sensor models)

• Test across simulated or real environments

Platform-Agnostic Design Example (in C++) :

Let’s say you're writing a driver for a temperature sensor:

// Abstracts the HW platform on which the sensor driver is being written
class TemperatureSensorPlatform {
public:
    void i2cInit(void);
    void i2cWrite(uint8_t reg, uint8_t value);
    uint8_t i2cRead(uint8_t reg);
};

// Creates a generic Temperature sensor driver interface
class TemperatureSensor {
public:
    virtual void init() = 0;
    virtual float read() = 0;
    virtual void sleep() = 0;
};

You can implement this interface differently for a specific type of temperature sensor and also add the platform support for the HW platform you are writing the driver on for example STM32.

class TempSensorTMP117 : public TemperatureSensor {
public:

    TempSensorTMP117(TemperatureSensorPlatform platform) : 
    _platform(platform)
    TemperatureSensor()
    {}

    void init() override {
        // TMP117-specific register configuration
    }

    float read() override {
        // Read ADC value and convert
        return 25.4f;
    }

    void sleep() override {
        // Put sensor in low-power mode
    }
private:
    TemperatureSensorPlatform _platform; // Implements the I2C driver for STM32
};

Your application code now depends on the TemperatureSensor interface and Temperature Sensor Platform passed in the constructor making it portable and testable across temperature sensors and HW platforms.

One of my previous articles provides details on how to interface a sensor and how to design a driver for it.

Designing robust and modular drivers helps your firmware interact seamlessly with hardware, but in today’s connected world, that’s only part of the challenge. As embedded devices increasingly communicate with other systems, security becomes just as critical as functionality.

Now that we’ve covered how to interface with hardware, let’s explore how to protect those systems from unauthorized access, tampering, and data breaches.

Security in Embedded Systems

Security is often overlooked in embedded development but it shouldn’t be. Embedded systems are increasingly connected to networks, cloud services, or other devices, which makes them vulnerable to attacks like unauthorized access, firmware tampering, or data leaks.

Even simple devices like smart plugs or fitness trackers can be exploited if their firmware is insecure.

Key Security Practices

• Secure Boot: Ensure the firmware is cryptographically signed and verified before execution. This prevents unauthorized firmware from running.

• Firmware Update Integrity: Use encrypted or signed updates, especially for Over-the-Air (OTA) upgrades. Unprotected updates can be a major attack vector.

• Lock Debug Interfaces: After flashing the final firmware, disable or lock access to JTAG, SWD, or UART debug ports to prevent reverse engineering.

• Minimal Exposure: Disable unused peripherals (for example, Bluetooth, USB, network interfaces) and avoid exposing debug info (like UART prints) in production.

• Watchdog Timers: While not security features per se, watchdogs help ensure system recovery in the event of unexpected software behavior – which could result from attacks or bugs.

Security should be layered, as no single mechanism is sufficient on its own. Build security into every stage of the development process, from boot to communication to update handling.

Whether you're designing a consumer product or an industrial controller, proactive security practices are essential for protecting user data, system reliability, and device reputation.

This resource provides a good understanding of Embedded Systems Security: BlackBerry QNX: Embedded System Security Guide

Debugging and Forensics in Embedded Systems

Debugging embedded systems is one of the most challenging and fascinating aspects of development. Unlike in desktop or web applications, bugs in embedded systems often manifest as unexpected hardware behavior rather than error messages.

For example, suppose your code is supposed to blink an LED once per second:

• If the LED stays on, your delay code might be broken.

• If it blinks erratically, you might have a timing bug.

• If it doesn’t blink at all, you might never be reaching that part of your code or the hardware might not be configured correctly.

Why Debugging is Critical

Embedded systems directly control real-world hardware, often in critical or safety-sensitive environments. A small bug can lead to large consequences.

Historical Note: During the Apollo 11 moon landing, the onboard computer started throwing alarms due to a task overflow. The system restarted and was able to recover itself and allowing the mission to continue safely.

Debugging and post-mortem analysis (forensics) are essential skills for embedded developers.

Common Debugging Tools and Techniques

1. Print Statements (UART Logging)

The simplest and most common method. They send debug messages over a serial connection (UART).

You can use printf() or similar to track variable values, function entries/exits, and system state

• Pros: Easy to implement

• Cons: Can affect timing – not usable if UART is unavailable or disabled

2. Trace Variables

In systems without output peripherals (like UART), you can use trace flags, setting bits in a global variable to indicate code progress.

uint32_t trace_flags = 0;

void init_sensor() 
{
    trace_flags |= (1 << 0); // Bit 0: sensor init started
    // ...
    trace_flags |= (1 << 1); // Bit 1: sensor init complete
}

You can then examine trace_flags in memory to track execution flow, even post-mortem. The trace flags can be printed out or dumped via lldb or gdb.

3. Hardware Debugging: JTAG, SWD, and Debuggers

Modern microcontrollers (like ARM Cortex-Ms) support hardware debugging interfaces such as:

• JTAG (Joint Test Action Group)

• SWD (Serial Wire Debug)

These allow a debugger to:

• Pause execution

• Set breakpoints

• Inspect and modify memory

• Single-step through code

ARM CoreSight is a debug and trace architecture developed by ARM for its processor cores (like Cortex-M, Cortex-A, Cortex-R). It provides a set of hardware modules built into ARM-based chips that allow developers to:

• Debug the system while it's running (non-intrusively)

• Trace code execution, memory accesses, and peripheral activity

• Analyze system performance and find hard-to-catch bugs

In short: CoreSight lets you look inside your embedded system while it's alive and working, without halting it unnecessarily.

Why CoreSight Exists

Traditional debugging tools (like breakpoints or single-stepping with JTAG) are often intrusive (they pause the system), limited (can't capture what happened right before a crash), or not suitable for real-time systems.

CoreSight solves these by enabling real-time tracing and non-intrusive observation of what's happening inside the chip.

Popular Debug Tools:

• ST-Link – HW from STMicrocontrollers

• J-Link – Universal debugger supporting a wide range of MCUs

• OpenOCD – Open-source interface for hardware debugging

• GDB / LLDB – Command-line debuggers used alongside the above

Single-stepping is most effective when compiler optimizations are off. With optimization, code might be reordered, inlined, or even eliminated.

4. Using Map and Disassembly Files

When debugging complex issues, especially crashes or memory overflows, you'll need to go deeper.

Map Files show the layout of functions and variables in memory (Flash and RAM). They help you locate:

• Stack overflows

• Unexpected memory usage

• Function addresses

Disassembly Files let you see the machine code generated from your source. This is critical when:

• Code is heavily optimized

• You’re diagnosing instruction-level failures

• You’re working without source code (e.g., binary-only drivers)

This resource provides a good overview on Map files, linkers and ELF format: Tenouk’s ELF/Map/Linker Guide

Common Bug: Buffer Overflows

Buffer overflows are one of the most frequent (and dangerous) issues in embedded systems. They happen when data is written past the end of an allocated array, overwriting nearby memory and causing unpredictable behavior.

Symptoms:

• Code crashes mysteriously

• Data appears to “corrupt itself”

• Variables change value without explanation

You can learn more in my article on Debugging Buffer Overflows, which walks through ways to debug a buffer overflow and build robust buffer code.

Embedded Forensics

Sometimes, a device fails in the field, where you can’t attach a debugger. That’s where forensics comes in:

• Use watchdog timers to reset the system and log failure info

• Save crash signatures to non-volatile memory (for example, EEPROM, Flash)

• Implement assert handlers that log file names, line numbers, or fault types

These techniques help you reconstruct what went wrong after the device has rebooted or been recovered.

You can learn more here: Debugging Techniques for Embedded Systems – Medium.

Debugging and forensics are invaluable when something goes wrong – but a robust system should aim to catch issues before they reach deployment.

That’s where automated testing becomes essential. With embedded software increasingly powering critical applications, the ability to run consistent, repeatable tests across hardware configurations saves time, improves reliability, and enables faster development cycles.

Next, let’s explore how embedded testing works, the challenges unique to hardware, and how automation frameworks help streamline validation.

Automation and Testing in Embedded Systems

Like all other areas of software engineering, testing is essential in embedded systems. But testing embedded software comes with its own set of challenges, mainly because it interacts with hardware.

Manual testing can be time-consuming and resource-intensive, especially when tests need to be repeated for multiple firmware versions or configurations. That’s where automated testing becomes invaluable.

Why Automated Testing?

Automated testing helps:

• Catch regressions early

• Test edge cases consistently

• Reduce human error

• Scale testing across versions and hardware setups

But automating tests for embedded systems isn’t just writing test cases – it’s about setting up an infrastructure that connects your code to the physical hardware under test.

Test Architecture: Host + DUT

Most embedded test setups involve two components:

• Host: Your development PC or CI test controller, which sends test commands and receives data.

• DUT (Device Under Test): The microcontroller board or embedded system running the firmware.

These two communicate over a physical link, commonly USB, UART, or FTDI, which carries commands and test data between them.

Diagram (suggested structure)

You could visualize this as:

Key Components of Embedded Test Automation

1. File Management

Many automated tests rely on CSV or JSON files to define:

• Input configurations

• Expected outputs

• Test parameters

Python makes it easy to:

• Read input vectors from CSVs

• Write logs or pass/fail results

• Parse structured data

2. Data Communication

Maintaining a stable and reliable link between the Host and DUT is critical. This includes:

• Opening and managing UART or USB connections (for example, with pyserial)

• Framing test commands using opcodes or simple protocols

• Handling timeouts, retries, and error recovery

Example (Python with PySerial):

import serial

ser = serial.Serial('/dev/ttyUSB0', 115200) #set Baud rate
ser.write(b'\x01')  # Send opcode for "start test"
response = ser.read(64)  # Read 64 bytes of response

3. Automation Manager (DUT-side)

A lightweight software agent runs on the embedded device. Its responsibilities:

• Parse incoming commands

• Trigger specific test routines

• Send response data back to the host

This is often implemented using a switch-case structure in C or C++:

void automation_manager(uint8_t opcode) {
    switch(opcode) {
        case 0x01: run_sensor_test(); break;
        case 0x02: run_motor_test(); break;
        default: break;
    }
}

4. Automation Manager (Host-side)

This is the control center of your test workflow:

• Sends test commands and parameters to the DUT

• Waits for and logs results

• Compares responses to expected output

• Handles communication retries or failures

Often written in Python using:

• pyserial for communication

• pandas for file/data processing

• unittest or pytest for test structure

Tips for Effective Automation

• Use unique opcodes for each test command to avoid ambiguity

• Implement timeout handling to avoid hanging scripts

• Log everything, responses, errors, test timestamps

• Use versioned test input files to track changes over time

• Include self-tests on the DUT to validate hardware state before running full tests

Automated testing in embedded systems is not just about running scripts, it's about building a bridge between your host PC and your device, managing the flow of commands and data, and ensuring tests are consistent, repeatable, and reliable.

While this requires effort to set up, the payoff is huge: confidence in your firmware, faster development cycles, and reduced risk of bugs making it into production.

Where to Go from Here

Building your Embedded Project

After exploring the theory and tooling of embedded systems, it's time to apply what you've learned. This section walks you through the steps to create your own embedded system – from concept to code and deployment.

Use the checklist below to guide your first project, whether you're prototyping a sensor device or automating a simple process.

Project Setup Checklist:

1. Define the Goal

   • What task does the system perform?

   • Identify inputs (for example, temperature sensor) and outputs (for example, relay or LED).

2. Requirements Gathering

   • Functional: What features must it support?

   • Non-functional: Memory limits, real-time behavior, power constraints.

   • Any security or safety-critical elements?

3. Choose Your Hardware

   • Microcontroller (for example, STM32F4)

   • Sensors and actuators

   • Communication interfaces (UART, I2C, SPI, and so on)

4. Software Architecture

   • Bare-metal, RTOS, or embedded OS?

   • Driver abstraction: will you use HAL or custom low-level code?

   • Organize code into layers: application logic, drivers, hardware init.

5. Toolchain Setup

   • Install GCC toolchain (for example, arm-none-eabi-gcc)

   • Configure Makefile and linker script

   • Set up debugger and flashing tools (for example, OpenOCD, ST-Link)

6. Firmware Implementation

   • Initialize peripherals

   • Implement control logic inside main() or tasks

   • Use interrupts or timers for responsiveness

7. Flashing and Initial Tests

   • Use OpenOCD or ST-Link to flash the binary

   • Test peripheral behavior and debug with UART or GDB

8. Debug and Profile

   • Use JTAG/SWD, CoreSight, and trace logs

   • Check memory layout with map/disassembly files

   • Identify bottlenecks and edge cases

9. Security Hardening

   • Disable debug interfaces post-flash

   • Add firmware signing and secure boot

   • Minimize surface area: disable unused features

10. Testing and Automation

• Connect Host to DUT via UART/USB

• Use Python + PySerial to send test vectors

• Log, compare, and report test outcomes

Embedded firmware development is a deep and rewarding field where software meets the hardware. Whether you're controlling an LED, reading from a sensor, or orchestrating multiple tasks in real time, the embedded stack teaches you how hardware, software, timing, and efficiency all come together.

Summary:

In this guide, we walked through the essential building blocks at a high level:

• What embedded systems are, and how they sense → process → act

• How microcontrollers work, from memory layout to interrupts and protocols

• How to design robust, scalable embedded software with clean architecture

• When to choose bare-metal, RTOS, or full OS solutions

• How to build drivers, write modular code, and interface with peripherals

• Tools for debugging, tracing, and analyzing system behavior

• Strategies for automating embedded testing using Python and host-device communication

• And finally, why security matters, especially in a connected world

Whether you're preparing for embedded job interviews, building your own IoT projects, or just exploring how software drives real-world systems, this article gives you a launchpad for deeper learning.

The first is general-purpose computing, where they handle a wide range of tasks, including running diverse applications and programs. Examples include laptops, desktops, servers, and supercomputers.

The second is embedded systems, which are specialized computers designed for specific functions. Commonly found in devices such as thermostats, refrigerators, cars, and other smart appliances, they rely on sensors to collect environmental data and execute their tasks efficiently.

The Role of Sensors

Sensors play a critical role in both types of computing. In embedded systems, sensors gather environmental data to help devices like autonomous vehicles, home appliances, and industrial machines perform tasks. In general-purpose computers, sensors primarily monitor internal conditions such as temperature and voltage, ensuring safe operation and preventing issues like overheating or electrical faults.

As Artificial Intelligence (AI) and the Internet of Things (IoT) evolve, sensors have become indispensable for gathering real-world data to support intelligent decision-making. Embedded systems leverage sensors to perceive their environment, transforming raw data into actionable insights that power automation and improve efficiency across industries.

This means that understanding sensor interfacing and designing robust sensor-driven software has become a vital skill for engineers and hobbyists alike.

Whether you're a beginner or experienced engineer, this guide will help you build a solid understanding of sensor interfacing software.

What You’ll Learn and Article Scope

In this article, you’ll learn how to connect sensors to microcontrollers (MCUs) and design sensor software pipelines that turn raw data into meaningful, usable information. You’ll also explore practical techniques for processing sensor data accurately and efficiently in embedded systems.

Here’s a breakdown of what we’ll cover:

• What sensors are and how they work – An introduction to sensors, common types, and how sensor pipelines help process sensor data.

• Key sensor characteristics – Important parameters like sensitivity, accuracy, precision, range, drift, and response time to help you choose the right sensor for your project.

• How to interface sensors with microcontrollers – Hardware connections and communication protocols like SPI, I²C, and GPIO that allow microcontrollers to read sensor data.

• Software architecture for sensor data – A high-level overview of the software pipeline that processes sensor data, including drivers, ADC support, scaling, calibration, and post-processing.

• Detailed design of pipeline components – A closer look at each step in the pipeline, focusing on scaling raw data, calibrating sensors, and applying filters to clean up noisy signals.

• Practical tips for power management – Best practices for handling power efficiently using low-power modes, FIFO buffers, and DMA when working with sensor data in embedded systems.

By the end of this article, you’ll know how to design and implement a complete sensor data pipeline for an embedded system, from reading raw sensor data to preparing it for real-world use in intelligent, connected devices.

Note: Advanced data processing, high-resolution ADCs, and hardware circuit design for sensors are outside the scope of this article.

Prerequisites

To get the most out of this article, you should have:

1. Basic knowledge of microcontrollers: Understanding of common peripherals like ADCs (Analog-to-Digital Converters), SPI (Serial Peripheral Interface), I2C (Inter-Integrated Circuit) and GPIO (General Purpose Input/Output). If you’re new to these protocols, this article provides a great overview.

2. Basic knowledge of electronics: Familiarity with circuits and signals, including analog and digital interfaces.

3. Programming in C: Familiarity in embedded software development, including driver development.

4. (Optional) Basic knowledge of sensors: Understanding different types of sensors (like temperature, pressure, motion) is helpful but not required.

Also, this article assumes the following:

• You are working with a microcontroller equipped with the peripherals needed for sensor integration. The details of microcontroller peripherals can be found in a reference manual for example for an STM32F4 series microcontroller will have all the details :

• You are familiar with compilers, debuggers, and IDEs used in embedded systems. Some common tools include:

  • Compilers: GCC, Clang,

  • Debuggers: GDB, LLDB

  • IDEs: Visual Studio Code (VSCode) is a popular choice, especially with extensions for embedded development and debugging.

• You aim to build reliable, sensor-driven embedded systems, capable of collecting and processing real-world data efficiently.

Table of Contents

• What is a Sensor and Sensor Pipeline?

• Sensor Characteristics

• How to Interface with a Microcontroller

• Software Architecture

  • High-Level Overview of Components

  • Accessing Data from the Sensor

  • Sensor Power Management

• Detailed Design of Components

  • 1. Sensor Driver

  • 2. ADC Support

  • 3. Scaling

  • 4. Calibration

  • 5. Data Post-Processing

• Conclusion

What is a Sensor and Sensor Pipeline?

A sensor detects changes in physical properties such as temperature, pressure, or light and converts them into electrical signals that can be measured or interpreted. For example, a thermistor is a type of resistor whose resistance changes with temperature. As the temperature varies, the resistance of the thermistor changes, altering the voltage across it. The system then interprets this voltage change to determine the temperature.

To better understand sensors, consider the natural sensors in the human body: the eyes, ears, skin, nose, and tongue. These natural sensors constantly send signals about the environment to the brain for processing. Different regions of the brain interpret these signals and use the information to drive actions and responses. Just like the brain processes signals from natural sensors, a microcontroller processes signals from electronic sensors using a sensor pipeline.

Sensors come in many types, each designed to detect specific physical properties. Some sensors have a sensing element that changes its properties in response to conditions like heat, light, or pressure. Examples include thermistors, infrared receivers, and photodiodes.

For detecting movement, such as acceleration and rotation, MEMS (Microelectromechanical Systems) sensors—like accelerometers and gyroscopes—are widely used.

To measure distance, sensors like sonars, ultrasonic sensors, and radars are common. These are just a few examples of the many types of sensors available.

Beyond the types of physical properties they detect, sensors also differ in their levels of integration. Some sensors are raw sensors, consisting only of a sensing element and a transducer with simple leads for direct connection to an external circuit.

Others, known as smart sensors, include additional components such as an ADC (analog-to-digital converter) and onboard processing capabilities, enabling them to handle more of the data processing independently.

The choice between a raw sensor and a smart sensor depends on your application requirements, including factors like cost, size, and the processing load on the interfacing microcontroller.

Returning to our human analogy, consider how vision works as a sensor pipeline. When light enters our eyes, photoreceptor cells (rods and cones) in the retina act as sensing elements, converting the light into electrical signals. These signals travel via the optic nerve to the brain’s visual cortex, where they undergo processing to form a recognizable image. The brain then interprets this information and initiates a response, like smiling when you see a beautiful scenery.

Similarly, a sensor pipeline for an embedded system can be defined as shown in the picture below:

Each of these steps may have different requirements based on the application. Creating a requirements document for the sensor is helpful when selecting the appropriate sensor and configuring the pipeline.

Sensor Characteristics

Before you dive into the blocks of the sensor pipeline, let’s review some important characteristics of a sensor.

Sensitivity

Sensitivity is the ability of a sensor to detect small changes in the physical property it’s designed to measure.

Sensitivity can vary based on factors like manufacturing processes, cost, and the design of the sensing element.

Sensors designed for a specific property often come in different sensitivity levels, allowing users to select an appropriate sensitivity based on the application requirements.

Accuracy

Accuracy is the degree to which a sensor’s measurement matches the true value of the physical property it’s measuring. Testing a sensor’s accuracy typically requires comparing its readings to those of a reference instrument.

A sensor may have gain and offset errors—issues that calibration can help correct. Calibration adjusts for these systematic errors, which are often due to manufacturing tolerances or design factors.

Once calibrated, the sensor’s output can be verified against a reference to confirm its accuracy. The required level of accuracy should be determined based on the application’s needs.

Precision

Precision refers to the consistency or repeatability of a sensor's measurements, regardless of how close those measurements are to the true value. It indicates the sensor's ability to produce the same output under identical conditions and how finely it can resolve and report values.

For example, if the true temperature of an object is 12.53°C:

• A precise sensor will consistently measure values like 12.52°C, 12.53°C, or 12.54°C, even if those values are slightly offset from the true temperature.

• A highly accurate sensor, on the other hand, will measure values close to 12.53°C but may lack precision if those readings vary widely (e.g., 12.50°C, 12.53°C, and 12.56°C).

For applications requiring exact measurements, a sensor with both high accuracy (closeness to the true value) and high precision (low variability) is essential. This is especially important in distinguishing small differences, such as between 12.5°C and 12.53°C.

In contrast, applications with less stringent requirements might use sensors with broader tolerances, such as ±1°C, which are sufficient for general monitoring purposes.

Range

The range of a sensor refers to the span between the maximum and minimum values of the physical property it can measure while maintaining its specified precision and accuracy. A sensor's operating range may extend beyond its measurement range, but the measurement range defines the limits within which the sensor reliably adheres to its specified sensitivity, accuracy, and response time.

Drift

Drift is when a sensor's output changes over time due to conditions like temperature or humidity. Components within the sensor, including the sensing element, may be sensitive to these conditions, leading to gradual shifts in measurements.

For example, many components are affected by temperature and humidity changes, which can alter sensor readings. Also, sensors with internal oscillators may experience time-based drift, impacting accuracy.

Regular calibration with an accurate external reference (such as a precise clock) can help correct for drift and maintain reliable measurements. For certain applications, selecting a sensor with acceptable drift characteristics is crucial.

Response Time

Response time is the duration a sensor takes to detect and reflect a change in the measured physical property. For example, if the temperature rises by 5°C, the response time indicates how long the temperature sensor takes to reflect this change in its output.

Response time depends on the sensor’s design, manufacturing quality, and internal components, such as the ADC (Analog-to-Digital Converter), averaging circuits, and filters within the sensor pipeline.

All the parameters mentioned above are thoroughly documented in the sensor’s data-sheet. In practice, it’s a good idea to create a sensor requirements document for each specific application, detailing these key parameters as a baseline for sensor selection.

Now that you’ve examined the key characteristics of sensors, let’s explore how you can connect them to a microcontroller for real-world applications.

How to Interface with a Microcontroller

Choosing a Communication Protocol

Another essential aspect of sensor requirements is specifying the communication interface between the sensor and the MCU or processor in the system. It’s important to understand how the sensor will be interfaced based on its output signal type and the available pins on the microcontroller.

For instance, certain sensors may connect directly to an analog or digital input pin on a microcontroller. A raw sensor, such as a temperature sensor, typically connects to an analog input pin, which is then read by the microcontroller’s internal ADC (Analog-to-Digital Converter).

In contrast, a digital-output sensor connects to a digital GPIO (General Purpose Input/Output) pin. For instance, speed sensors generate square waves with variable pulse widths to indicate speed. These signals are usually connected to a GPIO pin configured as an external interrupt or timer capture input, allowing the microcontroller to measure pulse width accurately.

A smart sensor, on the other hand, often supports communication protocols like SPI (Serial Peripheral Interface) or I2C (Inter-Integrated Circuit). These interfaces enable the microcontroller to configure the sensor, check its status, and retrieve data through register reads and writes.

Choosing the appropriate communication protocol for interfacing a sensor depends on the available pins in the system and the specific requirements of the application.

Tip: When working with protocols like I²C or SPI, using tools such as Saleae logic analyzers can greatly simplify debugging and validation. Logic analyzers capture and visualize communication signals, and tools like Saleae offer built-in protocol interpreters to help you decode sensor communication in real time. This can be especially helpful when troubleshooting configuration issues, timing problems, or communication errors during sensor interfacing.

Figure 2 below shows an example of a microcontroller connected to 4 sensors having different interfaces.

Determining Power Requirements

Power requirements are another key consideration when interfacing a sensor. Sensors may operate at different voltages (for example, 3.3V or 5V), so ensuring the microcontroller can accommodate these levels is essential. Level converters can bridge voltage mismatches, ensuring compatibility between the sensor and microcontroller voltage levels.

Timing and sampling requirements must also be evaluated, especially for sensors generating high-frequency data. Configuring external interrupts on GPIO pins can ensure timely data capture, while techniques like using DMA can streamline data transfer for sensors sampling at high frequencies without CPU involvement.

Now that you’ve learned about communication protocols and hardware connections, let’s focus on designing the software architecture that acquires, processes, and prepares sensor data for use. Designing effective software is crucial for obtaining clean, reliable data from the sensor.

Software Architecture

Now that we’ve chosen the sensor and communication protocol, let’s design the software architecture for the sensor pipeline. This software runs on the microcontroller connected to the sensor and processes raw data to make it clean and usable.

While application-level data processing is beyond the scope of this article, let’s focus on interfacing with the sensor and preparing the data for application use.

The sensor processing pipeline can be broken into the following components:

1. Sensor Driver

2. Analog-to-Digital Conversion (ADC) Support

3. Scaling

4. Calibration

5. Data Post-Processing

Let’s examine a high-level overview of these components for both smart and raw sensors.

High-Level Overview of Components

1. Sensor Driver

   1. Smart sensors: The driver configures the sensor, manages power, and handles read and write operations to the sensor registers over a communication protocol like SPI, I2C.

   2. Raw sensors: The driver may only control GPIOs for power management, as raw sensors typically lack registers.

2. Analog-to-Digital Conversion (ADC) Support

   1. Smart sensors: Include an onboard ADC, which is configured through the sensor driver.

   2. Raw sensors: Requires an external ADC, an ADC driver implemented in software to configure the ADC, initiate conversions, and retrieve data.

3. Scaling: Scaling is necessary for both smart and raw sensors. It converts digital counts after the analog to digital conversion into meaningful physical quantities using formulas provided in the sensor data sheet. For example, a temperature sensor will use a formula to convert digital counts to degree Celsius.

4. Calibration: Once the measured physical quantity is obtained, calibration adjusts the value by applying offsets, gains, or both to correct errors. This process ensures the sensor output aligns with reference values across its entire measurement range. A detailed discussion of the calibration process will follow in the next section.

5. Data Post-Processing: Post-processing techniques, such as filtering are applied to improve data quality and reduce noise. Common filters such as low-pass or high-pass filters can remove unwanted frequency components.

Accessing Data from the Sensor

The method of accessing data depends on the whether it’s a raw sensor or a smart sensor. Smart sensors will have onboard ADCs and FIFOs. Before delving into how data is accessed, it’s important to first understand sampling frequency.

Sampling Frequency:

The frequency of taking a measurement from the sensor must follow the Nyquist-Shannon sampling theorem. It states that the sampling rate must be twice the highest frequency component of the signal to be measured to accurately reconstruct the measured data.

The sampling frequency defines how often the sensor captures data, which affects how the data is accessed. Depending on whether the sensor is a raw sensor or a smart sensor, the approach to handling this sampled data varies.

Smart Sensors:

1. Data register: The sensor writes sampled data directly into a register based on the set sample frequency updated during setup. The microcontroller reads this data register based on a data conversion completion interrupt.

2. FIFObBuffer: Some sensors include FIFO (First-In, First-Out) buffers to store multiple data points. When enabled, the FIFO updates at the configured sampling frequency and trigger interrupts when it becomes full or reaches a predefined level.
   The benefits of FIFO include:

   1. Power efficiency: The MCU can process data in batches, reducing CPU overhead and allowing it to enter low-power mode during data collection.

   2. Sampling and processing rate matching: FIFO buffers help reconcile differences between the sensor’s sampling rate and the MCU’s data processing rate.

   3. For MCUs with Direct Memory Access (DMA), data transfer from the sensor to MCU memory can occur without CPU intervention, further reducing power consumption.

Raw Sensors:

For raw sensors, the MCU triggers ADC conversions at the sampling frequency, often using a timer interrupt. Data is read upon the ADC conversion complete interrupt, allowing the MCU to sleep during conversions and between samples to save power.

Sensor Power Management

Power management is critical for energy-sensitive applications. Strategies include:

1. Low-power modes: Many sensors support low-power modes configurable through sensor registers.

2. GPIO-controlled power cycling (Duty-Cycling): For sensors without built-in low-power modes, the microcontroller can toggle the sensor’s power line using a GPIO pin, reducing power consumption further. Figure 3 below shows the diagram of a raw temperature sensor whose power is controlled using a GPIO from the MCU. For example, a temperature sensor in sleep mode can be activated only when temperature readings are required.

The above techniques ensure efficient use of power while maintaining the required data sampling rate and sensor responsiveness.

With the high-level architecture in mind, we’ll now dive into the detailed design of each pipeline component.

Detailed Design of Components

In this section, you’ll delve into the key components of the sensor pipeline outlined in the Software Architecture section.

1. Sensor Driver

The sensor driver is responsible for managing communication, configuration, power, and data acquisition for both smart and raw sensors.

Smart Sensor Driver:

1. Communication driver: Generic I2C or SPI drivers on the MCU can be adapted using wrapper functions to handle sensor-specific requirements, such as 1-byte, 2-byte, or 4-byte transfers.

2. Configuration: Typical tasks include setting the sampling rate, configuring interrupts, managing FIFO buffers, and, if needed, clock settings.

3. Power management: APIs should allow higher software layers to transition sensors between power modes by writing to specific registers or controlling GPIO lines for sensors without built-in power modes.

Raw Sensor Driver:

For raw sensors, the driver primarily manages power, often through GPIO-controlled toggling.

2. ADC Support

ADC support is required only for raw sensors. In this article, we’re focusing on SAR ADCs, which are commonly embedded in microcontrollers.

How SAR ADCs Work?

A SAR ADC converts an analog signal to a digital value over multiple clock cycles, with the number of cycles equal to its bit resolution (for example, 10 cycles for a 10-bit ADC).

Key terms related to ADCs:

1. Reference Voltage (VRef): Represents the maximum voltage the ADC can measure. Analog signals exceeding this limit must be scaled down.

2. Resolution: Determines the smallest detectable voltage change. For example, a 10-bit ADC with a 3.3V VRef has a resolution of 3.22 mV

$$V_{\text{Res}} = V_{\text{Ref}} /2^{10}$$

The ADC result is stored in a data register, which can then be scaled to meaningful physical units.

3. Scaling

Scaling converts ADC counts into meaningful physical values, such as temperature (°C) or acceleration (g) depending on the sensor type. Sensor datasheets typically provide the necessary formulas or lookup tables.

For example, the method to convert a voltage measured by a raw temperature sensor to temperature value is shown below:

$$V_{\text{Measured}} = Counts_{\text{ADC}} / 2^{10} * V_{\text{Ref}} \quad \text{(Get V_Measured from ADC Counts)}$$

$$Temperature_{\text{Measured}} = V_{\text{Measured}} * T_{\text{C/mV}} \quad \text{(Get Temperature physical value)}$$

Similarly, a 3-axis accelerometer maps counts on the X, Y, and Z axes to acceleration values in g or milli-g.

4. Calibration

The figure above on the left (4a) is showing Calibration with gain and offset, while the figure above on the right (4b) is showing calibration with fixed offset.

$$x_{\text{calibrated}} = Gain * x_{\text{raw}} + Offset \quad \text{(Figure 4a - Linear Calibration)}$$

$$x_{\text{calibrated}} = x_{\text{raw}} + Offset \quad \text{(Figure 4b - Fixed offset Calibration)}$$

Calibration ensures the sensor’s output aligns with reference measurements, correcting for errors introduced by design, materials, or manufacturing.

Types of Errors:

1. Offset error: A constant deviation of the sensor’s output from the true reference value, regardless of input magnitude.

2. Gain error: A proportional error where the sensor’s output scale deviates from the expected value, causing the output to increase or decrease incorrectly relative to the input.

Calibration Methods:

1. 2/3-Point calibration: This type of calibration may involve either applying a fixed offset to the raw value or applying both gain and offset. Figure 4a illustrates an example of a gain/offset calibration, while Figure 4b depicts offset calibration. In both figures, the y-axis represents the reference value measured by an accurate instrument, while the x-axis represents the raw value measured by the sensor after ADC.

2. N-Point calibration: Involves multiple points for more complex, non-linear error correction.

Implementation:

1. Calibration points shall cover the sensor’s entire measurement range for accuracy.

2. Parameters like gain and offset once estimated shall be stored in a non-volatile memory in the system for persistence to be used across power cycles.

5. Data Post-Processing

Post-processing covered in this section talks about removing noise and unwanted signal components, which improves data reliability.

Filtering

Filtering is the process of removing unwanted frequency components from a signal to improve data quality. There are several different types of filters:

• Low-Pass Filters: Allows low-frequency signals to pass while attenuating high-frequency noise.

• High-Pass Filters: Allows high-frequency signals to pass while attenuating low-frequency noise. (for example, gravitational acceleration in accelerometer data).

• Band-Pass Filters: Retains only signals within a specific frequency range, removing both lower and higher frequencies outside the desired band.

These filters are often implemented as FIR (Finite Impulse Response) or IIR (Infinite Impulse Response) filters. IIR filters are easy to implement and computationally efficient while FIR filters are computationally intensive but have better control over the frequency response.

Here, we will explore a simple low-pass filter known as the Exponential Moving Average (EMA), a type of IIR filter. A moving average filter is a mathematical technique that smooths short-term fluctuations while highlighting longer-term trends.

Unlike other moving average filters, EMA does not require maintaining a buffer, making it more memory-efficient. It is also more responsive to data changes while still providing smoothing, making it well-suited for real-time filtering. EMA assigns greater weight to recent data samples than older ones, allowing it to adapt quickly to changes in sensor readings.

EMA can be calculated like this:

$$EMA_{\text{t}} = \alpha * x_{\text{t}} + (1 - \alpha) * EMA_{\text{t - 1}}$$

$$\alpha = 2 / (N + 1) \quad \text{(Smoothening Factor, N - filter window size)}$$

$$EMA_{\text{t}} \quad \text{(Exponential Moving Average in current iteration)}$$

$$x_{\text{t}} \quad \text{(New Data Sample in Current Iteration)}$$

$$EMA_{\text{t - 1}} \quad \text{(Exponential Moving Average in the last iteration)}$$

Now that we understand the Exponential Moving Average (EMA) filter, here are two key factors to consider when tuning it for an application:

• Smoothing vs. Responsiveness: A higher smoothing factor (closer to 1, smaller filter window size) gives more weight to recent data, making the filter more responsive to changes but less effective at noise reduction. A lower smoothing factor (closer to 0, larger filter window size) provides better noise reduction but reacts more slowly to data changes.

• Application-Specific Tuning: The smoothing factor should be chosen based on the sampling rate, sensor sensitivity, and application requirements. Real-time systems often require a balance between quick responsiveness and stable output.

Here’s a code sample for EMA:

#include <stdio.h>
#include <stdint.h>

// Exponential Moving Average (EMA) filter implementation
#define FILTER_WINDOW 5

// Function to calculate EMA
float calculateEMA(float ema, float new_value, float alpha) {
    return (alpha * new_value) + (1 - alpha) * ema;
}

int main() {
    float sensorReadings[] = {26.0, 27.5, 28.2, 27.0, 26.8, 26.5, 27.2};
    int numReadings = sizeof(sensorReadings) / sizeof(sensorReadings[0]);

    float alpha = 2.0f / (FILTER_WINDOW + 1); // Standard EMA formula
    float ema = sensorReadings[0];  // Initialize EMA with the first reading

    printf("EMA Filtered Sensor Data:\n");

    for (int i = 0; i < numReadings; i++) {
        ema = calculateEMA(ema, sensorReadings[i], alpha);
        printf("Reading %d: Raw = %.2f, EMA = %.2f\n", i + 1, sensorReadings[i], ema);
    }

    return 0;
}

Conclusion

In summary, sensors are the backbone of modern smart devices, bridging the gap between the physical world and digital systems. From consumer electronics to industrial automation and medical devices, they enable devices to perceive and interact with their environments.

Understanding how sensors work, the components of their data pipeline, and their integration with microcontrollers is essential for engineers and hobbyists alike. By designing effective pipelines, developers can ensure accurate, clean, and reliable data, enabling systems to meet performance and power efficiency goals.

If you have questions or want to talk more about this topic, feel free to reach out on Twitter or LinkedIn. Always happy to connect.