<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""></div><blockquote type="cite" class=""><div text="#000000" bgcolor="#FFFFFF" class="">OK. How about using separate branches for release and development. That way we can cherry-pick important fixes early into the release branch if necessary.</div></blockquote><div class=""><br class=""></div>Yes, probably a good idea. I’ll do it just before the first release.<div class=""><br class=""></div><div class="">Note that we also have the menuconfig CONFIG_OVMS_VERSION_TAG (default: “main”). I plan to use that for OTA to be able to switch to different versions and different release priorities. So, we can have an OTA version X release for beta cars, and OTA version Y for everybody else.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div text="#000000" bgcolor="#FFFFFF" class="">With automatic start of the vehicle module, wifi, modem & server connections, I think we need a rescue scheme. I.e. if the boot crashes, the reboot should automatically be done without any auto start -- otherwise the only option to get back to a working module would be to erase the config. I'll have a look at that.</div></blockquote><div class=""><br class=""></div>When looking at the deep sleep stuff, I found there is a way to tag a global variable as ‘rtc’. That should survive a deep sleep (or reboot). For example:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><a href="https://github.com/espressif/esp-idf/blob/3ede9f011b50999b0560683f9419538c066dd09e/examples/system/deep_sleep/main/deep_sleep_example_main.c" class="">https://github.com/espressif/esp-idf/blob/3ede9f011b50999b0560683f9419538c066dd09e/examples/system/deep_sleep/main/deep_sleep_example_main.c</a></div><div class=""><br class=""></div><div class="">static RTC_DATA_ATTR struct timeval sleep_enter_time;</div></blockquote><div class=""><div><br class=""></div><div>I did like the feature we had in v2 that recorded the number of resets, as well as the cause of the last reset. Perhaps we can do the same for v3 and store in a metric on boot?</div><div><br class=""></div><div>Presumably we can set a flag during startup (in rtc ram) and clear it once the startup has been completed. Then when booting if that flag is set, don’t do this auto stuff. That should give us the rescue scheme.</div><div><br class=""></div><div>I suggest to put this all in one RTC_DATA_ATTR structure in ovms.h (and ovms.cpp), then do the automation either in housekeeping or in a new ovms_auto.{h,cpp} component.</div><div><br class=""></div><div>Should we create a ‘auto’ config area to store all this? Such as auto/vehicletype, etc...</div><div><br class=""></div><div><blockquote type="cite" class=""><div text="#000000" bgcolor="#FFFFFF" class="">Btw, how about activating wifi AP mode as the factory default, i.e. with SSID "OVMS" and password derived from the MAC or ICCID? That way a new user can power the module on and directly connect to the OVMS AP and do the initial configuration with his/her browser.</div></blockquote><br class=""></div><div>Yes, that makes good sense. Again, it can go in ‘auto’ section, wifiap or something like that. Can default to on, and be explicitly disabled by config later.</div><div><br class=""></div><div>Regarding the password, not all modules will have ICCID. The MAC address is not externally visible. Maybe just have the access point named OVMS.<last-bit-of-mac> and password OVMS? Then provide a facility in the web UI to be able to change that password?</div><div><br class=""></div><div>P.S. Your work on the web UI is incredible. Really neat and powerful. Very impressed.</div><div><br class=""></div><div>Regards, Mark.</div><div><br class=""><blockquote type="cite" class=""><div class="">On 22 Feb 2018, at 4:21 AM, Michael Balzer <<a href="mailto:dexter@expeedo.de" class="">dexter@expeedo.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
<br class="">
<div class="moz-cite-prefix">Am 21.02.2018 um 03:05 schrieb Mark
Webb-Johnson:<br class="">
</div>
<blockquote type="cite" cite="mid:36BB0DF8-40E9-4A5F-9EA4-A19F323C0EF6@webb-johnson.net" class="">On
the firmware side, we need to move to a production style release
cycle, and I will need to provide the first ‘factory’ firmware
around the second week of March. Accordingly, I’m setting up some
clean build environments and OTA release repositories (so I can
cleanly build v3.0 and v3.1 firmware and have it available for OTA
download).
<div class=""><br class="">
</div>
<div class="">I have created a changes.txt log file in the root of
the project. I would appreciate it if those with commit access
to master could update that file when they merge/commit changes
to the project. The top of the file will contain an entry for
the ‘next’ version, so the change text just needs to be added
below that. When the version is ready to go, I will update
changes.txt with the date and name, commit it, tag it, and then
build OTA versions for release. Please only use tags for OTA
versions - or just don’t tag at all for the moment and let me
maintain this.</div>
</blockquote>
<br class="">
OK. How about using separate branches for release and development.
That way we can cherry-pick important fixes early into the release
branch if necessary.<br class="">
<br class="">
<blockquote type="cite" cite="mid:36BB0DF8-40E9-4A5F-9EA4-A19F323C0EF6@webb-johnson.net" class="">
<div class="">The last list of things I have for this build are:</div>
<div class=""><br class="">
</div>
<div class="">
<ol class="MailOutline">
<li class="">OTA via HTTP. SD CARD firmware updates seems to
work fine today, as does serial flashing. I’ve still got to
make the changes to HTTP firmware updates to use mongoose
and support the new ESP IDF v2.1+ firmware arrangement of
putting the checksum at the end of the firmware file.<br class="">
<br class="">
</li>
<li class="">We need some simple high-level configs for
auto-starting things. Stuff like vehicle type, whether the
v2 server should auto-run, etc. Make it simpler for people
to configure, without having to use scripts. This can be
mapped to v2 protocol parameters/features.<br class="">
</li>
</ol>
</div>
</blockquote>
<br class="">
Config for vehicle type is there (added that for the web UI), but I
haven't done the auto start on this.<br class="">
<br class="">
With automatic start of the vehicle module, wifi, modem & server
connections, I think we need a rescue scheme. I.e. if the boot
crashes, the reboot should automatically be done without any auto
start -- otherwise the only option to get back to a working module
would be to erase the config. I'll have a look at that.<br class="">
<br class="">
Btw, how about activating wifi AP mode as the factory default, i.e.
with SSID "OVMS" and password derived from the MAC or ICCID? That
way a new user can power the module on and directly connect to the
OVMS AP and do the initial configuration with his/her browser.<br class="">
<br class="">
Regards,<br class="">
Michael<br class="">
<br class="">
<br class="">
<blockquote type="cite" cite="mid:36BB0DF8-40E9-4A5F-9EA4-A19F323C0EF6@webb-johnson.net" class="">
<div class="">
<ol class="MailOutline">
<li class=""><br class="">
</li>
<li class="">SPI RAM support and stability for v3.1 hardware
(as well as compatibility with v3.0 hardware).<br class="">
<br class="">
</li>
<li class="">Finalise the partition sizes. I think we can
squeeze a bit more (maybe 3x 5MB firmwares, plus 512KB
store?).<br class="">
<br class="">
</li>
<li class="">End-User Documentation.<br class="">
<br class="">
</li>
<li class="">Real-world stability (in cars).</li>
</ol>
<div class=""><br class="">
</div>
</div>
<div class="">My concern is to have a relatively stable firmware
that is usable for technically capable end-users in their cars,
but also to have a way for them to simply update the firmware to
keep pace with the fast release cycle we expect (at least in the
coming months).</div>
<div class=""><br class="">
</div>
<div class="">Anything I’ve missed?</div>
<div class=""><br class="">
</div>
<div class="">Regards, Mark.</div>
</blockquote>
<br class="">
<pre class="moz-signature" cols="160">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</div>
_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.teslaclub.hk" class="">OvmsDev@lists.teslaclub.hk</a><br class="">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev<br class=""></div></blockquote></div><br class=""></div></body></html>