[Ovmsdev] PSRAM fix in esp-idf release v3.3
dexter at expeedo.de
Wed Jul 15 14:07:07 HKT 2020
Yes, differences on the test branches are minor, also in esp-idf.
But we probably also need to pull in the latest changes on the esp-idf
3.3 branch, which may be some more work.
I'll fetch the current toolchain version and check what is needed.
Am 15.07.20 um 04:13 schrieb Mark Webb-Johnson:
> Finally… Crazy that this took so long.
> We have a GetOVMSHardware() in ovms_version.cpp that picks up
> the esp_chip_info_t structure and has chip.revision (documented as
> "chip revision number”). That is stored in metric m.hardware. My bench
> unit is showing rev=ESP32/1. I checked a bunch of recent cars
> connected to api.openvehicles.com <http://api.openvehicles.com>, but
> all showed the same. So not sure if the v3 silicon is not reported in
> that chip.revision, if we are just using existing stocks, or an IDF
> update is required to pickup the new silicon version number. The v3
> seems fairly recent (March 2020?) and I don’t see a v2 listed. Anyway,
> I’ve just yesterday received a new batch of modules so will check
> those to see if it shows up.
> What do we need to do to switch to this? Presumably I turn off
> auto-build of the firmware on api.openvehicles.com
> <http://api.openvehicles.com>, you merge your SPIRAM branch to master,
> we tell everyone to download the new toolchain, then we switch both
> our edge builds back to master branch with new toolchain?
> Apart from the CONFIG_SPIRAM_SUPPORT 2MB workaround, I can’t see any
> significant differences between remotes/origin/spiram-fix-test and
> master? Is the only difference the ovms_websockethandler.cpp change to
> std::string (vs extram::string)?
> Regards, Mark.
>> On 15 Jul 2020, at 2:11 AM, Michael Balzer <dexter at expeedo.de
>> <mailto:dexter at expeedo.de>> wrote:
>> it seems the fix has finally arrived in the official release 3.3 branch:
>>> In the v3 silicon, the issue has been fixed, and the workaround is
>>> no longer required.
>> I guess that means from some manufacturing point on we should provide
>> two builds, one for the older hardware and one for the modules with
>> v3 chips, as the fix definitely has a performance impact.
>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OvmsDev