AP_HAL_ESP32: UART driver tweaks and making closer in shape to chibios

[srmainwaring]

Break out 9e0ada6 from @davidbuzz's larger PR #28514 and apply fixes.

Testing

Tested on esp32empty. The console print in UARTDriver::_begin is suppressed because the message is displayed repeatedly for UART1 = SERIAL3 (default params set SERIAL3_PROTOCOL = 5 (GPS), which is not available).

[tpwrules]

I don't get this, nobody ever uses uart_drivers?

I'm also realizing now that the ESP32 HAL has the serial ports mis-numbered, we need to kill that before it becomes a whole thing like on STM32...

[srmainwaring]

Change name to serial_drivers to align with chibiOS UARTDriver.

Changed in: 169e164

[srmainwaring]

I don't get this, nobody ever uses uart_drivers?

I think the aim here is to begin aligning the esp32 UART driver with the one for chibiOS. In the latter case the equivalent of uart_drivers is called serial_drivers (so the name should change in esp32 if it's kept), and it is used to retrieve the driver from the uart_rx_thread.

I'm also realizing now that the ESP32 HAL has the serial ports mis-numbered, we need to kill that before it becomes a whole thing like on STM32...

This being UART1 = SERIAL3 etc? Agree it's confusing, but having the mapping between UART# and SERIAL# different on esp32 and stm32 may be worse.

[tpwrules]

I don't get this, nobody ever uses uart_drivers?

I think the aim here is to begin aligning the esp32 UART driver with the one for chibiOS. In the latter case the equivalent of uart_drivers is called serial_drivers (so the name should change in esp32 if it's kept), and it is used to retrieve the driver from the uart_rx_thread.

Okay, let's add that table in whichever PR we add a uart_rx_thread (if we ever do it). For now we don't use it so adding it just introduces confusion IMO.

I'm also realizing now that the ESP32 HAL has the serial ports mis-numbered, we need to kill that before it becomes a whole thing like on STM32...

This being UART1 = SERIAL3 etc? Agree it's confusing, but having the mapping between UART# and SERIAL# different on esp32 and stm32 may be worse.

I did a big PR last year (#25589) to fix all of this up for ChibiOS and other HALs, I will review my notes and decide what we need to do for ESP32. I had noted that I needed to come back to it but I didn't have hardware at the time. That PR is also how a lot of the guts of the ChibiOS driver got renamed to serial from uart, like is being proposed here.

I don't think this PR gets us anything at the moment. The semaphore in vprintf might be smart but the new comment suggests it might not be the right thing anyway?

[davidbuzz]

re: "ESP32 HAL has the serial ports mis-numbered, we need to kill that before it becomes a whole thing like on STM32."

• we're never gonna be able to be aligned with chibios in the numbering, AND we have additional "virtual" uart/s for TCP and UDP that dont attach to physical uart hardware in the same way as the others, so my logic was simply to try to init the real-hardware at indexes.. console(0), and (1), and (2) are for mavlink or gps, and and the virtual tcp and udp "uarts" come after the real ones.

re esp32 variable/function/class naming conventions...

• always try to be as consistent in the layout/ordering/structure/classes/files/variables with chibios as you can if u have no other reason. If chibios "has it", name it the same and put it in the same place. We want to be able to continue to diff/s between these HALs moving forward as easily as possible. :-)
• s/chibios/esp32/ s/ChibiOS/ESP32/ remove all mentions of stm32 that you can, etc.
• sometimes stuff gets copied-over-from the Chibios HAL and then commented out as a way of noting that its not-implemented in the ESP32 hal, and its absence is not necessarily a mistake, rather perhaps a todo, or an anti-todo.

the specific's of this PR is/was about the uarts becoming a "list" and having an index into them, and isnt necessarily perfect by any stretch, but it was adequate at the time - if you want to cleanup/re-work/whatever thats fine too.