SPI bus concept for hardware abstraction. More...
#include <concepts>#include <cstdint>#include <span>
Include dependency graph for spi.hpp:
This graph shows which files directly or indirectly include this file:
Go to the source code of this file.
Namespaces | |
| namespace | epaper |
| namespace | epaper::hal |
Concepts | |
| concept | epaper::hal::SpiBus |
| Concept for a raw SPI data transfer bus. | |
Detailed Description
SPI bus concept for hardware abstraction.
Defines C++20 concept for SPI data transfer operations, enabling generic driver code that works with any SPI backend.
Design Philosophy:
Hardware Abstraction via Concepts
├─ Platform Independence: Drivers work with Linux SPIdev, embedded HALs, mocks
├─ Minimal Interface: Only data transfer, no config (CS/DC handled by GPIO)
├─ Zero Overhead: Concepts inline to register-level ops in production
└─ Mockability: Easy to substitute mock SPI for testing
SPI Responsibilities:
- MOSI: Master Out, Slave In (data from CPU to display)
- MISO: Master In, Slave Out (data from display to CPU) [full-duplex only]
- SCLK: Serial clock (generated by master)
NOT Handled by SpiBus:
- Chip Select (CS): Managed by GPIO DigitalOutput pin
- Data/Command (DC): Managed by GPIO DigitalOutput pin
- Configuration: Mode, speed, bit order set externally (e.g., Device constructor)
Rationale for Minimal Interface: E-paper displays require precise CS/DC control for command vs data writes. Decoupling CS/DC from SPI allows drivers to implement hardware-specific timing requirements (e.g., CS must go low 10ns before SCLK starts).
Typical Implementations:
- Production: Linux SPIdev wrapper (ioctl-based, /dev/spidevX.Y)
- Testing: MockSPI (records writes, simulates reads)
- Embedded: Platform-specific SPI peripheral drivers
Thread Safety:
- SpiBus concept does not require thread-safe operations
- Concurrent access must be synchronized externally (e.g., mutex in Device)
