[Ovmsdev] CAN-3 broken again?

[Mark Webb-Johnson]

The core #0 vs #1 issue was just following Espressif’s original recommendations. I thought that was how they liked it to be done?

We’re close now. Very close. RAM is the biggest issue, but I think with a bunch of stuff moved to SPIRAM, that will give us a lot of headroom. I’m working on Steve to optimise that over the next few days. I’ve got it running on my desk at least.

For beta test / initial release, I think we can just do it like we did with OVMS v1. Clearly say this is pre-beta, intended for developers / technical people only, and make sure people know how to update firmware. Once the hardware and SDK are stable, I think things will get easier. We can just concentrate on the last few reliability issues.

Regards, Mark.

> On 11 Jan 2018, at 2:20 PM, Greg D. <gregd2350 at gmail.com> wrote:
> 
> WiFi running on core #0 would explain the impact of wifi operations on
> the receipt of CAN frames.  But, with the car interfaces running on core
> #1, core #0 might actually have more bandwidth under normal
> circumstances, as I'm assuming the modem is pretty light loading due to
> the limited data rate.
> 
> {shrug}  Need more real-world experience for optimizing this kind of
> stuff.  Are we going to have a semi-formalized "beta" testing period for
> the first sets of production units per car?  What will the feedback
> channel be?
> 
> Greg
> 
> 
> Mark Webb-Johnson wrote:
>> 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?
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev