Using C as Your Raspberry Pi Programming Language for Low-Latency GPIO

If you are building a high-speed data acquisition system, a bit-banged SPI interface, or a low-latency motor controller, Python’s Global Interpreter Lock (GIL) and garbage collection pauses will eventually cause you to miss pulses. The direct answer to achieving deterministic, microsecond-level GPIO control on modern hardware is to use C as your Raspberry Pi programming language, specifically targeting the Linux character device API via the lgpio library.

This guide targets the Raspberry Pi 5 8GB running Raspberry Pi OS (Bookworm or later). The Pi 5 uses the new RP1 southbridge chip, which completely broke legacy memory-mapped libraries like wiringPi and bcm2835. We will bypass those deprecated tools and write modern, compilable C code that interacts directly with the kernel's GPIO subsystem.

The Case for C: Escaping Python's GIL on the Pi 5

Before writing a single line of code, it is critical to understand the performance delta between languages when interacting with the Pi 5's RP1 chip over the PCIe-connected GPIO matrix. Python is excellent for prototyping, but its execution overhead introduces jitter that is unacceptable for hardware timing.

As the data shows, compiling C directly against the lgpio library yields sub-microsecond latency with virtually zero jitter. This is because C executes as native ARM64 machine code, bypassing the interpreter overhead and socket-based IPC daemons that plague other approaches. For authoritative details on the Pi 5's RP1 architecture and why older memory-mapped approaches fail, refer to the official Raspberry Pi hardware documentation.

Hardware BOM and Pin Mapping

For this build, we are implementing a high-speed pulse counter for a quadrature optical encoder. This is a common scenario where missing a single edge transition ruins your positional tracking.

Parts List

• Board: Raspberry Pi 5 8GB (Official 27W USB-C PD power supply required to prevent brownouts during rapid GPIO switching)
• Sensor: CUI Devices AMT103 Quadrature Encoder (or any 5V open-collector optical encoder)
• Level Shifters: 2x Bi-directional logic level converters (BSS138 MOSFET-based) to step the encoder's 5V signals down to the Pi 5's 3.3V logic.
• Pull-ups: 2x 10kΩ resistors (if your level shifter board lacks them)

Pin Mapping Table

Complete C Implementation: High-Speed Pulse Counting

We will use the lgpio C API. Unlike the deprecated bcm2835 library, lgpio uses the modern Linux /dev/gpiochip character device interface, making it fully compatible with the Pi 5's RP1 chip and future-proof for upcoming kernel updates. You can find the full API reference at the lgpio documentation hub.

Prerequisite: Install the library via sudo apt install liblgpio-dev before compiling.

#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <lgpio.h>

// Pin Definitions (BCM Numbering - NEVER use physical pin numbers here)
#define GPIO_CHIP 0
#define PIN_A 16
#define PIN_B 18

// State variables
volatile int keep_running = 1;
volatile long pulse_count = 0;

// Graceful shutdown handler
void handle_sigint(int sig) {
    keep_running = 0;
}

int main() {
    signal(SIGINT, handle_sigint);

    // 1. Open the GPIO character device
    int h = lgGpiochipOpen(GPIO_CHIP);
    if (h < 0) {
        fprintf(stderr, "Error opening GPIO chip %d: %s\n", GPIO_CHIP, lguErrorMessage(h));
        return EXIT_FAILURE;
    }

    // 2. Claim the lines as inputs with internal pull-ups disabled (using external hardware pull-ups)
    if (lgGpioClaimInput(h, 0, PIN_A) < 0) {
        fprintf(stderr, "Failed to claim PIN_A (%d): %s\n", PIN_A, lguErrorMessage(h));
        lgGpiochipClose(h);
        return EXIT_FAILURE;
    }
    if (lgGpioClaimInput(h, 0, PIN_B) < 0) {
        fprintf(stderr, "Failed to claim PIN_B (%d): %s\n", PIN_B, lguErrorMessage(h));
        lgGpiochipClose(h);
        return EXIT_FAILURE;
    }

    printf("Counting pulses on GPIO %d. Press Ctrl+C to stop.\n", PIN_A);

    int last_state = lgGpioRead(h, PIN_A);
    int current_state;

    // 3. High-speed polling loop
    while (keep_running) {
        current_state = lgGpioRead(h, PIN_A);
        
        // Detect rising edge
        if (current_state != last_state && current_state == 1) {
            pulse_count++;
        }
        last_state = current_state;
        
        // Sleep for 50 microseconds to prevent CPU monopolization while maintaining 10kHz+ read rates
        lguSleep(0.00005); 
    }

    // 4. Cleanup and release lines
    lgGpiochipClose(h);
    printf("\nShutdown complete. Final Pulse Count: %ld\n", pulse_count);
    
    return EXIT_SUCCESS;
}

