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@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev