Mark, Am 11.01.2018 um 01:35 schrieb Mark Webb-Johnson:
Every other task is created on core #1. Supposedly our App runs on core #1, and wifi/bluetooth run on core #0. Why is can::can CAN_rxtask running on core #0?
See my post "can1 TX performance solved" (Dec 31):
Turned out this was no hardware issue but a scheduler problem: the CAN rx and vehicle rx tasks were not scheduled often & fast enough to consistently keep up with the 10 ms period.
After assigning the CAN RX task to core 0 and raising the vehicle task priority to 10, there are no more TX overflows, and my charge control override works perfectly.
It's just a first attempt to optimize core & priority assignment to better utilize the dual core system. We sure can do some more optimization on this. Core #0 is called the "protocol core" by Espressif, from my understanding it's the preferred core for communication processes & driver tasks. The cores are identical, we can also use another assignment scheme: https://dl.espressif.com/doc/esp-idf/latest/api-guides/freertos-smp.html Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26