Add configurable shared SPI bus pins

[Feather-P]

PR Summary

This PR adds configurable pins for the shared SPI bus:

• PIN_IMU_SCK
• PIN_IMU_MISO
• PIN_IMU_MOSI

The shared SPI bus configuration is integrated into:

• board-defaults.schema.json
• board-defaults.json
• scripts/preprocessor.py
• DirectSPIInterface

Chip select remains configured separately for each sensor through PinInterface.

Platform behavior

• On ESP32, configured pins are passed to SPIClass::begin(sck, miso, mosi).
• On ESP8266, the supported pin set is selected through SPIClass::pins().
• If SPI bus pins are not configured, the existing parameterless SPI.begin() behavior is preserved.
• ESP8266 hardware CS is disabled after initialization because CS is managed separately for each sensor.

Testing

Tested locally with:

• ESP32-C3 and LSM6DSV over SPI
• Custom SCK, MISO and MOSI pins
• ESP8266 build compatibility (Not tested on real chips)

LLM usage

DeepSeek and ChatGPT were used only for debugging assistance and translating commit messages.

Related to #537

[unlogisch04]

With the current board-defaults.json the server crashes when selecting a board different than "BOARD_SLIMEVR_V1_2"

The Flasher generates the Interface over that board-defaults.json

I used a modified board-defaults.json to add the SPI everywhere so the flasher interfaces does not crash for the screenshot.
As you see in the screenshot the SPI settings seem quit a bit out of touch.

So either add it to the SPI_IMU (SCK MISO MOSI)

Best implementation would be that it is BUS -> I2C/SPI -> I2C_IMU/SPI_IMU
But i will not decide here.

I did not test any functions of the firmware.

[Feather-P]

Yeah, I agree. Sorry for not checking how the Server flasher handles the board configuration. I normally flash boards on PlatformIO, completely overlooked the flasher :O
I think the bus configuration could be structured roughly like this:

BUS:

• protocol: I2C or SPI

For I2C:

• SDA
• SCL
• I2C_IMUs
  • IMU type
  • INT pin
  • address
  • rotation

For SPI:

• SCK
• MISO
• MOSI
• SPI_IMUs
  • IMU type
  • INT pin
  • CS pin
  • rotation

The selected bus protocol would determine which bus fields and IMU schema are displayed, so the protocol would not need to be selected again for every IMU.

[Feather-P]

I have implemented the schema and preprocessor changes for BUS -> I2C/SPI -> I2C_IMU/SPI_IMU

But... it seems that some parts of the frontend may need to be adjusted for this new schema.

Everything looks okay when the window is narrower:

When I make the window slightly wider:

The whole layout gets compressed.

It seems that, at this responsive breakpoint, the Bus group is rendered as a two-column grid, while the nested IMU list is also rendered as a two-column grid. As a result, the whole IMU list only occupies the left cell of the parent grid and is then divided into two columns again inside that cell.

Another problem occurs when trying to add a second Bus. The frontend crashes with:

Uncaught Error: Expected array data but received non-array
    at handleArrayNode (firmware-tool.ts:460:11)
    at handleNode (firmware-tool.ts:654:14)
    at handleDiscriminatedOneOf (firmware-tool.ts:427:12)
    at handleObjectNode (firmware-tool.ts:317:12)
    at handleNode (firmware-tool.ts:650:14)

When a new Bus is added, the frontend only initializes:

{
  "protocol": "I2C"
}

However, the selected I2C_BUS schema also contains an imus array. The new object does not initialize this property.

This seems like it could be handled in a separate PR for the Server repository, although it is directly related to the schema changes in this PR.