[Ovmsdev] CAN-3 broken again?

[Mark Webb-Johnson]

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.

Regards, Mark

> On 11 Jan 2018, at 8:21 PM, Michael Balzer <dexter at expeedo.de> wrote:
> 
> 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
> 
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev