<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
Everyone,<br>
<br>
I've pushed another optimization for the SIMCOM component that
reduces the UART hardware<br>
FIFO overflows
(<a class="moz-txt-link-freetext" href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/274">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/274</a>)<br>
to nearly zero by changing core associations.<br>
<br>
TL;DR:<br>
<ul>
<li>you also should apply the sdkconfig changes from the commit</li>
<li>we need to optimize interrupt latency</li>
</ul>
<br>
Analyzing our current core usage I found we've been running nearly
all interrupt handlers on<br>
core #1. That's because interrupts are bound to the core that
allocates them, and after system<br>
init, the housekeeper created all peripheral components on core #1.<br>
<br>
This has been our interrupt allocation up to now:<br>
<br>
<tt>Task Run# Lvl ISR# Usage Source</tt><tt><br>
</tt><tt>----------------------------------------------------------------------------------------</tt><tt><br>
</tt><tt>- 0 1 0 RTC Core
ETS_RTC_CORE_INTR_SOURCE</tt><tt><br>
</tt><tt>esp_timer 0 1 0 RTOS esp_timer
ETS_TIMER2_INTR_SOURCE</tt><tt><br>
</tt><tt>ipc0 0 1 0 RTOS Scheduler Core0
ETS_FROM_CPU_INTR0_SOURCE</tt><tt><br>
</tt><tt>ipc1 1 1 1 RTOS Scheduler Core1
ETS_FROM_CPU_INTR1_SOURCE</tt><tt><br>
</tt><tt>main 0 1 0 RTOS Watchdog
ETS_TG0_WDT_LEVEL_INTR_SOURCE</tt><tt><br>
</tt><tt>OVMS Events 1 1 1 Peripherals (GPIO ISR)
ETS_GPIO_INTR_SOURCE</tt><tt><br>
</tt><tt>OVMS Events 1 1 1 MAX7317 (spi_nodma)
ETS_SPI3_INTR_SOURCE</tt><tt><br>
</tt><tt>OVMS Events 1 1 1 ESP32 CAN
ETS_CAN_INTR_SOURCE</tt><tt><br>
</tt><tt>OVMS Events 1 1 1 SIMCOM UART
ETS_UART1_INTR_SOURCE</tt><tt><br>
</tt><tt>OVMS Events 1 1 1 USB console (UART)
ETS_UART0_INTR_SOURCE</tt><tt><br>
</tt><tt>OVMS Events 1 1 1 SD card
ETS_SDIO_HOST_INTR_SOURCE</tt><tt><br>
</tt><tt>----------------------------------------------------------------------------------------</tt><br>
<br>
I had some advances on the FIFO overflows by allocating a level 3
interrupt for the SIMCOM UART,<br>
but not much. I then tried moving the SIMCOM interrupt handler to
core #0, and that immediately<br>
reduced the overflows drastically -- most of the time.<br>
<br>
I read through the Espressif forums and issues on interrupt latency
optimization and found a<br>
precious hint here:
<a class="moz-txt-link-freetext" href="https://www.esp32.com/viewtopic.php?t=11462#p46437">https://www.esp32.com/viewtopic.php?t=11462#p46437</a><br>
<br>
<i>"Finally, by default the LWIP task is allowed to run on either
core, and will sometimes take a</i><i><br>
</i><i>spinlock which requires disabling interrupts. Try pinning
this task to CPU 0, only"</i><br>
<br>
I did so, and the FIFO overflows disappeared completely on my bench.
In my car there still<br>
are some, but very few. I also tested pinning LWIP to core #1, that
also worked and may be<br>
an alternative.<br>
<br>
I then searched for more config candidates affecting interrupt
performance and also disabled<br>
the interrupt backtrace feature. That saves just 4 instructions on
interrupt entry, so has<br>
little effect and can be re-enabled in case we need it.<br>
<br>
I've reduced the UART IRQ level to 2 again as a support for my
second finding regarding<br>
the CAN controller, will describe that in the next post.<br>
<br>
Regards,<br>
Michael<br>
<br>
<pre class="moz-signature" cols="160">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</body>
</html>