Achronite / energenie-ener314rt

Node module for RaspberryPi energenie ener314-rt board, used by node-red-contrib-energenie-ener314rt
MIT License
4 stars 2 forks source link

Switch to hardware SPI driver #5

Closed Achronite closed 1 year ago

Achronite commented 4 years ago

Switch from software based SPI device driver to hardware based one for efficiency.

See: https://www.raspberrypi.org/documentation/hardware/raspberrypi/spi/README.md

Achronite commented 1 year ago

Initial POC version is working really well, the number of messages received has increased significantly. But there is an issue in that it seems to require root to be able to access SPI via bcm2835_spi_begin(); I'm not sure how this will work within the complexities of the node-red module implementation.

I'm thinking I could fallback to the software SPI if root unavailable...

Achronite commented 1 year ago

Have now switched to testing with spidev (which does not require root), and I have the initial version working with /dev/spidev0,1 (not 0.0 as expected due to CS LOW). Will need to think about how best to distribute this. Ideally it should try and use the hardware driver and if it has not been enabled (using raspi-config) fallback to the software driver.

FYI: @whaleygeek

whaleygeek commented 1 year ago

You could write an adaptor around the spi function, that tries to read the radiover with spidev, if that returns 0, fallback to the softspi.

whaleygeek commented 1 year ago

E.g spiv.c calls spih.c(transfer, radiover) If it gets non zero, set flag to indicate hardware works. Future calls to spiv(transfer) use spih.c transfer.

If fails, clear flag and defer all future spiv(transfer) calls to spis.c

Could do this via static function calls, or by remapping a function pointer.

Spiv for virtual, spis for software, spih for hardware.