[Ovmsdev] Porting code from v2 to v3
Mark Webb-Johnson
mark at webb-johnson.net
Thu Jul 26 22:05:54 HKT 2018
The backtrace you provided does not seem complete. Here is what it shows:
# xtensa-esp32-elf-addr2line -pfiaC -e 3.1.008-29-gaf41242.ovms3.elf 0x400dc8ec 0x4008f43d 0x4008e181 0x400818cc 0x40082163 0x40083c4d 0x400dc8e9
0x400dc8ec: esp_vApplicationIdleHook at /home/openvehicles/build/esp-idf/components/esp32/freertos_hooks.c:85
0x4008f43d: prvIdleTask at /home/openvehicles/build/esp-idf/components/freertos/tasks.c:4587
0x4008e181: xQueueGiveFromISR at /home/openvehicles/build/esp-idf/components/freertos/queue.c:2037
0x400818cc: timer_alarm_handler at /home/openvehicles/build/esp-idf/components/esp32/esp_timer.c:318
0x40082163: timer_alarm_isr at /home/openvehicles/build/esp-idf/components/esp32/esp_timer_esp32.c:323
0x40083c4d: _xt_lowint1 at /home/openvehicles/build/esp-idf/components/freertos/xtensa_vectors.S:1105
0x400dc8e9: esp_vApplicationIdleHook at /home/openvehicles/build/esp-idf/components/esp32/freertos_hooks.c:85
The 'Alloca exception’ is a stack overflow.
I don’t see anything in vehicle_thinkcity using up much stack.
Are you using the api.openvehicles.com <http://api.openvehicles.com/> server? If so, what is your vehicle id? These crashes are also reported to the server and we can check there for details. I do see some crashes for TC003 (which I think is one of yours):
# xtensa-esp32-elf-addr2line -pfiaC -e 3.1.008-29-gaf41242.ovms3.elf 0x40091e6b 0x40091fc3 0x40091063 0x40091423 0x40091a83 0x40083e80 0x40083f1f 0x4008db31 0x401b36c5 0x401bca20 0x40089ea1
0x40091e6b: invoke_abort at /home/openvehicles/build/esp-idf/components/esp32/panic.c:669
0x40091fc3: abort at /home/openvehicles/build/esp-idf/components/esp32/panic.c:669
0x40091063: multi_heap_assert at /home/openvehicles/build/esp-idf/components/heap/multi_heap.c:696
0x40091423: multi_heap_malloc_impl at /home/openvehicles/build/esp-idf/components/heap/multi_heap.c:696
0x40091a83: multi_heap_malloc at /home/openvehicles/build/esp-idf/components/heap/multi_heap_poisoning.c:328
0x40083e80: heap_caps_malloc at /home/openvehicles/build/esp-idf/components/heap/heap_caps.c:387
0x40083f1f: heap_caps_malloc_prefer at /home/openvehicles/build/esp-idf/components/heap/heap_caps.c:387
0x4008db31: wifi_malloc at /home/openvehicles/build/esp-idf/components/esp32/wifi_internal.c:31
0x401b36c5: esf_buf_alloc at ??:?
0x401bca20: wdevProcessRxSucDataAll at ??:?
0x40089ea1: ppTask at ??:?
Maybe heap/stack corruption? But your module looks ok. What else do you have configured to run? Can you show the output of ‘config show auto’, ‘module memory’, and ‘module tasks’?
> How is performance and power usage affected when using StandardMetrics.xxxxx->SetValue in the IncomingFrameCan1 method?
> Most of the messages update value every 100ms, and except maybe speed, battery current and voltage, most of the parameters are not changing that often. And even for the speed, current and voltage, it is probably enough to update StandardMetrics in the 1 second ticker... does this make sense or is the difference non-existing.
The function to set a metric’s value checks to see if the value has changed before updating, so should not be too expensive/costly to run. The only time I’ve seen this as an issue is when a value if flapping (changing every 1/100th second, as it moves around). You can workaround that with the age() function of the metric. Such as this example from vehicle_teslamodels:
// Don't update battery voltage too quickly (as it jumps around like crazy)
if (StandardMetrics.ms_v_bat_voltage->Age() > 10)
StandardMetrics.ms_v_bat_voltage->SetValue(((float)((int)d[1]<<8)+d[0])/100);
Or, if you really want to limit the number of updates, you could use monotonictime in your IncomingFrameCan1() function, and only run the code to look at changed metrics if it is different from the last run (which would delay metrics for a maximum of once every second):
static uint32_t tc_monotonic = 0;
void OvmsVehicleThinkCity::IncomingFrameCan1(CAN_frame_t* p_frame)
{
if (tc_monotonic == monotonictime) return;
tc_monotonic = monotonictime
...
Regards, Mark.
> On 26 Jul 2018, at 3:59 PM, Nikolay Shishkov <nshishkov at yahoo.com> wrote:
>
> Quick update:
> I managed to do a not so quick update on one of the ovms v.3 boxes that sits in a Think and can confirm that the porting seems to work.
> I could see speed, parking time, ambient temperature.
>
> I had very strange problems doing the OTA update. The firmware start download and I can see the messages progressing, but it would halt in between 700kB and 1600kB and then stay there until I refresh the browser.
> And when I refresh the browser I am asked of my password which leads me to that there must have been a crash in the meantime.
>
> I was finally able to get the OTA update work by disconnecting the box from the car and powering it via USB. This is a single data point but it kind of points to a problem with the code that communicates with the car.
>
> I was not able to get a laptop connected to checkout the console, but managed to get the following log - not sure how to interpret it.
>
> Last boot was 87 second(s) ago
> Time at boot: 2018-07-25 18:07:43 GMT
> This is reset #3 since last power cycle
> Detected boot reason: Crash (12/12)
> Crash counters: 3 total, 0 early
>
> Last crash: Alloca exception on core 0
> Registers:
> PC : 0x400dc8ec PS : 0x00060234 A0 : 0x8008f440 A1 : 0x3ffc45b0
> A2 : 0x00000020 A3 : 0x00000001 A4 : 0x00000000 A5 : 0x3ffb44b8
> A6 : 0x3ffb47e4 A7 : 0x3ffb458c A8 : 0x3ffb44d4 A9 : 0x3ffc4590
> A10 : 0x00000000 A11 : 0x7fffffff A12 : 0x8008e65b A13 : 0x3ffcc450
> A14 : 0x00000003 A15 : 0x00060023 SAR : 0x00000000 EXCCAUSE: 0x00000005
> EXCVADDR: 0x00000000 LBEG : 0x00000000 LEND : 0x00000000 LCOUNT : 0x00000000
> Backtrace:
> 0x400dc8ec 0x4008f43d 0x4008e181 0x400818cc 0x40082163 0x40083c4d 0x400dc8e9
> Version: 3.1.008-29-gaf41242/ota_1/edge (build idf v3.1-dev-987-g55d915e Jul 6 2018 00:14:59)
> Running partition: ota_1
> Boot partition: ota_1
> Firmware: 3.1.008-29-gaf41242/ota_1/edge (build idf v3.1-dev-987-g55d915e Jul 6 2018 00:14:59)
>
> How is performance and power usage affected when using StandardMetrics.xxxxx->SetValue in the IncomingFrameCan1 method?
> Most of the messages update value every 100ms, and except maybe speed, battery current and voltage, most of the parameters are not changing that often. And even for the speed, current and voltage, it is probably enough to update StandardMetrics in the 1 second ticker... does this make sense or is the difference non-existing.
>
> Thanks for all the hand holding and help,
> Nikolay
>
> On Thursday, July 19, 2018, 1:11:46 PM GMT+2, Nikolay Shishkov <nshishkov at yahoo.com> wrote:
>
>
> Done.
> https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/143 <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/143>
>
> I have not tested this in a vehicle.
> It would take some time to receive the new boxes, but I thought it may help someone to go further.
>
>
>
>
>
> On Thursday, July 19, 2018, 12:46:28 PM GMT+2, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
>
>
> Best is to create a pull request, and let us know. We can check and merge with master.
>
> Regards, Mark
>
> On 19 Jul 2018, at 6:41 PM, Nikolay Shishkov <nshishkov at yahoo.com <mailto:nshishkov at yahoo.com>> wrote:
>
>> Thank you guys!
>> I think I am ready with something I want to create pull request on. Do I do this through my own repository, or can I just send someone a diff?
>> Nikolay
>>
>> On Thursday, July 19, 2018, 12:37:58 PM GMT+2, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>>
>>
>> Nikolay,
>>
>>
>>> - what is the best way to compare OvmsMetricStrings? Or should I dublicate the state in an enum and use that?
>>> - what is the best way to compare the OvmsMetricFloat to a literal float?
>>
>> If you want to compare a state code encoded as a string, you can simply compare the std::string returned by AsString() with hard coded strings, e.g.
>>
>> std::string charge_state = StdMetrics.ms_v_charge_state->AsString();
>> if (charge_state == "charging")
>> …
>>
>> If you'd rather use the old numeric state codes, there are utility functions in the ovms_utils module for encoding / decoding them.
>>
>> As Mark wrote, you get the float value by the AsFloat() method and can compare that directly to a float literal. We haven't added comparison operators to the metrics classes yet, just assignment (and that needs casts in many cases). If you'd like to add more operators/types, go ahead.
>>
>>
>>>
>>>> - what is the current way of doing net_req_notification
>>>
>>> Not required in v3. If you change a metric that needs notification, the serverv2 and serverv3 will act appropriately.
>>
>> And if you want to customize standard notifications, you can do so by overloading the vehicle methods:
>>
>> virtual void NotifyChargeState();
>> virtual void NotifyChargeStart();
>> virtual void NotifyHeatingStart();
>> virtual void NotifyChargeStopped();
>> virtual void NotifyChargeDone();
>> virtual void NotifyValetEnabled();
>> virtual void NotifyValetDisabled();
>> virtual void NotifyValetHood();
>> virtual void NotifyValetTrunk();
>> virtual void NotifyAlarmSounding();
>> virtual void NotifyAlarmStopped();
>> virtual void Notify12vCritical();
>> virtual void Notify12vRecovered();
>>
>> If you want to add vehicle specific notifications, take a look at the Twizy module (rt_notify).
>>
>> You can simply send a notification from any command output by issuing MyNotify.NotifyCommand() (att: stack intensive) or send any string by MyNotify.NotifyString(). There are also varargs versions with "f" suffix acting like printf.
>>
>> For building strings from command methods, there is the StringWriter class, that's a std::string that can be used as an OvmsWriter. Example:
>>
>> StringWriter buf(200);
>> CommandStat(COMMAND_RESULT_NORMAL, &buf);
>> MyNotify.NotifyString("info", "charge.sufficient", buf.c_str());
>>
>> Best practice is to send notifications from within an event handler (e.g. Ticker1), so they run asynchronously in the event task context instead of blocking something.
>>
>> Regards,
>> Michael
>>
>> PS: we should start collecting these pieces for the developer manual, the general system API is quite mature now
>>
>>
>>
>>> On 19 Jul 2018, at 6:00 AM, Nikolay Shishkov <nshishkov at yahoo.com <mailto:nshishkov at yahoo.com>> wrote:
>>>>
>>>> Hi,
>>>> I am working on the Think City EV code and have some questions.
>>>> - what is the best way to signal that the charging connector is plugged? ms_v_charge_pilot?
>>>> previously it was cardoorbits1.
>>>>
>>>> - what is the best way to compare OvmsMetricStrings? Or should I dublicate the state in an enum and use that?
>>>>
>>>> - what is the best way to compare the OvmsMetricFloat to a literal float?
>>>>
>>>> - what is the current way of doing net_req_notification
>>>>
>>>> Thanks in advance,
>>>> Nikolay
>>>> On Tuesday, July 17, 2018, 3:37:49 AM GMT+2, Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>> wrote:
>>>>
>>
>> --
>> 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>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180726/50121962/attachment.htm>
More information about the OvmsDev
mailing list