Handle unexpected changes to SPI bus

[jcapona]

Status	Ticket/Issue
Ready/Hold	Ticket

Main changes

This PR implements a workaround for the bug that changes the SPI bus in the hub of a pi-top[4] by making sure that the only valid way to change the SPI bus used by the OLED is through pi-topd, rolling back any changes to it if done any other way.

Basically:

• On initialization, the SPI bus value, read from the hub, is stored in the app internal state.
• Whenever there's a request to pi-topd asking to update the SPI bus it updates the internal state.
• On initialization, a thread runs in the background continuously reading the OLED registers from the hub. If this value differs from the one in the internal state of the app, it will consider that it's an unexpected change, and will write the value set in state into the hub.

Screenshots (feature, test output, profiling, dev tools etc)

N/A

Other notes (e.g. implementation quirks, edge cases, questions / issues)

-

Manual testing tips

To reproduce the bug, we can write values directly into the hub using the SDK.

Steps:

• Install artifacts
• Restart pi-topd. Run sudo systemctl restart pi-topd.
• Read the current SPI bus. Run pi-top oled spi.
• Force the OLED to use SPI bus 1. Run pi-top oled spi 1.
• Confirm the change was applied: pi-top oled spi should return 1
• Change the SPI bus by writing to the hub. In a python interpreter, run:

  
  from pitop.common.i2c_device import I2CDevice

i2c_device = I2CDevice("/dev/i2c-1", 0x11) i2c_device.set_delays(0.001, 0.001) i2c_device.connect()

OLED uses SPI bus 0

i2c_device.write_byte(0x14, 0b101)

- Check the SPI bus again using the CLI: `pi-top oled spi` should return `1`, since writing to the register directly is not a valid way to set the SPI bus.

#### Tag anyone who definitely needs to review or help
-