Compile and run:
gcc -O3 -o encoder_counter encoder.c -llgpio
./encoder_counter

Debugging: When the Compiler and Kernel Fight Back

When working with Linux character devices in C, the kernel's security model will frequently block your code. Here are the exact error strings you will encounter and their ranked causes.

Error: Error opening GPIO chip 0: /dev/gpiochip0: Permission denied

1. Missing Group Membership: Your current user is not in the gpio group. Fix: sudo usermod -aG gpio $USER, then log out and back in.
2. Udev Rules Missing: The OS hasn't assigned the correct permissions to the character device. Fix: Ensure the lgpio udev rules are installed in /etc/udev/rules.d/.

Error: Failed to claim PIN_A (16): lgGpioClaimInput: GPIO busy

1. Daemon Conflict: The pigpiod daemon or lgpiod service is running in the background and has already claimed exclusive access to the line. Fix: sudo systemctl stop pigpiod.
2. Device Tree Overlay Conflict: A /boot/firmware/config.txt overlay (like dtoverlay=uart1) has mapped GPIO 16 to a hardware peripheral. Fix: Remove the overlay and reboot.

Error: Segmentation fault (core dumped) immediately on execution

1. Physical vs. BCM Pin Confusion: You passed the physical header pin number (e.g., 36) into lgGpioClaimInput instead of the BCM GPIO number (16). The library attempted to access an out-of-bounds memory address for the line offset. Always use BCM numbering in C.

First Three Things to Check When It Fails

If the code compiles but the pulse count remains at zero despite the encoder spinning, run through this diagnostic triage:

1. Verify Voltage Levels with a Multimeter: The Pi 5's RP1 chip is strictly 3.3V tolerant. Measure the voltage at the Pi-side of your level shifter while spinning the encoder. If you see 5V spikes, your level shifter is wired backward or lacks a common ground, and you may have already damaged the RP1 GPIO pad.
2. Check for I2C/SPI Bus Bleed: GPIO 16 and 18 do not have default pull-up resistors enabled in the RP1 silicon at boot. If your external hardware pull-ups are missing or disconnected, the lines will float, causing thousands of phantom interrupts. Measure the resting voltage; it must be a solid 3.3V.
3. Profile the Polling Loop Overhead: If you are missing pulses at high RPMs, your terminal's printf output might be blocking the thread. Comment out any debug printing inside the while loop and only print the final count upon receiving the SIGINT signal.

Scaling the Build: Simplify or Extend

The polling method used in the code above is robust and easy to understand, but it inherently consumes a small slice of CPU time. Depending on your project's final scope, you should adapt the architecture.

How to Simplify

If you only need to track slow movements (e.g., a wind speed anemometer generating < 50 pulses per second), drop the C code entirely. Switch to Python using the gpiozero library's Button or LineSensor classes, which utilize the kernel's interrupt system under the hood. Alternatively, if you are building a simple RPM counter, use the Pi's hardware PWM clock output to feed a dedicated microcontroller (like an ATtiny85) and read the result over I2C, offloading the timing burden completely.

How to Extend

To scale this up for industrial motor control or CNC applications running at 100kHz+ edge rates, you must move from polling to hardware interrupts. The lgpio library supports this via lgGpioSetAlerts(). By registering a callback function, the Linux kernel will push edge events to your application only when a transition occurs, dropping CPU usage to near zero while maintaining microsecond timestamp accuracy. For full quadrature decoding (tracking both direction and speed), extend the C code to read the state of PIN_B exactly when PIN_A triggers a rising edge; if PIN_B is low, the motor is spinning forward, and if high, it is spinning in reverse.