Am 21.02.2018 um 03:05 schrieb Mark Webb-Johnson:
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).
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.
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.
The last list of things I have for this build are:
1. 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.
2. 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.
Config for vehicle type is there (added that for the web UI), but I haven't done the auto start on this. 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. 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. Regards, Michael
1.
2. SPI RAM support and stability for v3.1 hardware (as well as compatibility with v3.0 hardware).
3. Finalise the partition sizes. I think we can squeeze a bit more (maybe 3x 5MB firmwares, plus 512KB store?).
4. End-User Documentation.
5. Real-world stability (in cars).
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).
Anything I’ve missed?
Regards, Mark.
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26