How to design a bus driver layer for multiple (different) devices and buses.

[Atam3r]

Hello!

My team and I are developing flight software using F Prime and Zephyr. We are quite new to F Prime, and while working through the documentation and looking at our own hardware, some questions came up. Mainly, how should a bus driver handle different devices on the same bus and multiple buses of the same type on a single MCU?

Consider the following example (schematic below): The MCU has two different SPI buses. SPI1 has one device attached, and SPI2 has two devices attached. As far as we have looked into the application-manager-driver pattern, it is not immediately clear to us how to structure the bus driver layer in this scenario.
We also looked into different existing SPI drivers (Linux, Zephyr) and found that they have a port number (portNum) argument. However, it seems unused (except in a couple of asserts)?

I would really appreciate some insight into the following questions:

• Should there be two instances of the SPI bus driver, one for each SPI bus? In such a case, how should the device on a single SPI bus be chosen? Using portNum?
• Should we utilise portNum for selecting something? Or should we add our own arguments somehow? I know that the I2C driver has an address as an argument, for example.

Currently feeling like I am missing a piece of this puzzle somewhere.

[celskeggs]

Each instance of the Linux SPI driver is for a single device on a single bus, not all devices on a single bus. In your example topology, you would use three instances of LinuxSpiDriver -- portNum would always be 0.

The VA41630's SpiController is an example of doing it the other way: Each instance represents one SPI bus, and there are multiple ports so you can attach multiple devices. So in your example topology, if you used something structured like this project, you would use two instances of SpiController.

portNum is present on all F Prime ports, but it is always 0 except when a port array is used. Note that the portNum on an output port function is not directly passed to the portNum on the corresponding input port function; this is because different port instances can be connected to different target components (or connected out-of-order to ports on those components). You can think of portNum as corresponding to the topology.