Clarify use of SPI in docs

[whaleygeek]

Re: #82

Update README to explain use of a software SPI driver, and please turn off hardware SPI

[Achronite]

Hi David, I'm still struggling to get the timings correct to hit the Rx window for the eTRV with your software spi driver, can you share some information why you decided to re-code this?

What is the difference between this, the bcm2835 driver and the spi that uses ioctl?

[whaleygeek]

Hi, well, as always, there was a very good reason at the time, but things may be very different now.

The software SPI driver was written because in those days it meant 'download this zip file, run it, and it all works out of the box'. The BCM SPI driver required config changes at the time the Pi was new, and posed install complexities for users I didn't want. I recall that the ioctl driver came along a bit later than that too.

GPIOzero even today has a soft SPI driver in it as a fall-back if the hardware one doesn't work for some reason of configuration etc (as it often failed on the very early Pi's). Also at the time, the BCM C library wasn't well controlled (it was just a random zip file that people used to share) and it was yet something else you had to download before it all worked. That's how the original Energenie code was delivered to me, it was quite a bag of bits to be fair!

Also, the simple sockets we were testing against had no strict requirements on timing, so a slower but more compatible SPI driver (zero install, zero extra downloads) was better at that time for what we were trying to achieve.

I aways had a view that given the maturing of hardware SPI support, I would one day look to see if there is now a pre-installed driver with the latest distro's and a pre-installed (or sufficiently licenced so the code could be copied verbatim here safely).

The drv/spi in this repo is written to easily allow this switch, spi.h provides a generic SPI interface, and spis.c is the software driver. spih.c could easily be the hardware driver that implements the identical interface, providing that the code fits the MIT licence and can be provided verbatim in this repo.

You could easily prove if a hardware SPI driver solves the issue by doing a quick hack and sitting the BCM SPI driver or an ioctl driver under the spi.h interface (call it spih.c) and see if your turnaround time improves.

I'd hazard a guess that polling isn't much better as the FIFO size read is only a couple of bytes, But getting the whole payload in would take longer as it is a few 10's of bytes (but interestingly, once it is in the FIFO you should be able to shift it out at your leisure, which suggests the poll cycle IS instrumental in any latecy you are seeing).

Myself I would do a quick experiment comparing both soft and hard approaches, toggle a GPIO around the poll window in each and measure it. If the performance significantly improves and improves the probability of hitting the receive window, it's worth properly integrating the BCM SPI driver under spi.h and feel free to send a PR if that works without breaking any of the other devices (doubtful, but we'd really have to re-test all devices again to make sure).

Thanks

[whaleygeek]

I have added a message in setup_tool.py and also a note in the README that say to turn off hardware SPI.

I have a separate issue open regarding introducing the SPI hardware driver: #120

I also have a separate issue open regarding moving to a scheduled driver rather than a blocking driver, which would probably have more of an impact on the eTRV support than the hardware driver would: #9

So, I'm closing this issue, as it is already described in other issues.