[Ovmsdev] SIMCOM UART interrupt issue & optimization

[Michael Balzer]

Everyone,

I've pushed another optimization for the SIMCOM component that reduces the UART hardware
FIFO overflows (https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/274)
to nearly zero by changing core associations.

TL;DR:

  * you also should apply the sdkconfig changes from the commit
  * we need to optimize interrupt latency


Analyzing our current core usage I found we've been running nearly all interrupt handlers on
core #1. That's because interrupts are bound to the core that allocates them, and after system
init, the housekeeper created all peripheral components on core #1.

This has been our interrupt allocation up to now:

Task           Run#  Lvl  ISR#  Usage                    Source
----------------------------------------------------------------------------------------
-              0     1    0     RTC Core                 ETS_RTC_CORE_INTR_SOURCE
esp_timer      0     1    0     RTOS esp_timer           ETS_TIMER2_INTR_SOURCE
ipc0           0     1    0     RTOS Scheduler Core0     ETS_FROM_CPU_INTR0_SOURCE
ipc1           1     1    1     RTOS Scheduler Core1     ETS_FROM_CPU_INTR1_SOURCE
main           0     1    0     RTOS Watchdog            ETS_TG0_WDT_LEVEL_INTR_SOURCE
OVMS Events    1     1    1     Peripherals (GPIO ISR)   ETS_GPIO_INTR_SOURCE
OVMS Events    1     1    1     MAX7317 (spi_nodma)      ETS_SPI3_INTR_SOURCE
OVMS Events    1     1    1     ESP32 CAN                ETS_CAN_INTR_SOURCE
OVMS Events    1     1    1     SIMCOM UART              ETS_UART1_INTR_SOURCE
OVMS Events    1     1    1     USB console (UART)       ETS_UART0_INTR_SOURCE
OVMS Events    1     1    1     SD card                  ETS_SDIO_HOST_INTR_SOURCE
----------------------------------------------------------------------------------------

I had some advances on the FIFO overflows by allocating a level 3 interrupt for the SIMCOM UART,
but not much. I then tried moving the SIMCOM interrupt handler to core #0, and that immediately
reduced the overflows drastically -- most of the time.

I read through the Espressif forums and issues on interrupt latency optimization and found a
precious hint here: https://www.esp32.com/viewtopic.php?t=11462#p46437

/"Finally, by default the LWIP task is allowed to run on either core, and will sometimes take a//
//spinlock which requires disabling interrupts. Try pinning this task to CPU 0, only"/

I did so, and the FIFO overflows disappeared completely on my bench. In my car there still
are some, but very few. I also tested pinning LWIP to core #1, that also worked and may be
an alternative.

I then searched for more config candidates affecting interrupt performance and also disabled
the interrupt backtrace feature. That saves just 4 instructions on interrupt entry, so has
little effect and can be re-enabled in case we need it.

I've reduced the UART IRQ level to 2 again as a support for my second finding regarding
the CAN controller, will describe that in the next post.

Regards,
Michael

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20191031/500ffc8a/attachment-0001.html>