In many cases, the SPI bus is not just connected to a single device. For example, some displays have both the display and a font chip on the same bus. So taking full ownership of the SPI bus object isn't always practical.
It's a lot easier to have the SPI bus managed by a different management struct, and then create a temporary display interface on demand. That way sharing an SPI bus is trivially possible:
let mut spi_manager = SPIManager::new(spi_bus, ...pins...);
let display_bus: SPIInterface = spi_manager.get_display_bus();
do_display_things(display_bus);
// Drop display_bus to re-use SPI for other things
Sadly, this doesn't work with the current API of this crate, as the bus always takes full ownership.
While this issue is specifically about SPI, the other busses might face similar issues in the future (especially I2C, which is a strongly shared bus), and the proposed SPI solution might be apply to them as well.
In many cases, the SPI bus is not just connected to a single device. For example, some displays have both the display and a font chip on the same bus. So taking full ownership of the SPI bus object isn't always practical.
It's a lot easier to have the SPI bus managed by a different management struct, and then create a temporary display interface on demand. That way sharing an SPI bus is trivially possible:
Sadly, this doesn't work with the current API of this crate, as the bus always takes full ownership.
The most elegant solution would be to provide a borrowed bus object. I submitted a pull request for such an object: https://github.com/therealprof/display-interface/pull/33
The problem first came up in this issue of the
st7565
display driver: https://github.com/Finomnis/st7565/issues/8While this issue is specifically about SPI, the other busses might face similar issues in the future (especially I2C, which is a strongly shared bus), and the proposed SPI solution might be apply to them as well.