Communication block instantiation

[PontusO]

Hi,
Is there a specific reason for having the instance definitions of hw blocks such as UART, I2C and SPI in their "drivers" ?
The reason for me asking is that I am working on implementing hardware flow support for the UARTs and having the definition in the driver instead of in the board specific part makes it difficult to work with. Having it in the board specific part would allow each board to be able to define the configuration of a specific hw block.

[earlephilhower]

I'm not quite sure I understand the question or issue, but if you're talking about actually instantiating SerialX or WireX like in

arduino-pico/cores/rp2040/SerialUART.cpp

Lines 194 to 195 in 3585c58

	SerialUART Serial1(uart0, PIN_SERIAL1_TX, PIN_SERIAL1_RX);
	SerialUART Serial2(uart1, PIN_SERIAL2_TX, PIN_SERIAL2_RX);

that's actually the normal Arduino way.

What I've seen done in cores that have a wide variety of HW support is to include #defines in the board.h files which can then enable/disable the actual instantiation in the object.cpp file. Arduino's MBED RP2040 core uses something like NUM_SERIAL to control this, but there are other ways, too.

[PontusO]

Exactly, and Adafruit for instance has moved the instantiation out to the board files in their SAMD21 support package. The idea behind this is that when someone develops a new board using hw resources the board definition files are responsible for setting the peripherals up according to the internal pin mapping and/or functionality of the hw block. For instance, with the hw_flow I am fiddling with now it would look something like this for our Challenger board with an LTE modem:

SerialUART Serial1(uart0, PIN_SERIAL1_TX, PIN_SERIAL1_RX);
SerialUART Serial2(uart1, PIN_SERIAL2_TX, PIN_SERIAL2_RX, PIN_SERIAL2_RTS, PIN_SERIAL2_CTS);

This is just an example, you could apply this to the SPI or any HW block that is being used by the board so that the end user does not have to worry about how a particular function is connected on the board.