[Ovmsdev] Porting code from v2 to v3
Michael Balzer
dexter at expeedo.de
Thu Aug 2 03:40:15 HKT 2018
Nikolay,
see config → server v2 → update intervals.
Regarding speed, you do provide it:
StandardMetrics.ms_v_pos_speed->SetValue(((unsigned char) d[5]) / 2);
…that's line 65 of the thinkcity module. There is no fallback to GPS speed.
Regards,
Michael
Am 01.08.2018 um 21:10 schrieb Nikolay Shishkov:
> That same module has not crashed in almost a week now. So maybe there was something that was not connected to Think City code and got fixed by some of the
> library fixes.
>
> I noticed that it takes almost half a minute for the gps location to update in the app. The same goes for the speed and other parameters. Is there a setting
> to make that more frequent?
>
> Also - I can see speed, but I am not providing it - is it coming from the GPS?
>
> Thanks again!
>
>
> On Wednesday, August 1, 2018, 1:11:49 AM GMT+2, Nikolay Shishkov <nshishkov at yahoo.com> wrote:
>
>
> Thanks Michael,
>
> I did not refresh the mail thread and saw you answer after I posted my solution.
> I see about the states and the timing now... I may need to adjust this accordingly. I thought it was in milliseconds...
>
> These are all temperatures that are changing quite slow. So every 1 second or 4 seconds is perfectly fine.
> Hopefully I will have access to a car tomorrow and can test this.
>
> Thanks again,
> Nikolay
> On Wednesday, August 1, 2018, 1:06:32 AM GMT+2, Nikolay Shishkov <nshishkov at yahoo.com> wrote:
>
>
> I think I found a solution. Have not tested it yet.
>
> static const OvmsVehicle::poll_pid_t obdii_polls[] =
> {
> // 0x753 03 22 49 65 - charger temp
> { 0x753, 0x75B, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4965, { 0, 999, 999 } },
> // 0x753 03 22 49 66 - pcu heat sink temp
> { 0x753, 0x75B, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4966, { 0, 999, 999 } },
> // 0x753 03 22 49 67 - motor temp
> { 0x753, 0x75B, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4967, { 0, 999, 999 } },
> // 0x753 03 22 49 68 - sli batt temp and volts
> { 0x753, 0x75B, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4968, { 0, 200, 200 } },
> { 0, 0, 0x00, 0x00, { 0, 0, 0 } }
> };
>
>
> On Tuesday, July 31, 2018, 8:57:51 PM GMT+2, Nikolay Shishkov <nshishkov at yahoo.com> wrote:
>
>
> Quick question.
> How do I convert this:
>
> while (TXB0CONbits.TXREQ) {} // Loop until TX is done
> TXB0CON = 0;
> TXB0SIDL = 0b01100000;
> TXB0SIDH = 0b11101010;
> TXB0D0 = 0x03;
> TXB0D1 = 0x22;
> TXB0D2 = 0x49;
> TXB0D3 = 0x65;
> TXB0DLC = 0b00000100; // data length (4)
> TXB0CON = 0b00001000; // mark for transmission
> delay100b(); // Delay a little... (100ms, approx)
>
> while (TXB0CONbits.TXREQ) {} // Loop until TX is done
> TXB0CON = 0;
> TXB0SIDL = 0b01100000;
> TXB0SIDH = 0b11101010;
> TXB0D0 = 0x03;
> TXB0D1 = 0x22;
> TXB0D2 = 0x49;
> TXB0D3 = 0x66;
> TXB0DLC = 0b00000100; // data length (4)
> TXB0CON = 0b00001000; // mark for transmission
> delay100b(); // Delay a little... (100ms, approx)
>
> while (TXB0CONbits.TXREQ) {} // Loop until TX is done
> TXB0CON = 0;
> TXB0SIDL = 0b01100000;
> TXB0SIDH = 0b11101010;
> TXB0D0 = 0x03;
> TXB0D1 = 0x22;
> TXB0D2 = 0x49;
> TXB0D3 = 0x67;
> TXB0DLC = 0b00000100; // data length (4)
> TXB0CON = 0b00001000; // mark for transmission
> delay100b(); // Delay a little... (100ms, approx)
>
> while (TXB0CONbits.TXREQ) {} // Loop until TX is done
> TXB0CON = 0;
> TXB0SIDL = 0b01100000;
> TXB0SIDH = 0b11101010;
> TXB0D0 = 0x03;
> TXB0D1 = 0x22;
> TXB0D2 = 0x49;
> TXB0D3 = 0x68;
> TXB0DLC = 0b00000100; // data length (4)
> TXB0CON = 0b00001000; // mark for transmission
> delay100b(); // Delay a little... (100ms, approx)
>
> To the new polling framework?
> I took a look at the leaf code, but the configuration is a mystery to me. What are the input parameters?
> Maybe there is a document that I am missing?
>
> Thanks in advance,
> Nikolay
> On Saturday, July 28, 2018, 11:42:13 PM GMT+2, Nikolay Shishkov <nshishkov at yahoo.com> wrote:
>
>
> Thank you!
> Yes the carid is TC003.
> I was not running anything extraordinary - just followed the developer tutorial, but never flashed directly - always flashed from edge branch OTA.
> I will run the commands and provide output, but it will be with the newer firmware.
> I will need to see if updating will have same problems.
>
>
>
> On Friday, July 27, 2018, 3:07:09 AM GMT+2, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
>
>
> Note that I store the .elf files alongside the .bin, for edge/eap/main builds.
>
> For example:
>
> http://api.openvehicles.com/firmware/ota/v3.1/edge/3.1.008-29-gaf41242.ovms3.elf
>
>
> Regards, Mark.
>
>> On 27 Jul 2018, at 5:51 AM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>>
> Nikolay,
>
> you need to keep the .elf files for your builds to be able to analyze a backtrace. Do not use addr2line, it shows wrong line numbers. Use the script "a2l" I
> posted previously (I'll include it again below). Just feed it the .elf file and the backtrace. Example:
>
> a2l tmp/3.1.008-32-g2fa3ab8-elf/ovms3.elf 0x400dc8ec 0x4008f43d 0x4008e181 0x400818cc 0x40082163 0x40083c4d 0x400dc8e9
>
> (I don't have the -28- version, so my output doesn't make sense)
>
> @Mark: spurious task WDT crashes and heap corruption crashes still occur, but it seems they have become less often with the internal RAM rework.
>
>> 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.
>
> Extending Mark's answer:
>
> It's normally OK to directly set metrics from IncomingFrameCan1(), but be aware metrics listeners will be executed synchronously in the context that changes
> the metric.
>
> Standard metrics listeners are now for example the automatic notification generators in the vehicle base class. These may need quite some stack and time.
>
> If you spend too much time handling frames on a high volume bus, your vehicle task may lose frames. It's possible to raise the queue size (currently 20
> frames) and the vehicle task stack size, but it's better to keep the CAN processing simple.
>
> TL;DR: if you need to handle many CAN frames, I recommend changing metrics that trigger notifications or other complex actions from the ticker. If you
> encounter crashes on some CAN frames that may be due to the vehicle task stack being too small (CONFIG_OVMS_VEHICLE_RXTASK_STACK=6144).
>
> Regards,
> Michael
>
>
> Script a2l:
>
> #!/bin/bash
> elf=~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms3.elf
> for adr in $* ; do
> if [[ "$adr" =~ "elf" ]] ; then
> elf="$adr"
> else
> cmd+=" -ex 'l *$adr'"
> fi
> done
> cmd+=" -ex 'q'"
> echo "Using elf file: $elf"
> eval xtensa-esp32-elf-gdb -batch $elf $cmd 2>/dev/null #| grep "^0x.* is in "
>
>
>
>
> Am 26.07.2018 um 09:59 schrieb Nikolay Shishkov:
> 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
>
> --
> 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
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180801/d12fb4fd/attachment.htm>
More information about the OvmsDev
mailing list