UART pins validation and dynamic alternative function recognition

[rusefillc]

At the moment EFI_CONSOLE_AF and TS_SERIAL_AF are hard-coded

// todo: this should be detected automatically based on pin selection
#define EFI_CONSOLE_AF 7

// todo: this should be detected automatically based on pin selection
#define TS_SERIAL_AF 7

This magic '7' does not work for all pins for instance see https://www.rusefi.com/forum/viewtopic.php?f=19&t=2208 drama
We need runtime dictionary lookup of AF based on pin.

Another point: at the moment we do not validate is specified pins are correct. Auto-detect of alternative function would probably have effect of allowing validation to happen.

[rusefillc]

well, maybe not even lookup but at least compilation options

same as TS_PRIMARY_UART is hard-coded at the moment and exposed to build scripts

[mck1117]

I think you meant to link this forum thread: https://rusefi.com/forum/viewtopic.php?f=13&t=2206

[mck1117]

the problem is that TS_PRIMARY_UART is not set for nb1, so of course serial doesn't work

[rusefillc]

the part of where I gave up is

# Disable serial ports on this board as UART3 causes a DMA conflict with the SD card
DDEFS += -DTS_NO_PRIMARY -DTS_NO_SECONDARY

[mck1117]

PD5/6 are in fact USART2, which has no conflict with other hw on this board

[mck1117]

usart 1/2/3 are always AF7
usart 4/5/6 are always AF8

[mck1117]

IMO the solution is that we should simply not allow users to pick serial pins - just enable the labeled serial pins on our boards, and be done.

[rusefillc]

the dream is total flexibility right?

we only need one hard-coded channel to make sure we can communicate with FW

[mck1117]

the dream is total flexibility right?

Is it? Why do we need flexibility here? We know where the pins are at manufacture time, just like how we hard code the knock config, etc.

[mck1117]

"full flexibility" for serial ports just seems like unnecessary complexity to me.