March 2023 - OvmsDev - Open Vehicles

Warning in Duktape
by Michael Geddes 09 Aug '24

09 Aug '24

There's an unused variable 'dcc' warning in the below code. It seems that the 'Perform the callback' is not being 'performed! Is this deliberate? //.ichael void DukOvmsCommandRegisterRun(int verbosity, OvmsWriter* writer, OvmsCommand* cmd, int argc, const char* const* argv) { ESP_LOGD(TAG, "DukOvmsCommandRegisterRun(%s)",cmd->GetName()); auto it = MyDuktape.m_cmdmap.find(cmd); if (it == MyDuktape.m_cmdmap.end()) { ESP_LOGE(TAG, "Command '%s' cannot be found in registry",cmd->GetName ()); return; } else { DuktapeConsoleCommand* dcc = it->second; // Perform the callback } }

3 6

Netmanager priority issue solved
by Michael Balzer 05 Jul '23

05 Jul '23

TL;DR: you need to pull my latest esp-idf changes. I've finally found & solved the strange priority changes for our netmanager task (i.e. being raised suddenly from origin 5 to 18/22): the bug was in the esp-idf posix threads mutex implementation. I had suspected the mutex priority inheritance for a while, so added a way to retrieve the internal mutex hold count for our task list. Using this I noticed the hold count would always & only raise by 2 whenever any kind of mongoose connection was closed. That lead me to checking the thread concurrency protection for mongoose mbufs, because every mongoose connection has two mbufs associated (rx & tx), each having a posix mutex. The bug was: posix mutexes were deleted after locking (taking) them. FreeRTOS mutexes must not be deleted while being taken, that breaks the priority inheritance (more precisely the disinheritance), with the visible effect being the mutex hold count not returning to zero. As a side effect, this may also solve the strange event task starvations (hope so…). I was investigating this as I suspected some busy loop in the netmanager context. With the netman running at prio 22, that would effectively block almost all other processing including the timer service. I've found & fixed one potential busy loop trigger in the netman that would have been caused by the netman task still running while all interfaces had been lost -- not sure if that could happen, but it would explain the effects. So please watch your crash debug info & report if the issue still turns up. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

5 19

Subaru Solterra
by Solterra 11 Jun '23

11 Jun '23

Any interest in adding support for Subaru Solterra?

4 9

ECU / HUD and OBD Poller response redesign
by Michael Geddes 11 Mar '23

11 Mar '23

Hi all, I have a big change set coming for the OBD Poller that has really improved what I have been able to do with the responsiveness of the HUD and should provide a framework for consolidation of custom polling designs. The aim was to: - Have a single interface to the poll list that moves the one-shot blocking polling and the default list polling behind a single interface - Have the ability to have multiple poll-lists / responders active at once. - Be able to have responders that could use any spare polling time to continually update a value without impinging on moving to the 'next poll count'. (For example speed and rpm) - Be able to have a once-off responder that is non-blocking (for example a request for the VIN which is a once-off but requires the car to be 'on' for ioniq 5). All this I have implemented and am just finalising now - doing some stability testing and going through it to make sure it does what it needs to. The bulk of ISOTP and VWTP code has been left alone, with the exception of where it used to interface back to the poll queue / once-off blocking poll. I have a class that represents a poll responder, and a class that handles a list of responders. 'Blocking' handlers are treated specially. Implemented so far is: List Poller - to handle the standard list of entries Blocking Once-Off poller - to handle PollSingleRequest Data Buffer List Poller - handles a standard list but calls back with the complete data rather than frame-by-frame. Once-Off Poller - Handles a single request (with retries) but is non-blocking. On my TODO list is a special poll responder that allows us to add user entries that would grab/interpret particular ecu addresses on the fly and place them either in metrics or a special temporary metric area. This would enable better testing of values while driving (for example, I want to know which flag is for the brake being pressed, and which one is for the brake light, and I can use the ECU to display these on a HUD without recompiling). I would appreciate any thoughts on this. I might be pushing it up as a draft soon, but the usage of it in the I5 code does depend on the sub-tick p/r so I might wait for that. //.ichael

1 0

ESP-IDF v4 / v5 - baby steps
by Ludovic LANGE 06 Mar '23

06 Mar '23

