I’m having problems setting ms_v_charge_mode. I do it this way, but it fails at runtime: StdMetrics.ms_v_charge_mode->SetValue( chademo ? "performance" : "standard"); This is the trace I get, so it seems to fail somewhere else: I (6451) events: Signal(vehicle.charge.mGuru Meditation Error of type LoadProhibited occurred on core 0. Exception was unhandled. Register dump: PC : 0x400883c3 PS : 0x00060633 A0 : 0x8008708a A1 : 0x3ffc6b30 0x400883c3: vListInsertEnd at /Users/goev/esp/esp-idf/components/freertos/./list.c:130 A2 : 0x3ffc6384 A3 : 0x3ffc6c78 A4 : 0x00060620 A5 : 0x00000000 A6 : 0x00000000 A7 : 0x00000000 A8 : 0x00000038 A9 : 0x3ffb33b8 A10 : 0x3ffb131c A11 : 0x00060623 A12 : 0x00060623 A13 : 0x3ffce1ec A14 : 0x3ffce1ec A15 : 0x3ffc6a70 SAR : 0x00000010 EXCCAUSE: 0x0000001c EXCVADDR: 0x00000040 LBEG : 0x400014fd LEND : 0x4000150d LCOUNT : 0xfffffffa Backtrace: 0x400883c3:0x3ffc6b30 0x40087087:0x3ffc6b50 0x400860f1:0x3ffc6b70 0x4008771b:0x3ffc6b90 0x40087818:0x3ffc6bc0 0x400883c3: vListInsertEnd at /Users/goev/esp/esp-idf/components/freertos/./list.c:130 0x40087087: vTaskPlaceOnEventListRestricted at /Users/goev/esp/esp-idf/components/freertos/./tasks.c:4446 0x400860f1: vQueueWaitForMessageRestricted at /Users/goev/esp/esp-idf/components/freertos/./queue.c:2392 0x4008771b: prvProcessTimerOrBlockTask at /Users/goev/esp/esp-idf/components/freertos/./timers.c:839 0x40087818: prvTimerTask at /Users/goev/esp/esp-idf/components/freertos/./timers.c:839 It looks like it has something to do with the Signal event, but I ‘m still not that good using gbd to find out what actually makes this fail. Any one got a clue? Regards, Geir
Really need to see the overall context of this. Where are you calling the ms_v_charge_mode->SetValue from? Probably easiest to commit what you have to your own github clone, then let us know where that is and we can see the whole thing. Regards, Mark.
On 26 Nov 2017, at 4:35 AM, Geir Øyvind Vælidalo <geir@validalo.net> wrote:
I’m having problems setting ms_v_charge_mode. I do it this way, but it fails at runtime:
StdMetrics.ms_v_charge_mode->SetValue( chademo ? "performance" : "standard");
This is the trace I get, so it seems to fail somewhere else:
I (6451) events: Signal(vehicle.charge.mGuru Meditation Error of type LoadProhibited occurred on core 0. Exception was unhandled. Register dump: PC : 0x400883c3 PS : 0x00060633 A0 : 0x8008708a A1 : 0x3ffc6b30 0x400883c3: vListInsertEnd at /Users/goev/esp/esp-idf/components/freertos/./list.c:130
A2 : 0x3ffc6384 A3 : 0x3ffc6c78 A4 : 0x00060620 A5 : 0x00000000 A6 : 0x00000000 A7 : 0x00000000 A8 : 0x00000038 A9 : 0x3ffb33b8 A10 : 0x3ffb131c A11 : 0x00060623 A12 : 0x00060623 A13 : 0x3ffce1ec A14 : 0x3ffce1ec A15 : 0x3ffc6a70 SAR : 0x00000010 EXCCAUSE: 0x0000001c EXCVADDR: 0x00000040 LBEG : 0x400014fd LEND : 0x4000150d LCOUNT : 0xfffffffa
Backtrace: 0x400883c3:0x3ffc6b30 0x40087087:0x3ffc6b50 0x400860f1:0x3ffc6b70 0x4008771b:0x3ffc6b90 0x40087818:0x3ffc6bc0 0x400883c3: vListInsertEnd at /Users/goev/esp/esp-idf/components/freertos/./list.c:130
0x40087087: vTaskPlaceOnEventListRestricted at /Users/goev/esp/esp-idf/components/freertos/./tasks.c:4446
0x400860f1: vQueueWaitForMessageRestricted at /Users/goev/esp/esp-idf/components/freertos/./queue.c:2392
0x4008771b: prvProcessTimerOrBlockTask at /Users/goev/esp/esp-idf/components/freertos/./timers.c:839
0x40087818: prvTimerTask at /Users/goev/esp/esp-idf/components/freertos/./timers.c:839
It looks like it has something to do with the Signal event, but I ‘m still not that good using gbd to find out what actually makes this fail. Any one got a clue?
Regards, Geir
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Ok, Mark, I've committed my latest version to https://github.com/goev/Open-Vehicle-Monitoring-System-3 Everything I've done is in vehicle_kiasoulev. I set the charge mode in a function called SetChargeMetrics. It is called from Ticker1 when ks_charge_bits.ChargingJ1772 or ks_charge_bits.ChargingChademo is true. (Un)fortunately ks_charge_bits is uninitialized and probably contains some garbage, so it usually fires the call to SetChargeMetrics when running "vehicle module KS" even when not connected to the car. I need to set a default value to the ks_charge_bits and probab some more ks_-variables in the constructor, but I haven't come that yet. NB! In SetChargeMetrics, I've commented out the charge mode-line, so you need to remove the comment-tag and comment. Yesterday I also found out that ms_v_charge_state gives similar problems. It was *really* late, so I didn't look to close into it, but it seemed related. I've added a macro in vehicle_kiasoulev.h called SET_CHARGE_STATE where I've commented out the setting of the charge state, in case you find time to look into that too. Thanks! Geir
Really need to see the overall context of this. Where are you calling the ms_v_charge_mode->SetValue from?
Probably easiest to commit what you have to your own github clone, then let us know where that is and we can see the whole thing.
Regards, Mark.
On 26 Nov 2017, at 4:35 AM, Geir Ãyvind Vælidalo <geir@validalo.net> wrote:
Iâm having problems setting ms_v_charge_mode. I do it this way, but it fails at runtime:
StdMetrics.ms_v_charge_mode->SetValue( chademo ? "performance" : "standard");
This is the trace I get, so it seems to fail somewhere else:
I (6451) events: Signal(vehicle.charge.mGuru Meditation Error of type LoadProhibited occurred on core 0. Exception was unhandled. Register dump: PC : 0x400883c3 PS : 0x00060633 A0 : 0x8008708a A1 : 0x3ffc6b30 0x400883c3: vListInsertEnd at /Users/goev/esp/esp-idf/components/freertos/./list.c:130
A2 : 0x3ffc6384 A3 : 0x3ffc6c78 A4 : 0x00060620 A5 : 0x00000000 A6 : 0x00000000 A7 : 0x00000000 A8 : 0x00000038 A9 : 0x3ffb33b8 A10 : 0x3ffb131c A11 : 0x00060623 A12 : 0x00060623 A13 : 0x3ffce1ec A14 : 0x3ffce1ec A15 : 0x3ffc6a70 SAR : 0x00000010 EXCCAUSE: 0x0000001c EXCVADDR: 0x00000040 LBEG : 0x400014fd LEND : 0x4000150d LCOUNT : 0xfffffffa
Backtrace: 0x400883c3:0x3ffc6b30 0x40087087:0x3ffc6b50 0x400860f1:0x3ffc6b70 0x4008771b:0x3ffc6b90 0x40087818:0x3ffc6bc0 0x400883c3: vListInsertEnd at /Users/goev/esp/esp-idf/components/freertos/./list.c:130
0x40087087: vTaskPlaceOnEventListRestricted at /Users/goev/esp/esp-idf/components/freertos/./tasks.c:4446
0x400860f1: vQueueWaitForMessageRestricted at /Users/goev/esp/esp-idf/components/freertos/./queue.c:2392
0x4008771b: prvProcessTimerOrBlockTask at /Users/goev/esp/esp-idf/components/freertos/./timers.c:839
0x40087818: prvTimerTask at /Users/goev/esp/esp-idf/components/freertos/./timers.c:839
It looks like it has something to do with the Signal event, but I âm still not that good using gbd to find out what actually makes this fail. Any one got a clue?
Regards, 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
I can’t repeat the issue. Here is what I did: Bring your vehicle_kiasoulev into the latest build tree for ovms v3. Change #include “esp_log.h" to #include "ovms_log.h" Remove: MyEvents.RegisterEvent(TAG, "ticker.1", std::bind(&OvmsVehicleKiaSoulEv::Ticker1, this, _1, _2)); and change: OvmsVehicleKiaSoulEv::Ticker1(std::string event, void* data) to OvmsVehicleKiaSoulEv::Ticker1(uint32_t ticker) Add an ESP_LOGI diagnostic trace to Ticker1 and SetChargeMetrics In the constructor, set: ks_charge_bits.ChargingJ1772 = true; ks_charge_bits.ChargingChademo = true; and removed the comment-out in SetChargeMetrics Here is the output that I get: OVMS > level info Logging level for * set to info OVMS > vehicle module KS I (9235) v-kiasoulev: Kia Soul EV v3.0 vehicle module I (10035) v-kiasoulev: Ticker1 ks_charge_bits.ChargingJ1772=1 ks_charge_bits.ChargingChademo=1 I (10035) v-kiasoulev: SetChargeMetrics V=230.000000 C=0.000000 CL=28.695652 CHADEMO=0 I (10035) v-kiasoulev: Aux Battery voltage low OVMS > metrics list v.c.mode v.c.mode standard OVMS > metrics list v.c.type v.c.type type1 OVMS > metrics list v.c.vol v.c.voltage 230V Are you sure you are running against the ‘latest’ openvehicles/esp-idf (2.1 branch) and openvehicles/ovmsv3 (master branch)? You can try to menuconfig Components -> ESP32 -> Panic Handler Behaviour -> Invoke GDBStub (to get a better stack trace and diagnostic capability). Going forward, it is probably easiest to merge in what you have with our master github, and tidy up the integration a bit (stuff like the ovms_log.h not esp_log.h, the Ticker1 event, etc); that way we keep you up-to-date with framework (in particular vehicle.{h,cpp}) changes. Shall I do that now? Based on your master or pr/5 branch? Regards, Mark.
On 27 Nov 2017, at 4:18 PM, Geir Øyvind Vælidalo <geir@validalo.net> wrote:
Ok, Mark, I've committed my latest version to https://github.com/goev/Open-Vehicle-Monitoring-System-3 Everything I've done is in vehicle_kiasoulev.
I set the charge mode in a function called SetChargeMetrics. It is called from Ticker1 when ks_charge_bits.ChargingJ1772 or ks_charge_bits.ChargingChademo is true. (Un)fortunately ks_charge_bits is uninitialized and probably contains some garbage, so it usually fires the call to SetChargeMetrics when running "vehicle module KS" even when not connected to the car. I need to set a default value to the ks_charge_bits and probab some more ks_-variables in the constructor, but I haven't come that yet.
NB! In SetChargeMetrics, I've commented out the charge mode-line, so you need to remove the comment-tag and comment.
Yesterday I also found out that ms_v_charge_state gives similar problems. It was *really* late, so I didn't look to close into it, but it seemed related. I've added a macro in vehicle_kiasoulev.h called SET_CHARGE_STATE where I've commented out the setting of the charge state, in case you find time to look into that too.
Thanks!
Geir
Really need to see the overall context of this. Where are you calling the ms_v_charge_mode->SetValue from?
Probably easiest to commit what you have to your own github clone, then let us know where that is and we can see the whole thing.
Regards, Mark.
On 26 Nov 2017, at 4:35 AM, Geir Øyvind Vælidalo <geir@validalo.net> wrote:
I’m having problems setting ms_v_charge_mode. I do it this way, but it fails at runtime:
StdMetrics.ms_v_charge_mode->SetValue( chademo ? "performance" : "standard");
This is the trace I get, so it seems to fail somewhere else:
I (6451) events: Signal(vehicle.charge.mGuru Meditation Error of type LoadProhibited occurred on core 0. Exception was unhandled. Register dump: PC : 0x400883c3 PS : 0x00060633 A0 : 0x8008708a A1 : 0x3ffc6b30 0x400883c3: vListInsertEnd at /Users/goev/esp/esp-idf/components/freertos/./list.c:130
A2 : 0x3ffc6384 A3 : 0x3ffc6c78 A4 : 0x00060620 A5 : 0x00000000 A6 : 0x00000000 A7 : 0x00000000 A8 : 0x00000038 A9 : 0x3ffb33b8 A10 : 0x3ffb131c A11 : 0x00060623 A12 : 0x00060623 A13 : 0x3ffce1ec A14 : 0x3ffce1ec A15 : 0x3ffc6a70 SAR : 0x00000010 EXCCAUSE: 0x0000001c EXCVADDR: 0x00000040 LBEG : 0x400014fd LEND : 0x4000150d LCOUNT : 0xfffffffa
Backtrace: 0x400883c3:0x3ffc6b30 0x40087087:0x3ffc6b50 0x400860f1:0x3ffc6b70 0x4008771b:0x3ffc6b90 0x40087818:0x3ffc6bc0 0x400883c3: vListInsertEnd at /Users/goev/esp/esp-idf/components/freertos/./list.c:130
0x40087087: vTaskPlaceOnEventListRestricted at /Users/goev/esp/esp-idf/components/freertos/./tasks.c:4446
0x400860f1: vQueueWaitForMessageRestricted at /Users/goev/esp/esp-idf/components/freertos/./queue.c:2392
0x4008771b: prvProcessTimerOrBlockTask at /Users/goev/esp/esp-idf/components/freertos/./timers.c:839
0x40087818: prvTimerTask at /Users/goev/esp/esp-idf/components/freertos/./timers.c:839
It looks like it has something to do with the Signal event, but I ‘m still not that good using gbd to find out what actually makes this fail. Any one got a clue?
Regards, 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
Thanks a lot for checking this out, Mark! I’m sorry to bother you with these things that probably are very trivial to you. I hope you don’t mind. So… In addition to the things you mention, I found out that I did not have the correct ESP-IDF. I had the espressif-version. I still haven’t got the grips on GIT, so that’s probably the reason for that, and most of the problems I’m having :-D Anyway, I have cloned the open vehicle/esp-idf now and I have pulled the latest build tree for ohms v3, but when i run make it fails with this message: /Users/goev/Prosjekter/ovms3/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_module.cpp:39:41: fatal error: freertos/heap_regions_debug.h: No such file or directory I can’t find heap_regions_debug.h & .c in openvehicles/esp-idf nor in espressif/esp-idf. Do you have those locally on your computer? Best regards, Geir
1. des. 2017 kl. 01:52 skrev Mark Webb-Johnson <mark@webb-johnson.net>:
I can’t repeat the issue. Here is what I did:
Bring your vehicle_kiasoulev into the latest build tree for ovms v3.
Change #include “esp_log.h" to #include "ovms_log.h"
Remove: MyEvents.RegisterEvent(TAG, "ticker.1", std::bind(&OvmsVehicleKiaSoulEv::Ticker1, this, _1, _2));
and change: OvmsVehicleKiaSoulEv::Ticker1(std::string event, void* data) to OvmsVehicleKiaSoulEv::Ticker1(uint32_t ticker)
Add an ESP_LOGI diagnostic trace to Ticker1 and SetChargeMetrics
In the constructor, set: ks_charge_bits.ChargingJ1772 = true; ks_charge_bits.ChargingChademo = true; and removed the comment-out in SetChargeMetrics
Here is the output that I get:
OVMS > level info Logging level for * set to info
OVMS > vehicle module KS I (9235) v-kiasoulev: Kia Soul EV v3.0 vehicle module I (10035) v-kiasoulev: Ticker1 ks_charge_bits.ChargingJ1772=1 ks_charge_bits.ChargingChademo=1 I (10035) v-kiasoulev: SetChargeMetrics V=230.000000 C=0.000000 CL=28.695652 CHADEMO=0 I (10035) v-kiasoulev: Aux Battery voltage low
OVMS > metrics list v.c.mode v.c.mode standard
OVMS > metrics list v.c.type v.c.type type1
OVMS > metrics list v.c.vol v.c.voltage 230V
Are you sure you are running against the ‘latest’ openvehicles/esp-idf (2.1 branch) and openvehicles/ovmsv3 (master branch)?
You can try to menuconfig Components -> ESP32 -> Panic Handler Behaviour -> Invoke GDBStub (to get a better stack trace and diagnostic capability).
Going forward, it is probably easiest to merge in what you have with our master github, and tidy up the integration a bit (stuff like the ovms_log.h not esp_log.h, the Ticker1 event, etc); that way we keep you up-to-date with framework (in particular vehicle.{h,cpp}) changes. Shall I do that now? Based on your master or pr/5 branch?
Regards, Mark.
On 27 Nov 2017, at 4:18 PM, Geir Øyvind Vælidalo <geir@validalo.net <mailto:geir@validalo.net>> wrote:
Ok, Mark, I've committed my latest version to https://github.com/goev/Open-Vehicle-Monitoring-System-3 <https://github.com/goev/Open-Vehicle-Monitoring-System-3> Everything I've done is in vehicle_kiasoulev.
I set the charge mode in a function called SetChargeMetrics. It is called from Ticker1 when ks_charge_bits.ChargingJ1772 or ks_charge_bits.ChargingChademo is true. (Un)fortunately ks_charge_bits is uninitialized and probably contains some garbage, so it usually fires the call to SetChargeMetrics when running "vehicle module KS" even when not connected to the car. I need to set a default value to the ks_charge_bits and probab some more ks_-variables in the constructor, but I haven't come that yet.
NB! In SetChargeMetrics, I've commented out the charge mode-line, so you need to remove the comment-tag and comment.
Yesterday I also found out that ms_v_charge_state gives similar problems. It was *really* late, so I didn't look to close into it, but it seemed related. I've added a macro in vehicle_kiasoulev.h called SET_CHARGE_STATE where I've commented out the setting of the charge state, in case you find time to look into that too.
Thanks!
Geir
Really need to see the overall context of this. Where are you calling the ms_v_charge_mode->SetValue from?
Probably easiest to commit what you have to your own github clone, then let us know where that is and we can see the whole thing.
Regards, Mark.
On 26 Nov 2017, at 4:35 AM, Geir Øyvind Vælidalo <geir@validalo.net> wrote:
I’m having problems setting ms_v_charge_mode. I do it this way, but it fails at runtime:
StdMetrics.ms_v_charge_mode->SetValue( chademo ? "performance" : "standard");
This is the trace I get, so it seems to fail somewhere else:
I (6451) events: Signal(vehicle.charge.mGuru Meditation Error of type LoadProhibited occurred on core 0. Exception was unhandled. Register dump: PC : 0x400883c3 PS : 0x00060633 A0 : 0x8008708a A1 : 0x3ffc6b30 0x400883c3: vListInsertEnd at /Users/goev/esp/esp-idf/components/freertos/./list.c:130
A2 : 0x3ffc6384 A3 : 0x3ffc6c78 A4 : 0x00060620 A5 : 0x00000000 A6 : 0x00000000 A7 : 0x00000000 A8 : 0x00000038 A9 : 0x3ffb33b8 A10 : 0x3ffb131c A11 : 0x00060623 A12 : 0x00060623 A13 : 0x3ffce1ec A14 : 0x3ffce1ec A15 : 0x3ffc6a70 SAR : 0x00000010 EXCCAUSE: 0x0000001c EXCVADDR: 0x00000040 LBEG : 0x400014fd LEND : 0x4000150d LCOUNT : 0xfffffffa
Backtrace: 0x400883c3:0x3ffc6b30 0x40087087:0x3ffc6b50 0x400860f1:0x3ffc6b70 0x4008771b:0x3ffc6b90 0x40087818:0x3ffc6bc0 0x400883c3: vListInsertEnd at /Users/goev/esp/esp-idf/components/freertos/./list.c:130
0x40087087: vTaskPlaceOnEventListRestricted at /Users/goev/esp/esp-idf/components/freertos/./tasks.c:4446
0x400860f1: vQueueWaitForMessageRestricted at /Users/goev/esp/esp-idf/components/freertos/./queue.c:2392
0x4008771b: prvProcessTimerOrBlockTask at /Users/goev/esp/esp-idf/components/freertos/./timers.c:839
0x40087818: prvTimerTask at /Users/goev/esp/esp-idf/components/freertos/./timers.c:839
It looks like it has something to do with the Signal event, but I ‘m still not that good using gbd to find out what actually makes this fail. Any one got a clue?
Regards, 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
Geir, You need to select branch release/v2.1 of ESP-IDF. Try the 'git branch' command and see if release/v2.1 is there but not selected. Then switch to it with 'git checkout release/v2.1'. -- Steve On Fri, 1 Dec 2017, Geir ?yvind V?lidalo wrote:
Thanks a lot for checking this out, Mark! I’m sorry to bother you with these things that probably are very trivial to you. I hope you don’t mind.
So… In addition to the things you mention, I found out that I did not have the correct ESP-IDF. I had the espressif-version. I still haven’t got the grips on GIT, so that’s probably the reason for that, and most of the problems I’m having :-D Anyway, I have cloned the open vehicle/esp-idf now and I have pulled the latest build tree for ohms v3, but when i run make it fails with this message:
/Users/goev/Prosjekter/ovms3/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_module.cpp:39:41: fatal error: freertos/heap_regions_debug.h: No such file or directory
I can’t find heap_regions_debug.h & .c in openvehicles/esp-idf nor in espressif/esp-idf. Do you have those locally on your computer?
Best regards, Geir
Thanks, Steve! It compiles now 🙂 Geir
1. des. 2017 kl. 23:34 skrev Stephen Casner <casner@acm.org>:
Geir,
You need to select branch release/v2.1 of ESP-IDF. Try the 'git branch' command and see if release/v2.1 is there but not selected. Then switch to it with 'git checkout release/v2.1'.
-- Steve
On Fri, 1 Dec 2017, Geir ?yvind V?lidalo wrote:
Thanks a lot for checking this out, Mark! I’m sorry to bother you with these things that probably are very trivial to you. I hope you don’t mind.
So… In addition to the things you mention, I found out that I did not have the correct ESP-IDF. I had the espressif-version. I still haven’t got the grips on GIT, so that’s probably the reason for that, and most of the problems I’m having :-D Anyway, I have cloned the open vehicle/esp-idf now and I have pulled the latest build tree for ohms v3, but when i run make it fails with this message:
/Users/goev/Prosjekter/ovms3/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_module.cpp:39:41: fatal error: freertos/heap_regions_debug.h: No such file or directory
I can’t find heap_regions_debug.h & .c in openvehicles/esp-idf nor in espressif/esp-idf. Do you have those locally on your computer?
Best regards, Geir
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Just an update on my problems: my sdkconfig missed a few of the newer settings. So this is the recipe for success, in case i forget :-D 1) make sure esp-idf is correct: release/v2.1 from openvehicle/esp-idf 2) Make sure sdkconfig is up to date 3) Pull the lates build tree for ohms v3. Thanks for all the help! Best regards, Geir
1. des. 2017 kl. 23:50 skrev Geir Øyvind Vælidalo <geir@validalo.net>:
Thanks, Steve! It compiles now 🙂
Geir
1. des. 2017 kl. 23:34 skrev Stephen Casner <casner@acm.org <mailto:casner@acm.org>>:
Geir,
You need to select branch release/v2.1 of ESP-IDF. Try the 'git branch' command and see if release/v2.1 is there but not selected. Then switch to it with 'git checkout release/v2.1'.
-- Steve
On Fri, 1 Dec 2017, Geir ?yvind V?lidalo wrote:
Thanks a lot for checking this out, Mark! I’m sorry to bother you with these things that probably are very trivial to you. I hope you don’t mind.
So… In addition to the things you mention, I found out that I did not have the correct ESP-IDF. I had the espressif-version. I still haven’t got the grips on GIT, so that’s probably the reason for that, and most of the problems I’m having :-D Anyway, I have cloned the open vehicle/esp-idf now and I have pulled the latest build tree for ohms v3, but when i run make it fails with this message:
/Users/goev/Prosjekter/ovms3/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_module.cpp:39:41: fatal error: freertos/heap_regions_debug.h: No such file or directory
I can’t find heap_regions_debug.h & .c in openvehicles/esp-idf nor in espressif/esp-idf. Do you have those locally on your computer?
Best regards, Geir
OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto: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
participants (3)
-
Geir Øyvind Vælidalo -
Mark Webb-Johnson -
Stephen Casner