The project includes a reusable sbc_hardware_lib.slx library for hardware blocks that do not depend on a board-vendor Simulink support package. The current implementation targets the Linux GPIO character-device v2 API and is intended for Raspberry Pi, Orange Pi, Radxa, and other Linux SBCs with compatible kernel support.
Available blocks
| Block | Purpose | Generated-code behaviour |
|---|---|---|
| GPIO Read | Reads one Linux GPIO line and outputs its logical state plus status. | Uses the project C HAL through coder.ExternalDependency. |
| GPIO Write | Writes a logical state to one Linux GPIO line and returns status. | Uses the same generic Linux C HAL; no vendor daemon or board SDK call is required. |
Open or regenerate the library
addpath(fullfile(pwd, "sbc")) sbcCreateLibrary
The command regenerates sbc_hardware_lib.slx after editing the block definitions. The SBC Hardware library then appears in the Simulink Library Browser.
GPIO identity: chip and line, not header pin number
Generic Linux GPIO uses a character device path such as /dev/gpiochip0 and a zero-based line offset. A board header label such as “pin 11” is not a portable software identifier. The header-to-chip/line mapping is board-specific and may also change with device-tree overlays or kernel configuration.
Use board profiles outside the model
Keep logical signal names and board mappings in a JSON profile, then resolve it during model setup. The supplied profiles/generic-linux-gpio.example.json shows the expected pattern.
pin = sbcLoadGpioProfile("my-board.json", "status_led");
% Set a GPIO block's Chip, Line and ActiveLow properties from pin.
This makes the same model portable: only the profile changes between boards. Store the deployed profile alongside the target configuration and record it in validation notes.
Simulation and generated code
- In normal simulation, the blocks use deterministic mock behaviour and do not access host GPIO devices.
- In generated ERT code, the blocks compile the project C HAL automatically.
- The status output is zero on success. Connect it to diagnostics/fault handling so pin-mux, permission, or request errors are visible.
Target prerequisites
- Linux kernel GPIO character-device v2 support.
- Correct device-tree pin mux for GPIO mode.
- Target process permission to access
/dev/gpiochip*, normally through a distribution group or udev rule. - Confirmed chip/line mapping for the actual board and OS image.
Extending the hardware library
Use the same HAL/profile pattern for I2C, SPI, PWM, UART, SocketCAN, and GPIO events. Keep board SDK calls out of generated model code where possible. A small generic C adapter plus external board profile is easier to validate and avoids tying code generation to a particular vendor support package.