The GPIO sub-system in BitThunder is very straight-forward and simple to use. Throughout the entire system GPIOs are addressed using a GPIO number/flag space.
Depending on your system/application GPIO flags can be mapped and aliased within this address space. Usually primary GPIOs start at 0, but thats just a convention.
GPIO are accesible to all, and no BT_HANDLE is associated or exported to user-space. Therefore its possible to have multiple processes conflicting, and controlling the same GPIO by mistake.
Having the GPIO API in this way makes its usage very simple, and most BitThunder systems are currently closed embedded systems. However we intend to extend the API later to allow a process to LOCK a GPIO to itself, and only make use of the GPIO pin using a special HANDLE based API.
The following table lists all functions related to the GPIO subsystem API.
Gets the current state of a GPIO line.
Sets a GPIO line to the desired state.
Gets the direction / mode of a GPIO line.
Sets the direction / mode of a GPIO line.
Kernel-space / Driver API
Registers a GPIO controller driver with the GPIO sub-system.
The BitThunder GPIO subsystem is simple, and all operations on a standard system are relatively cheap. There is an O(n) cost, where n = number of registered GPIO controllers, to resolve GPIO numbers to the correct driver implementation.
The GPIO api is not meant to be a high-performance API for doing bit-banging, or accurately timed PWM signals, bit mostly for setting board MUXs, or LEDs, or chip-selects.
Those wanting to do high-performance GPIO access should write a driver that utilises the GPIO registers directly in kernel-mode. E.g. a bit-banged I2C bus driver should be implemented directly.
The driver interface implements interrupt hooking, and this will be later exposed to user-space and other kernel-mode drivers.
The full API is defined under:
See the implementation under:
See the driver interface under: