The Gpio5 library is a replacement specifically for the Raspberry Pi 5 for direct access libraries such as Wiring Pi, bcm2835, pigpio, etc and it provides direct access to the GPIO lines, SPI, PWM and I2C. This is an extract from the newly-published Raspberry Pi 5 IoT In C: Drivers and Gpoi5.

Raspberry Pi 5 IoT In C
Drivers and Gpio5

By Harry Fairhead

Buy from Amazon.

Contents

1. The Pi 5 For The IoT
2. C and Visual Studio Code
3. Drivers: A First Program
4. The GPIO Character Drive
5. GPIO Using I/O Control
6. GPIO Events
7. GPIO Hardware With Gpio5
        Extract: GPIO Registers
        Extract: GPIO5 ***NEW!
8. Some Electronics
9. The Device Tree
10. Pulse Width Modulation
11. SPI Devices
12. I2C Driver and Gpio5
13. Sensor Drivers – Linux IIO & hwmon
14. 1-Wire Bus
15. The PIO 313
16. Going Further With Drivers
17. Appendix I Gpio5

 <ASIN:1871962943>

The Gpio5 Library

If you are going to use direct access to the GPIO registers it makes sense to build a library. The Gpio5 library is modeled on the Pico SDK and is close enough that it is possible to run Pico GPIO programs on the Pi 5 with only minor changes. You can find the complete Gpio5 at its Github repo:

 https://github.com/IOPress/Gpio5,

at the book’s web page:

https://iopress.info/index.php/books/raspberry-pi-5-iot-in-c

and as a complete a listing in Appendix I. The library is built up step by step in subsequent chapters but if you want to go directly to the finished code you can simply download and use it.

Initializing Memory

The first function we need, however, is not part of the Pico SDK. Before we can start working with the registers we have to map them into Linux user space. To make the library more useful it makes sense to first try to use mem as this gives complete access to the entire peripheral area. However, it needs to be run with root privileges. If an attempt at opening mem fails then it makes sense to fall back to gpiomem0 which only needs to be run by a member of the gpio user group and the default use is automatically a member of this group:

int rp1_Init()
{
    int memfd = open("/dev/mem", O_RDWR | O_SYNC);
    uint32_t *map = (uint32_t *)mmap(
        NULL,
        64 * 1024 * 1024,
        (PROT_READ | PROT_WRITE),
        MAP_SHARED,
        memfd,
        0x1f00000000);
    close(memfd);
    PERIBase = map;
    if (map == MAP_FAILED)
    {
      int memfd = open("/dev/gpiomem0", O_RDWR | O_SYNC);
        uint32_t *map = (uint32_t *)mmap(
            NULL,
            576 * 1024,
            (PROT_READ | PROT_WRITE),
            MAP_SHARED,
            memfd,
            0x0);
        close(memfd);
        
if (map == MAP_FAILED)
        {
            printf("mmap failed: %s\n", strerror(errno));
            return (-1);
        };
        PERIBase = map - 0xD0000 / 4;
    };
    GPIOBase = PERIBase + 0xD0000 / 4;
    RIOBase = PERIBase + 0xe0000 / 4;
    PADBase = PERIBase + 0xf0000 / 4;
    pad = PADBase + 1;
    return 0;
}

Notice that if we succeed in opening mem then the start of the block of memory is PERIBase. If we fail to open mem, usually because the program is not running as root, then gpiomem0 is tried and if it works the block of memory starts at GPIOBase and hence PERIBase is set to 0xD0000 “below” that and inaccessible. In either case the values of GPIOBase, RIOBase and PADBase are correct and are accessible.