[Ovmsdev] CAN-3 broken again?
mark at webb-johnson.net
Fri Jan 12 09:43:44 HKT 2018
I think the naming PRO (protocols - wifi & bluetooth) and APP (application code) reflect the original intention.
As you say, it seems that Espressif have ironed out the bugs and don’t care so much now. That’s good to know.
> On 11 Jan 2018, at 8:21 PM, Michael Balzer <dexter at expeedo.de> wrote:
> 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:
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
More information about the OvmsDev