ChibiOS: UARTDriver: init dma buffer #30023
Conversation
|
Thanks for the contribution. Are you seeing an issue caused by this? ArduPilot zeros memory on allocation so member variables are assumed initialized. |
|
I was finding that the driver was always using DMA for receiving data, even when I set the |
|
What board and compiler? |
|
CubeOrangePlus, arm-none-eabi-gcc (GNU Arm Embedded Toolchain 10-2020-q4-major) 10.2.1 20201103 (release) |
| @@ -107,6 +107,9 @@ _baudrate(57600) | |||
| { | |||
| osalDbgAssert(serial_num < UART_MAX_DRIVERS, "too many SERIALn drivers"); | |||
| serial_drivers[serial_num] = this; | |||
| rx_bounce_buf[0] = nullptr; | |||
There was a problem hiding this comment.
Please remove these, they are not necessary
There was a problem hiding this comment.
I believe it is necessary for correctly handling the case when the user intends to use DMA. Without it, rx_bounce_buf[0] could be non-null. This if case would fail and therefor the malloc_type would be skipped. Thats def bad.
There was a problem hiding this comment.
Unless someone is creating one of these UARTDriver objects on the stack, all member fields are guaranteed zero in the constructor. We override new to get that effect.
If someone is creating one of these on the stack... well...
| @@ -107,6 +107,9 @@ _baudrate(57600) | |||
| { | |||
| osalDbgAssert(serial_num < UART_MAX_DRIVERS, "too many SERIALn drivers"); | |||
| serial_drivers[serial_num] = this; | |||
| rx_bounce_buf[0] = nullptr; | |||
There was a problem hiding this comment.
Unless someone is creating one of these UARTDriver objects on the stack, all member fields are guaranteed zero in the constructor. We override new to get that effect.
If someone is creating one of these on the stack... well...
|
@peterbarker ok removed now |
this change initializes the UART DMA buffers properly and also respects the OPTION_NODMA_RX and OPTION_NODMA_TX options.