Hi list, I am interested in upgrading our codebase to a latest ESP-IDF version (preferentially v5 which has just happened end of 2022 - Happy New Year ! :-)) - mostly to be able to use some components for which a backport seems difficult (for example : https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/752 ), and as a matter of balance between stability vs latest bugfixes, security fixes, new features etc... In the past it seems that some endeavours already set the basis to make this happen (https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/263, https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/360 ). I'm now trying to revive this effort, and after some work managed to have: * OVMS codebase building under v4.x using Makefile * OVMS codebase building under v4.x using cmake / idf.py (not 100% finished, multiple vehicle_* components are missing) (/*WARNING*: some important features of OVMS have been deactivated for the moment, see end of post)/ The produced binaries seem to "work on my machine board", as they end with a "OVMS#" prompt and a few (very) basic tests look OK (to be honest, unfortunately no real tests have been done except to check that the binary does not crash during boot and a few seconds of run, checking that WiFi / web Interface is OK, sdcard is OK - but very basic) You'll find the changes here : https://github.com/llange/Open-Vehicle-Monitoring-System-3/tree/experimenta… (In the README.md, there is a short notice at the top with a few useful informations) I'm now reaching out here mostly for : * gathering feedback both around the effort (is it worth pursuing this goal ?) and the implementation (do my CMakeLists.txt look weird ? yes they do.) * having volunteers using those builds on real-world workload (which I cannot do at the moment) and finding bugs * guidance and fixes regarding the CMakeLists.txt files My next steps could be (of course, subject to feedback) : 1. Have 100% of the cmake implementation finished (all the missing vehicle_* components) -> easy (only missing time) 2. Work on the warnings (currently disabled in the builds) and try to fix as much as possible 3. Iron out all the bugs, improve the dev documentation -> need help on finding them with real-world use 4. 1st goal is to propose this result as a merge request (either as a whole, or split depending on feedback - ideally I would like to have a first (big) MR accepted quickly so that people can play with it, and deliver incremental updates as expected) 5. then work on the v5 and do the same. (Please note that my cmake skills are inexistent - so be careful when opening those files to not hurt yourself.) # The guidelines I tried to follow: * Stay compatible with our 3.3.x branch which should still compile without any issue nor loss of functionality * Keep Makefiles running for 3.3.x (and 4.x if possible) * When possible, isolate differences (between 3.x, 4.x, 5.x) by testing the versions of ESP-IDF. * Focus on 5.x (if there are impossibilities, let's make it easier to build v5.x than v4.x) * https://docs.espressif.com/projects/esp-idf/en/release-v4.4/esp32/api-refer… * https://docs.espressif.com/projects/esp-idf/en/release-v4.4/esp32/api-guide… * https://docs.espressif.com/projects/esp-idf/en/latest/esp32/migration-guide… * https://docs.espressif.com/projects/esp-idf/en/latest/esp32/migration-guide… # Missing features: In the course of this work I had to make some decisions to speed up the work - that will need to be acted upon: * I disabled the crash handler (`xt_set_error_handler_callback` and `esp_task_wdt_get_trigger_tasknames`) for the moment, we need to decide whether we "fork" ESP-IDF again to port it ; or if the new APIs are enough to (partially ?) reimplement it * There is a crash in `OvmsConsole::Poll` which I did not analyse (yet) and which I worked around by declaring a variable static. * I decided to transform our local copies of `wolfssh` and `wolfssl` in submodules (and move them one level below in terms of directories) - mainly to be able to have a CMakeLists.txt different from the upstream one. In the process, I "lost" one of our patches : https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/514… and we need to decide how to handle this. * A lot of dependencies are now explicitly (hard-)coded in the CMakeLists.txt - which may, or may not be a good thing. Let's discuss it. * I had to change a set of defines into a header generation (in ovms_webserver) because I was unable to implement those in a satisfying manner in cmake. If you manage to do it, it's a win ! * Build warnings were disabled to keep the output clean and focus on the build issues - but now they need to be re-activated. * etc... * Even if there is experimental support for cmake / idf.py in ESP-IDF 3.3.x, I did not make any effort to be compatible with it: o Our own fork does not seem to include this build system o It was experimental, the component API changed and I did not want to have edge case for something not used at the moment. Let me know your comments and questions. Best regards,

4 27