Hi all, I got my USB CAN bus interface working with the OVMS v3 hardware on my desk, it turns out you need at least one terminator before the bus will work! I cargo culted (I've never written C++) my way through transposing the Leaf OVMS v2 can bus decoder into the v3 code. When I play a can bus recording I see the metrics update! I see that quite a few of the metrics used on the leaf are missing. Do I just add them to metrics_standard.cpp? None of them are particularly leaf specific, so this seems the right place. Is anyone working on the v2 server support code to send the S and D messages?
Tom,
When I play a can bus recording I see the metrics update!
Sounds great. It is pretty cool to see the metrics populated. Much easier to ensure everything is working than with v2.
I see that quite a few of the metrics used on the leaf are missing. Do I just add them to metrics_standard.cpp? None of them are particularly leaf specific, so this seems the right place.
I just added the very basic ones, as a starting point and proof of concept. Hadn’t decided if I needed anything special for the bitmapped ones at the time (either a new MetricBitmap type, or extend MetricInt). Looking at how things have evolved, and bearing in mind the GAPP bluetooth stuff, and OVMS v3 MQTT, it seems that each bit should be a metric of their own. Not too hard for ovms_server_v2 to convert that back to an integer bitmap, for backwards compatibility. To do that, car_doors1 becomes: v.d.frontleft: bool v.d.frontright: bool v.d.chargeport: bool v.c.pilot: bool v.c.charging: bool v.e.handbrake: bool v.e.caron: bool N.B. The ‘v.’ is the prefix for vehicle metrics, then the second part becomes the area of the vehicle (‘b.’ for battery, ‘p.’ for position, ‘tp.’ for tpms, ‘d.’ for doors, ‘c.’ for charger, etc). So, if you have time, please go ahead and add the other standard ones that are simple and shared across all cars. You need to add a '#define MS_V_…’ for the string name, then a ‘ms_v_…’ member variable to MetricsStandard, then change MetricsStandard::MetricsStandard() constructor to create the metric itself and store a pointer in the member variable. I guess we need to add all the car_ ones from ovms.h in the v2 project. Here are the ones outstanding: extern unsigned int car_linevoltage; // Line Voltage extern unsigned char car_chargecurrent; // Charge Current extern unsigned char car_chargelimit; // Charge Limit (amps) extern unsigned int car_chargeduration; // Charge Duration (minutes) extern unsigned char car_chargestate; // 1=charging, 2=top off, 4=done, 13=preparing to charge, 21-25=stopped charging extern unsigned char car_chargesubstate; extern unsigned char car_chargemode; // 0=standard, 1=storage, 3=range, 4=performance extern unsigned char car_charge_b4; // B4 byte of charge state extern unsigned int car_chargekwh; // Energy charged (1/10 kWh) extern chargetype car_chargetype; extern unsigned int car_chargepower; // Charge Power (1/10 kW) extern unsigned int car_battvoltage; // Battery Voltage (1/10 V) extern unsigned char car_doors1; typedef struct { unsigned FrontLeftDoor:1; // 0x01 unsigned FrontRightDoor:1; // 0x02 unsigned ChargePort:1; // 0x04 unsigned PilotSignal:1; // 0x08 unsigned Charging:1; // 0x10 unsigned :1; // 0x20 unsigned HandBrake:1; // 0x40 unsigned CarON:1; // 0x80 } car_doors1bits_t; #define car_doors1bits (*((car_doors1bits_t*)&car_doors1)) extern unsigned char car_doors2; typedef struct { unsigned :1; // 0x01 unsigned :1; // 0x02 unsigned :1; // 0x04 unsigned CarLocked:1; // 0x08 unsigned ValetMode:1; // 0x10 unsigned Headlights:1; // 0x20 unsigned Bonnet:1; // 0x40 unsigned Trunk:1; // 0x80 } car_doors2bits_t; #define car_doors2bits (*((car_doors2bits_t*)&car_doors2)) extern unsigned char car_doors3; typedef struct { unsigned CarAwake:1; // 0x01 unsigned CoolingPump:1; // 0x02 unsigned :1; // 0x04 unsigned :1; // 0x08 unsigned :1; // 0x10 unsigned :1; // 0x20 unsigned CtrlLoggedIn:1; // 0x40 - logged into controller unsigned CtrlCfgMode:1; // 0x80 - controller in configuration mode } car_doors3bits_t; #define car_doors3bits (*((car_doors3bits_t*)&car_doors3)) extern unsigned char car_doors4; typedef struct { unsigned :1; // 0x01 unsigned AlarmSounds:1; // 0x02 unsigned :1; // 0x04 unsigned :1; // 0x08 unsigned :1; // 0x10 unsigned :1; // 0x20 unsigned :1; // 0x40 unsigned :1; // 0x80 } car_doors4bits_t; #define car_doors4bits (*((car_doors4bits_t*)&car_doors4)) extern unsigned char car_doors5; typedef struct { unsigned RearLeftDoor:1; // 0x01 unsigned RearRightDoor:1; // 0x02 unsigned Frunk:1; // 0x04 unsigned :1; // 0x08 unsigned Charging12V:1; // 0x10 unsigned :1; // 0x20 unsigned :1; // 0x40 unsigned HVAC:1; // 0x80 } car_doors5bits_t; extern unsigned char car_lockstate; // Lock State extern unsigned char car_drivemode; // Car specific encoding of current drive mode extern signed int car_power; // Current battery power level (1/10 kW) extern unsigned long car_energy_used; // Energy used on trip (Wh) extern unsigned long car_energy_recd; // Energy recovered on trip (Wh) extern unsigned long car_time; // UTC Time extern unsigned long car_parktime; // UTC time car was parked (or 0 if not) extern unsigned char car_stopped_mincnt; // Minute countdown while stopped extern signed char car_timermode; // Timer mode (0=onplugin, 1=timer) extern unsigned int car_timerstart; // Timer start extern unsigned char car_gpslock; // GPS lock status & satellite count #define GPS_LOCK() ((car_gpslock & 0b11000000) >> 6) #define GPS_SATCNT() (car_gpslock & 0b00111111) extern signed char car_stale_ambient; // 0 = Ambient temperature is stale extern signed char car_stale_temps; // 0 = Powertrain temperatures are stale extern signed char car_stale_gps; // 0 = gps is stale extern signed char car_stale_tpms; // 0 = tpms is stale extern signed char car_stale_timer; // 0 = timer is stale extern unsigned char net_reg; // Network registration extern unsigned char net_link; // Network link status extern unsigned char net_iccid[MAX_ICCID]; // ICCID extern char net_apps_connected; // Network apps connected extern char sys_features[FEATURES_MAX]; // System features extern unsigned char net_sq; // GSM Network Signal Quality extern unsigned int car_12v_current; // 12V (DC converter) current in 1/10 A extern unsigned char car_gsmcops[9]; // GSM provider extern signed int car_chargefull_minsremaining; // ETR for 100% extern signed int car_chargelimit_minsremaining_range; // ETR for range limit extern signed int car_chargelimit_minsremaining_soc; // ETR for SOC limit extern unsigned int car_chargelimit_rangelimit; // Range limit (in vehicle units) extern unsigned char car_chargelimit_soclimit; // SOC% limit extern unsigned int car_max_idealrange; // Maximum ideal range in miles extern signed char car_coolingdown; // >=0 if car is cooling down extern unsigned char car_cooldown_chargemode; // 0=standard, 1=storage, 3=range, 4=performance extern unsigned char car_cooldown_chargelimit; // Charge Limit (amps) extern signed int car_cooldown_tbattery; // Cooldown temperature limit extern unsigned int car_cooldown_timelimit; // Cooldown time limit (minutes) remaining extern unsigned char car_cooldown_wascharging; // TRUE if car was charging when cooldown started extern int car_chargeestimate; // ACC: charge time estimation for current charger capabilities (min.) extern unsigned char car_SOCalertlimit; // Low limit of SOC at which alert should be raised #define CAR_IS_ON (car_doors1bits.CarON) #define CAR_IS_CHARGING (car_doors1bits.Charging) #define CAR_IS_HEATING (car_chargestate==0x0f) Now, a bunch of those aren’t necessary to convert. We have ‘modifiers’ to track whether something has been modified, and I’ve just added m_lastmodified (and GetLastModified()), and m_stale (and SetStale()) to metrics, to allow us to know if a metric is stale or not. So, now all those _stale variables can go (and ovms_server_v2 can work it out itself). Then we have a bunch that seem to be not actually used in protocol messages. Those should either be vehicle-specific (so not in standard_metrics), or just stored in the vehicle module itself.
Is anyone working on the v2 server support code to send the S and D messages?
Nope. Not at the moment. I’ve stubbed it. The v2 code used CRCs to check if something has been modified. The stubbed version doesn’t use that. I think we can use modifiers on the metrics to know whether the metric itself has changed. I tried implementing one (TransmitMsgTPMS) and that went quite cleanly. It was wordy, but overall looked neat. Certainly easier for the vehicle modules not to have to maintain these CRCs and decrementing timers. Let me know what you think, and if you have time to try to implement some of this. Regards, Mark.
On 3 Oct 2017, at 5:33 PM, Tom Parker <tom@carrott.org> wrote:
Hi all,
I got my USB CAN bus interface working with the OVMS v3 hardware on my desk, it turns out you need at least one terminator before the bus will work!
I cargo culted (I've never written C++) my way through transposing the Leaf OVMS v2 can bus decoder into the v3 code. When I play a can bus recording I see the metrics update!
I see that quite a few of the metrics used on the leaf are missing. Do I just add them to metrics_standard.cpp? None of them are particularly leaf specific, so this seems the right place.
Is anyone working on the v2 server support code to send the S and D messages?
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
On 04/10/17 02:30, Mark Webb-Johnson wrote:
I just added the very basic ones, as a starting point and proof of concept. Hadn’t decided if I needed anything special for the bitmapped ones at the time (either a new MetricBitmap type, or extend MetricInt). Looking at how things have evolved, and bearing in mind the GAPP bluetooth stuff, and OVMS v3 MQTT, it seems that each bit should be a metric of their own. Not too hard for ovms_server_v2 to convert that back to an integer bitmap, for backwards compatibility. To do that, car_doors1 becomes:
I fully support the concept of storing the data in the most appropriate format and serializing it into the v2 message in the v2 server code. I like the idea of storing the bit field stuff as separate boolean objects. I don't know if you can do anything clever with C++ to use less memory while preserving a nice API within the vehicle code, but we probably have enough memory to not need to worry too much?
So, if you have time, please go ahead and add the other standard ones that are simple and shared across all cars.
I'll add them as I need them for porting the leaf code. I don't support most of the "standard" metrics in the leaf code so it won't be all of them.
Is anyone working on the v2 server support code to send the S and D messages?
Nope. Not at the moment. I’ve stubbed it.
I've implemented an S message using the TPMS as an example and the few metrics that we already have. I found the android client can't cope with an empty value, so I had to modify the if undefined return the empty string behavior in the AsString implementations in subclasses of OvmsMetric. I'm currently "learning" how C++ inheritance works and am in a twisty maze of complier errors. I'll explain what I'm doing tomorrow and hopefully there is an obvious answer. Once I've sorted that out I'll send a pull request (I hacked it by hard coding values that work for a v2 android client which presumably breaks other things. What I want to do is replace the existing methods with ones that takes an argument to return as a default value, and re-implement the existing no-argument methods in terms of the new method). I'm at the point where I can take it for a drive on my phone's wifi hotspot.
I’ve added the standard metrics that I could work out, and pushed that to the main. About 80 in total now. That should work for 99% of the functionality, and is a nice format for MQTT and GATT (although more work for v2 server protocol). The ones I haven’t done are: extern unsigned char car_charge_b4; // B4 byte of charge state extern unsigned int car_chargepower; // Charge Power (1/10 kW) extern unsigned char car_lockstate; // Lock State extern char sys_features[FEATURES_MAX]; // System features extern unsigned char net_link; // Network link status extern unsigned int car_max_idealrange; // Maximum ideal range in miles extern signed int car_power; // Current battery power level (1/10 kW) extern unsigned long car_energy_used; // Energy used on trip (Wh) extern unsigned long car_energy_recd; // Energy recovered on trip (Wh) extern unsigned char car_stopped_mincnt; // Minute countdown while stopped extern unsigned int car_12v_current; // 12V (DC converter) current in 1/10 A extern signed int car_chargefull_minsremaining; // ETR for 100% extern signed int car_chargelimit_minsremaining_range; // ETR for range limit extern signed int car_chargelimit_minsremaining_soc; // ETR for SOC limit extern unsigned int car_chargelimit_rangelimit; // Range limit (in vehicle units) extern unsigned char car_chargelimit_soclimit; // SOC% limit extern signed char car_coolingdown; // >=0 if car is cooling down extern unsigned char car_cooldown_chargemode; // 0=standard, 1=storage, 3=range, 4=performance extern unsigned char car_cooldown_chargelimit; // Charge Limit (amps) extern signed int car_cooldown_tbattery; // Cooldown temperature limit extern unsigned int car_cooldown_timelimit; // Cooldown time limit (minutes) remaining extern unsigned char car_cooldown_wascharging; // TRUE if car was charging when cooldown started extern unsigned char car_SOCalertlimit; // Low limit of SOC at which alert should be raised As they seem either vehicle-specific, or internal working variables. I think they should be fairly self-explanatory, although in places I’ve renamed them to make more sense (e.g. MS_V_CHARGE_MINUTES and MS_V_CHARGE_KWH, rather than car_chargeduration and car_chargekwh). I’ve also dropped a few that were really duplicating the same basic information. Do the best you can, and if you can’t work out how to get something in particular, let me know or leave it as a “TODO” marked in the code. Thanks, Mark
On 8 Oct 2017, at 5:40 PM, Tom Parker <tom@carrott.org> wrote:
On 04/10/17 02:30, Mark Webb-Johnson wrote:
I just added the very basic ones, as a starting point and proof of concept. Hadn’t decided if I needed anything special for the bitmapped ones at the time (either a new MetricBitmap type, or extend MetricInt). Looking at how things have evolved, and bearing in mind the GAPP bluetooth stuff, and OVMS v3 MQTT, it seems that each bit should be a metric of their own. Not too hard for ovms_server_v2 to convert that back to an integer bitmap, for backwards compatibility. To do that, car_doors1 becomes:
I fully support the concept of storing the data in the most appropriate format and serializing it into the v2 message in the v2 server code. I like the idea of storing the bit field stuff as separate boolean objects. I don't know if you can do anything clever with C++ to use less memory while preserving a nice API within the vehicle code, but we probably have enough memory to not need to worry too much?
So, if you have time, please go ahead and add the other standard ones that are simple and shared across all cars.
I'll add them as I need them for porting the leaf code. I don't support most of the "standard" metrics in the leaf code so it won't be all of them.
Is anyone working on the v2 server support code to send the S and D messages?
Nope. Not at the moment. I’ve stubbed it.
I've implemented an S message using the TPMS as an example and the few metrics that we already have. I found the android client can't cope with an empty value, so I had to modify the if undefined return the empty string behavior in the AsString implementations in subclasses of OvmsMetric. I'm currently "learning" how C++ inheritance works and am in a twisty maze of complier errors. I'll explain what I'm doing tomorrow and hopefully there is an obvious answer. Once I've sorted that out I'll send a pull request (I hacked it by hard coding values that work for a v2 android client which presumably breaks other things. What I want to do is replace the existing methods with ones that takes an argument to return as a default value, and re-implement the existing no-argument methods in terms of the new method).
I'm at the point where I can take it for a drive on my phone's wifi hotspot. _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
On 09/10/17 03:29, Mark Webb-Johnson wrote:
Do the best you can, and if you can’t work out how to get something in particular, let me know or leave it as a “TODO” marked in the code.
Thanks for adding the metrics. I sent a pull request with an initial implementation of the Stat message. It doesn't use any of your new metrics except battery voltage (I'd already added that one) and I wedged sending it into a nearby loop which is almost certainly the wrong place, but it works and I was able to send telemetry from a real car today using a wifi hotspot for network connectivity. I had trouble with method overloading and hiding in the Metrics classes and ended up giving the AsStringDefault method a unique name. The api I made also seems very clunky, do I really have to make a std::string from a constant and then pass it in? Or is it more idomatic to pass in the constant and turn it into a std::string when and if it is returned? I don't like the fixed size buffer to construct the message, I copied the TPMS message code, and not knowing the "right" way to do it in this embedded C++, I just cargo culted it together. I'd be much happier if we at least used something that was aware of how big the buffer was and failed more gracefully than overflowing. I tried an SD card and it didn't work. How do I hard code or otherwise inject some startup commands without an SD card? I tried tracing through the command code but quickly decided it was easier to just start the vehicle module, wifi and v2 server with my laptop in monitor mode. Since I rebased onto the current master, things don't compile: /vagrant/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/spiffs/./spiffs_vfs.c: In function 'vfs_spiffs_fstat': /vagrant/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/spiffs/./spiffs_vfs.c:344:22: error: 'CONFIG_SPIFFS_LOG_PAGE_SIZE' undeclared (first use in this function) st->st_blksize = CONFIG_SPIFFS_LOG_PAGE_SIZE;
Tom, Thanks for your help with this. It is useful to have a different set of eyes on the problem, and see some alternative approaches.
It doesn't use any of your new metrics except battery voltage
You seem to have added: + #define MS_V_BAT_CURRENT “v.b.current" + OvmsMetricFloat* ms_v_bat_v; + OvmsMetricFloat* ms_v_bat_i; + ms_v_bat_current = new OvmsMetricFloat(MS_V_BAT_CURRENT, SM_STALE_MID); But that seems strange. Is it ms_v_bat_current or ms_v_bat_i? What is this MS_V_BAT_CURRENT? Presumably some sort of instantaneous current reading from the battery? If so, probably best to put it just after MS_V_BAT_VOLTAGE, as: #define MS_V_BAT_CURRENT “v.b.current" OvmsMetricInt* ms_v_bat_current ms_v_bat_current = new OvmsMetricInt(MS_V_BAT_CURRENT, SM_STALE_MID);
I had trouble with method overloading and hiding in the Metrics classes and ended up giving the AsStringDefault method a unique name. The api I made also seems very clunky, do I really have to make a std::string from a constant and then pass it in? Or is it more idomatic to pass in the constant and turn it into a std::string when and if it is returned?
I think the standard C++ mechanisms for providing pre-initialised default values as parameters should work, so have modified the AsString, AsInt, etc functions to use that. It doesn’t change a normal call (so current behaviour is unchanged), but does give you a way of providing a default value for undefined metrics. For example, for OvmsMetricBool, we have: std::string AsString(const char* defvalue = ""); int AsBool(const bool defvalue = false); Let’s look at the implementation of AsBool(): int OvmsMetricBool::AsBool(const bool defvalue) { if (m_defined) return m_value; else return defvalue; } So, you can call metric->AsBool(true) to make ‘true’ the default. Or metric->AsString(“undefined") to make “undefined” the default. I’ve pushed this, and I think it should satisfy your requirements. Can you modify to adopt this?
I don't like the fixed size buffer to construct the message, I copied the TPMS message code, and not knowing the "right" way to do it in this embedded C++, I just cargo culted it together. I'd be much happier if we at least used something that was aware of how big the buffer was and failed more gracefully than overflowing.
You’re right, it is ugly and dangerous. I re-worked my tpms example, to use std::string: std::string buffer; buffer.reserve(512); buffer.append("MP-0 W"); buffer.append(StandardMetrics.ms_v_tpms_fr_p->AsString()); buffer.append(",”); ... That pre-allocates 512 bytes (for performance), but can grow if that reserved size is exceeded. What do you think of that? It looks better, but I still don’t really like all those append(“,”) lines. Can you try to re-work your code, to use these three new things, and then re-submit a pull request?
I tried an SD card and it didn't work. How do I hard code or otherwise inject some startup commands without an SD card?
I’m working with the China guys on SD CARD to try to find out why it is working for them but not us. In the meantime, Steve made a ‘vfs append’ command: vfs append <quoted line> <file> You can use /store to create an event script: vfs mkdir /store/scripts vfs mkdir /store/scripts/system.start vfs append “wifi mode client <SSID>” /store/scripts/system.start/startmeup vfs append “vehicle module NL” /store/scripts/system.start/startmeup vfs mkdir /store/scripts/network.up vfs append “server v2 start” /store/scripts/network.up/startmeup Untested, so may not be perfect, but I think you get the idea…
Since I rebased onto the current master, things don't compile:
/vagrant/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/spiffs/./spiffs_vfs.c: In function 'vfs_spiffs_fstat’:
I think this is related to the sdkconfig. Anyway, I removed the components/spiffs (as we don’t use it), and it now compiles. I also created a sdkconfig.default that developers can copy to sdkconfig, to provide a good set of defaults. You should also be able to diff it, to see anything changed. Regards, Mark.
On 9 Oct 2017, at 6:10 PM, Tom Parker <tom@carrott.org> wrote:
On 09/10/17 03:29, Mark Webb-Johnson wrote:
Do the best you can, and if you can’t work out how to get something in particular, let me know or leave it as a “TODO” marked in the code.
Thanks for adding the metrics. I sent a pull request with an initial implementation of the Stat message. It doesn't use any of your new metrics except battery voltage (I'd already added that one) and I wedged sending it into a nearby loop which is almost certainly the wrong place, but it works and I was able to send telemetry from a real car today using a wifi hotspot for network connectivity.
I had trouble with method overloading and hiding in the Metrics classes and ended up giving the AsStringDefault method a unique name. The api I made also seems very clunky, do I really have to make a std::string from a constant and then pass it in? Or is it more idomatic to pass in the constant and turn it into a std::string when and if it is returned?
I don't like the fixed size buffer to construct the message, I copied the TPMS message code, and not knowing the "right" way to do it in this embedded C++, I just cargo culted it together. I'd be much happier if we at least used something that was aware of how big the buffer was and failed more gracefully than overflowing.
I tried an SD card and it didn't work. How do I hard code or otherwise inject some startup commands without an SD card? I tried tracing through the command code but quickly decided it was easier to just start the vehicle module, wifi and v2 server with my laptop in monitor mode.
Since I rebased onto the current master, things don't compile:
/vagrant/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/spiffs/./spiffs_vfs.c: In function 'vfs_spiffs_fstat': /vagrant/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/spiffs/./spiffs_vfs.c:344:22: error: 'CONFIG_SPIFFS_LOG_PAGE_SIZE' undeclared (first use in this function) st->st_blksize = CONFIG_SPIFFS_LOG_PAGE_SIZE;
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
On 10/10/17 02:17, Mark Webb-Johnson wrote:
But that seems strange. Is it ms_v_bat_current or ms_v_bat_i?
Oops, I originally added voltage and current as ms_v_bat_v and ms_v_bat_i, and you spelled out voltage, so I removed my voltage metric and attempted to update my current metric and missed half the changes.
I had trouble with method overloading and hiding in the Metrics classes and ended up giving the AsStringDefault method a unique name. The api I made also seems very clunky, do I really have to make a std::string from a constant and then pass it in? Or is it more idomatic to pass in the constant and turn it into a std::string when and if it is returned?
I think the standard C++ mechanisms for providing pre-initialised default values as parameters should work, so have modified the AsString, AsInt, etc functions to use that. It doesn’t change a normal call (so current behaviour is unchanged), but does give you a way of providing a default value for undefined metrics.
Yes, this is very much what I wanted, it didn't occur to me that C++ supported default values for arguments. I've updated my code to use the default argument method.
I re-worked my tpms example, to use std::string:
...
What do you think of that? It looks better, but I still don’t really like all those append(“,”) lines.
Much better. I too didn't like how the commas were added. I had a read of https://stackoverflow.com/questions/1430757/c-vector-to-string and wasn't sure which answer was most appropriate. Given we're going to have quite a few different v2 messages, I think it is worth serializing each field in the message into members of an array and then programmatically serializing that to a comma separated string, such as the following pastiche of Java and our code: std:string message[] = { StandardMetrics.ms_v_bat_soc->AsString("0"), StandardMetrics.ms_v_bat_range_ideal->AsString("0"), StandardMetrics.ms_v_bat_range_est->AsString("0"), ... }; buffer = "MP-0 S" + String.join(",", message);
Can you try to re-work your code, to use these three new things, and then re-submit a pull request?
I've reworked it, will test and update the pull request tomorrow.
I think this is related to the sdkconfig. Anyway, I removed the components/spiffs (as we don’t use it), and it now compiles.
I also created a sdkconfig.default that developers can copy to sdkconfig, to provide a good set of defaults. You should also be able to diff it, to see anything changed.
Thanks it is compiling again. I'll test the vfs append tomorrow too
On 10/10/17 23:39, Tom Parker wrote:
I'll test the vfs append tomorrow too
I think there is a problem with the simcom support. The following trace at the bottom of this mail happens on startup and it reboots before doing it again in a loop. I haven't startup tasks. I've got the hologram simcard in it but haven't registered it or anything like that, so maybe an error is being reported that isn't being handled. I turned off the simcom support in make menuconfig and it's stable. The vfs things don't work: OVMS > vfs mkdir /store/scripts Error: Could not create VFS directory It also used to store my config across power cycles but it doesn't do that anymore. Is this relevant: I (1132) ovms_main: Mounting CONFIG... E (1132) vfs_fat_spiflash: Failed to find FATFS partition (type='data', subtype='fat', partition_label='store'). Check the partition table. Initialising OVMS CONFIG within STORE I appear to be using the ./vehicle/OVMS.V3/partitions.csv partition table, does /store need formatting? I see there is autoformat code in the sdcard paths, but not in the internal storage? Simcom reboot loop referred to above: Welcome to the Open Vehicle Monitoring System (OVMS) - Async Console I (2280) simcom: State: Enter CheckPowerOff state SIMCOM tx 41 54 0d 0a AT.. ***ERROR*** A stack overflow in task Tmr Svc has been detected. abort() was called at PC 0x400887b8 on core 0 0x400887b8: vApplicationStackOverflowHook at /home/ubuntu/esp/esp-idf/components/esp32/./panic.c:519 Backtrace: 0x400886a0:0x3ffc7670 0x4008879f:0x3ffc7690 0x400887b8:0x3ffc76b0 0x400864e9:0x3ffc76d0 0x40087a9c:0x3ffc76f0 0x40087a56:0xa5a5a5a5 0x400886a0: invoke_abort at /home/ubuntu/esp/esp-idf/components/esp32/./panic.c:519 0x4008879f: abort at /home/ubuntu/esp/esp-idf/components/esp32/./panic.c:519 0x400887b8: vApplicationStackOverflowHook at /home/ubuntu/esp/esp-idf/components/esp32/./panic.c:519 0x400864e9: vTaskSwitchContext at /home/ubuntu/esp/esp-idf/components/freertos/./tasks.c:4446 0x40087a9c: _frxt_dispatch at ??:? 0x40087a56: _frxt_int_exit at ??:?
Tom, I think your problem is sdkconfig. That has settings for partition table, fat filesystem, and timer task stack size; all three of your issues. Can you try to diff your sdkconfig against sdkconfig.default (which contains all the custom settings)? Or just copy sdkconfig.default over your sdkconfig, and then adjust appropriately for what you need custom? You’ll need to ‘make menuconfig’ to confirm things, then I suggest ‘make clean’ and ‘make flash’ to flash everything (partition table, bootloader, etc). Regards, Mark. P.S. The store has ‘m_store_fat.format_if_mount_failed = true’, so should format as necessary.
On 11 Oct 2017, at 3:17 AM, Tom Parker <tom@carrott.org> wrote:
On 10/10/17 23:39, Tom Parker wrote:
I'll test the vfs append tomorrow too
I think there is a problem with the simcom support. The following trace at the bottom of this mail happens on startup and it reboots before doing it again in a loop. I haven't startup tasks. I've got the hologram simcard in it but haven't registered it or anything like that, so maybe an error is being reported that isn't being handled. I turned off the simcom support in make menuconfig and it's stable.
The vfs things don't work:
OVMS > vfs mkdir /store/scripts Error: Could not create VFS directory
It also used to store my config across power cycles but it doesn't do that anymore.
Is this relevant:
I (1132) ovms_main: Mounting CONFIG... E (1132) vfs_fat_spiflash: Failed to find FATFS partition (type='data', subtype='fat', partition_label='store'). Check the partition table. Initialising OVMS CONFIG within STORE
I appear to be using the ./vehicle/OVMS.V3/partitions.csv partition table, does /store need formatting? I see there is autoformat code in the sdcard paths, but not in the internal storage?
Simcom reboot loop referred to above:
Welcome to the Open Vehicle Monitoring System (OVMS) - Async Console I (2280) simcom: State: Enter CheckPowerOff state SIMCOM tx 41 54 0d 0a AT.. ***ERROR*** A stack overflow in task Tmr Svc has been detected. abort() was called at PC 0x400887b8 on core 0 0x400887b8: vApplicationStackOverflowHook at /home/ubuntu/esp/esp-idf/components/esp32/./panic.c:519
Backtrace: 0x400886a0:0x3ffc7670 0x4008879f:0x3ffc7690 0x400887b8:0x3ffc76b0 0x400864e9:0x3ffc76d0 0x40087a9c:0x3ffc76f0 0x40087a56:0xa5a5a5a5 0x400886a0: invoke_abort at /home/ubuntu/esp/esp-idf/components/esp32/./panic.c:519
0x4008879f: abort at /home/ubuntu/esp/esp-idf/components/esp32/./panic.c:519
0x400887b8: vApplicationStackOverflowHook at /home/ubuntu/esp/esp-idf/components/esp32/./panic.c:519
0x400864e9: vTaskSwitchContext at /home/ubuntu/esp/esp-idf/components/freertos/./tasks.c:4446
0x40087a9c: _frxt_dispatch at ??:?
0x40087a56: _frxt_int_exit at ??:?
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
On 11/10/17 13:02, Mark Webb-Johnson wrote:
Tom,
I think your problem is sdkconfig. That has settings for partition table, fat filesystem, and timer task stack size; all three of your issues.
Can you try to diff your sdkconfig against sdkconfig.default (which contains all the custom settings)? Or just copy sdkconfig.default over your sdkconfig, and then adjust appropriately for what you need custom? You’ll need to ‘make menuconfig’ to confirm things, then I suggest ‘make clean’ and ‘make flash’ to flash everything (partition table, bootloader, etc).
That worked! My sdkconfig was quite far from the default. Your untested scripts recommendation didn't work as they need to be stored in the events directory, this works: vfs mkdir /store/events vfs mkdir /store/events/system.start vfs append "wifi mode client <ssid>" /store/events/system.start/startmeup vfs append "vehicle module NL" /store/events/system.start/startmeup vfs mkdir /store/events/network.up vfs append "server v2 start" /store/events/network.up/startmeup With these in place I get a reboot loop: I (5822) event: ip: 192.168.43.92, mask: 255.255.255.0, gw: 192.168.43.1 I (5822) ovms-mdns: Launching MDNS service I (5832) script: Running script /store/events/network.up/startmeup Launching OVMS Server V2 connection (oscv2)/home/ubuntu/esp/esp-idf/components/freertos/./heap_regions.c:368 (vPortFreeTagged)- assert failed! abort() was called at PC 0x40085f8f on core 1 0x40085f8f: vPortFreeTagged at /home/ubuntu/esp/esp-idf/components/freertos/./heap_regions.c:410 Backtrace: 0x40088680:0x3ffebe80 0x4008877f:0x3ffebea0 0x40085f8f:0x3ffebec0 0x40088cd1:0x3ffebee0 0x40081f89:0x3ffebf00 0x4000bec7:0x3ffebf20 0x400eff2a:0x3ffebf40 0x400eff54:0x3ffebf70 0x400efcc0:0x3ffebf90 0x40088680: invoke_abort at /home/ubuntu/esp/esp-idf/components/esp32/./panic.c:519 0x4008877f: abort at /home/ubuntu/esp/esp-idf/components/esp32/./panic.c:519 0x40085f8f: vPortFreeTagged at /home/ubuntu/esp/esp-idf/components/freertos/./heap_regions.c:410 0x40088cd1: vPortFree at /home/ubuntu/esp/esp-idf/components/esp32/./heap_alloc_caps.c:323 0x40081f89: _free_r at /home/ubuntu/esp/esp-idf/components/newlib/./syscalls.c:32 0x400eff2a: _ZN11OvmsConsole7ServiceEv at /vagrant/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_console.cpp:215 0x400eff54: _ZThn296_N11OvmsConsole7ServiceEv at ??:? 0x400efcc0: _ZN8TaskBase4TaskEPv at /vagrant/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./task_base.cpp:119 Rebooting... If I remove the network.up/startmeup file (the file that starts the v2 server client) then it starts up ok and when I start the v2 client manually, it connects to the v2 server and everything works. I tried using the ticker.60 event and got the same crash so it's not a race condition with the wifi startup. The cause is a double free by the looks of it, and if I comment out the writer->puts called in the v2 server start function, things work: diff --git a/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp b/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp index 106269e..d1ee797 100644 --- a/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp +++ b/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp @@ -515,7 +515,7 @@ void ovmsv2_start(int verbosity, OvmsWriter* writer, OvmsCommand* cmd, int argc, { if (MyOvmsServerV2 == NULL) { - writer->puts("Launching OVMS Server V2 connection (oscv2)"); + // writer->puts("Launching OVMS Server V2 connection (oscv2)"); MyOvmsServerV2 = new OvmsServerV2("oscv2"); } } The ESP_LOGI in OvmsServerV2::OvmsServerV2 also gets called, in this code path but doesn't need to be commented out. Progress!
I think this double-free may be related to the new event script system Steve and I have been working on (in preparation for SMS, etc). @steve: That seems to be on 'free(event.buffer)’ at ovms_console.cpp:215. One of those nasty ‘passing around pointers, and who is responsible for freeing’ issues, I guess. Can you try to reproduce the fault? Thanks, Mark.
On 11 Oct 2017, at 1:52 PM, Tom Parker <tom@carrott.org> wrote:
On 11/10/17 13:02, Mark Webb-Johnson wrote:
Tom,
I think your problem is sdkconfig. That has settings for partition table, fat filesystem, and timer task stack size; all three of your issues.
Can you try to diff your sdkconfig against sdkconfig.default (which contains all the custom settings)? Or just copy sdkconfig.default over your sdkconfig, and then adjust appropriately for what you need custom? You’ll need to ‘make menuconfig’ to confirm things, then I suggest ‘make clean’ and ‘make flash’ to flash everything (partition table, bootloader, etc).
That worked! My sdkconfig was quite far from the default.
Your untested scripts recommendation didn't work as they need to be stored in the events directory, this works:
vfs mkdir /store/events vfs mkdir /store/events/system.start vfs append "wifi mode client <ssid>" /store/events/system.start/startmeup vfs append "vehicle module NL" /store/events/system.start/startmeup vfs mkdir /store/events/network.up vfs append "server v2 start" /store/events/network.up/startmeup
With these in place I get a reboot loop:
I (5822) event: ip: 192.168.43.92, mask: 255.255.255.0, gw: 192.168.43.1 I (5822) ovms-mdns: Launching MDNS service I (5832) script: Running script /store/events/network.up/startmeup Launching OVMS Server V2 connection (oscv2)/home/ubuntu/esp/esp-idf/components/freertos/./heap_regions.c:368 (vPortFreeTagged)- assert failed! abort() was called at PC 0x40085f8f on core 1 0x40085f8f: vPortFreeTagged at /home/ubuntu/esp/esp-idf/components/freertos/./heap_regions.c:410
Backtrace: 0x40088680:0x3ffebe80 0x4008877f:0x3ffebea0 0x40085f8f:0x3ffebec0 0x40088cd1:0x3ffebee0 0x40081f89:0x3ffebf00 0x4000bec7:0x3ffebf20 0x400eff2a:0x3ffebf40 0x400eff54:0x3ffebf70 0x400efcc0:0x3ffebf90 0x40088680: invoke_abort at /home/ubuntu/esp/esp-idf/components/esp32/./panic.c:519 0x4008877f: abort at /home/ubuntu/esp/esp-idf/components/esp32/./panic.c:519 0x40085f8f: vPortFreeTagged at /home/ubuntu/esp/esp-idf/components/freertos/./heap_regions.c:410 0x40088cd1: vPortFree at /home/ubuntu/esp/esp-idf/components/esp32/./heap_alloc_caps.c:323 0x40081f89: _free_r at /home/ubuntu/esp/esp-idf/components/newlib/./syscalls.c:32 0x400eff2a: _ZN11OvmsConsole7ServiceEv at /vagrant/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_console.cpp:215 0x400eff54: _ZThn296_N11OvmsConsole7ServiceEv at ??:? 0x400efcc0: _ZN8TaskBase4TaskEPv at /vagrant/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./task_base.cpp:119
Rebooting...
If I remove the network.up/startmeup file (the file that starts the v2 server client) then it starts up ok and when I start the v2 client manually, it connects to the v2 server and everything works. I tried using the ticker.60 event and got the same crash so it's not a race condition with the wifi startup.
The cause is a double free by the looks of it, and if I comment out the writer->puts called in the v2 server start function, things work:
diff --git a/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp b/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp index 106269e..d1ee797 100644 --- a/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp +++ b/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp @@ -515,7 +515,7 @@ void ovmsv2_start(int verbosity, OvmsWriter* writer, OvmsCommand* cmd, int argc, { if (MyOvmsServerV2 == NULL) { - writer->puts("Launching OVMS Server V2 connection (oscv2)"); + // writer->puts("Launching OVMS Server V2 connection (oscv2)"); MyOvmsServerV2 = new OvmsServerV2("oscv2"); } }
The ESP_LOGI in OvmsServerV2::OvmsServerV2 also gets called, in this code path but doesn't need to be commented out.
Progress! _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
On Wed, 11 Oct 2017, Mark Webb-Johnson wrote:
I think this double-free may be related to the new event script system Steve and I have been working on (in preparation for SMS, etc).
@steve: That seems to be on 'free(event.buffer)' at ovms_console.cpp:215. One of those nasty 'passing around pointers, and who is responsible for freeing' issues, I guess. Can you try to reproduce the fault?
The OvmsConsole::Log(char* message) function expects to be called with a message allocated from the heap (usually by vasprintf()). It was originally implemented to be called only from OvmsCommandApp::Log() as it iterated over all the registered consoles and gave each a separate copy of the message. Thus it was not valid for the script code to call MyUsbConsole->Log() directly. I had not recognized this before. I need to go to bed now, but will study this more tomorrow. This OvmsConsole::Log(char* message) function isn't used for the logging of messages on consoles anymore since I created the LogBuffers class and added OvmsConsole::Log(LogBuffers* message) to handle the console logging more efficiently. The solution may be to remove the problem Log() function completely and proceed with revising your script code to use the new BufferedShell mechanism, presuming that you are OK with it. -- Steve
Thanks, Mark.
On 11 Oct 2017, at 1:52 PM, Tom Parker <tom@carrott.org> wrote:
On 11/10/17 13:02, Mark Webb-Johnson wrote:
Tom,
I think your problem is sdkconfig. That has settings for partition table, fat filesystem, and timer task stack size; all three of your issues.
Can you try to diff your sdkconfig against sdkconfig.default (which contains all the custom settings)? Or just copy sdkconfig.default over your sdkconfig, and then adjust appropriately for what you need custom? You'll need to 'make menuconfig' to confirm things, then I suggest 'make clean' and 'make flash' to flash everything (partition table, bootloader, etc).
That worked! My sdkconfig was quite far from the default.
Your untested scripts recommendation didn't work as they need to be stored in the events directory, this works:
vfs mkdir /store/events vfs mkdir /store/events/system.start vfs append "wifi mode client <ssid>" /store/events/system.start/startmeup vfs append "vehicle module NL" /store/events/system.start/startmeup vfs mkdir /store/events/network.up vfs append "server v2 start" /store/events/network.up/startmeup
With these in place I get a reboot loop:
I (5822) event: ip: 192.168.43.92, mask: 255.255.255.0, gw: 192.168.43.1 I (5822) ovms-mdns: Launching MDNS service I (5832) script: Running script /store/events/network.up/startmeup Launching OVMS Server V2 connection (oscv2)/home/ubuntu/esp/esp-idf/components/freertos/./heap_regions.c:368 (vPortFreeTagged)- assert failed! abort() was called at PC 0x40085f8f on core 1 0x40085f8f: vPortFreeTagged at /home/ubuntu/esp/esp-idf/components/freertos/./heap_regions.c:410
Backtrace: 0x40088680:0x3ffebe80 0x4008877f:0x3ffebea0 0x40085f8f:0x3ffebec0 0x40088cd1:0x3ffebee0 0x40081f89:0x3ffebf00 0x4000bec7:0x3ffebf20 0x400eff2a:0x3ffebf40 0x400eff54:0x3ffebf70 0x400efcc0:0x3ffebf90 0x40088680: invoke_abort at /home/ubuntu/esp/esp-idf/components/esp32/./panic.c:519 0x4008877f: abort at /home/ubuntu/esp/esp-idf/components/esp32/./panic.c:519 0x40085f8f: vPortFreeTagged at /home/ubuntu/esp/esp-idf/components/freertos/./heap_regions.c:410 0x40088cd1: vPortFree at /home/ubuntu/esp/esp-idf/components/esp32/./heap_alloc_caps.c:323 0x40081f89: _free_r at /home/ubuntu/esp/esp-idf/components/newlib/./syscalls.c:32 0x400eff2a: _ZN11OvmsConsole7ServiceEv at /vagrant/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_console.cpp:215 0x400eff54: _ZThn296_N11OvmsConsole7ServiceEv at ??:? 0x400efcc0: _ZN8TaskBase4TaskEPv at /vagrant/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./task_base.cpp:119
Rebooting...
If I remove the network.up/startmeup file (the file that starts the v2 server client) then it starts up ok and when I start the v2 client manually, it connects to the v2 server and everything works. I tried using the ticker.60 event and got the same crash so it's not a race condition with the wifi startup.
The cause is a double free by the looks of it, and if I comment out the writer->puts called in the v2 server start function, things work:
diff --git a/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp b/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp index 106269e..d1ee797 100644 --- a/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp +++ b/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp @@ -515,7 +515,7 @@ void ovmsv2_start(int verbosity, OvmsWriter* writer, OvmsCommand* cmd, int argc, { if (MyOvmsServerV2 == NULL) { - writer->puts("Launching OVMS Server V2 connection (oscv2)"); + // writer->puts("Launching OVMS Server V2 connection (oscv2)"); MyOvmsServerV2 = new OvmsServerV2("oscv2"); } }
The ESP_LOGI in OvmsServerV2::OvmsServerV2 also gets called, in this code path but doesn't need to be commented out.
Progress! _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
On 11/10/17 20:15, Stephen Casner wrote:
The solution may be to remove the problem Log() function completely and proceed with revising your script code to use the new BufferedShell mechanism, presuming that you are OK with it.
I replaced the writer->puts() call with a ESP_LOGI() and it doesn't abort with the v2 server invoked from a script triggered by an event. I don't know whether this really fixes the underlying bug but I've updated my pull request.
On 11/10/17 21:59, Tom Parker wrote:
I replaced the writer->puts() call with a ESP_LOGI() and it doesn't abort with the v2 server invoked from a script triggered by an event. I don't know whether this really fixes the underlying bug but I've updated my pull request.
I implemented part of the environment message and ported over more of the v2 Leaf code. I'm getting close to feature parity with the v2's read only features on the Leaf (assuming you use a wifi hotspot). I've got a little more testing to do and I'll update my pull request.
Tom, I’ve gone ahead and accepted the pull. A couple of minor issues: The #define in vehicle_nissanleaf.h Put back the ovmswriter puts on server startup (as Steve has fixed that) Put in a 60/600 second timer, for transmission of status messages Looks good, compiles, and runs. Regards, Mark.
On 13 Oct 2017, at 4:41 PM, Tom Parker <tom@carrott.org> wrote:
On 11/10/17 21:59, Tom Parker wrote:
I replaced the writer->puts() call with a ESP_LOGI() and it doesn't abort with the v2 server invoked from a script triggered by an event. I don't know whether this really fixes the underlying bug but I've updated my pull request.
I implemented part of the environment message and ported over more of the v2 Leaf code. I'm getting close to feature parity with the v2's read only features on the Leaf (assuming you use a wifi hotspot). I've got a little more testing to do and I'll update my pull request. _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
On 15/10/17 02:47, Mark Webb-Johnson wrote:
1. The #define in vehicle_nissanleaf.h
Should that go in the .h? Is the preprocessor namespace global in cpp, or if I stick it in the private section of the class, will it be a class private define? I'm thinking the former and I should prefix the names with NL or something?
1. Put back the ovmswriter puts on server startup (as Steve has fixed that) 2. Put in a 60/600 second timer, for transmission of status messages
Thanks for fixing these up for me. I've sent another pull request with expanded support for the v2 server messages, including a silly bug fix due to an errant semicolon. I've also ported over some more of the v2 Leaf can bus decoding support, which led me to try to implement "car off" detection, which in v2 on the leaf was done by waiting for the can bus to go quiet. I bodged something together using a ticker and the staleness indicator on the car_on metric, but I think something better could be done in the core framework. I've noticed that the wifi does not reconnect if it goes out of range. I made a terrible network manager to reconnect. It signals some events and I wrote some scripts to execute the relevant commands, mostly because I don't know how to directly execute a command. The network.down event doesn't seem to be generated when the wifi goes down, but system.wifi.sta.disconnected is. I found a very odd bug, if you make a script which calls a command that doesn't log anything, you get a crash in ovms_console.cpp. It took me quite some time to trace this to commands that don't log, because start and stop do log if they're called in the right order, but my terrible network manager would call start whenever the network came up which would die the second time because the v2 client is already running and doesn't log anything if you try to start it again. In my terrible network manager branch I have worked around this by making the v2 server log even if it's already running or stopped but that obviously doesn't fix the underlying bug. It can be reproduced with the ticker event: OVMS > vfs mkdir /store/events/ticker.10 OVMS > vfs append "server v2 stop" /store/events/ticker.10/tick I (23885) script: Running script /store/events/ticker.10/tick Guru Meditation Error of type LoadProhibited occurred on core 1. Exception was unhandled. Register dump: PC : 0x400efb54 PS : 0x00060f30 A0 : 0x800efc07 A1 : 0x3ffe5220 0x400efb54: _ZN11OvmsConsole7ServiceEv at /vagrant/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_console.cpp:58 A2 : 0x3ffe200c A3 : 0x00000000 A4 : 0x00010002 A5 : 0x00000014 A6 : 0x00000008 A7 : 0x00000000 A8 : 0x800efb35 A9 : 0x3ffe5200 A10 : 0x00000001 A11 : 0x3ffc13cc A12 : 0x00000001 A13 : 0x00000000 A14 : 0x3ffe2c2c A15 : 0xff000000 SAR : 0x0000001e EXCCAUSE: 0x0000001c EXCVADDR: 0x00000004 LBEG : 0x4000c2e0 LEND : 0x4000c2f6 LCOUNT : 0xffffffff Backtrace: 0x400efb54:0x3ffe5220 0x400efc04:0x3ffe5250 0x400ef8b4:0x3ffe5270 0x400efb54: _ZN11OvmsConsole7ServiceEv at /vagrant/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_console.cpp:58 0x400efc04: _ZThn304_N11OvmsConsole7ServiceEv at ??:? 0x400ef8b4: _ZN8TaskBase4TaskEPv at /vagrant/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./task_base.cpp:126 Rebooting...
Mark, I just sent a Pull request for the initial Kia Soul EV-stub. I’m still a newbie on GIT so forgive me if I make a mess! Most of the time spent so far is setting up esp-idf and trying to figure out GIT again 🙂 Geir
Hi Geir, I see you've got Soule on line 41, and you've used the NL vehicle code on line 63 of vehicle_kiasoulev.cpp. Otherwise it looks good. I've been porting the Leaf v2 logic with as few changes as possible. The changes are mostly simple, replacement of can_databuffer with d and replacing the global state variables with metrics setters. I can still make sense of a diff between the v3 .cpp file and the v2 .c file. Once I have full feature parity between v2 and v3, I'll probably refactor the cpp code some. On 23/10/17 09:50, Geir Øyvind Vælidalo wrote:
Mark,
I just sent a Pull request for the initial Kia Soul EV-stub. I’m still a newbie on GIT so forgive me if I make a mess! Most of the time spent so far is setting up esp-idf and trying to figure out GIT again 🙂
Geir
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
All good. I merged it, and changed NL->KS on line 41. Regards, Mark.
On 23 Oct 2017, at 9:19 AM, Tom Parker <tom@carrott.org> wrote:
Hi Geir,
I see you've got Soule on line 41, and you've used the NL vehicle code on line 63 of vehicle_kiasoulev.cpp.
Otherwise it looks good.
I've been porting the Leaf v2 logic with as few changes as possible. The changes are mostly simple, replacement of can_databuffer with d and replacing the global state variables with metrics setters. I can still make sense of a diff between the v3 .cpp file and the v2 .c file. Once I have full feature parity between v2 and v3, I'll probably refactor the cpp code some.
On 23/10/17 09:50, Geir Øyvind Vælidalo wrote:
Mark,
I just sent a Pull request for the initial Kia Soul EV-stub. I’m still a newbie on GIT so forgive me if I make a mess! Most of the time spent so far is setting up esp-idf and trying to figure out GIT again 🙂
Geir
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Great! I missed the NL-part🙂 Is the poll functionality/framework in place, by the way? Geir Sendt fra min iPhone
23. okt. 2017 kl. 03:52 skrev Mark Webb-Johnson <mark@webb-johnson.net>:
All good. I merged it, and changed NL->KS on line 41.
Regards, Mark.
On 23 Oct 2017, at 9:19 AM, Tom Parker <tom@carrott.org> wrote:
Hi Geir,
I see you've got Soule on line 41, and you've used the NL vehicle code on line 63 of vehicle_kiasoulev.cpp.
Otherwise it looks good.
I've been porting the Leaf v2 logic with as few changes as possible. The changes are mostly simple, replacement of can_databuffer with d and replacing the global state variables with metrics setters. I can still make sense of a diff between the v3 .cpp file and the v2 .c file. Once I have full feature parity between v2 and v3, I'll probably refactor the cpp code some.
On 23/10/17 09:50, Geir Øyvind Vælidalo wrote: Mark,
I just sent a Pull request for the initial Kia Soul EV-stub. I’m still a newbie on GIT so forgive me if I make a mess! Most of the time spent so far is setting up esp-idf and trying to figure out GIT again 🙂
Geir
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Is the poll functionality/framework in place, by the way?
Nope. And, I think that will have to be mine to do (as pretty fundamental) - unless someone else wants to step forward :-) What do people think of the v2 polling mechanism? Shall I just straight port it (moving to the object model, of course), or are there things we need to change/improve to make it more usable? Regards, Mark.
On 23 Oct 2017, at 2:05 PM, Geir Øyvind Vælidalo <geir@validalo.net> wrote:
Great! I missed the NL-part🙂
Is the poll functionality/framework in place, by the way?
Geir
Sendt fra min iPhone
23. okt. 2017 kl. 03:52 skrev Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>>:
All good. I merged it, and changed NL->KS on line 41.
Regards, Mark.
On 23 Oct 2017, at 9:19 AM, Tom Parker <tom@carrott.org <mailto:tom@carrott.org>> wrote:
Hi Geir,
I see you've got Soule on line 41, and you've used the NL vehicle code on line 63 of vehicle_kiasoulev.cpp.
Otherwise it looks good.
I've been porting the Leaf v2 logic with as few changes as possible. The changes are mostly simple, replacement of can_databuffer with d and replacing the global state variables with metrics setters. I can still make sense of a diff between the v3 .cpp file and the v2 .c file. Once I have full feature parity between v2 and v3, I'll probably refactor the cpp code some.
On 23/10/17 09:50, Geir Øyvind Vælidalo wrote:
Mark,
I just sent a Pull request for the initial Kia Soul EV-stub. I’m still a newbie on GIT so forgive me if I make a mess! Most of the time spent so far is setting up esp-idf and trying to figure out GIT again 🙂
Geir
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
I think the V2 polling mechanism is ok. Can’t think of anything that I was missing... A port must be able to handle all three can buses though 🙂 Geir Sendt fra min iPhone
23. okt. 2017 kl. 08:19 skrev Mark Webb-Johnson <mark@webb-johnson.net>:
Is the poll functionality/framework in place, by the way?
Nope. And, I think that will have to be mine to do (as pretty fundamental) - unless someone else wants to step forward :-)
What do people think of the v2 polling mechanism? Shall I just straight port it (moving to the object model, of course), or are there things we need to change/improve to make it more usable?
Regards, Mark.
On 23 Oct 2017, at 2:05 PM, Geir Øyvind Vælidalo <geir@validalo.net> wrote:
Great! I missed the NL-part🙂
Is the poll functionality/framework in place, by the way?
Geir
Sendt fra min iPhone
23. okt. 2017 kl. 03:52 skrev Mark Webb-Johnson <mark@webb-johnson.net>:
All good. I merged it, and changed NL->KS on line 41.
Regards, Mark.
On 23 Oct 2017, at 9:19 AM, Tom Parker <tom@carrott.org> wrote:
Hi Geir,
I see you've got Soule on line 41, and you've used the NL vehicle code on line 63 of vehicle_kiasoulev.cpp.
Otherwise it looks good.
I've been porting the Leaf v2 logic with as few changes as possible. The changes are mostly simple, replacement of can_databuffer with d and replacing the global state variables with metrics setters. I can still make sense of a diff between the v3 .cpp file and the v2 .c file. Once I have full feature parity between v2 and v3, I'll probably refactor the cpp code some.
On 23/10/17 09:50, Geir Øyvind Vælidalo wrote: Mark,
I just sent a Pull request for the initial Kia Soul EV-stub. I’m still a newbie on GIT so forgive me if I make a mess! Most of the time spent so far is setting up esp-idf and trying to figure out GIT again 🙂
Geir
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Looking at the vehicle modules now, I think we can standardise a few things in vehicle.{h,cpp} base class: Simple registration of CAN buses required to be listened on, mode and speed. Virtual functions for receiving CAN bus messages on can1, can2, and can3. Incoming CAN message queue and reception task (with dispatch to appropriate virtual receiving function). That way, the vehicle module just has to call the function to configure the CAN ports it requires, then handle the incoming CAN messages in a virtual function. No messing around with tasks/queues. The reason we need this standardised is because for the poll functions we need to be able to intercept incoming poll reply messages and convert them to PID polling - having the individual vehicle modules handle the incoming message queue makes that tricky. Once that is done, then for this polling: Simple registration of PIDs to be polled, on which modules. Poll mode set (like v2). If polling, look at incoming CAN bus messages and don’t pass on to the raw message handlers if it is a poll response. Virtual function for receiving poll responses. I’ll have a look at it. Probably have to do a quick port of the vehicle_obdii code from v2, in order to be able to test it. Regards, Mark.
On 23 Oct 2017, at 2:49 PM, Geir Øyvind Vælidalo <geir@validalo.net> wrote:
I think the V2 polling mechanism is ok. Can’t think of anything that I was missing... A port must be able to handle all three can buses though 🙂
Geir
Sendt fra min iPhone
23. okt. 2017 kl. 08:19 skrev Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>>:
Is the poll functionality/framework in place, by the way?
Nope. And, I think that will have to be mine to do (as pretty fundamental) - unless someone else wants to step forward :-)
What do people think of the v2 polling mechanism? Shall I just straight port it (moving to the object model, of course), or are there things we need to change/improve to make it more usable?
Regards, Mark.
On 23 Oct 2017, at 2:05 PM, Geir Øyvind Vælidalo <geir@validalo.net <mailto:geir@validalo.net>> wrote:
Great! I missed the NL-part🙂
Is the poll functionality/framework in place, by the way?
Geir
Sendt fra min iPhone
23. okt. 2017 kl. 03:52 skrev Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>>:
All good. I merged it, and changed NL->KS on line 41.
Regards, Mark.
On 23 Oct 2017, at 9:19 AM, Tom Parker <tom@carrott.org <mailto:tom@carrott.org>> wrote:
Hi Geir,
I see you've got Soule on line 41, and you've used the NL vehicle code on line 63 of vehicle_kiasoulev.cpp.
Otherwise it looks good.
I've been porting the Leaf v2 logic with as few changes as possible. The changes are mostly simple, replacement of can_databuffer with d and replacing the global state variables with metrics setters. I can still make sense of a diff between the v3 .cpp file and the v2 .c file. Once I have full feature parity between v2 and v3, I'll probably refactor the cpp code some.
On 23/10/17 09:50, Geir Øyvind Vælidalo wrote:
Mark,
I just sent a Pull request for the initial Kia Soul EV-stub. I’m still a newbie on GIT so forgive me if I make a mess! Most of the time spent so far is setting up esp-idf and trying to figure out GIT again 🙂
Geir
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Sounds good! No point in duplicating code for each vehicle. Geir Sendt fra min iPhone
23. okt. 2017 kl. 09:00 skrev Mark Webb-Johnson <mark@webb-johnson.net>:
Looking at the vehicle modules now, I think we can standardise a few things in vehicle.{h,cpp} base class:
Simple registration of CAN buses required to be listened on, mode and speed. Virtual functions for receiving CAN bus messages on can1, can2, and can3. Incoming CAN message queue and reception task (with dispatch to appropriate virtual receiving function).
That way, the vehicle module just has to call the function to configure the CAN ports it requires, then handle the incoming CAN messages in a virtual function. No messing around with tasks/queues. The reason we need this standardised is because for the poll functions we need to be able to intercept incoming poll reply messages and convert them to PID polling - having the individual vehicle modules handle the incoming message queue makes that tricky.
Once that is done, then for this polling:
Simple registration of PIDs to be polled, on which modules. Poll mode set (like v2). If polling, look at incoming CAN bus messages and don’t pass on to the raw message handlers if it is a poll response. Virtual function for receiving poll responses.
I’ll have a look at it. Probably have to do a quick port of the vehicle_obdii code from v2, in order to be able to test it.
Regards, Mark.
On 23 Oct 2017, at 2:49 PM, Geir Øyvind Vælidalo <geir@validalo.net> wrote:
I think the V2 polling mechanism is ok. Can’t think of anything that I was missing... A port must be able to handle all three can buses though 🙂
Geir
Sendt fra min iPhone
23. okt. 2017 kl. 08:19 skrev Mark Webb-Johnson <mark@webb-johnson.net>:
Is the poll functionality/framework in place, by the way?
Nope. And, I think that will have to be mine to do (as pretty fundamental) - unless someone else wants to step forward :-)
What do people think of the v2 polling mechanism? Shall I just straight port it (moving to the object model, of course), or are there things we need to change/improve to make it more usable?
Regards, Mark.
On 23 Oct 2017, at 2:05 PM, Geir Øyvind Vælidalo <geir@validalo.net> wrote:
Great! I missed the NL-part🙂
Is the poll functionality/framework in place, by the way?
Geir
Sendt fra min iPhone
23. okt. 2017 kl. 03:52 skrev Mark Webb-Johnson <mark@webb-johnson.net>:
All good. I merged it, and changed NL->KS on line 41.
Regards, Mark.
On 23 Oct 2017, at 9:19 AM, Tom Parker <tom@carrott.org> wrote:
Hi Geir,
I see you've got Soule on line 41, and you've used the NL vehicle code on line 63 of vehicle_kiasoulev.cpp.
Otherwise it looks good.
I've been porting the Leaf v2 logic with as few changes as possible. The changes are mostly simple, replacement of can_databuffer with d and replacing the global state variables with metrics setters. I can still make sense of a diff between the v3 .cpp file and the v2 .c file. Once I have full feature parity between v2 and v3, I'll probably refactor the cpp code some.
> On 23/10/17 09:50, Geir Øyvind Vælidalo wrote: > Mark, > > I just sent a Pull request for the initial Kia Soul EV-stub. > I’m still a newbie on GIT so forgive me if I make a mess! Most of the time spent so far is setting up esp-idf and trying to figure out GIT again 🙂 > > Geir > > > > > _______________________________________________ > OvmsDev mailing list > OvmsDev@lists.teslaclub.hk > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
I’ve implemented the first part of this. It does look very neat, and seems to work well. A lot of duplication in the vehicle modules has been removed. But, it will break vehicle module implementations, so I’ve updated those as well. All is in GitHub now, so please pull, merge, and check. I’ve also updated the developer’s documentation to reflect these changes. I’ll work on the polling next, although that will probably not be quite so simple. Regards, Mark.
On 23 Oct 2017, at 3:00 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Looking at the vehicle modules now, I think we can standardise a few things in vehicle.{h,cpp} base class:
Simple registration of CAN buses required to be listened on, mode and speed. Virtual functions for receiving CAN bus messages on can1, can2, and can3. Incoming CAN message queue and reception task (with dispatch to appropriate virtual receiving function).
That way, the vehicle module just has to call the function to configure the CAN ports it requires, then handle the incoming CAN messages in a virtual function. No messing around with tasks/queues. The reason we need this standardised is because for the poll functions we need to be able to intercept incoming poll reply messages and convert them to PID polling - having the individual vehicle modules handle the incoming message queue makes that tricky.
Once that is done, then for this polling:
Simple registration of PIDs to be polled, on which modules. Poll mode set (like v2). If polling, look at incoming CAN bus messages and don’t pass on to the raw message handlers if it is a poll response. Virtual function for receiving poll responses.
I’ll have a look at it. Probably have to do a quick port of the vehicle_obdii code from v2, in order to be able to test it.
Regards, Mark.
On 23 Oct 2017, at 2:49 PM, Geir Øyvind Vælidalo <geir@validalo.net <mailto:geir@validalo.net>> wrote:
I think the V2 polling mechanism is ok. Can’t think of anything that I was missing... A port must be able to handle all three can buses though 🙂
Geir
Sendt fra min iPhone
23. okt. 2017 kl. 08:19 skrev Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>>:
Is the poll functionality/framework in place, by the way?
Nope. And, I think that will have to be mine to do (as pretty fundamental) - unless someone else wants to step forward :-)
What do people think of the v2 polling mechanism? Shall I just straight port it (moving to the object model, of course), or are there things we need to change/improve to make it more usable?
Regards, Mark.
On 23 Oct 2017, at 2:05 PM, Geir Øyvind Vælidalo <geir@validalo.net <mailto:geir@validalo.net>> wrote:
Great! I missed the NL-part🙂
Is the poll functionality/framework in place, by the way?
Geir
Sendt fra min iPhone
23. okt. 2017 kl. 03:52 skrev Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>>:
All good. I merged it, and changed NL->KS on line 41.
Regards, Mark.
On 23 Oct 2017, at 9:19 AM, Tom Parker <tom@carrott.org <mailto:tom@carrott.org>> wrote:
Hi Geir,
I see you've got Soule on line 41, and you've used the NL vehicle code on line 63 of vehicle_kiasoulev.cpp.
Otherwise it looks good.
I've been porting the Leaf v2 logic with as few changes as possible. The changes are mostly simple, replacement of can_databuffer with d and replacing the global state variables with metrics setters. I can still make sense of a diff between the v3 .cpp file and the v2 .c file. Once I have full feature parity between v2 and v3, I'll probably refactor the cpp code some.
On 23/10/17 09:50, Geir Øyvind Vælidalo wrote: > Mark, > > I just sent a Pull request for the initial Kia Soul EV-stub. > I’m still a newbie on GIT so forgive me if I make a mess! Most of the time spent so far is setting up esp-idf and trying to figure out GIT again 🙂 > > Geir > > > > > _______________________________________________ > OvmsDev mailing list > OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
I’ve done a rough port of the vehicle PID polling framework into OVMS v3. Kept things as similar as possible, but simplified a bunch (from the vehicle module point of view). I’ve also ported vehicle_obdii as an example for those of you needing PID polling. Only very roughly tested. You’ll also find Ticker1() .. Ticker3600() virtual functions in the vehicle.h, that you can now override to do your own timer based stuff. No need to hook into the event framework (as I guess pretty much all vehicles will need this functionality, as did the poller - which is why I implemented it). Let me know how you get on with it. Regards, Mark. P.S. The “can can1 trace on” functionality is very very useful.
On 23 Oct 2017, at 8:06 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
I’ve implemented the first part of this. It does look very neat, and seems to work well. A lot of duplication in the vehicle modules has been removed.
But, it will break vehicle module implementations, so I’ve updated those as well. All is in GitHub now, so please pull, merge, and check.
I’ve also updated the developer’s documentation to reflect these changes.
I’ll work on the polling next, although that will probably not be quite so simple.
Regards, Mark.
On 23 Oct 2017, at 3:00 PM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
Looking at the vehicle modules now, I think we can standardise a few things in vehicle.{h,cpp} base class:
Simple registration of CAN buses required to be listened on, mode and speed. Virtual functions for receiving CAN bus messages on can1, can2, and can3. Incoming CAN message queue and reception task (with dispatch to appropriate virtual receiving function).
That way, the vehicle module just has to call the function to configure the CAN ports it requires, then handle the incoming CAN messages in a virtual function. No messing around with tasks/queues. The reason we need this standardised is because for the poll functions we need to be able to intercept incoming poll reply messages and convert them to PID polling - having the individual vehicle modules handle the incoming message queue makes that tricky.
Once that is done, then for this polling:
Simple registration of PIDs to be polled, on which modules. Poll mode set (like v2). If polling, look at incoming CAN bus messages and don’t pass on to the raw message handlers if it is a poll response. Virtual function for receiving poll responses.
I’ll have a look at it. Probably have to do a quick port of the vehicle_obdii code from v2, in order to be able to test it.
Regards, Mark.
On 23 Oct 2017, at 2:49 PM, Geir Øyvind Vælidalo <geir@validalo.net <mailto:geir@validalo.net>> wrote:
I think the V2 polling mechanism is ok. Can’t think of anything that I was missing... A port must be able to handle all three can buses though 🙂
Geir
Sendt fra min iPhone
23. okt. 2017 kl. 08:19 skrev Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>>:
Is the poll functionality/framework in place, by the way?
Nope. And, I think that will have to be mine to do (as pretty fundamental) - unless someone else wants to step forward :-)
What do people think of the v2 polling mechanism? Shall I just straight port it (moving to the object model, of course), or are there things we need to change/improve to make it more usable?
Regards, Mark.
On 23 Oct 2017, at 2:05 PM, Geir Øyvind Vælidalo <geir@validalo.net <mailto:geir@validalo.net>> wrote:
Great! I missed the NL-part🙂
Is the poll functionality/framework in place, by the way?
Geir
Sendt fra min iPhone
23. okt. 2017 kl. 03:52 skrev Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>>:
All good. I merged it, and changed NL->KS on line 41.
Regards, Mark.
> On 23 Oct 2017, at 9:19 AM, Tom Parker <tom@carrott.org <mailto:tom@carrott.org>> wrote: > > Hi Geir, > > I see you've got Soule on line 41, and you've used the NL vehicle code on line 63 of vehicle_kiasoulev.cpp. > > Otherwise it looks good. > > I've been porting the Leaf v2 logic with as few changes as possible. The changes are mostly simple, replacement of can_databuffer with d and replacing the global state variables with metrics setters. I can still make sense of a diff between the v3 .cpp file and the v2 .c file. Once I have full feature parity between v2 and v3, I'll probably refactor the cpp code some. > > On 23/10/17 09:50, Geir Øyvind Vælidalo wrote: >> Mark, >> >> I just sent a Pull request for the initial Kia Soul EV-stub. >> I’m still a newbie on GIT so forgive me if I make a mess! Most of the time spent so far is setting up esp-idf and trying to figure out GIT again 🙂 >> >> Geir >> >> >> >> >> _______________________________________________ >> OvmsDev mailing list >> OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> >> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev> > > _______________________________________________ > OvmsDev mailing list > OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
The #define will be seen by anything that pulls in vehicle_nissanleaf.h. You are pretty safe in this case, as vehicle_nissanleaf.cpp is probably the only thing that will ever pull in that .h. Classes don’t have private #defines. That is a pre-processor directive, so is actually processed even before the C/C++ compiler is called. Steve is looking at the ovms_command issue you identified. I think he’s fixed it already (based on commit history), but will leave him to reply. Very helpful - please keep hacking away at this to discover the edge cases. I think the car-on and car-off detection will always be vehicle-specific. Perhaps something to help with this could be done in vehicle.{h,cpp}? Perhaps a CarAwakeTickle() function that the car module calls, and if that is not called in N seconds, then vehicle.{h,cpp} automatically records the car as off? Just not sure how many vehicles would need this. Perhaps simplest for you to implement: OvmsVehicleNissanLeaf::CarAwakeTickle() If metrics show car is off, then make it as on. Reset car awake tickle counter OvmsVehicleNissanLeaf::Ticker1 A generic ticker to increment car awake tickle counter, and if it hits a limit then to metric the car as off. Or, however you think best to implement this. The idea is to implement it using a generic mechanism, but in OvmsVehicleNissanLeaf class. If it is found to be generically useful, then it can simply be moved to the vehicle.{h,cpp} parent class and is then available everyone. For high-level events like car-off, car-started, car-asleep, etc, I think these can be handled at a high level (probably in vehicle.{h,cpp}). Regards, Mark.
On 22 Oct 2017, at 6:40 PM, Tom Parker <tom@carrott.org> wrote:
On 15/10/17 02:47, Mark Webb-Johnson wrote:
The #define in vehicle_nissanleaf.h
Should that go in the .h? Is the preprocessor namespace global in cpp, or if I stick it in the private section of the class, will it be a class private define? I'm thinking the former and I should prefix the names with NL or something?
Put back the ovmswriter puts on server startup (as Steve has fixed that) Put in a 60/600 second timer, for transmission of status messages
Thanks for fixing these up for me.
I've sent another pull request with expanded support for the v2 server messages, including a silly bug fix due to an errant semicolon.
I've also ported over some more of the v2 Leaf can bus decoding support, which led me to try to implement "car off" detection, which in v2 on the leaf was done by waiting for the can bus to go quiet. I bodged something together using a ticker and the staleness indicator on the car_on metric, but I think something better could be done in the core framework.
I've noticed that the wifi does not reconnect if it goes out of range. I made a terrible network manager to reconnect. It signals some events and I wrote some scripts to execute the relevant commands, mostly because I don't know how to directly execute a command.
The network.down event doesn't seem to be generated when the wifi goes down, but system.wifi.sta.disconnected is.
I found a very odd bug, if you make a script which calls a command that doesn't log anything, you get a crash in ovms_console.cpp. It took me quite some time to trace this to commands that don't log, because start and stop do log if they're called in the right order, but my terrible network manager would call start whenever the network came up which would die the second time because the v2 client is already running and doesn't log anything if you try to start it again.
In my terrible network manager branch I have worked around this by making the v2 server log even if it's already running or stopped but that obviously doesn't fix the underlying bug. It can be reproduced with the ticker event:
OVMS > vfs mkdir /store/events/ticker.10 OVMS > vfs append "server v2 stop" /store/events/ticker.10/tick I (23885) script: Running script /store/events/ticker.10/tick Guru Meditation Error of type LoadProhibited occurred on core 1. Exception was unhandled. Register dump: PC : 0x400efb54 PS : 0x00060f30 A0 : 0x800efc07 A1 : 0x3ffe5220 0x400efb54: _ZN11OvmsConsole7ServiceEv at /vagrant/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_console.cpp:58
A2 : 0x3ffe200c A3 : 0x00000000 A4 : 0x00010002 A5 : 0x00000014 A6 : 0x00000008 A7 : 0x00000000 A8 : 0x800efb35 A9 : 0x3ffe5200 A10 : 0x00000001 A11 : 0x3ffc13cc A12 : 0x00000001 A13 : 0x00000000 A14 : 0x3ffe2c2c A15 : 0xff000000 SAR : 0x0000001e EXCCAUSE: 0x0000001c EXCVADDR: 0x00000004 LBEG : 0x4000c2e0 LEND : 0x4000c2f6 LCOUNT : 0xffffffff
Backtrace: 0x400efb54:0x3ffe5220 0x400efc04:0x3ffe5250 0x400ef8b4:0x3ffe5270 0x400efb54: _ZN11OvmsConsole7ServiceEv at /vagrant/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_console.cpp:58
0x400efc04: _ZThn304_N11OvmsConsole7ServiceEv at ??:?
0x400ef8b4: _ZN8TaskBase4TaskEPv at /vagrant/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./task_base.cpp:126
Rebooting...
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
On 23/10/17 16:05, Mark Webb-Johnson wrote:
The #define will be seen by anything that pulls in vehicle_nissanleaf.h. You are pretty safe in this case, as vehicle_nissanleaf.cpp is probably the only thing that will ever pull in that .h.
Classes don’t have private #defines. That is a pre-processor directive, so is actually processed even before the C/C++ compiler is called.
Yeah, I thought it would work like that. I've moved the defines to the .h file without changing their names, rebased, tested and pushed to my branch.
I think the car-on and car-off detection will always be vehicle-specific. Perhaps something to help with this could be done in vehicle.{h,cpp}? Perhaps a CarAwakeTickle() function that the car module calls, and if that is not called in N seconds, then vehicle.{h,cpp} automatically records the car as off? Just not sure how many vehicles would need this. Perhaps simplest for you to implement:
I'll see what I can prototype in the leaf code and if it's generally useful it can be pulled out.
For high-level events like car-off, car-started, car-asleep, etc, I think these can be handled at a high level (probably in vehicle.{h,cpp}).
Yes, once the condition is actually identified, it makes sense to trigger a shared event for common functionality to build upon.
On Sun, 22 Oct 2017, Tom Parker wrote:
I found a very odd bug, if you make a script which calls a command that doesn't log anything, you get a crash in ovms_console.cpp. It took me quite some time to trace this to commands that don't log, because start and stop do log if they're called in the right order, but my terrible network manager would call start whenever the network came up which would die the second time because the v2 client is already running and doesn't log anything if you try to start it again.
When the code in ovms_console was written it was not possible for a LogBuffers object to have no buffers because it was only created at the same time as the first buffer was inserted. When I began using LogBuffers to collect the output of BufferedShell, this was no longer true. I fixed the crash by checking for the empty case. A second commit was required because the first one resulted in leaking the empty LogBuffers. However, while checking about that leak I see what looks like a leak of another 108-byte block every time the tick script runs. I have not identified that yet. Also, I think if I call the tick script from another one I can get a different (related) crash. About to test that one. -- Steve
On Sun, 22 Oct 2017, Stephen Casner wrote:
However, while checking about that leak I see what looks like a leak of another 108-byte block every time the tick script runs. I have not identified that yet.
I don't have the answer yet regarding why this memory is leaked, but I can answer how it is leaked. The following may serve as an example for using the debugging tools I've implemented to explore other memory leaks. First, I use the 'module memory' command before and after the event that causes the leak to see what it looks like: OVMS > module memory ============================ Free 8-bit 37284/217136, 32-bit 18588/43560, numafter = 950 ============================ I (172019) script: Running script /store/events/ticker.10/tick OVMS > module memory ============================ Free 8-bit 37176/217136, 32-bit 18588/43560, numafter = 951 task=Tmr total= 0 2752 0 change= +0 +108 +0 ============================ Here 108 bytes are leaked each time the script runs. This could be more than one block, but I've seen this size before and am guessing that it is one block. Since I don't know where the allocation is occurring, I can use the "module abort" command to force an abort at the point where the allocation is made. The abort is restricted to allocations made by the named task and for a particular size since there may be other blocks of different sizes successfully allocated and freed. OVMS > module abort ? Usage: module abort <task> <count> [<size>] OVMS > module abort Tmr 1 108 OVMS > abort() was called at PC 0x40085a3b on core 0 0x40085a3b: mem_malloc_block at /Users/casner/src/github/esp-idf/components/freertos/./heap_regions_debug.c:214 [snip the automatic backtrace since gdb's is better] Entering gdb stub now. [more snip] Remote debugging using /dev/cu.SLAB_USBtoUART 0x40088c8c in invoke_abort () at /Users/casner/src/github/esp-idf/components/esp32/./panic.c:125 125 *((int*) 0) = 0; (gdb) bt #0 0x40088c8c in invoke_abort () at /Users/casner/src/github/esp-idf/components/esp32/./panic.c:125 #1 0x40088d5a in abort () at /Users/casner/src/github/esp-idf/components/esp32/./panic.c:134 #2 0x40085a3e in mem_malloc_block (data=0x3fffb400) at /Users/casner/src/github/esp-idf/components/freertos/./heap_regions_debug.c:214 #3 0x4008547a in pvPortMallocTagged (xWantedSize=<optimized out>, tag=<optimized out>) at /Users/casner/src/github/esp-idf/components/freertos/./heap_regions.c:308 #4 0x4008938b in pvPortMallocCaps (xWantedSize=84, caps=4) at /Users/casner/src/github/esp-idf/components/esp32/./heap_alloc_caps.c:372 #5 0x400893cc in pvPortMalloc (xWantedSize=84) at /Users/casner/src/github/esp-idf/components/esp32/./heap_alloc_caps.c:306 #6 0x40085e8a in xQueueGenericCreate (uxQueueLength=1, uxItemSize=0, ucQueueType=4 '\004') at /Users/casner/src/github/esp-idf/components/freertos/./queue.c:388 #7 0x400860bb in xQueueCreateMutex (ucQueueType=4 '\004') at /Users/casner/src/github/esp-idf/components/freertos/./queue.c:495 #8 0x40081db9 in lock_init_generic (lock=0x3ffca87c, mutex_type=4 '\004') at /Users/casner/src/github/esp-idf/components/newlib/./locks.c:79 #9 0x40081eca in _lock_init_recursive (lock=0x3ffca87c) at /Users/casner/src/github/esp-idf/components/newlib/./locks.c:95 #10 0x4000bde8 in ?? () #11 0x40001ef3 in ?? () #12 0x400d72c2 in _fopen_r (ptr=0x3ffd96d0, file=0x3fff66dc "/store/events/ticker.10/tick", mode=0x3f4167e0 "r") at ../../../.././newlib/libc/stdio/fopen.c:138 #13 0x400d735f in fopen (file=0x3fff66dc "/store/events/ticker.10/tick", mode=0x3f4167e0 "r") at ../../../.././newlib/libc/stdio/fopen.c:181 #14 0x400f57f9 in OvmsScripts::AllScripts (this=<optimized out>, path=...) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/main/./ovms_script.cpp:102 #15 0x400f58d8 in OvmsScripts::EventScript (this=0x3ffc3c7c <MyScripts>, event=..., data=<optimized out>) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/main/./ovms_script.cpp:122 #16 0x400f02a9 in OvmsEvents::SignalEvent (this=<optimized out>, event=..., data=0x0) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/main/./ovms_events.cpp:117 #17 0x400f0f1a in Housekeeping::Ticker1 (this=0x3ffda03c) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/main/./ovms_housekeeping.cpp:182 #18 0x400f1053 in HousekeepingTicker1 (timer=0x3ffd6878) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/main/./ovms_housekeeping.cpp:56 #19 0x40087ca9 in prvProcessExpiredTimer (xNextExpireTime=170009, xTimeNow=170009) at /Users/casner/src/github/esp-idf/components/freertos/./timers.c:422 #20 0x40087cdc in prvProcessTimerOrBlockTask (xNextExpireTime=170009, xListWasEmpty=<optimized out>) at /Users/casner/src/github/esp-idf/components/freertos/./timers.c:469 #21 0x40087de7 in prvTimerTask (pvParameters=0x0) at /Users/casner/src/github/esp-idf/components/freertos/./timers.c:442 (gdb) Here I see that this allocation is a FreeRTOS Queue to serve as a lock for file I/O during fopen(). I assume that Queue should be freed when the file is closed. So there may be multiple blocks of the same size allocated, and perhaps this is not the one that is leaked. I can specify not to abort until some number of blocks of the requested size have been allocated. So I try again specifying a count of 2 rather than 1. OVMS > module abort Tmr 2 108 (gdb) bt #0 0x40088c8c in invoke_abort () at /Users/casner/src/github/esp-idf/components/esp32/./panic.c:125 #1 0x40088d5a in abort () at /Users/casner/src/github/esp-idf/components/esp32/./panic.c:134 #2 0x40085a3e in mem_malloc_block (data=0x3fff69bc) at /Users/casner/src/github/esp-idf/components/freertos/./heap_regions_debug.c:214 #3 0x4008547a in pvPortMallocTagged (xWantedSize=<optimized out>, tag=<optimized out>) at /Users/casner/src/github/esp-idf/components/freertos/./heap_regions.c:308 #4 0x4008938b in pvPortMallocCaps (xWantedSize=84, caps=4) at /Users/casner/src/github/esp-idf/components/esp32/./heap_alloc_caps.c:372 #5 0x400893cc in pvPortMalloc (xWantedSize=84) at /Users/casner/src/github/esp-idf/components/esp32/./heap_alloc_caps.c:306 #6 0x40085e8a in xQueueGenericCreate (uxQueueLength=1, uxItemSize=0, ucQueueType=4 '\004') at /Users/casner/src/github/esp-idf/components/freertos/./queue.c:388 #7 0x400860bb in xQueueCreateMutex (ucQueueType=4 '\004') at /Users/casner/src/github/esp-idf/components/freertos/./queue.c:495 #8 0x40081db9 in lock_init_generic (lock=0x3ffca87c, mutex_type=4 '\004') at /Users/casner/src/github/esp-idf/components/newlib/./locks.c:79 #9 0x40081ddf in lock_acquire_generic (lock=0x3ffca87c, delay=4294967295, mutex_type=4 '\004') at /Users/casner/src/github/esp-idf/components/newlib/./locks.c:132 #10 0x40081f24 in _lock_acquire_recursive (lock=0x3ffca87c) at /Users/casner/src/github/esp-idf/components/newlib/./locks.c:169 #11 0x4000be38 in ?? () #12 0x40002031 in ?? () #13 0x400020b8 in ?? () #14 0x400f584c in OvmsScripts::AllScripts (this=<optimized out>, path=...) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/main/./ovms_script.cpp:108 #15 0x400f58f4 in OvmsScripts::EventScript (this=0x3ffc3c7c <MyScripts>, event=..., data=<optimized out>) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/main/./ovms_script.cpp:123 #16 0x400f02b1 in OvmsEvents::SignalEvent (this=<optimized out>, event=..., data=0x0) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/main/./ovms_events.cpp:117 #17 0x400f0f22 in Housekeeping::Ticker1 (this=0x3ffda03c) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/main/./ovms_housekeeping.cpp:182 #18 0x400f105b in HousekeepingTicker1 (timer=0x3ffd6878) at /Users/casner/src/github/ovms/vehicle/OVMS.V3/main/./ovms_housekeeping.cpp:56 #19 0x40087ca9 in prvProcessExpiredTimer (xNextExpireTime=5009, xTimeNow=5009) at /Users/casner/src/github/esp-idf/components/freertos/./timers.c:422 #20 0x40087cdc in prvProcessTimerOrBlockTask (xNextExpireTime=5009, xListWasEmpty=<optimized out>) at /Users/casner/src/github/esp-idf/components/freertos/./timers.c:469 #21 0x40087de7 in prvTimerTask (pvParameters=0x0) at /Users/casner/src/github/esp-idf/components/freertos/./timers.c:442 (gdb) q This abort is pretty similar in that a Queue is being created, but there is no call to fopen in frame 13 and the source line of ovms_script in frame 14 is different. Looking at the code I see that is a redundant fclose(), that is, on a file that is already closed. Removing that fclose() got rid of the leak. One would expect that the redundant fclose would just result in an error, but apparently FreeRTOS does not handle it gracefully. -- Steve
I see now why we had not already seen this crash that Tom hit. In the ovms_script code, the printf() function properly mallocs a buffer, but puts() and write() do not. So the scripts that have been running without crashing so far must have invoked routines that only did printf() or ESP_LOG (which goes to console_logger() that also does malloc). So, if the OVMS Server V2 code had done printf() rather than puts() the crash would not have happened. Tom's change to ESP_LOG is also a valid fix, but could be changed to printf() if the prefix applied by ESP_LOG is not desired. As proposed, I will change the script code to use BufferedShell and also change how console_logger() is done so I can remove the problematic OvmsConsole::Log() function. Then puts() will work again, too. -- Steve On Wed, 11 Oct 2017, Stephen Casner wrote:
On Wed, 11 Oct 2017, Mark Webb-Johnson wrote:
I think this double-free may be related to the new event script system Steve and I have been working on (in preparation for SMS, etc).
@steve: That seems to be on 'free(event.buffer)' at ovms_console.cpp:215. One of those nasty 'passing around pointers, and who is responsible for freeing' issues, I guess. Can you try to reproduce the fault?
The OvmsConsole::Log(char* message) function expects to be called with a message allocated from the heap (usually by vasprintf()). It was originally implemented to be called only from OvmsCommandApp::Log() as it iterated over all the registered consoles and gave each a separate copy of the message. Thus it was not valid for the script code to call MyUsbConsole->Log() directly. I had not recognized this before.
I need to go to bed now, but will study this more tomorrow. This OvmsConsole::Log(char* message) function isn't used for the logging of messages on consoles anymore since I created the LogBuffers class and added OvmsConsole::Log(LogBuffers* message) to handle the console logging more efficiently. The solution may be to remove the problem Log() function completely and proceed with revising your script code to use the new BufferedShell mechanism, presuming that you are OK with it.
-- Steve
Thanks, Mark.
On 11 Oct 2017, at 1:52 PM, Tom Parker <tom@carrott.org> wrote:
On 11/10/17 13:02, Mark Webb-Johnson wrote:
Tom,
I think your problem is sdkconfig. That has settings for partition table, fat filesystem, and timer task stack size; all three of your issues.
Can you try to diff your sdkconfig against sdkconfig.default (which contains all the custom settings)? Or just copy sdkconfig.default over your sdkconfig, and then adjust appropriately for what you need custom? You'll need to 'make menuconfig' to confirm things, then I suggest 'make clean' and 'make flash' to flash everything (partition table, bootloader, etc).
That worked! My sdkconfig was quite far from the default.
Your untested scripts recommendation didn't work as they need to be stored in the events directory, this works:
vfs mkdir /store/events vfs mkdir /store/events/system.start vfs append "wifi mode client <ssid>" /store/events/system.start/startmeup vfs append "vehicle module NL" /store/events/system.start/startmeup vfs mkdir /store/events/network.up vfs append "server v2 start" /store/events/network.up/startmeup
With these in place I get a reboot loop:
I (5822) event: ip: 192.168.43.92, mask: 255.255.255.0, gw: 192.168.43.1 I (5822) ovms-mdns: Launching MDNS service I (5832) script: Running script /store/events/network.up/startmeup Launching OVMS Server V2 connection (oscv2)/home/ubuntu/esp/esp-idf/components/freertos/./heap_regions.c:368 (vPortFreeTagged)- assert failed! abort() was called at PC 0x40085f8f on core 1 0x40085f8f: vPortFreeTagged at /home/ubuntu/esp/esp-idf/components/freertos/./heap_regions.c:410
Backtrace: 0x40088680:0x3ffebe80 0x4008877f:0x3ffebea0 0x40085f8f:0x3ffebec0 0x40088cd1:0x3ffebee0 0x40081f89:0x3ffebf00 0x4000bec7:0x3ffebf20 0x400eff2a:0x3ffebf40 0x400eff54:0x3ffebf70 0x400efcc0:0x3ffebf90 0x40088680: invoke_abort at /home/ubuntu/esp/esp-idf/components/esp32/./panic.c:519 0x4008877f: abort at /home/ubuntu/esp/esp-idf/components/esp32/./panic.c:519 0x40085f8f: vPortFreeTagged at /home/ubuntu/esp/esp-idf/components/freertos/./heap_regions.c:410 0x40088cd1: vPortFree at /home/ubuntu/esp/esp-idf/components/esp32/./heap_alloc_caps.c:323 0x40081f89: _free_r at /home/ubuntu/esp/esp-idf/components/newlib/./syscalls.c:32 0x400eff2a: _ZN11OvmsConsole7ServiceEv at /vagrant/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_console.cpp:215 0x400eff54: _ZThn296_N11OvmsConsole7ServiceEv at ??:? 0x400efcc0: _ZN8TaskBase4TaskEPv at /vagrant/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./task_base.cpp:119
Rebooting...
If I remove the network.up/startmeup file (the file that starts the v2 server client) then it starts up ok and when I start the v2 client manually, it connects to the v2 server and everything works. I tried using the ticker.60 event and got the same crash so it's not a race condition with the wifi startup.
The cause is a double free by the looks of it, and if I comment out the writer->puts called in the v2 server start function, things work:
diff --git a/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp b/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp index 106269e..d1ee797 100644 --- a/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp +++ b/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp @@ -515,7 +515,7 @@ void ovmsv2_start(int verbosity, OvmsWriter* writer, OvmsCommand* cmd, int argc, { if (MyOvmsServerV2 == NULL) { - writer->puts("Launching OVMS Server V2 connection (oscv2)"); + // writer->puts("Launching OVMS Server V2 connection (oscv2)"); MyOvmsServerV2 = new OvmsServerV2("oscv2"); } }
The ESP_LOGI in OvmsServerV2::OvmsServerV2 also gets called, in this code path but doesn't need to be commented out.
Progress! _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
On Oct 8, 2017, at 2:40 AM, Tom Parker <tom@carrott.org> wrote:
On 04/10/17 02:30, Mark Webb-Johnson wrote:
I just added the very basic ones, as a starting point and proof of concept. Hadn’t decided if I needed anything special for the bitmapped ones at the time (either a new MetricBitmap type, or extend MetricInt). Looking at how things have evolved, and bearing in mind the GAPP bluetooth stuff, and OVMS v3 MQTT, it seems that each bit should be a metric of their own. Not too hard for ovms_server_v2 to convert that back to an integer bitmap, for backwards compatibility. To do that, car_doors1 becomes:
I fully support the concept of storing the data in the most appropriate format and serializing it into the v2 message in the v2 server code. I like the idea of storing the bit field stuff as separate boolean objects.
What are the specific advantages of having boolean "objects" as opposed to standard C bit fields? The compiler can certainly emit more efficient code for bit fields. I almost always find an advantage to using objects in any design. However, there are also many examples where using standard C types can make the code way more efficient and execute much faster. Sometimes it's difficult to predict which way to go in a design until after you've tried out one of the options in running code.
I don't know if you can do anything clever with C++ to use less memory while preserving a nice API within the vehicle code, but we probably have enough memory to not need to worry too much?
It may not be true of all C++ compilers, but in my embedded experience I have found that grouping all of the boolean member variables together in the class definition allows them to be automatically grouped into a bit field. As soon as you have another type interleaved between boolean member variables, the compiler no longer efficiently groups them into the same word. I have been able to save a lot of memory in embedded firmware by merely editing the class headers to change the order of member variables and move the booleans together. I tend to avoid using C++ in my own designs, but it is sometimes possible to make good use of the language. I have noticed a trend in the industry of using C++ where it is inappropriate (e.g. only one instance of any object, and no inheritance). In other words, I think it's best not to try too hard to make everything "C++" unless you can see a distinct advantage that is only possible with that language. Good design structure is way more important than the language. In our example, I think that the communications protocol needs to be efficient, even more so than the embedded code. With OVMS v2, we ran out of Flash and other memory, and while it seems that v3 has space to burn I wouldn't recommend being too wasteful. Brian Willoughby
The issue is that for the MQTT and GATT protocols (generic IoT style), we need to provide granular updates. It just seems simpler to store things in that way in the first place. That way, the MQTT and GATT code in OVMS v3 can just publish all metrics in the same way - no need for per-metric logic. It is also trivial then to add per-vehicle custom metrics, as necessary. Doing it that way, we do take a hit on storage (RAM). But, even if each metric took say 50 bytes, over 80 metrics that is <4KB. About the stack for one task thread (of which we have more than a dozen already). I’m frankly more worried about task bloat, and in particular the massive wifi and bluetooth protocol stacks, then the metrics. Flash size is probably not much different either way. Regards, Mark.
On 9 Oct 2017, at 4:53 AM, HONDA S-2000 <s2000@audiobanshee.com> wrote:
On Oct 8, 2017, at 2:40 AM, Tom Parker <tom@carrott.org> wrote:
On 04/10/17 02:30, Mark Webb-Johnson wrote:
I just added the very basic ones, as a starting point and proof of concept. Hadn’t decided if I needed anything special for the bitmapped ones at the time (either a new MetricBitmap type, or extend MetricInt). Looking at how things have evolved, and bearing in mind the GAPP bluetooth stuff, and OVMS v3 MQTT, it seems that each bit should be a metric of their own. Not too hard for ovms_server_v2 to convert that back to an integer bitmap, for backwards compatibility. To do that, car_doors1 becomes:
I fully support the concept of storing the data in the most appropriate format and serializing it into the v2 message in the v2 server code. I like the idea of storing the bit field stuff as separate boolean objects.
What are the specific advantages of having boolean "objects" as opposed to standard C bit fields? The compiler can certainly emit more efficient code for bit fields.
I almost always find an advantage to using objects in any design. However, there are also many examples where using standard C types can make the code way more efficient and execute much faster. Sometimes it's difficult to predict which way to go in a design until after you've tried out one of the options in running code.
I don't know if you can do anything clever with C++ to use less memory while preserving a nice API within the vehicle code, but we probably have enough memory to not need to worry too much?
It may not be true of all C++ compilers, but in my embedded experience I have found that grouping all of the boolean member variables together in the class definition allows them to be automatically grouped into a bit field. As soon as you have another type interleaved between boolean member variables, the compiler no longer efficiently groups them into the same word. I have been able to save a lot of memory in embedded firmware by merely editing the class headers to change the order of member variables and move the booleans together.
I tend to avoid using C++ in my own designs, but it is sometimes possible to make good use of the language. I have noticed a trend in the industry of using C++ where it is inappropriate (e.g. only one instance of any object, and no inheritance). In other words, I think it's best not to try too hard to make everything "C++" unless you can see a distinct advantage that is only possible with that language. Good design structure is way more important than the language.
In our example, I think that the communications protocol needs to be efficient, even more so than the embedded code. With OVMS v2, we ran out of Flash and other memory, and while it seems that v3 has space to burn I wouldn't recommend being too wasteful.
Brian Willoughby
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Am 09.10.2017 um 03:17 schrieb Mark Webb-Johnson:
The issue is that for the MQTT and GATT protocols (generic IoT style), we need to provide granular updates. It just seems simpler to store things in that way in the first place. That way, the MQTT and GATT code in OVMS v3 can just publish all metrics in the same way - no need for per-metric logic. It is also trivial then to add per-vehicle custom metrics, as necessary.
That's clear for single flags with isolated semantics like "key on". How about collections of semantically coupled flags? I.e. how about battery cell voltage / temperature alert flags? I would normally map these flags to a string metric with set syntax, i.e. "3,7,12" to reflect active alerts on cells 3, 7 & 12. That would still be a granularly updatable metric, happening to transport structured information. As a client only interested in an alert status change, I can subscribe to this single attribute. Conversion to JSON can also be done by simply adding brackets. If that makes sense, I'll have a look at adding some sort of OvmsMetricsSet class for these cases -- I've been working on the metrics module anyway. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
That approach seems fine. Regards, Mark
On 23 Oct 2017, at 10:25 PM, Michael Balzer <dexter@expeedo.de> wrote:
Am 09.10.2017 um 03:17 schrieb Mark Webb-Johnson:
The issue is that for the MQTT and GATT protocols (generic IoT style), we need to provide granular updates. It just seems simpler to store things in that way in the first place. That way, the MQTT and GATT code in OVMS v3 can just publish all metrics in the same way - no need for per-metric logic. It is also trivial then to add per-vehicle custom metrics, as necessary.
That's clear for single flags with isolated semantics like "key on".
How about collections of semantically coupled flags?
I.e. how about battery cell voltage / temperature alert flags?
I would normally map these flags to a string metric with set syntax, i.e. "3,7,12" to reflect active alerts on cells 3, 7 & 12.
That would still be a granularly updatable metric, happening to transport structured information. As a client only interested in an alert status change, I can subscribe to this single attribute. Conversion to JSON can also be done by simply adding brackets.
If that makes sense, I'll have a look at adding some sort of OvmsMetricsSet class for these cases -- I've been working on the metrics module anyway.
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
There are now two new metrics class templates: - OvmsMetricBitset<N> - OvmsMetricSet<ElemType> Both use the string representation as mentioned (i.e. "3,7,12"). On the Bitset class, bit positions are numbered beginning at 1 to provide a "human" interface. OVMS > metrics list pack x.rt.b.pack.1.temp.alerts x.rt.b.pack.1.temp.stddev.max 0.495093°C ***x.rt.b.pack.1.temp.watches 1,3,5* x.rt.b.pack.1.voltage.alerts x.rt.b.pack.1.voltage.max 56.2V x.rt.b.pack.1.voltage.min 56.2V x.rt.b.pack.1.voltage.stddev.max 0.00395285V ***x.rt.b.pack.1.voltage.watches 1,13,14* x.rt.b.pack.cnt 1 I recommend using the bitset class where possible: The std::set class has a memory overhead similar to std::map, it also uses btrees to provide fast member lookups. So any new member added to the set will allocate a chunk of at least 16 bytes of RAM. The std::bitset class is basically just a wrap around a standard bit field, needing no more memory than the bits + metrics overhead. Regards, Michael Am 24.10.2017 um 02:38 schrieb Mark Webb-Johnson:
That approach seems fine.
Regards, Mark
On 23 Oct 2017, at 10:25 PM, Michael Balzer <dexter@expeedo.de> wrote:
Am 09.10.2017 um 03:17 schrieb Mark Webb-Johnson:
The issue is that for the MQTT and GATT protocols (generic IoT style), we need to provide granular updates. It just seems simpler to store things in that way in the first place. That way, the MQTT and GATT code in OVMS v3 can just publish all metrics in the same way - no need for per-metric logic. It is also trivial then to add per-vehicle custom metrics, as necessary. That's clear for single flags with isolated semantics like "key on".
How about collections of semantically coupled flags?
I.e. how about battery cell voltage / temperature alert flags?
I would normally map these flags to a string metric with set syntax, i.e. "3,7,12" to reflect active alerts on cells 3, 7 & 12.
That would still be a granularly updatable metric, happening to transport structured information. As a client only interested in an alert status change, I can subscribe to this single attribute. Conversion to JSON can also be done by simply adding brackets.
If that makes sense, I'll have a look at adding some sort of OvmsMetricsSet class for these cases -- I've been working on the metrics module anyway.
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
On 09/10/17 09:53, HONDA S-2000 wrote:
What are the specific advantages of having boolean "objects" as opposed to standard C bit fields? The compiler can certainly emit more efficient code for bit fields.
Individual dirty tracking and being able to access all the metrics through the same interface. a special case. In principal this could be done while storing the values in a set of bit fields, though I don' t know the best way to do so in C++. The OVMS v2's bitfield accessors were nice and presented basically the same interface as the other types, but none of those did dirty tracking.
participants (6)
-
Geir Øyvind Vælidalo -
HONDA S-2000 -
Mark Webb-Johnson -
Michael Balzer -
Stephen Casner -
Tom Parker