Hi, I am working on the Think City EV code and have some questions.- what is the best way to signal that the charging connector is plugged? ms_v_charge_pilot?previously it was cardoorbits1. - what is the best way to compare OvmsMetricStrings? Or should I dublicate the state in an enum and use that? - what is the best way to compare the OvmsMetricFloat to a literal float? - what is the current way of doing net_req_notification Thanks in advance,Nikolay On Tuesday, July 17, 2018, 3:37:49 AM GMT+2, Mark Webb-Johnson <mark@webb-johnson.net> wrote: Jacob,
Is there a reason why OVMS bundles three different SSL libraries?
I think wolfSSL is there (but WOLFCRYPT_ONLY) because wolfSSH needs it. The ESP-IDF offers mbedtls and openssl libraries, but we don’t currently use either.
Also why is there a custom HTTP implementation when mongoose already has one?
Primarily because we wrote those before we included mongoose into the project. But also because the mongoose http_client code sucks. It reads the entire message body into RAM, before passing it on to the client; that just won’t work for something like a firmware image. To complicate the choice further, ESP now includes a esp_http_client in their latest 3.x IDF (which wasn’t there before). I did try to convert our TCP and HTTP client libraries to mongoose a while ago, but failed. Those libraries are blocking (with i/o done in the context of the thread calling them), but the mongoose library is event-based non-blocking (with i/o output in the context of the calling thread, and i/o input in the context of the mongoose thread). Mongoose didn’t use to be thread safe, and that caused us all sorts of issues (now solved, by the work Michael and others did to make it thread safe).
IMO the best way would be to rewrite ovms_net and ovms_http to use mongoose and configure mongoose to compile with SSL support (probably mbedtls as the other two don't work).
I agree. In general, I prefer the mongoose approach, and we are trying to standardise on that (for good or bad). Probably the best would be to fix the http client in mongoose to work properly (or at least have an option to deliver the body block by block as they arrive), then convert our stuff that uses ovms tcp/http libraries, then drop the tcp and http libraries. Not trivial given the different models (blocking vs non-blocking events). Between openssl vs mbedtls, I don’t really care. I think we’re going to have to manage certificate loading ourselves anyway (as we need to load from a combination of statically defined (in flash using COMPONENT_EMBED_TXTFILES and asm(“_binary_* start/end) and dynamic (in /store/tls/trustedca/* or somewhere like that). Regards, Mark.
On 17 Jul 2018, at 1:02 AM, Jakob Löw <ovms@m4gnus.de> wrote:
Hey,
I've been playing around a bit with implementing SSL/TLS support. For starters I wanted to implement an OvmsNetTlsConnection class which could then be used for https requests. At first I tried using wolfSSL but it turns out wolfSSL is compiled with WOLFCRYPT_ONLY. OpenSSL also didn't work as SSL_CTX_load_verify_locations is missing in ESP-IDF's OpenSSL. I didn't try mbedtls yet. Is there a reason why OVMS bundles three different SSL libraries? Also why is there a custom HTTP implementation when mongoose already has one? Speaking of mongoose, it seems to have an abstraction layer which allows to use one of the three SSL/TLS libraries. IMO the best way would be to rewrite ovms_net and ovms_http to use mongoose and configure mongoose to compile with SSL support (probably mbedtls as the other two don't work).
- Jakob
On Mon, 2018-07-16 at 12:47 +0800, Mark Webb-Johnson wrote:
Drupal authentication is done, and working against mosquitto now on the live api.openvehicles.com site. Plain text MQTT only at the moment (I still need to get mosquitto and OVMS module firmware supporting SSL).
To configure OVMS v3 to use Server V3 protocol:
config set: vehicle id <vehicleid> server.v3 server api.openvehicles.com server.v3 port 1883 server.v3 user <openvehicles.com username> password server.v3 <openvehicles.com password>
server v3 start
Can also 'config set auto server.v3 yes’ to auto-start at boot
If you have an MQTT client, you can connect to the same server to query the metrics, issue commands, etc. The default topic hierarchy is ovms/<username>/<vehicleid>.
I think we are close now. Just need SSL support. And then Apps…
Feedback appreciated.
Regards, Mark.
On 10 Jul 2018, at 2:42 PM, Mark Webb-Johnson <mark@webb-johnson.ne t> wrote:
I’ve just pushed the support for notifications in OVMS Server v3.
With that, the server v3 is functionally complete (at least on the car side). We can:
Connect/disconnect Handle lists of apps connecting/disconnecting Send metrics Send events Send notifications (including info, error, alert, and historical data) Receive commands, run them, and return the results
I’m still struggling against drupal authentication at the server side; once that is done we can open this up to wider testing.
Overall, I’m pretty happy with it. We need SSL/TLS support, but at least functionally now it works and is complete.
Regards, Mark
On 6 Jul 2018, at 4:16 PM, Mark Webb-Johnson <mark@webb-johnson.n et> wrote:
> I suppose the following topic names: > metrics: <prefix>/metric/# > events: <prefix>/event/# > notifications: <prefix>/notify/# > config: <prefix>/config/# > logs: <prefix>/log/<tag> > active: <prefix>/client/<clientid>/active > requests: <prefix>/client/<clientid>/request/# > commands: <prefix>/client/<clientid>/command/<command > id> > cmd responses: <prefix>/client/<clientid>/response/<command > id>
All ok. I am fine with this, and looks clean. I will make the changes today, as I want to get this into some cars asap so we can get a feel for how it behaves.
Ok. Now implemented, and tested:
<prefix>/metric/# <prefix>/client/<clientid>/active <prefix>/client/<clientid>/command/<command id> <prefix>/client/<clientid>/response/<command id>
I don’t think config, logs, and requests are critical or urgent. So, I will try to finish events tonight (as that is relatively simple). Notifications over the weekend (more tricky, especially for historical data). It can go in my car with tonight’s nightly ota, for real world testing.
I’m still trying to get the authentication working for drupal vs mosquitto. Once that is done, I can open up api.openvehicles.com MQTT for public use. If I can’t get it done within the next couple of days, I’ll try another broker (lua scripting, anyone?).
P.S. Commands over MQTT are pretty cool:
<PastedGraphic-2.tiff> <PastedGraphic-3.tiff>
Regards, Mark. _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
- what is the best way to signal that the charging connector is plugged? ms_v_charge_pilot? previously it was cardoorbits1.
From OVMS v2: 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)) For v3, ChargePort is MS_V_DOOR_CHARGEPORT (v.d.cp), PilotSignal is MS_V_CHARGE_PILOT (v.c.pilot), and Charging is MS_V_CHARGE_INPROGRESS (v.c.charging). If you don’t have charge port detection, probably best to change that along with MS_V_CHARGE_PILOT.
- what is the best way to compare OvmsMetricStrings? Or should I dublicate the state in an enum and use that? - what is the best way to compare the OvmsMetricFloat to a literal float?
Not really sure what you mean by these. You typically don’t need to compare (just set the value and the metrics system will work out if it is modified and change appropriately). You can retrieve the current value with functions like AsString, AsInt, AsFloat, etc.
- what is the current way of doing net_req_notification
Not required in v3. If you change a metric that needs notification, the serverv2 and serverv3 will act appropriately. In general, we’ve tried to make it as easy for the vehicle modules as possible, and remove duplicate code. All you need to do is read the value off the bus, and set the appropriate metric. If you need that for later comparison (in native form), store it as well as a m_* member variable of your vehicle object and use that. Regards, Mark.
On 19 Jul 2018, at 6:00 AM, Nikolay Shishkov <nshishkov@yahoo.com> wrote:
Hi, I am working on the Think City EV code and have some questions. - what is the best way to signal that the charging connector is plugged? ms_v_charge_pilot? previously it was cardoorbits1.
- what is the best way to compare OvmsMetricStrings? Or should I dublicate the state in an enum and use that?
- what is the best way to compare the OvmsMetricFloat to a literal float?
- what is the current way of doing net_req_notification
Thanks in advance, Nikolay On Tuesday, July 17, 2018, 3:37:49 AM GMT+2, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Jacob,
Is there a reason why OVMS bundles three different SSL libraries?
I think wolfSSL is there (but WOLFCRYPT_ONLY) because wolfSSH needs it.
The ESP-IDF offers mbedtls and openssl libraries, but we don’t currently use either.
Also why is there a custom HTTP implementation when mongoose already has one?
Primarily because we wrote those before we included mongoose into the project. But also because the mongoose http_client code sucks. It reads the entire message body into RAM, before passing it on to the client; that just won’t work for something like a firmware image.
To complicate the choice further, ESP now includes a esp_http_client in their latest 3.x IDF (which wasn’t there before).
I did try to convert our TCP and HTTP client libraries to mongoose a while ago, but failed. Those libraries are blocking (with i/o done in the context of the thread calling them), but the mongoose library is event-based non-blocking (with i/o output in the context of the calling thread, and i/o input in the context of the mongoose thread). Mongoose didn’t use to be thread safe, and that caused us all sorts of issues (now solved, by the work Michael and others did to make it thread safe).
IMO the best way would be to rewrite ovms_net and ovms_http to use mongoose and configure mongoose to compile with SSL support (probably mbedtls as the other two don't work).
I agree. In general, I prefer the mongoose approach, and we are trying to standardise on that (for good or bad).
Probably the best would be to fix the http client in mongoose to work properly (or at least have an option to deliver the body block by block as they arrive), then convert our stuff that uses ovms tcp/http libraries, then drop the tcp and http libraries. Not trivial given the different models (blocking vs non-blocking events).
Between openssl vs mbedtls, I don’t really care. I think we’re going to have to manage certificate loading ourselves anyway (as we need to load from a combination of statically defined (in flash using COMPONENT_EMBED_TXTFILES and asm(“_binary_* start/end) and dynamic (in /store/tls/trustedca/* or somewhere like that).
Regards, Mark.
On 17 Jul 2018, at 1:02 AM, Jakob Löw <ovms@m4gnus.de <mailto:ovms@m4gnus.de>> wrote:
Hey,
I've been playing around a bit with implementing SSL/TLS support. For starters I wanted to implement an OvmsNetTlsConnection class which could then be used for https requests. At first I tried using wolfSSL but it turns out wolfSSL is compiled with WOLFCRYPT_ONLY. OpenSSL also didn't work as SSL_CTX_load_verify_locations is missing in ESP-IDF's OpenSSL. I didn't try mbedtls yet. Is there a reason why OVMS bundles three different SSL libraries? Also why is there a custom HTTP implementation when mongoose already has one? Speaking of mongoose, it seems to have an abstraction layer which allows to use one of the three SSL/TLS libraries. IMO the best way would be to rewrite ovms_net and ovms_http to use mongoose and configure mongoose to compile with SSL support (probably mbedtls as the other two don't work).
- Jakob
On Mon, 2018-07-16 at 12:47 +0800, Mark Webb-Johnson wrote:
Drupal authentication is done, and working against mosquitto now on the live api.openvehicles.com site. Plain text MQTT only at the moment (I still need to get mosquitto and OVMS module firmware supporting SSL).
To configure OVMS v3 to use Server V3 protocol:
config set: vehicle id <vehicleid> server.v3 server api.openvehicles.com server.v3 port 1883 server.v3 user <openvehicles.com username> password server.v3 <openvehicles.com password>
server v3 start
Can also 'config set auto server.v3 yes’ to auto-start at boot
If you have an MQTT client, you can connect to the same server to query the metrics, issue commands, etc. The default topic hierarchy is ovms/<username>/<vehicleid>.
I think we are close now. Just need SSL support. And then Apps…
Feedback appreciated.
Regards, Mark.
On 10 Jul 2018, at 2:42 PM, Mark Webb-Johnson <mark@webb-johnson.ne <mailto:mark@webb-johnson.ne> t> wrote:
I’ve just pushed the support for notifications in OVMS Server v3.
With that, the server v3 is functionally complete (at least on the car side). We can:
Connect/disconnect Handle lists of apps connecting/disconnecting Send metrics Send events Send notifications (including info, error, alert, and historical data) Receive commands, run them, and return the results
I’m still struggling against drupal authentication at the server side; once that is done we can open this up to wider testing.
Overall, I’m pretty happy with it. We need SSL/TLS support, but at least functionally now it works and is complete.
Regards, Mark
On 6 Jul 2018, at 4:16 PM, Mark Webb-Johnson <mark@webb-johnson.n <mailto:mark@webb-johnson.n> et> wrote:
>> I suppose the following topic names: >> metrics: <prefix>/metric/# >> events: <prefix>/event/# >> notifications: <prefix>/notify/# >> config: <prefix>/config/# >> logs: <prefix>/log/<tag> >> active: <prefix>/client/<clientid>/active >> requests: <prefix>/client/<clientid>/request/# >> commands: <prefix>/client/<clientid>/command/<command >> id> >> cmd responses: <prefix>/client/<clientid>/response/<command >> id> > > All ok. I am fine with this, and looks clean. I will make the > changes today, as I want to get this into some cars asap so > we can get a feel for how it behaves.
Ok. Now implemented, and tested:
<prefix>/metric/# <prefix>/client/<clientid>/active <prefix>/client/<clientid>/command/<command id> <prefix>/client/<clientid>/response/<command id>
I don’t think config, logs, and requests are critical or urgent. So, I will try to finish events tonight (as that is relatively simple). Notifications over the weekend (more tricky, especially for historical data). It can go in my car with tonight’s nightly ota, for real world testing.
I’m still trying to get the authentication working for drupal vs mosquitto. Once that is done, I can open up api.openvehicles.com MQTT for public use. If I can’t get it done within the next couple of days, I’ll try another broker (lua scripting, anyone?).
P.S. Commands over MQTT are pretty cool:
<PastedGraphic-2.tiff> <PastedGraphic-3.tiff>
Regards, Mark. _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Nikolay,
- what is the best way to compare OvmsMetricStrings? Or should I dublicate the state in an enum and use that? - what is the best way to compare the OvmsMetricFloat to a literal float?
If you want to compare a state code encoded as a string, you can simply compare the std::string returned by AsString() with hard coded strings, e.g. std::string charge_state = StdMetrics.ms_v_charge_state->AsString(); if (charge_state == "charging") … If you'd rather use the old numeric state codes, there are utility functions in the ovms_utils module for encoding / decoding them. As Mark wrote, you get the float value by the AsFloat() method and can compare that directly to a float literal. We haven't added comparison operators to the metrics classes yet, just assignment (and that needs casts in many cases). If you'd like to add more operators/types, go ahead.
- what is the current way of doing net_req_notification
Not required in v3. If you change a metric that needs notification, the serverv2 and serverv3 will act appropriately.
And if you want to customize standard notifications, you can do so by overloading the vehicle methods: virtual void NotifyChargeState(); virtual void NotifyChargeStart(); virtual void NotifyHeatingStart(); virtual void NotifyChargeStopped(); virtual void NotifyChargeDone(); virtual void NotifyValetEnabled(); virtual void NotifyValetDisabled(); virtual void NotifyValetHood(); virtual void NotifyValetTrunk(); virtual void NotifyAlarmSounding(); virtual void NotifyAlarmStopped(); virtual void Notify12vCritical(); virtual void Notify12vRecovered(); If you want to add vehicle specific notifications, take a look at the Twizy module (rt_notify). You can simply send a notification from any command output by issuing MyNotify.NotifyCommand() (att: stack intensive) or send any string by MyNotify.NotifyString(). There are also varargs versions with "f" suffix acting like printf. For building strings from command methods, there is the StringWriter class, that's a std::string that can be used as an OvmsWriter. Example: StringWriter buf(200); CommandStat(COMMAND_RESULT_NORMAL, &buf); MyNotify.NotifyString("info", "charge.sufficient", buf.c_str()); Best practice is to send notifications from within an event handler (e.g. Ticker1), so they run asynchronously in the event task context instead of blocking something. Regards, Michael PS: we should start collecting these pieces for the developer manual, the general system API is quite mature now
On 19 Jul 2018, at 6:00 AM, Nikolay Shishkov <nshishkov@yahoo.com <mailto:nshishkov@yahoo.com>> wrote:
Hi, I am working on the Think City EV code and have some questions. - what is the best way to signal that the charging connector is plugged? ms_v_charge_pilot? previously it was cardoorbits1.
- what is the best way to compare OvmsMetricStrings? Or should I dublicate the state in an enum and use that?
- what is the best way to compare the OvmsMetricFloat to a literal float?
- what is the current way of doing net_req_notification
Thanks in advance, Nikolay On Tuesday, July 17, 2018, 3:37:49 AM GMT+2, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Thank you guys!I think I am ready with something I want to create pull request on. Do I do this through my own repository, or can I just send someone a diff?Nikolay On Thursday, July 19, 2018, 12:37:58 PM GMT+2, Michael Balzer <dexter@expeedo.de> wrote: Nikolay, - what is the best way to compare OvmsMetricStrings? Or should I dublicate the state in an enum and use that? - what is the best way to compare the OvmsMetricFloat to a literal float? If you want to compare a state code encoded as a string, you can simply compare the std::string returned by AsString() with hard coded strings, e.g. std::string charge_state = StdMetrics.ms_v_charge_state->AsString(); if (charge_state == "charging") … If you'd rather use the old numeric state codes, there are utility functions in the ovms_utils module for encoding / decoding them. As Mark wrote, you get the float value by the AsFloat() method and can compare that directly to a float literal. We haven't added comparison operators to the metrics classes yet, just assignment (and that needs casts in many cases). If you'd like to add more operators/types, go ahead. - what is the current way of doing net_req_notification Not required in v3. If you change a metric that needs notification, the serverv2 and serverv3 will act appropriately. And if you want to customize standard notifications, you can do so by overloading the vehicle methods: virtual void NotifyChargeState(); virtual void NotifyChargeStart(); virtual void NotifyHeatingStart(); virtual void NotifyChargeStopped(); virtual void NotifyChargeDone(); virtual void NotifyValetEnabled(); virtual void NotifyValetDisabled(); virtual void NotifyValetHood(); virtual void NotifyValetTrunk(); virtual void NotifyAlarmSounding(); virtual void NotifyAlarmStopped(); virtual void Notify12vCritical(); virtual void Notify12vRecovered(); If you want to add vehicle specific notifications, take a look at the Twizy module (rt_notify). You can simply send a notification from any command output by issuing MyNotify.NotifyCommand() (att: stack intensive) or send any string by MyNotify.NotifyString(). There are also varargs versions with "f" suffix acting like printf. For building strings from command methods, there is the StringWriter class, that's a std::string that can be used as an OvmsWriter. Example: StringWriter buf(200); CommandStat(COMMAND_RESULT_NORMAL, &buf); MyNotify.NotifyString("info", "charge.sufficient", buf.c_str()); Best practice is to send notifications from within an event handler (e.g. Ticker1), so they run asynchronously in the event task context instead of blocking something. Regards, Michael PS: we should start collecting these pieces for the developer manual, the general system API is quite mature now On 19 Jul 2018, at 6:00 AM, Nikolay Shishkov <nshishkov@yahoo.com> wrote: Hi, I am working on the Think City EV code and have some questions. - what is the best way to signal that the charging connector is plugged? ms_v_charge_pilot? previously it was cardoorbits1. - what is the best way to compare OvmsMetricStrings? Or should I dublicate the state in an enum and use that? - what is the best way to compare the OvmsMetricFloat to a literal float? - what is the current way of doing net_req_notification Thanks in advance, Nikolay On Tuesday, July 17, 2018, 3:37:49 AM GMT+2, Mark Webb-Johnson <mark@webb-johnson.net> wrote: -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Best is to create a pull request, and let us know. We can check and merge with master. Regards, Mark
On 19 Jul 2018, at 6:41 PM, Nikolay Shishkov <nshishkov@yahoo.com> wrote:
Thank you guys! I think I am ready with something I want to create pull request on. Do I do this through my own repository, or can I just send someone a diff? Nikolay
On Thursday, July 19, 2018, 12:37:58 PM GMT+2, Michael Balzer <dexter@expeedo.de> wrote:
Nikolay,
- what is the best way to compare OvmsMetricStrings? Or should I dublicate the state in an enum and use that? - what is the best way to compare the OvmsMetricFloat to a literal float?
If you want to compare a state code encoded as a string, you can simply compare the std::string returned by AsString() with hard coded strings, e.g.
std::string charge_state = StdMetrics.ms_v_charge_state->AsString(); if (charge_state == "charging") …
If you'd rather use the old numeric state codes, there are utility functions in the ovms_utils module for encoding / decoding them.
As Mark wrote, you get the float value by the AsFloat() method and can compare that directly to a float literal. We haven't added comparison operators to the metrics classes yet, just assignment (and that needs casts in many cases). If you'd like to add more operators/types, go ahead.
- what is the current way of doing net_req_notification
Not required in v3. If you change a metric that needs notification, the serverv2 and serverv3 will act appropriately.
And if you want to customize standard notifications, you can do so by overloading the vehicle methods:
virtual void NotifyChargeState(); virtual void NotifyChargeStart(); virtual void NotifyHeatingStart(); virtual void NotifyChargeStopped(); virtual void NotifyChargeDone(); virtual void NotifyValetEnabled(); virtual void NotifyValetDisabled(); virtual void NotifyValetHood(); virtual void NotifyValetTrunk(); virtual void NotifyAlarmSounding(); virtual void NotifyAlarmStopped(); virtual void Notify12vCritical(); virtual void Notify12vRecovered();
If you want to add vehicle specific notifications, take a look at the Twizy module (rt_notify).
You can simply send a notification from any command output by issuing MyNotify.NotifyCommand() (att: stack intensive) or send any string by MyNotify.NotifyString(). There are also varargs versions with "f" suffix acting like printf.
For building strings from command methods, there is the StringWriter class, that's a std::string that can be used as an OvmsWriter. Example:
StringWriter buf(200); CommandStat(COMMAND_RESULT_NORMAL, &buf); MyNotify.NotifyString("info", "charge.sufficient", buf.c_str());
Best practice is to send notifications from within an event handler (e.g. Ticker1), so they run asynchronously in the event task context instead of blocking something.
Regards, Michael
PS: we should start collecting these pieces for the developer manual, the general system API is quite mature now
On 19 Jul 2018, at 6:00 AM, Nikolay Shishkov <nshishkov@yahoo.com> wrote:
Hi, I am working on the Think City EV code and have some questions. - what is the best way to signal that the charging connector is plugged? ms_v_charge_pilot? previously it was cardoorbits1.
- what is the best way to compare OvmsMetricStrings? Or should I dublicate the state in an enum and use that?
- what is the best way to compare the OvmsMetricFloat to a literal float?
- what is the current way of doing net_req_notification
Thanks in advance, Nikolay On Tuesday, July 17, 2018, 3:37:49 AM GMT+2, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Done. https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/143 I have not tested this in a vehicle.It would take some time to receive the new boxes, but I thought it may help someone to go further. On Thursday, July 19, 2018, 12:46:28 PM GMT+2, Mark Webb-Johnson <mark@webb-johnson.net> wrote: Best is to create a pull request, and let us know. We can check and merge with master. Regards, Mark On 19 Jul 2018, at 6:41 PM, Nikolay Shishkov <nshishkov@yahoo.com> wrote: Thank you guys!I think I am ready with something I want to create pull request on. Do I do this through my own repository, or can I just send someone a diff?Nikolay On Thursday, July 19, 2018, 12:37:58 PM GMT+2, Michael Balzer <dexter@expeedo.de> wrote: Nikolay, - what is the best way to compare OvmsMetricStrings? Or should I dublicate the state in an enum and use that? - what is the best way to compare the OvmsMetricFloat to a literal float? If you want to compare a state code encoded as a string, you can simply compare the std::string returned by AsString() with hard coded strings, e.g. std::string charge_state = StdMetrics.ms_v_charge_state->AsString(); if (charge_state == "charging") … If you'd rather use the old numeric state codes, there are utility functions in the ovms_utils module for encoding / decoding them. As Mark wrote, you get the float value by the AsFloat() method and can compare that directly to a float literal. We haven't added comparison operators to the metrics classes yet, just assignment (and that needs casts in many cases). If you'd like to add more operators/types, go ahead. - what is the current way of doing net_req_notification Not required in v3. If you change a metric that needs notification, the serverv2 and serverv3 will act appropriately. And if you want to customize standard notifications, you can do so by overloading the vehicle methods: virtual void NotifyChargeState(); virtual void NotifyChargeStart(); virtual void NotifyHeatingStart(); virtual void NotifyChargeStopped(); virtual void NotifyChargeDone(); virtual void NotifyValetEnabled(); virtual void NotifyValetDisabled(); virtual void NotifyValetHood(); virtual void NotifyValetTrunk(); virtual void NotifyAlarmSounding(); virtual void NotifyAlarmStopped(); virtual void Notify12vCritical(); virtual void Notify12vRecovered(); If you want to add vehicle specific notifications, take a look at the Twizy module (rt_notify). You can simply send a notification from any command output by issuing MyNotify.NotifyCommand() (att: stack intensive) or send any string by MyNotify.NotifyString(). There are also varargs versions with "f" suffix acting like printf. For building strings from command methods, there is the StringWriter class, that's a std::string that can be used as an OvmsWriter. Example: StringWriter buf(200); CommandStat(COMMAND_RESULT_NORMAL, &buf); MyNotify.NotifyString("info", "charge.sufficient", buf.c_str()); Best practice is to send notifications from within an event handler (e.g. Ticker1), so they run asynchronously in the event task context instead of blocking something. Regards, Michael PS: we should start collecting these pieces for the developer manual, the general system API is quite mature now On 19 Jul 2018, at 6:00 AM, Nikolay Shishkov <nshishkov@yahoo.com> wrote: Hi, I am working on the Think City EV code and have some questions. - what is the best way to signal that the charging connector is plugged? ms_v_charge_pilot? previously it was cardoorbits1. - what is the best way to compare OvmsMetricStrings? Or should I dublicate the state in an enum and use that? - what is the best way to compare the OvmsMetricFloat to a literal float? - what is the current way of doing net_req_notification Thanks in advance, Nikolay On Tuesday, July 17, 2018, 3:37:49 AM GMT+2, Mark Webb-Johnson <mark@webb-johnson.net> wrote: -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Quick update:I managed to do a not so quick update on one of the ovms v.3 boxes that sits in a Think and can confirm that the porting seems to work. I could see speed, parking time, ambient temperature. I had very strange problems doing the OTA update. The firmware start download and I can see the messages progressing, but it would halt in between 700kB and 1600kB and then stay there until I refresh the browser. And when I refresh the browser I am asked of my password which leads me to that there must have been a crash in the meantime. I was finally able to get the OTA update work by disconnecting the box from the car and powering it via USB. This is a single data point but it kind of points to a problem with the code that communicates with the car. I was not able to get a laptop connected to checkout the console, but managed to get the following log - not sure how to interpret it. Last boot was 87 second(s) agoTime at boot: 2018-07-25 18:07:43 GMTThis is reset #3 since last power cycleDetected boot reason: Crash (12/12)Crash counters: 3 total, 0 early Last crash: Alloca exception on core 0Registers:PC : 0x400dc8ec PS : 0x00060234 A0 : 0x8008f440 A1 : 0x3ffc45b0A2 : 0x00000020 A3 : 0x00000001 A4 : 0x00000000 A5 : 0x3ffb44b8A6 : 0x3ffb47e4 A7 : 0x3ffb458c A8 : 0x3ffb44d4 A9 : 0x3ffc4590A10 : 0x00000000 A11 : 0x7fffffff A12 : 0x8008e65b A13 : 0x3ffcc450A14 : 0x00000003 A15 : 0x00060023 SAR : 0x00000000 EXCCAUSE: 0x00000005EXCVADDR: 0x00000000 LBEG : 0x00000000 LEND : 0x00000000 LCOUNT : 0x00000000Backtrace:0x400dc8ec 0x4008f43d 0x4008e181 0x400818cc 0x40082163 0x40083c4d 0x400dc8e9Version: 3.1.008-29-gaf41242/ota_1/edge (build idf v3.1-dev-987-g55d915e Jul 6 2018 00:14:59)Running partition: ota_1Boot partition: ota_1Firmware: 3.1.008-29-gaf41242/ota_1/edge (build idf v3.1-dev-987-g55d915e Jul 6 2018 00:14:59) How is performance and power usage affected when using StandardMetrics.xxxxx->SetValue in the IncomingFrameCan1 method?Most of the messages update value every 100ms, and except maybe speed, battery current and voltage, most of the parameters are not changing that often. And even for the speed, current and voltage, it is probably enough to update StandardMetrics in the 1 second ticker... does this make sense or is the difference non-existing. Thanks for all the hand holding and help, Nikolay On Thursday, July 19, 2018, 1:11:46 PM GMT+2, Nikolay Shishkov <nshishkov@yahoo.com> wrote: Done. https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/143 I have not tested this in a vehicle.It would take some time to receive the new boxes, but I thought it may help someone to go further. On Thursday, July 19, 2018, 12:46:28 PM GMT+2, Mark Webb-Johnson <mark@webb-johnson.net> wrote: Best is to create a pull request, and let us know. We can check and merge with master. Regards, Mark On 19 Jul 2018, at 6:41 PM, Nikolay Shishkov <nshishkov@yahoo.com> wrote: Thank you guys!I think I am ready with something I want to create pull request on. Do I do this through my own repository, or can I just send someone a diff?Nikolay On Thursday, July 19, 2018, 12:37:58 PM GMT+2, Michael Balzer <dexter@expeedo.de> wrote: Nikolay, - what is the best way to compare OvmsMetricStrings? Or should I dublicate the state in an enum and use that? - what is the best way to compare the OvmsMetricFloat to a literal float? If you want to compare a state code encoded as a string, you can simply compare the std::string returned by AsString() with hard coded strings, e.g. std::string charge_state = StdMetrics.ms_v_charge_state->AsString(); if (charge_state == "charging") … If you'd rather use the old numeric state codes, there are utility functions in the ovms_utils module for encoding / decoding them. As Mark wrote, you get the float value by the AsFloat() method and can compare that directly to a float literal. We haven't added comparison operators to the metrics classes yet, just assignment (and that needs casts in many cases). If you'd like to add more operators/types, go ahead. - what is the current way of doing net_req_notification Not required in v3. If you change a metric that needs notification, the serverv2 and serverv3 will act appropriately. And if you want to customize standard notifications, you can do so by overloading the vehicle methods: virtual void NotifyChargeState(); virtual void NotifyChargeStart(); virtual void NotifyHeatingStart(); virtual void NotifyChargeStopped(); virtual void NotifyChargeDone(); virtual void NotifyValetEnabled(); virtual void NotifyValetDisabled(); virtual void NotifyValetHood(); virtual void NotifyValetTrunk(); virtual void NotifyAlarmSounding(); virtual void NotifyAlarmStopped(); virtual void Notify12vCritical(); virtual void Notify12vRecovered(); If you want to add vehicle specific notifications, take a look at the Twizy module (rt_notify). You can simply send a notification from any command output by issuing MyNotify.NotifyCommand() (att: stack intensive) or send any string by MyNotify.NotifyString(). There are also varargs versions with "f" suffix acting like printf. For building strings from command methods, there is the StringWriter class, that's a std::string that can be used as an OvmsWriter. Example: StringWriter buf(200); CommandStat(COMMAND_RESULT_NORMAL, &buf); MyNotify.NotifyString("info", "charge.sufficient", buf.c_str()); Best practice is to send notifications from within an event handler (e.g. Ticker1), so they run asynchronously in the event task context instead of blocking something. Regards, Michael PS: we should start collecting these pieces for the developer manual, the general system API is quite mature now On 19 Jul 2018, at 6:00 AM, Nikolay Shishkov <nshishkov@yahoo.com> wrote: Hi, I am working on the Think City EV code and have some questions. - what is the best way to signal that the charging connector is plugged? ms_v_charge_pilot? previously it was cardoorbits1. - what is the best way to compare OvmsMetricStrings? Or should I dublicate the state in an enum and use that? - what is the best way to compare the OvmsMetricFloat to a literal float? - what is the current way of doing net_req_notification Thanks in advance, Nikolay On Tuesday, July 17, 2018, 3:37:49 AM GMT+2, Mark Webb-Johnson <mark@webb-johnson.net> wrote: -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
The backtrace you provided does not seem complete. Here is what it shows: # xtensa-esp32-elf-addr2line -pfiaC -e 3.1.008-29-gaf41242.ovms3.elf 0x400dc8ec 0x4008f43d 0x4008e181 0x400818cc 0x40082163 0x40083c4d 0x400dc8e9 0x400dc8ec: esp_vApplicationIdleHook at /home/openvehicles/build/esp-idf/components/esp32/freertos_hooks.c:85 0x4008f43d: prvIdleTask at /home/openvehicles/build/esp-idf/components/freertos/tasks.c:4587 0x4008e181: xQueueGiveFromISR at /home/openvehicles/build/esp-idf/components/freertos/queue.c:2037 0x400818cc: timer_alarm_handler at /home/openvehicles/build/esp-idf/components/esp32/esp_timer.c:318 0x40082163: timer_alarm_isr at /home/openvehicles/build/esp-idf/components/esp32/esp_timer_esp32.c:323 0x40083c4d: _xt_lowint1 at /home/openvehicles/build/esp-idf/components/freertos/xtensa_vectors.S:1105 0x400dc8e9: esp_vApplicationIdleHook at /home/openvehicles/build/esp-idf/components/esp32/freertos_hooks.c:85 The 'Alloca exception’ is a stack overflow. I don’t see anything in vehicle_thinkcity using up much stack. Are you using the api.openvehicles.com <http://api.openvehicles.com/> server? If so, what is your vehicle id? These crashes are also reported to the server and we can check there for details. I do see some crashes for TC003 (which I think is one of yours): # xtensa-esp32-elf-addr2line -pfiaC -e 3.1.008-29-gaf41242.ovms3.elf 0x40091e6b 0x40091fc3 0x40091063 0x40091423 0x40091a83 0x40083e80 0x40083f1f 0x4008db31 0x401b36c5 0x401bca20 0x40089ea1 0x40091e6b: invoke_abort at /home/openvehicles/build/esp-idf/components/esp32/panic.c:669 0x40091fc3: abort at /home/openvehicles/build/esp-idf/components/esp32/panic.c:669 0x40091063: multi_heap_assert at /home/openvehicles/build/esp-idf/components/heap/multi_heap.c:696 0x40091423: multi_heap_malloc_impl at /home/openvehicles/build/esp-idf/components/heap/multi_heap.c:696 0x40091a83: multi_heap_malloc at /home/openvehicles/build/esp-idf/components/heap/multi_heap_poisoning.c:328 0x40083e80: heap_caps_malloc at /home/openvehicles/build/esp-idf/components/heap/heap_caps.c:387 0x40083f1f: heap_caps_malloc_prefer at /home/openvehicles/build/esp-idf/components/heap/heap_caps.c:387 0x4008db31: wifi_malloc at /home/openvehicles/build/esp-idf/components/esp32/wifi_internal.c:31 0x401b36c5: esf_buf_alloc at ??:? 0x401bca20: wdevProcessRxSucDataAll at ??:? 0x40089ea1: ppTask at ??:? Maybe heap/stack corruption? But your module looks ok. What else do you have configured to run? Can you show the output of ‘config show auto’, ‘module memory’, and ‘module tasks’?
How is performance and power usage affected when using StandardMetrics.xxxxx->SetValue in the IncomingFrameCan1 method? Most of the messages update value every 100ms, and except maybe speed, battery current and voltage, most of the parameters are not changing that often. And even for the speed, current and voltage, it is probably enough to update StandardMetrics in the 1 second ticker... does this make sense or is the difference non-existing.
The function to set a metric’s value checks to see if the value has changed before updating, so should not be too expensive/costly to run. The only time I’ve seen this as an issue is when a value if flapping (changing every 1/100th second, as it moves around). You can workaround that with the age() function of the metric. Such as this example from vehicle_teslamodels: // Don't update battery voltage too quickly (as it jumps around like crazy) if (StandardMetrics.ms_v_bat_voltage->Age() > 10) StandardMetrics.ms_v_bat_voltage->SetValue(((float)((int)d[1]<<8)+d[0])/100); Or, if you really want to limit the number of updates, you could use monotonictime in your IncomingFrameCan1() function, and only run the code to look at changed metrics if it is different from the last run (which would delay metrics for a maximum of once every second): static uint32_t tc_monotonic = 0; void OvmsVehicleThinkCity::IncomingFrameCan1(CAN_frame_t* p_frame) { if (tc_monotonic == monotonictime) return; tc_monotonic = monotonictime ... Regards, Mark.
On 26 Jul 2018, at 3:59 PM, Nikolay Shishkov <nshishkov@yahoo.com> wrote:
Quick update: I managed to do a not so quick update on one of the ovms v.3 boxes that sits in a Think and can confirm that the porting seems to work. I could see speed, parking time, ambient temperature.
I had very strange problems doing the OTA update. The firmware start download and I can see the messages progressing, but it would halt in between 700kB and 1600kB and then stay there until I refresh the browser. And when I refresh the browser I am asked of my password which leads me to that there must have been a crash in the meantime.
I was finally able to get the OTA update work by disconnecting the box from the car and powering it via USB. This is a single data point but it kind of points to a problem with the code that communicates with the car.
I was not able to get a laptop connected to checkout the console, but managed to get the following log - not sure how to interpret it.
Last boot was 87 second(s) ago Time at boot: 2018-07-25 18:07:43 GMT This is reset #3 since last power cycle Detected boot reason: Crash (12/12) Crash counters: 3 total, 0 early
Last crash: Alloca exception on core 0 Registers: PC : 0x400dc8ec PS : 0x00060234 A0 : 0x8008f440 A1 : 0x3ffc45b0 A2 : 0x00000020 A3 : 0x00000001 A4 : 0x00000000 A5 : 0x3ffb44b8 A6 : 0x3ffb47e4 A7 : 0x3ffb458c A8 : 0x3ffb44d4 A9 : 0x3ffc4590 A10 : 0x00000000 A11 : 0x7fffffff A12 : 0x8008e65b A13 : 0x3ffcc450 A14 : 0x00000003 A15 : 0x00060023 SAR : 0x00000000 EXCCAUSE: 0x00000005 EXCVADDR: 0x00000000 LBEG : 0x00000000 LEND : 0x00000000 LCOUNT : 0x00000000 Backtrace: 0x400dc8ec 0x4008f43d 0x4008e181 0x400818cc 0x40082163 0x40083c4d 0x400dc8e9 Version: 3.1.008-29-gaf41242/ota_1/edge (build idf v3.1-dev-987-g55d915e Jul 6 2018 00:14:59) Running partition: ota_1 Boot partition: ota_1 Firmware: 3.1.008-29-gaf41242/ota_1/edge (build idf v3.1-dev-987-g55d915e Jul 6 2018 00:14:59)
How is performance and power usage affected when using StandardMetrics.xxxxx->SetValue in the IncomingFrameCan1 method? Most of the messages update value every 100ms, and except maybe speed, battery current and voltage, most of the parameters are not changing that often. And even for the speed, current and voltage, it is probably enough to update StandardMetrics in the 1 second ticker... does this make sense or is the difference non-existing.
Thanks for all the hand holding and help, Nikolay
On Thursday, July 19, 2018, 1:11:46 PM GMT+2, Nikolay Shishkov <nshishkov@yahoo.com> wrote:
Done. https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/143 <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/143>
I have not tested this in a vehicle. It would take some time to receive the new boxes, but I thought it may help someone to go further.
On Thursday, July 19, 2018, 12:46:28 PM GMT+2, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Best is to create a pull request, and let us know. We can check and merge with master.
Regards, Mark
On 19 Jul 2018, at 6:41 PM, Nikolay Shishkov <nshishkov@yahoo.com <mailto:nshishkov@yahoo.com>> wrote:
Thank you guys! I think I am ready with something I want to create pull request on. Do I do this through my own repository, or can I just send someone a diff? Nikolay
On Thursday, July 19, 2018, 12:37:58 PM GMT+2, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Nikolay,
- what is the best way to compare OvmsMetricStrings? Or should I dublicate the state in an enum and use that? - what is the best way to compare the OvmsMetricFloat to a literal float?
If you want to compare a state code encoded as a string, you can simply compare the std::string returned by AsString() with hard coded strings, e.g.
std::string charge_state = StdMetrics.ms_v_charge_state->AsString(); if (charge_state == "charging") …
If you'd rather use the old numeric state codes, there are utility functions in the ovms_utils module for encoding / decoding them.
As Mark wrote, you get the float value by the AsFloat() method and can compare that directly to a float literal. We haven't added comparison operators to the metrics classes yet, just assignment (and that needs casts in many cases). If you'd like to add more operators/types, go ahead.
- what is the current way of doing net_req_notification
Not required in v3. If you change a metric that needs notification, the serverv2 and serverv3 will act appropriately.
And if you want to customize standard notifications, you can do so by overloading the vehicle methods:
virtual void NotifyChargeState(); virtual void NotifyChargeStart(); virtual void NotifyHeatingStart(); virtual void NotifyChargeStopped(); virtual void NotifyChargeDone(); virtual void NotifyValetEnabled(); virtual void NotifyValetDisabled(); virtual void NotifyValetHood(); virtual void NotifyValetTrunk(); virtual void NotifyAlarmSounding(); virtual void NotifyAlarmStopped(); virtual void Notify12vCritical(); virtual void Notify12vRecovered();
If you want to add vehicle specific notifications, take a look at the Twizy module (rt_notify).
You can simply send a notification from any command output by issuing MyNotify.NotifyCommand() (att: stack intensive) or send any string by MyNotify.NotifyString(). There are also varargs versions with "f" suffix acting like printf.
For building strings from command methods, there is the StringWriter class, that's a std::string that can be used as an OvmsWriter. Example:
StringWriter buf(200); CommandStat(COMMAND_RESULT_NORMAL, &buf); MyNotify.NotifyString("info", "charge.sufficient", buf.c_str());
Best practice is to send notifications from within an event handler (e.g. Ticker1), so they run asynchronously in the event task context instead of blocking something.
Regards, Michael
PS: we should start collecting these pieces for the developer manual, the general system API is quite mature now
On 19 Jul 2018, at 6:00 AM, Nikolay Shishkov <nshishkov@yahoo.com <mailto:nshishkov@yahoo.com>> wrote:
Hi, I am working on the Think City EV code and have some questions. - what is the best way to signal that the charging connector is plugged? ms_v_charge_pilot? previously it was cardoorbits1.
- what is the best way to compare OvmsMetricStrings? Or should I dublicate the state in an enum and use that?
- what is the best way to compare the OvmsMetricFloat to a literal float?
- what is the current way of doing net_req_notification
Thanks in advance, Nikolay On Tuesday, July 17, 2018, 3:37:49 AM GMT+2, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Nikolay, you need to keep the .elf files for your builds to be able to analyze a backtrace. Do not use addr2line, it shows wrong line numbers. Use the script "a2l" I posted previously (I'll include it again below). Just feed it the .elf file and the backtrace. Example: a2l tmp/3.1.008-32-g2fa3ab8-elf/ovms3.elf 0x400dc8ec 0x4008f43d 0x4008e181 0x400818cc 0x40082163 0x40083c4d 0x400dc8e9 (I don't have the -28- version, so my output doesn't make sense) @Mark: spurious task WDT crashes and heap corruption crashes still occur, but it seems they have become less often with the internal RAM rework.
How is performance and power usage affected when using StandardMetrics.xxxxx->SetValue in the IncomingFrameCan1 method? Most of the messages update value every 100ms, and except maybe speed, battery current and voltage, most of the parameters are not changing that often. And even for the speed, current and voltage, it is probably enough to update StandardMetrics in the 1 second ticker... does this make sense or is the difference non-existing.
Extending Mark's answer: It's normally OK to directly set metrics from IncomingFrameCan1(), but be aware metrics listeners will be executed synchronously in the context that changes the metric. Standard metrics listeners are now for example the automatic notification generators in the vehicle base class. These may need quite some stack and time. If you spend too much time handling frames on a high volume bus, your vehicle task may lose frames. It's possible to raise the queue size (currently 20 frames) and the vehicle task stack size, but it's better to keep the CAN processing simple. TL;DR: if you need to handle many CAN frames, I recommend changing metrics that trigger notifications or other complex actions from the ticker. If you encounter crashes on some CAN frames that may be due to the vehicle task stack being too small (CONFIG_OVMS_VEHICLE_RXTASK_STACK=6144). Regards, Michael Script a2l: #!/bin/bash elf=~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms3.elf for adr in $* ; do if [[ "$adr" =~ "elf" ]] ; then elf="$adr" else cmd+=" -ex 'l *$adr'" fi done cmd+=" -ex 'q'" echo "Using elf file: $elf" eval xtensa-esp32-elf-gdb -batch $elf $cmd 2>/dev/null #| grep "^0x.* is in " Am 26.07.2018 um 09:59 schrieb Nikolay Shishkov:
Quick update: I managed to do a not so quick update on one of the ovms v.3 boxes that sits in a Think and can confirm that the porting seems to work. I could see speed, parking time, ambient temperature.
I had very strange problems doing the OTA update. The firmware start download and I can see the messages progressing, but it would halt in between 700kB and 1600kB and then stay there until I refresh the browser. And when I refresh the browser I am asked of my password which leads me to that there must have been a crash in the meantime.
I was finally able to get the OTA update work by disconnecting the box from the car and powering it via USB. This is a single data point but it kind of points to a problem with the code that communicates with the car.
I was not able to get a laptop connected to checkout the console, but managed to get the following log - not sure how to interpret it. Last boot was 87 second(s) ago Time at boot: 2018-07-25 18:07:43 GMT This is reset #3 since last power cycle Detected boot reason: Crash (12/12) Crash counters: 3 total, 0 early
Last crash: Alloca exception on core 0 Registers: PC : 0x400dc8ec PS : 0x00060234 A0 : 0x8008f440 A1 : 0x3ffc45b0 A2 : 0x00000020 A3 : 0x00000001 A4 : 0x00000000 A5 : 0x3ffb44b8 A6 : 0x3ffb47e4 A7 : 0x3ffb458c A8 : 0x3ffb44d4 A9 : 0x3ffc4590 A10 : 0x00000000 A11 : 0x7fffffff A12 : 0x8008e65b A13 : 0x3ffcc450 A14 : 0x00000003 A15 : 0x00060023 SAR : 0x00000000 EXCCAUSE: 0x00000005 EXCVADDR: 0x00000000 LBEG : 0x00000000 LEND : 0x00000000 LCOUNT : 0x00000000 Backtrace: 0x400dc8ec 0x4008f43d 0x4008e181 0x400818cc 0x40082163 0x40083c4d 0x400dc8e9 Version: 3.1.008-29-gaf41242/ota_1/edge (build idf v3.1-dev-987-g55d915e Jul 6 2018 00:14:59) Running partition: ota_1 Boot partition: ota_1 Firmware: 3.1.008-29-gaf41242/ota_1/edge (build idf v3.1-dev-987-g55d915e Jul 6 2018 00:14:59)
How is performance and power usage affected when using StandardMetrics.xxxxx->SetValue in the IncomingFrameCan1 method? Most of the messages update value every 100ms, and except maybe speed, battery current and voltage, most of the parameters are not changing that often. And even for the speed, current and voltage, it is probably enough to update StandardMetrics in the 1 second ticker... does this make sense or is the difference non-existing.
Thanks for all the hand holding and help, Nikolay
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Note that I store the .elf files alongside the .bin, for edge/eap/main builds. For example: http://api.openvehicles.com/firmware/ota/v3.1/edge/3.1.008-29-gaf41242.ovms3... <http://api.openvehicles.com/firmware/ota/v3.1/edge/3.1.008-29-gaf41242.ovms3.elf> Regards, Mark.
On 27 Jul 2018, at 5:51 AM, Michael Balzer <dexter@expeedo.de> wrote:
Nikolay,
you need to keep the .elf files for your builds to be able to analyze a backtrace. Do not use addr2line, it shows wrong line numbers. Use the script "a2l" I posted previously (I'll include it again below). Just feed it the .elf file and the backtrace. Example:
a2l tmp/3.1.008-32-g2fa3ab8-elf/ovms3.elf 0x400dc8ec 0x4008f43d 0x4008e181 0x400818cc 0x40082163 0x40083c4d 0x400dc8e9
(I don't have the -28- version, so my output doesn't make sense)
@Mark: spurious task WDT crashes and heap corruption crashes still occur, but it seems they have become less often with the internal RAM rework.
How is performance and power usage affected when using StandardMetrics.xxxxx->SetValue in the IncomingFrameCan1 method? Most of the messages update value every 100ms, and except maybe speed, battery current and voltage, most of the parameters are not changing that often. And even for the speed, current and voltage, it is probably enough to update StandardMetrics in the 1 second ticker... does this make sense or is the difference non-existing.
Extending Mark's answer:
It's normally OK to directly set metrics from IncomingFrameCan1(), but be aware metrics listeners will be executed synchronously in the context that changes the metric.
Standard metrics listeners are now for example the automatic notification generators in the vehicle base class. These may need quite some stack and time.
If you spend too much time handling frames on a high volume bus, your vehicle task may lose frames. It's possible to raise the queue size (currently 20 frames) and the vehicle task stack size, but it's better to keep the CAN processing simple.
TL;DR: if you need to handle many CAN frames, I recommend changing metrics that trigger notifications or other complex actions from the ticker. If you encounter crashes on some CAN frames that may be due to the vehicle task stack being too small (CONFIG_OVMS_VEHICLE_RXTASK_STACK=6144).
Regards, Michael
Script a2l:
#!/bin/bash elf=~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms3.elf for adr in $* ; do if [[ "$adr" =~ "elf" ]] ; then elf="$adr" else cmd+=" -ex 'l *$adr'" fi done cmd+=" -ex 'q'" echo "Using elf file: $elf" eval xtensa-esp32-elf-gdb -batch $elf $cmd 2>/dev/null #| grep "^0x.* is in "
Am 26.07.2018 um 09:59 schrieb Nikolay Shishkov:
Quick update: I managed to do a not so quick update on one of the ovms v.3 boxes that sits in a Think and can confirm that the porting seems to work. I could see speed, parking time, ambient temperature.
I had very strange problems doing the OTA update. The firmware start download and I can see the messages progressing, but it would halt in between 700kB and 1600kB and then stay there until I refresh the browser. And when I refresh the browser I am asked of my password which leads me to that there must have been a crash in the meantime.
I was finally able to get the OTA update work by disconnecting the box from the car and powering it via USB. This is a single data point but it kind of points to a problem with the code that communicates with the car.
I was not able to get a laptop connected to checkout the console, but managed to get the following log - not sure how to interpret it.
Last boot was 87 second(s) ago Time at boot: 2018-07-25 18:07:43 GMT This is reset #3 since last power cycle Detected boot reason: Crash (12/12) Crash counters: 3 total, 0 early
Last crash: Alloca exception on core 0 Registers: PC : 0x400dc8ec PS : 0x00060234 A0 : 0x8008f440 A1 : 0x3ffc45b0 A2 : 0x00000020 A3 : 0x00000001 A4 : 0x00000000 A5 : 0x3ffb44b8 A6 : 0x3ffb47e4 A7 : 0x3ffb458c A8 : 0x3ffb44d4 A9 : 0x3ffc4590 A10 : 0x00000000 A11 : 0x7fffffff A12 : 0x8008e65b A13 : 0x3ffcc450 A14 : 0x00000003 A15 : 0x00060023 SAR : 0x00000000 EXCCAUSE: 0x00000005 EXCVADDR: 0x00000000 LBEG : 0x00000000 LEND : 0x00000000 LCOUNT : 0x00000000 Backtrace: 0x400dc8ec 0x4008f43d 0x4008e181 0x400818cc 0x40082163 0x40083c4d 0x400dc8e9 Version: 3.1.008-29-gaf41242/ota_1/edge (build idf v3.1-dev-987-g55d915e Jul 6 2018 00:14:59) Running partition: ota_1 Boot partition: ota_1 Firmware: 3.1.008-29-gaf41242/ota_1/edge (build idf v3.1-dev-987-g55d915e Jul 6 2018 00:14:59)
How is performance and power usage affected when using StandardMetrics.xxxxx->SetValue in the IncomingFrameCan1 method? Most of the messages update value every 100ms, and except maybe speed, battery current and voltage, most of the parameters are not changing that often. And even for the speed, current and voltage, it is probably enough to update StandardMetrics in the 1 second ticker... does this make sense or is the difference non-existing.
Thanks for all the hand holding and help, Nikolay
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Thank you!Yes the carid is TC003. I was not running anything extraordinary - just followed the developer tutorial, but never flashed directly - always flashed from edge branch OTA. I will run the commands and provide output, but it will be with the newer firmware. I will need to see if updating will have same problems. On Friday, July 27, 2018, 3:07:09 AM GMT+2, Mark Webb-Johnson <mark@webb-johnson.net> wrote: Note that I store the .elf files alongside the .bin, for edge/eap/main builds. For example: http://api.openvehicles.com/firmware/ota/v3.1/edge/3.1.008-29-gaf41242.ovms3... Regards, Mark. On 27 Jul 2018, at 5:51 AM, Michael Balzer <dexter@expeedo.de> wrote: Nikolay, you need to keep the .elf files for your builds to be able to analyze a backtrace. Do not use addr2line, it shows wrong line numbers. Use the script "a2l" I posted previously (I'll include it again below). Just feed it the .elf file and the backtrace. Example: a2l tmp/3.1.008-32-g2fa3ab8-elf/ovms3.elf 0x400dc8ec 0x4008f43d 0x4008e181 0x400818cc 0x40082163 0x40083c4d 0x400dc8e9 (I don't have the -28- version, so my output doesn't make sense) @Mark: spurious task WDT crashes and heap corruption crashes still occur, but it seems they have become less often with the internal RAM rework. How is performance and power usage affected when using StandardMetrics.xxxxx->SetValue in the IncomingFrameCan1 method? Most of the messages update value every 100ms, and except maybe speed, battery current and voltage, most of the parameters are not changing that often. And even for the speed, current and voltage, it is probably enough to update StandardMetrics in the 1 second ticker... does this make sense or is the difference non-existing. Extending Mark's answer: It's normally OK to directly set metrics from IncomingFrameCan1(), but be aware metrics listeners will be executed synchronously in the context that changes the metric. Standard metrics listeners are now for example the automatic notification generators in the vehicle base class. These may need quite some stack and time. If you spend too much time handling frames on a high volume bus, your vehicle task may lose frames. It's possible to raise the queue size (currently 20 frames) and the vehicle task stack size, but it's better to keep the CAN processing simple. TL;DR: if you need to handle many CAN frames, I recommend changing metrics that trigger notifications or other complex actions from the ticker. If you encounter crashes on some CAN frames that may be due to the vehicle task stack being too small (CONFIG_OVMS_VEHICLE_RXTASK_STACK=6144). Regards, Michael Script a2l: #!/bin/bash elf=~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms3.elf for adr in $* ; do if [[ "$adr" =~ "elf" ]] ; then elf="$adr" else cmd+=" -ex 'l *$adr'" fi done cmd+=" -ex 'q'" echo "Using elf file: $elf" eval xtensa-esp32-elf-gdb -batch $elf $cmd 2>/dev/null #| grep "^0x.* is in " Am 26.07.2018 um 09:59 schrieb Nikolay Shishkov: Quick update: I managed to do a not so quick update on one of the ovms v.3 boxes that sits in a Think and can confirm that the porting seems to work. I could see speed, parking time, ambient temperature. I had very strange problems doing the OTA update. The firmware start download and I can see the messages progressing, but it would halt in between 700kB and 1600kB and then stay there until I refresh the browser. And when I refresh the browser I am asked of my password which leads me to that there must have been a crash in the meantime. I was finally able to get the OTA update work by disconnecting the box from the car and powering it via USB. This is a single data point but it kind of points to a problem with the code that communicates with the car. I was not able to get a laptop connected to checkout the console, but managed to get the following log - not sure how to interpret it. Last boot was 87 second(s) ago Time at boot: 2018-07-25 18:07:43 GMT This is reset #3 since last power cycle Detected boot reason: Crash (12/12) Crash counters: 3 total, 0 early Last crash: Alloca exception on core 0 Registers: PC : 0x400dc8ec PS : 0x00060234 A0 : 0x8008f440 A1 : 0x3ffc45b0 A2 : 0x00000020 A3 : 0x00000001 A4 : 0x00000000 A5 : 0x3ffb44b8 A6 : 0x3ffb47e4 A7 : 0x3ffb458c A8 : 0x3ffb44d4 A9 : 0x3ffc4590 A10 : 0x00000000 A11 : 0x7fffffff A12 : 0x8008e65b A13 : 0x3ffcc450 A14 : 0x00000003 A15 : 0x00060023 SAR : 0x00000000 EXCCAUSE: 0x00000005 EXCVADDR: 0x00000000 LBEG : 0x00000000 LEND : 0x00000000 LCOUNT : 0x00000000 Backtrace: 0x400dc8ec 0x4008f43d 0x4008e181 0x400818cc 0x40082163 0x40083c4d 0x400dc8e9 Version: 3.1.008-29-gaf41242/ota_1/edge (build idf v3.1-dev-987-g55d915e Jul 6 2018 00:14:59) Running partition: ota_1 Boot partition: ota_1 Firmware: 3.1.008-29-gaf41242/ota_1/edge (build idf v3.1-dev-987-g55d915e Jul 6 2018 00:14:59) How is performance and power usage affected when using StandardMetrics.xxxxx->SetValue in the IncomingFrameCan1 method? Most of the messages update value every 100ms, and except maybe speed, battery current and voltage, most of the parameters are not changing that often. And even for the speed, current and voltage, it is probably enough to update StandardMetrics in the 1 second ticker... does this make sense or is the difference non-existing. Thanks for all the hand holding and help, Nikolay -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Quick question.How do I convert this: while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x65; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx) while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x66; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx) while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x67; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx) while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x68; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx) To the new polling framework?I took a look at the leaf code, but the configuration is a mystery to me. What are the input parameters? Maybe there is a document that I am missing? Thanks in advance,Nikolay On Saturday, July 28, 2018, 11:42:13 PM GMT+2, Nikolay Shishkov <nshishkov@yahoo.com> wrote: Thank you!Yes the carid is TC003. I was not running anything extraordinary - just followed the developer tutorial, but never flashed directly - always flashed from edge branch OTA. I will run the commands and provide output, but it will be with the newer firmware. I will need to see if updating will have same problems. On Friday, July 27, 2018, 3:07:09 AM GMT+2, Mark Webb-Johnson <mark@webb-johnson.net> wrote: Note that I store the .elf files alongside the .bin, for edge/eap/main builds. For example: http://api.openvehicles.com/firmware/ota/v3.1/edge/3.1.008-29-gaf41242.ovms3... Regards, Mark. On 27 Jul 2018, at 5:51 AM, Michael Balzer <dexter@expeedo.de> wrote: Nikolay, you need to keep the .elf files for your builds to be able to analyze a backtrace. Do not use addr2line, it shows wrong line numbers. Use the script "a2l" I posted previously (I'll include it again below). Just feed it the .elf file and the backtrace. Example: a2l tmp/3.1.008-32-g2fa3ab8-elf/ovms3.elf 0x400dc8ec 0x4008f43d 0x4008e181 0x400818cc 0x40082163 0x40083c4d 0x400dc8e9 (I don't have the -28- version, so my output doesn't make sense) @Mark: spurious task WDT crashes and heap corruption crashes still occur, but it seems they have become less often with the internal RAM rework. How is performance and power usage affected when using StandardMetrics.xxxxx->SetValue in the IncomingFrameCan1 method? Most of the messages update value every 100ms, and except maybe speed, battery current and voltage, most of the parameters are not changing that often. And even for the speed, current and voltage, it is probably enough to update StandardMetrics in the 1 second ticker... does this make sense or is the difference non-existing. Extending Mark's answer: It's normally OK to directly set metrics from IncomingFrameCan1(), but be aware metrics listeners will be executed synchronously in the context that changes the metric. Standard metrics listeners are now for example the automatic notification generators in the vehicle base class. These may need quite some stack and time. If you spend too much time handling frames on a high volume bus, your vehicle task may lose frames. It's possible to raise the queue size (currently 20 frames) and the vehicle task stack size, but it's better to keep the CAN processing simple. TL;DR: if you need to handle many CAN frames, I recommend changing metrics that trigger notifications or other complex actions from the ticker. If you encounter crashes on some CAN frames that may be due to the vehicle task stack being too small (CONFIG_OVMS_VEHICLE_RXTASK_STACK=6144). Regards, Michael Script a2l: #!/bin/bash elf=~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms3.elf for adr in $* ; do if [[ "$adr" =~ "elf" ]] ; then elf="$adr" else cmd+=" -ex 'l *$adr'" fi done cmd+=" -ex 'q'" echo "Using elf file: $elf" eval xtensa-esp32-elf-gdb -batch $elf $cmd 2>/dev/null #| grep "^0x.* is in " Am 26.07.2018 um 09:59 schrieb Nikolay Shishkov: Quick update: I managed to do a not so quick update on one of the ovms v.3 boxes that sits in a Think and can confirm that the porting seems to work. I could see speed, parking time, ambient temperature. I had very strange problems doing the OTA update. The firmware start download and I can see the messages progressing, but it would halt in between 700kB and 1600kB and then stay there until I refresh the browser. And when I refresh the browser I am asked of my password which leads me to that there must have been a crash in the meantime. I was finally able to get the OTA update work by disconnecting the box from the car and powering it via USB. This is a single data point but it kind of points to a problem with the code that communicates with the car. I was not able to get a laptop connected to checkout the console, but managed to get the following log - not sure how to interpret it. Last boot was 87 second(s) ago Time at boot: 2018-07-25 18:07:43 GMT This is reset #3 since last power cycle Detected boot reason: Crash (12/12) Crash counters: 3 total, 0 early Last crash: Alloca exception on core 0 Registers: PC : 0x400dc8ec PS : 0x00060234 A0 : 0x8008f440 A1 : 0x3ffc45b0 A2 : 0x00000020 A3 : 0x00000001 A4 : 0x00000000 A5 : 0x3ffb44b8 A6 : 0x3ffb47e4 A7 : 0x3ffb458c A8 : 0x3ffb44d4 A9 : 0x3ffc4590 A10 : 0x00000000 A11 : 0x7fffffff A12 : 0x8008e65b A13 : 0x3ffcc450 A14 : 0x00000003 A15 : 0x00060023 SAR : 0x00000000 EXCCAUSE: 0x00000005 EXCVADDR: 0x00000000 LBEG : 0x00000000 LEND : 0x00000000 LCOUNT : 0x00000000 Backtrace: 0x400dc8ec 0x4008f43d 0x4008e181 0x400818cc 0x40082163 0x40083c4d 0x400dc8e9 Version: 3.1.008-29-gaf41242/ota_1/edge (build idf v3.1-dev-987-g55d915e Jul 6 2018 00:14:59) Running partition: ota_1 Boot partition: ota_1 Firmware: 3.1.008-29-gaf41242/ota_1/edge (build idf v3.1-dev-987-g55d915e Jul 6 2018 00:14:59) How is performance and power usage affected when using StandardMetrics.xxxxx->SetValue in the IncomingFrameCan1 method? Most of the messages update value every 100ms, and except maybe speed, battery current and voltage, most of the parameters are not changing that often. And even for the speed, current and voltage, it is probably enough to update StandardMetrics in the 1 second ticker... does this make sense or is the difference non-existing. Thanks for all the hand holding and help, Nikolay -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Nikolay, that code does an OBDIIEXTENDED (16 bit PID) poll of the four PIDs 0x4965 … 0x4968 at module ID 0x753 (0b11101010011) with replies coming in at ID 0x75b. That's something like this as a polling list: static const OvmsVehicle::poll_pid_t obdii_polls[] = { { 0x753, 0x75b, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4965, { 0, 1, 60 } }, { 0x753, 0x75b, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4966, { 0, 1, 60 } }, { 0x753, 0x75b, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4967, { 0, 1, 60 } }, { 0x753, 0x75b, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4968, { 0, 1, 60 } }, { 0, 0, 0x00, 0x00, { 0, 0, 0 } } }; If you set this as a PidList and set the poll state to 1, the polls will be done in series with 1 second interval (every 60 seconds in state 2). Note that's 4 seconds for a full loop, not as fast as the old implementation which blocked the idle callback for 400 ms to send the requests with 100 ms delays. If you really need these polls to be that fast (?), the polling framework needs some change, or you could continue to do this in custom code. For a custom implementation you would define a software timer to be called every 100 ms. A single CAN TX may be possible to do within the timer callback (take care: no blocking calls allowed). Another option would be to generate a custom poll request or 100 ms ticker event from the timer callback and use an event handler to actually do the TX. Regards, Michael Am 31.07.2018 um 20:57 schrieb Nikolay Shishkov:
Quick question. How do I convert this:
while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x65; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx)
while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x66; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx)
while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x67; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx)
while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x68; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx) To the new polling framework? I took a look at the leaf code, but the configuration is a mystery to me. What are the input parameters? Maybe there is a document that I am missing?
Thanks in advance, Nikolay On Saturday, July 28, 2018, 11:42:13 PM GMT+2, Nikolay Shishkov <nshishkov@yahoo.com> wrote:
Thank you! Yes the carid is TC003. I was not running anything extraordinary - just followed the developer tutorial, but never flashed directly - always flashed from edge branch OTA. I will run the commands and provide output, but it will be with the newer firmware. I will need to see if updating will have same problems.
On Friday, July 27, 2018, 3:07:09 AM GMT+2, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Note that I store the .elf files alongside the .bin, for edge/eap/main builds.
For example:
http://api.openvehicles.com/firmware/ota/v3.1/edge/3.1.008-29-gaf41242.ovms3...
Regards, Mark.
On 27 Jul 2018, at 5:51 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Nikolay,
you need to keep the .elf files for your builds to be able to analyze a backtrace. Do not use addr2line, it shows wrong line numbers. Use the script "a2l" I posted previously (I'll include it again below). Just feed it the .elf file and the backtrace. Example:
a2l tmp/3.1.008-32-g2fa3ab8-elf/ovms3.elf 0x400dc8ec 0x4008f43d 0x4008e181 0x400818cc 0x40082163 0x40083c4d 0x400dc8e9
(I don't have the -28- version, so my output doesn't make sense)
@Mark: spurious task WDT crashes and heap corruption crashes still occur, but it seems they have become less often with the internal RAM rework.
How is performance and power usage affected when using StandardMetrics.xxxxx->SetValue in the IncomingFrameCan1 method? Most of the messages update value every 100ms, and except maybe speed, battery current and voltage, most of the parameters are not changing that often. And even for the speed, current and voltage, it is probably enough to update StandardMetrics in the 1 second ticker... does this make sense or is the difference non-existing.
Extending Mark's answer:
It's normally OK to directly set metrics from IncomingFrameCan1(), but be aware metrics listeners will be executed synchronously in the context that changes the metric.
Standard metrics listeners are now for example the automatic notification generators in the vehicle base class. These may need quite some stack and time.
If you spend too much time handling frames on a high volume bus, your vehicle task may lose frames. It's possible to raise the queue size (currently 20 frames) and the vehicle task stack size, but it's better to keep the CAN processing simple.
TL;DR: if you need to handle many CAN frames, I recommend changing metrics that trigger notifications or other complex actions from the ticker. If you encounter crashes on some CAN frames that may be due to the vehicle task stack being too small (CONFIG_OVMS_VEHICLE_RXTASK_STACK=6144).
Regards, Michael
Script a2l:
#!/bin/bash elf=~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms3.elf for adr in $* ; do if [[ "$adr" =~ "elf" ]] ; then elf="$adr" else cmd+=" -ex 'l *$adr'" fi done cmd+=" -ex 'q'" echo "Using elf file: $elf" eval xtensa-esp32-elf-gdb -batch $elf $cmd 2>/dev/null #| grep "^0x.* is in "
Am 26.07.2018 um 09:59 schrieb Nikolay Shishkov: Quick update: I managed to do a not so quick update on one of the ovms v.3 boxes that sits in a Think and can confirm that the porting seems to work. I could see speed, parking time, ambient temperature.
I had very strange problems doing the OTA update. The firmware start download and I can see the messages progressing, but it would halt in between 700kB and 1600kB and then stay there until I refresh the browser. And when I refresh the browser I am asked of my password which leads me to that there must have been a crash in the meantime.
I was finally able to get the OTA update work by disconnecting the box from the car and powering it via USB. This is a single data point but it kind of points to a problem with the code that communicates with the car.
I was not able to get a laptop connected to checkout the console, but managed to get the following log - not sure how to interpret it. Last boot was 87 second(s) ago Time at boot: 2018-07-25 18:07:43 GMT This is reset #3 since last power cycle Detected boot reason: Crash (12/12) Crash counters: 3 total, 0 early
Last crash: Alloca exception on core 0 Registers: PC : 0x400dc8ec PS : 0x00060234 A0 : 0x8008f440 A1 : 0x3ffc45b0 A2 : 0x00000020 A3 : 0x00000001 A4 : 0x00000000 A5 : 0x3ffb44b8 A6 : 0x3ffb47e4 A7 : 0x3ffb458c A8 : 0x3ffb44d4 A9 : 0x3ffc4590 A10 : 0x00000000 A11 : 0x7fffffff A12 : 0x8008e65b A13 : 0x3ffcc450 A14 : 0x00000003 A15 : 0x00060023 SAR : 0x00000000 EXCCAUSE: 0x00000005 EXCVADDR: 0x00000000 LBEG : 0x00000000 LEND : 0x00000000 LCOUNT : 0x00000000 Backtrace: 0x400dc8ec 0x4008f43d 0x4008e181 0x400818cc 0x40082163 0x40083c4d 0x400dc8e9 Version: 3.1.008-29-gaf41242/ota_1/edge (build idf v3.1-dev-987-g55d915e Jul 6 2018 00:14:59) Running partition: ota_1 Boot partition: ota_1 Firmware: 3.1.008-29-gaf41242/ota_1/edge (build idf v3.1-dev-987-g55d915e Jul 6 2018 00:14:59)
How is performance and power usage affected when using StandardMetrics.xxxxx->SetValue in the IncomingFrameCan1 method? Most of the messages update value every 100ms, and except maybe speed, battery current and voltage, most of the parameters are not changing that often. And even for the speed, current and voltage, it is probably enough to update StandardMetrics in the 1 second ticker... does this make sense or is the difference non-existing.
Thanks for all the hand holding and help, Nikolay
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
I think I found a solution. Have not tested it yet. static const OvmsVehicle::poll_pid_t obdii_polls[] = { // 0x753 03 22 49 65 - charger temp { 0x753, 0x75B, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4965, { 0, 999, 999 } }, // 0x753 03 22 49 66 - pcu heat sink temp { 0x753, 0x75B, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4966, { 0, 999, 999 } }, // 0x753 03 22 49 67 - motor temp { 0x753, 0x75B, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4967, { 0, 999, 999 } }, // 0x753 03 22 49 68 - sli batt temp and volts { 0x753, 0x75B, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4968, { 0, 200, 200 } }, { 0, 0, 0x00, 0x00, { 0, 0, 0 } } }; On Tuesday, July 31, 2018, 8:57:51 PM GMT+2, Nikolay Shishkov <nshishkov@yahoo.com> wrote: Quick question.How do I convert this: while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x65; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx) while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x66; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx) while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x67; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx) while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x68; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx) To the new polling framework?I took a look at the leaf code, but the configuration is a mystery to me. What are the input parameters? Maybe there is a document that I am missing? Thanks in advance,Nikolay On Saturday, July 28, 2018, 11:42:13 PM GMT+2, Nikolay Shishkov <nshishkov@yahoo.com> wrote: Thank you!Yes the carid is TC003. I was not running anything extraordinary - just followed the developer tutorial, but never flashed directly - always flashed from edge branch OTA. I will run the commands and provide output, but it will be with the newer firmware. I will need to see if updating will have same problems. On Friday, July 27, 2018, 3:07:09 AM GMT+2, Mark Webb-Johnson <mark@webb-johnson.net> wrote: Note that I store the .elf files alongside the .bin, for edge/eap/main builds. For example: http://api.openvehicles.com/firmware/ota/v3.1/edge/3.1.008-29-gaf41242.ovms3... Regards, Mark. On 27 Jul 2018, at 5:51 AM, Michael Balzer <dexter@expeedo.de> wrote: Nikolay, you need to keep the .elf files for your builds to be able to analyze a backtrace. Do not use addr2line, it shows wrong line numbers. Use the script "a2l" I posted previously (I'll include it again below). Just feed it the .elf file and the backtrace. Example: a2l tmp/3.1.008-32-g2fa3ab8-elf/ovms3.elf 0x400dc8ec 0x4008f43d 0x4008e181 0x400818cc 0x40082163 0x40083c4d 0x400dc8e9 (I don't have the -28- version, so my output doesn't make sense) @Mark: spurious task WDT crashes and heap corruption crashes still occur, but it seems they have become less often with the internal RAM rework. How is performance and power usage affected when using StandardMetrics.xxxxx->SetValue in the IncomingFrameCan1 method? Most of the messages update value every 100ms, and except maybe speed, battery current and voltage, most of the parameters are not changing that often. And even for the speed, current and voltage, it is probably enough to update StandardMetrics in the 1 second ticker... does this make sense or is the difference non-existing. Extending Mark's answer: It's normally OK to directly set metrics from IncomingFrameCan1(), but be aware metrics listeners will be executed synchronously in the context that changes the metric. Standard metrics listeners are now for example the automatic notification generators in the vehicle base class. These may need quite some stack and time. If you spend too much time handling frames on a high volume bus, your vehicle task may lose frames. It's possible to raise the queue size (currently 20 frames) and the vehicle task stack size, but it's better to keep the CAN processing simple. TL;DR: if you need to handle many CAN frames, I recommend changing metrics that trigger notifications or other complex actions from the ticker. If you encounter crashes on some CAN frames that may be due to the vehicle task stack being too small (CONFIG_OVMS_VEHICLE_RXTASK_STACK=6144). Regards, Michael Script a2l: #!/bin/bash elf=~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms3.elf for adr in $* ; do if [[ "$adr" =~ "elf" ]] ; then elf="$adr" else cmd+=" -ex 'l *$adr'" fi done cmd+=" -ex 'q'" echo "Using elf file: $elf" eval xtensa-esp32-elf-gdb -batch $elf $cmd 2>/dev/null #| grep "^0x.* is in " Am 26.07.2018 um 09:59 schrieb Nikolay Shishkov: Quick update: I managed to do a not so quick update on one of the ovms v.3 boxes that sits in a Think and can confirm that the porting seems to work. I could see speed, parking time, ambient temperature. I had very strange problems doing the OTA update. The firmware start download and I can see the messages progressing, but it would halt in between 700kB and 1600kB and then stay there until I refresh the browser. And when I refresh the browser I am asked of my password which leads me to that there must have been a crash in the meantime. I was finally able to get the OTA update work by disconnecting the box from the car and powering it via USB. This is a single data point but it kind of points to a problem with the code that communicates with the car. I was not able to get a laptop connected to checkout the console, but managed to get the following log - not sure how to interpret it. Last boot was 87 second(s) ago Time at boot: 2018-07-25 18:07:43 GMT This is reset #3 since last power cycle Detected boot reason: Crash (12/12) Crash counters: 3 total, 0 early Last crash: Alloca exception on core 0 Registers: PC : 0x400dc8ec PS : 0x00060234 A0 : 0x8008f440 A1 : 0x3ffc45b0 A2 : 0x00000020 A3 : 0x00000001 A4 : 0x00000000 A5 : 0x3ffb44b8 A6 : 0x3ffb47e4 A7 : 0x3ffb458c A8 : 0x3ffb44d4 A9 : 0x3ffc4590 A10 : 0x00000000 A11 : 0x7fffffff A12 : 0x8008e65b A13 : 0x3ffcc450 A14 : 0x00000003 A15 : 0x00060023 SAR : 0x00000000 EXCCAUSE: 0x00000005 EXCVADDR: 0x00000000 LBEG : 0x00000000 LEND : 0x00000000 LCOUNT : 0x00000000 Backtrace: 0x400dc8ec 0x4008f43d 0x4008e181 0x400818cc 0x40082163 0x40083c4d 0x400dc8e9 Version: 3.1.008-29-gaf41242/ota_1/edge (build idf v3.1-dev-987-g55d915e Jul 6 2018 00:14:59) Running partition: ota_1 Boot partition: ota_1 Firmware: 3.1.008-29-gaf41242/ota_1/edge (build idf v3.1-dev-987-g55d915e Jul 6 2018 00:14:59) How is performance and power usage affected when using StandardMetrics.xxxxx->SetValue in the IncomingFrameCan1 method? Most of the messages update value every 100ms, and except maybe speed, battery current and voltage, most of the parameters are not changing that often. And even for the speed, current and voltage, it is probably enough to update StandardMetrics in the 1 second ticker... does this make sense or is the difference non-existing. Thanks for all the hand holding and help, Nikolay -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Thanks Michael, I did not refresh the mail thread and saw you answer after I posted my solution. I see about the states and the timing now... I may need to adjust this accordingly. I thought it was in milliseconds... These are all temperatures that are changing quite slow. So every 1 second or 4 seconds is perfectly fine. Hopefully I will have access to a car tomorrow and can test this. Thanks again,Nikolay On Wednesday, August 1, 2018, 1:06:32 AM GMT+2, Nikolay Shishkov <nshishkov@yahoo.com> wrote: I think I found a solution. Have not tested it yet. static const OvmsVehicle::poll_pid_t obdii_polls[] = { // 0x753 03 22 49 65 - charger temp { 0x753, 0x75B, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4965, { 0, 999, 999 } }, // 0x753 03 22 49 66 - pcu heat sink temp { 0x753, 0x75B, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4966, { 0, 999, 999 } }, // 0x753 03 22 49 67 - motor temp { 0x753, 0x75B, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4967, { 0, 999, 999 } }, // 0x753 03 22 49 68 - sli batt temp and volts { 0x753, 0x75B, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4968, { 0, 200, 200 } }, { 0, 0, 0x00, 0x00, { 0, 0, 0 } } }; On Tuesday, July 31, 2018, 8:57:51 PM GMT+2, Nikolay Shishkov <nshishkov@yahoo.com> wrote: Quick question.How do I convert this: while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x65; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx) while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x66; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx) while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x67; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx) while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x68; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx) To the new polling framework?I took a look at the leaf code, but the configuration is a mystery to me. What are the input parameters? Maybe there is a document that I am missing? Thanks in advance,Nikolay On Saturday, July 28, 2018, 11:42:13 PM GMT+2, Nikolay Shishkov <nshishkov@yahoo.com> wrote: Thank you!Yes the carid is TC003. I was not running anything extraordinary - just followed the developer tutorial, but never flashed directly - always flashed from edge branch OTA. I will run the commands and provide output, but it will be with the newer firmware. I will need to see if updating will have same problems. On Friday, July 27, 2018, 3:07:09 AM GMT+2, Mark Webb-Johnson <mark@webb-johnson.net> wrote: Note that I store the .elf files alongside the .bin, for edge/eap/main builds. For example: http://api.openvehicles.com/firmware/ota/v3.1/edge/3.1.008-29-gaf41242.ovms3... Regards, Mark. On 27 Jul 2018, at 5:51 AM, Michael Balzer <dexter@expeedo.de> wrote: Nikolay, you need to keep the .elf files for your builds to be able to analyze a backtrace. Do not use addr2line, it shows wrong line numbers. Use the script "a2l" I posted previously (I'll include it again below). Just feed it the .elf file and the backtrace. Example: a2l tmp/3.1.008-32-g2fa3ab8-elf/ovms3.elf 0x400dc8ec 0x4008f43d 0x4008e181 0x400818cc 0x40082163 0x40083c4d 0x400dc8e9 (I don't have the -28- version, so my output doesn't make sense) @Mark: spurious task WDT crashes and heap corruption crashes still occur, but it seems they have become less often with the internal RAM rework. How is performance and power usage affected when using StandardMetrics.xxxxx->SetValue in the IncomingFrameCan1 method? Most of the messages update value every 100ms, and except maybe speed, battery current and voltage, most of the parameters are not changing that often. And even for the speed, current and voltage, it is probably enough to update StandardMetrics in the 1 second ticker... does this make sense or is the difference non-existing. Extending Mark's answer: It's normally OK to directly set metrics from IncomingFrameCan1(), but be aware metrics listeners will be executed synchronously in the context that changes the metric. Standard metrics listeners are now for example the automatic notification generators in the vehicle base class. These may need quite some stack and time. If you spend too much time handling frames on a high volume bus, your vehicle task may lose frames. It's possible to raise the queue size (currently 20 frames) and the vehicle task stack size, but it's better to keep the CAN processing simple. TL;DR: if you need to handle many CAN frames, I recommend changing metrics that trigger notifications or other complex actions from the ticker. If you encounter crashes on some CAN frames that may be due to the vehicle task stack being too small (CONFIG_OVMS_VEHICLE_RXTASK_STACK=6144). Regards, Michael Script a2l: #!/bin/bash elf=~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms3.elf for adr in $* ; do if [[ "$adr" =~ "elf" ]] ; then elf="$adr" else cmd+=" -ex 'l *$adr'" fi done cmd+=" -ex 'q'" echo "Using elf file: $elf" eval xtensa-esp32-elf-gdb -batch $elf $cmd 2>/dev/null #| grep "^0x.* is in " Am 26.07.2018 um 09:59 schrieb Nikolay Shishkov: Quick update: I managed to do a not so quick update on one of the ovms v.3 boxes that sits in a Think and can confirm that the porting seems to work. I could see speed, parking time, ambient temperature. I had very strange problems doing the OTA update. The firmware start download and I can see the messages progressing, but it would halt in between 700kB and 1600kB and then stay there until I refresh the browser. And when I refresh the browser I am asked of my password which leads me to that there must have been a crash in the meantime. I was finally able to get the OTA update work by disconnecting the box from the car and powering it via USB. This is a single data point but it kind of points to a problem with the code that communicates with the car. I was not able to get a laptop connected to checkout the console, but managed to get the following log - not sure how to interpret it. Last boot was 87 second(s) ago Time at boot: 2018-07-25 18:07:43 GMT This is reset #3 since last power cycle Detected boot reason: Crash (12/12) Crash counters: 3 total, 0 early Last crash: Alloca exception on core 0 Registers: PC : 0x400dc8ec PS : 0x00060234 A0 : 0x8008f440 A1 : 0x3ffc45b0 A2 : 0x00000020 A3 : 0x00000001 A4 : 0x00000000 A5 : 0x3ffb44b8 A6 : 0x3ffb47e4 A7 : 0x3ffb458c A8 : 0x3ffb44d4 A9 : 0x3ffc4590 A10 : 0x00000000 A11 : 0x7fffffff A12 : 0x8008e65b A13 : 0x3ffcc450 A14 : 0x00000003 A15 : 0x00060023 SAR : 0x00000000 EXCCAUSE: 0x00000005 EXCVADDR: 0x00000000 LBEG : 0x00000000 LEND : 0x00000000 LCOUNT : 0x00000000 Backtrace: 0x400dc8ec 0x4008f43d 0x4008e181 0x400818cc 0x40082163 0x40083c4d 0x400dc8e9 Version: 3.1.008-29-gaf41242/ota_1/edge (build idf v3.1-dev-987-g55d915e Jul 6 2018 00:14:59) Running partition: ota_1 Boot partition: ota_1 Firmware: 3.1.008-29-gaf41242/ota_1/edge (build idf v3.1-dev-987-g55d915e Jul 6 2018 00:14:59) How is performance and power usage affected when using StandardMetrics.xxxxx->SetValue in the IncomingFrameCan1 method? Most of the messages update value every 100ms, and except maybe speed, battery current and voltage, most of the parameters are not changing that often. And even for the speed, current and voltage, it is probably enough to update StandardMetrics in the 1 second ticker... does this make sense or is the difference non-existing. Thanks for all the hand holding and help, Nikolay -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
That same module has not crashed in almost a week now. So maybe there was something that was not connected to Think City code and got fixed by some of the library fixes. I noticed that it takes almost half a minute for the gps location to update in the app. The same goes for the speed and other parameters. Is there a setting to make that more frequent? Also - I can see speed, but I am not providing it - is it coming from the GPS? Thanks again! On Wednesday, August 1, 2018, 1:11:49 AM GMT+2, Nikolay Shishkov <nshishkov@yahoo.com> wrote: Thanks Michael, I did not refresh the mail thread and saw you answer after I posted my solution. I see about the states and the timing now... I may need to adjust this accordingly. I thought it was in milliseconds... These are all temperatures that are changing quite slow. So every 1 second or 4 seconds is perfectly fine. Hopefully I will have access to a car tomorrow and can test this. Thanks again,Nikolay On Wednesday, August 1, 2018, 1:06:32 AM GMT+2, Nikolay Shishkov <nshishkov@yahoo.com> wrote: I think I found a solution. Have not tested it yet. static const OvmsVehicle::poll_pid_t obdii_polls[] = { // 0x753 03 22 49 65 - charger temp { 0x753, 0x75B, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4965, { 0, 999, 999 } }, // 0x753 03 22 49 66 - pcu heat sink temp { 0x753, 0x75B, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4966, { 0, 999, 999 } }, // 0x753 03 22 49 67 - motor temp { 0x753, 0x75B, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4967, { 0, 999, 999 } }, // 0x753 03 22 49 68 - sli batt temp and volts { 0x753, 0x75B, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4968, { 0, 200, 200 } }, { 0, 0, 0x00, 0x00, { 0, 0, 0 } } }; On Tuesday, July 31, 2018, 8:57:51 PM GMT+2, Nikolay Shishkov <nshishkov@yahoo.com> wrote: Quick question.How do I convert this: while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x65; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx) while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x66; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx) while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x67; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx) while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x68; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx) To the new polling framework?I took a look at the leaf code, but the configuration is a mystery to me. What are the input parameters? Maybe there is a document that I am missing? Thanks in advance,Nikolay On Saturday, July 28, 2018, 11:42:13 PM GMT+2, Nikolay Shishkov <nshishkov@yahoo.com> wrote: Thank you!Yes the carid is TC003. I was not running anything extraordinary - just followed the developer tutorial, but never flashed directly - always flashed from edge branch OTA. I will run the commands and provide output, but it will be with the newer firmware. I will need to see if updating will have same problems. On Friday, July 27, 2018, 3:07:09 AM GMT+2, Mark Webb-Johnson <mark@webb-johnson.net> wrote: Note that I store the .elf files alongside the .bin, for edge/eap/main builds. For example: http://api.openvehicles.com/firmware/ota/v3.1/edge/3.1.008-29-gaf41242.ovms3... Regards, Mark. On 27 Jul 2018, at 5:51 AM, Michael Balzer <dexter@expeedo.de> wrote: Nikolay, you need to keep the .elf files for your builds to be able to analyze a backtrace. Do not use addr2line, it shows wrong line numbers. Use the script "a2l" I posted previously (I'll include it again below). Just feed it the .elf file and the backtrace. Example: a2l tmp/3.1.008-32-g2fa3ab8-elf/ovms3.elf 0x400dc8ec 0x4008f43d 0x4008e181 0x400818cc 0x40082163 0x40083c4d 0x400dc8e9 (I don't have the -28- version, so my output doesn't make sense) @Mark: spurious task WDT crashes and heap corruption crashes still occur, but it seems they have become less often with the internal RAM rework. How is performance and power usage affected when using StandardMetrics.xxxxx->SetValue in the IncomingFrameCan1 method? Most of the messages update value every 100ms, and except maybe speed, battery current and voltage, most of the parameters are not changing that often. And even for the speed, current and voltage, it is probably enough to update StandardMetrics in the 1 second ticker... does this make sense or is the difference non-existing. Extending Mark's answer: It's normally OK to directly set metrics from IncomingFrameCan1(), but be aware metrics listeners will be executed synchronously in the context that changes the metric. Standard metrics listeners are now for example the automatic notification generators in the vehicle base class. These may need quite some stack and time. If you spend too much time handling frames on a high volume bus, your vehicle task may lose frames. It's possible to raise the queue size (currently 20 frames) and the vehicle task stack size, but it's better to keep the CAN processing simple. TL;DR: if you need to handle many CAN frames, I recommend changing metrics that trigger notifications or other complex actions from the ticker. If you encounter crashes on some CAN frames that may be due to the vehicle task stack being too small (CONFIG_OVMS_VEHICLE_RXTASK_STACK=6144). Regards, Michael Script a2l: #!/bin/bash elf=~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms3.elf for adr in $* ; do if [[ "$adr" =~ "elf" ]] ; then elf="$adr" else cmd+=" -ex 'l *$adr'" fi done cmd+=" -ex 'q'" echo "Using elf file: $elf" eval xtensa-esp32-elf-gdb -batch $elf $cmd 2>/dev/null #| grep "^0x.* is in " Am 26.07.2018 um 09:59 schrieb Nikolay Shishkov: Quick update: I managed to do a not so quick update on one of the ovms v.3 boxes that sits in a Think and can confirm that the porting seems to work. I could see speed, parking time, ambient temperature. I had very strange problems doing the OTA update. The firmware start download and I can see the messages progressing, but it would halt in between 700kB and 1600kB and then stay there until I refresh the browser. And when I refresh the browser I am asked of my password which leads me to that there must have been a crash in the meantime. I was finally able to get the OTA update work by disconnecting the box from the car and powering it via USB. This is a single data point but it kind of points to a problem with the code that communicates with the car. I was not able to get a laptop connected to checkout the console, but managed to get the following log - not sure how to interpret it. Last boot was 87 second(s) ago Time at boot: 2018-07-25 18:07:43 GMT This is reset #3 since last power cycle Detected boot reason: Crash (12/12) Crash counters: 3 total, 0 early Last crash: Alloca exception on core 0 Registers: PC : 0x400dc8ec PS : 0x00060234 A0 : 0x8008f440 A1 : 0x3ffc45b0 A2 : 0x00000020 A3 : 0x00000001 A4 : 0x00000000 A5 : 0x3ffb44b8 A6 : 0x3ffb47e4 A7 : 0x3ffb458c A8 : 0x3ffb44d4 A9 : 0x3ffc4590 A10 : 0x00000000 A11 : 0x7fffffff A12 : 0x8008e65b A13 : 0x3ffcc450 A14 : 0x00000003 A15 : 0x00060023 SAR : 0x00000000 EXCCAUSE: 0x00000005 EXCVADDR: 0x00000000 LBEG : 0x00000000 LEND : 0x00000000 LCOUNT : 0x00000000 Backtrace: 0x400dc8ec 0x4008f43d 0x4008e181 0x400818cc 0x40082163 0x40083c4d 0x400dc8e9 Version: 3.1.008-29-gaf41242/ota_1/edge (build idf v3.1-dev-987-g55d915e Jul 6 2018 00:14:59) Running partition: ota_1 Boot partition: ota_1 Firmware: 3.1.008-29-gaf41242/ota_1/edge (build idf v3.1-dev-987-g55d915e Jul 6 2018 00:14:59) How is performance and power usage affected when using StandardMetrics.xxxxx->SetValue in the IncomingFrameCan1 method? Most of the messages update value every 100ms, and except maybe speed, battery current and voltage, most of the parameters are not changing that often. And even for the speed, current and voltage, it is probably enough to update StandardMetrics in the 1 second ticker... does this make sense or is the difference non-existing. Thanks for all the hand holding and help, Nikolay -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Nikolay, see config → server v2 → update intervals. Regarding speed, you do provide it: StandardMetrics.ms_v_pos_speed->SetValue(((unsigned char) d[5]) / 2); …that's line 65 of the thinkcity module. There is no fallback to GPS speed. Regards, Michael Am 01.08.2018 um 21:10 schrieb Nikolay Shishkov:
That same module has not crashed in almost a week now. So maybe there was something that was not connected to Think City code and got fixed by some of the library fixes.
I noticed that it takes almost half a minute for the gps location to update in the app. The same goes for the speed and other parameters. Is there a setting to make that more frequent? Also - I can see speed, but I am not providing it - is it coming from the GPS?
Thanks again!
On Wednesday, August 1, 2018, 1:11:49 AM GMT+2, Nikolay Shishkov <nshishkov@yahoo.com> wrote:
Thanks Michael,
I did not refresh the mail thread and saw you answer after I posted my solution. I see about the states and the timing now... I may need to adjust this accordingly. I thought it was in milliseconds...
These are all temperatures that are changing quite slow. So every 1 second or 4 seconds is perfectly fine. Hopefully I will have access to a car tomorrow and can test this.
Thanks again, Nikolay On Wednesday, August 1, 2018, 1:06:32 AM GMT+2, Nikolay Shishkov <nshishkov@yahoo.com> wrote:
I think I found a solution. Have not tested it yet.
static const OvmsVehicle::poll_pid_t obdii_polls[] = { // 0x753 03 22 49 65 - charger temp { 0x753, 0x75B, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4965, { 0, 999, 999 } }, // 0x753 03 22 49 66 - pcu heat sink temp { 0x753, 0x75B, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4966, { 0, 999, 999 } }, // 0x753 03 22 49 67 - motor temp { 0x753, 0x75B, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4967, { 0, 999, 999 } }, // 0x753 03 22 49 68 - sli batt temp and volts { 0x753, 0x75B, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4968, { 0, 200, 200 } }, { 0, 0, 0x00, 0x00, { 0, 0, 0 } } };
On Tuesday, July 31, 2018, 8:57:51 PM GMT+2, Nikolay Shishkov <nshishkov@yahoo.com> wrote:
Quick question. How do I convert this:
while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x65; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx)
while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x66; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx)
while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x67; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx)
while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x68; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx) To the new polling framework? I took a look at the leaf code, but the configuration is a mystery to me. What are the input parameters? Maybe there is a document that I am missing?
Thanks in advance, Nikolay On Saturday, July 28, 2018, 11:42:13 PM GMT+2, Nikolay Shishkov <nshishkov@yahoo.com> wrote:
Thank you! Yes the carid is TC003. I was not running anything extraordinary - just followed the developer tutorial, but never flashed directly - always flashed from edge branch OTA. I will run the commands and provide output, but it will be with the newer firmware. I will need to see if updating will have same problems.
On Friday, July 27, 2018, 3:07:09 AM GMT+2, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Note that I store the .elf files alongside the .bin, for edge/eap/main builds.
For example:
http://api.openvehicles.com/firmware/ota/v3.1/edge/3.1.008-29-gaf41242.ovms3...
Regards, Mark.
On 27 Jul 2018, at 5:51 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Nikolay,
you need to keep the .elf files for your builds to be able to analyze a backtrace. Do not use addr2line, it shows wrong line numbers. Use the script "a2l" I posted previously (I'll include it again below). Just feed it the .elf file and the backtrace. Example:
a2l tmp/3.1.008-32-g2fa3ab8-elf/ovms3.elf 0x400dc8ec 0x4008f43d 0x4008e181 0x400818cc 0x40082163 0x40083c4d 0x400dc8e9
(I don't have the -28- version, so my output doesn't make sense)
@Mark: spurious task WDT crashes and heap corruption crashes still occur, but it seems they have become less often with the internal RAM rework.
How is performance and power usage affected when using StandardMetrics.xxxxx->SetValue in the IncomingFrameCan1 method? Most of the messages update value every 100ms, and except maybe speed, battery current and voltage, most of the parameters are not changing that often. And even for the speed, current and voltage, it is probably enough to update StandardMetrics in the 1 second ticker... does this make sense or is the difference non-existing.
Extending Mark's answer:
It's normally OK to directly set metrics from IncomingFrameCan1(), but be aware metrics listeners will be executed synchronously in the context that changes the metric.
Standard metrics listeners are now for example the automatic notification generators in the vehicle base class. These may need quite some stack and time.
If you spend too much time handling frames on a high volume bus, your vehicle task may lose frames. It's possible to raise the queue size (currently 20 frames) and the vehicle task stack size, but it's better to keep the CAN processing simple.
TL;DR: if you need to handle many CAN frames, I recommend changing metrics that trigger notifications or other complex actions from the ticker. If you encounter crashes on some CAN frames that may be due to the vehicle task stack being too small (CONFIG_OVMS_VEHICLE_RXTASK_STACK=6144).
Regards, Michael
Script a2l:
#!/bin/bash elf=~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms3.elf for adr in $* ; do if [[ "$adr" =~ "elf" ]] ; then elf="$adr" else cmd+=" -ex 'l *$adr'" fi done cmd+=" -ex 'q'" echo "Using elf file: $elf" eval xtensa-esp32-elf-gdb -batch $elf $cmd 2>/dev/null #| grep "^0x.* is in "
Am 26.07.2018 um 09:59 schrieb Nikolay Shishkov: Quick update: I managed to do a not so quick update on one of the ovms v.3 boxes that sits in a Think and can confirm that the porting seems to work. I could see speed, parking time, ambient temperature.
I had very strange problems doing the OTA update. The firmware start download and I can see the messages progressing, but it would halt in between 700kB and 1600kB and then stay there until I refresh the browser. And when I refresh the browser I am asked of my password which leads me to that there must have been a crash in the meantime.
I was finally able to get the OTA update work by disconnecting the box from the car and powering it via USB. This is a single data point but it kind of points to a problem with the code that communicates with the car.
I was not able to get a laptop connected to checkout the console, but managed to get the following log - not sure how to interpret it. Last boot was 87 second(s) ago Time at boot: 2018-07-25 18:07:43 GMT This is reset #3 since last power cycle Detected boot reason: Crash (12/12) Crash counters: 3 total, 0 early
Last crash: Alloca exception on core 0 Registers: PC : 0x400dc8ec PS : 0x00060234 A0 : 0x8008f440 A1 : 0x3ffc45b0 A2 : 0x00000020 A3 : 0x00000001 A4 : 0x00000000 A5 : 0x3ffb44b8 A6 : 0x3ffb47e4 A7 : 0x3ffb458c A8 : 0x3ffb44d4 A9 : 0x3ffc4590 A10 : 0x00000000 A11 : 0x7fffffff A12 : 0x8008e65b A13 : 0x3ffcc450 A14 : 0x00000003 A15 : 0x00060023 SAR : 0x00000000 EXCCAUSE: 0x00000005 EXCVADDR: 0x00000000 LBEG : 0x00000000 LEND : 0x00000000 LCOUNT : 0x00000000 Backtrace: 0x400dc8ec 0x4008f43d 0x4008e181 0x400818cc 0x40082163 0x40083c4d 0x400dc8e9 Version: 3.1.008-29-gaf41242/ota_1/edge (build idf v3.1-dev-987-g55d915e Jul 6 2018 00:14:59) Running partition: ota_1 Boot partition: ota_1 Firmware: 3.1.008-29-gaf41242/ota_1/edge (build idf v3.1-dev-987-g55d915e Jul 6 2018 00:14:59)
How is performance and power usage affected when using StandardMetrics.xxxxx->SetValue in the IncomingFrameCan1 method? Most of the messages update value every 100ms, and except maybe speed, battery current and voltage, most of the parameters are not changing that often. And even for the speed, current and voltage, it is probably enough to update StandardMetrics in the 1 second ticker... does this make sense or is the difference non-existing.
Thanks for all the hand holding and help, Nikolay
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Forgot: the streaming mode (feature #8 / config vehicle stream) is an option to raise the location update frequency when the car is on. It's now interpreted as the interval in seconds, so "1" will give you per second updates. Regards, Michael Am 01.08.2018 um 21:40 schrieb Michael Balzer:
Nikolay,
see config → server v2 → update intervals.
Regarding speed, you do provide it: StandardMetrics.ms_v_pos_speed->SetValue(((unsigned char) d[5]) / 2);
…that's line 65 of the thinkcity module. There is no fallback to GPS speed.
Regards, Michael
Am 01.08.2018 um 21:10 schrieb Nikolay Shishkov:
That same module has not crashed in almost a week now. So maybe there was something that was not connected to Think City code and got fixed by some of the library fixes.
I noticed that it takes almost half a minute for the gps location to update in the app. The same goes for the speed and other parameters. Is there a setting to make that more frequent? Also - I can see speed, but I am not providing it - is it coming from the GPS?
Thanks again!
On Wednesday, August 1, 2018, 1:11:49 AM GMT+2, Nikolay Shishkov <nshishkov@yahoo.com> wrote:
Thanks Michael,
I did not refresh the mail thread and saw you answer after I posted my solution. I see about the states and the timing now... I may need to adjust this accordingly. I thought it was in milliseconds...
These are all temperatures that are changing quite slow. So every 1 second or 4 seconds is perfectly fine. Hopefully I will have access to a car tomorrow and can test this.
Thanks again, Nikolay On Wednesday, August 1, 2018, 1:06:32 AM GMT+2, Nikolay Shishkov <nshishkov@yahoo.com> wrote:
I think I found a solution. Have not tested it yet.
static const OvmsVehicle::poll_pid_t obdii_polls[] = { // 0x753 03 22 49 65 - charger temp { 0x753, 0x75B, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4965, { 0, 999, 999 } }, // 0x753 03 22 49 66 - pcu heat sink temp { 0x753, 0x75B, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4966, { 0, 999, 999 } }, // 0x753 03 22 49 67 - motor temp { 0x753, 0x75B, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4967, { 0, 999, 999 } }, // 0x753 03 22 49 68 - sli batt temp and volts { 0x753, 0x75B, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4968, { 0, 200, 200 } }, { 0, 0, 0x00, 0x00, { 0, 0, 0 } } };
On Tuesday, July 31, 2018, 8:57:51 PM GMT+2, Nikolay Shishkov <nshishkov@yahoo.com> wrote:
Quick question. How do I convert this:
while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x65; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx)
while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x66; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx)
while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x67; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx)
while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x68; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx) To the new polling framework? I took a look at the leaf code, but the configuration is a mystery to me. What are the input parameters? Maybe there is a document that I am missing?
Thanks in advance, Nikolay On Saturday, July 28, 2018, 11:42:13 PM GMT+2, Nikolay Shishkov <nshishkov@yahoo.com> wrote:
Thank you! Yes the carid is TC003. I was not running anything extraordinary - just followed the developer tutorial, but never flashed directly - always flashed from edge branch OTA. I will run the commands and provide output, but it will be with the newer firmware. I will need to see if updating will have same problems.
On Friday, July 27, 2018, 3:07:09 AM GMT+2, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Note that I store the .elf files alongside the .bin, for edge/eap/main builds.
For example:
http://api.openvehicles.com/firmware/ota/v3.1/edge/3.1.008-29-gaf41242.ovms3...
Regards, Mark.
On 27 Jul 2018, at 5:51 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Nikolay,
you need to keep the .elf files for your builds to be able to analyze a backtrace. Do not use addr2line, it shows wrong line numbers. Use the script "a2l" I posted previously (I'll include it again below). Just feed it the .elf file and the backtrace. Example:
a2l tmp/3.1.008-32-g2fa3ab8-elf/ovms3.elf 0x400dc8ec 0x4008f43d 0x4008e181 0x400818cc 0x40082163 0x40083c4d 0x400dc8e9
(I don't have the -28- version, so my output doesn't make sense)
@Mark: spurious task WDT crashes and heap corruption crashes still occur, but it seems they have become less often with the internal RAM rework.
How is performance and power usage affected when using StandardMetrics.xxxxx->SetValue in the IncomingFrameCan1 method? Most of the messages update value every 100ms, and except maybe speed, battery current and voltage, most of the parameters are not changing that often. And even for the speed, current and voltage, it is probably enough to update StandardMetrics in the 1 second ticker... does this make sense or is the difference non-existing.
Extending Mark's answer:
It's normally OK to directly set metrics from IncomingFrameCan1(), but be aware metrics listeners will be executed synchronously in the context that changes the metric.
Standard metrics listeners are now for example the automatic notification generators in the vehicle base class. These may need quite some stack and time.
If you spend too much time handling frames on a high volume bus, your vehicle task may lose frames. It's possible to raise the queue size (currently 20 frames) and the vehicle task stack size, but it's better to keep the CAN processing simple.
TL;DR: if you need to handle many CAN frames, I recommend changing metrics that trigger notifications or other complex actions from the ticker. If you encounter crashes on some CAN frames that may be due to the vehicle task stack being too small (CONFIG_OVMS_VEHICLE_RXTASK_STACK=6144).
Regards, Michael
Script a2l:
#!/bin/bash elf=~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms3.elf for adr in $* ; do if [[ "$adr" =~ "elf" ]] ; then elf="$adr" else cmd+=" -ex 'l *$adr'" fi done cmd+=" -ex 'q'" echo "Using elf file: $elf" eval xtensa-esp32-elf-gdb -batch $elf $cmd 2>/dev/null #| grep "^0x.* is in "
Am 26.07.2018 um 09:59 schrieb Nikolay Shishkov: Quick update: I managed to do a not so quick update on one of the ovms v.3 boxes that sits in a Think and can confirm that the porting seems to work. I could see speed, parking time, ambient temperature.
I had very strange problems doing the OTA update. The firmware start download and I can see the messages progressing, but it would halt in between 700kB and 1600kB and then stay there until I refresh the browser. And when I refresh the browser I am asked of my password which leads me to that there must have been a crash in the meantime.
I was finally able to get the OTA update work by disconnecting the box from the car and powering it via USB. This is a single data point but it kind of points to a problem with the code that communicates with the car.
I was not able to get a laptop connected to checkout the console, but managed to get the following log - not sure how to interpret it. Last boot was 87 second(s) ago Time at boot: 2018-07-25 18:07:43 GMT This is reset #3 since last power cycle Detected boot reason: Crash (12/12) Crash counters: 3 total, 0 early
Last crash: Alloca exception on core 0 Registers: PC : 0x400dc8ec PS : 0x00060234 A0 : 0x8008f440 A1 : 0x3ffc45b0 A2 : 0x00000020 A3 : 0x00000001 A4 : 0x00000000 A5 : 0x3ffb44b8 A6 : 0x3ffb47e4 A7 : 0x3ffb458c A8 : 0x3ffb44d4 A9 : 0x3ffc4590 A10 : 0x00000000 A11 : 0x7fffffff A12 : 0x8008e65b A13 : 0x3ffcc450 A14 : 0x00000003 A15 : 0x00060023 SAR : 0x00000000 EXCCAUSE: 0x00000005 EXCVADDR: 0x00000000 LBEG : 0x00000000 LEND : 0x00000000 LCOUNT : 0x00000000 Backtrace: 0x400dc8ec 0x4008f43d 0x4008e181 0x400818cc 0x40082163 0x40083c4d 0x400dc8e9 Version: 3.1.008-29-gaf41242/ota_1/edge (build idf v3.1-dev-987-g55d915e Jul 6 2018 00:14:59) Running partition: ota_1 Boot partition: ota_1 Firmware: 3.1.008-29-gaf41242/ota_1/edge (build idf v3.1-dev-987-g55d915e Jul 6 2018 00:14:59)
How is performance and power usage affected when using StandardMetrics.xxxxx->SetValue in the IncomingFrameCan1 method? Most of the messages update value every 100ms, and except maybe speed, battery current and voltage, most of the parameters are not changing that often. And even for the speed, current and voltage, it is probably enough to update StandardMetrics in the 1 second ticker... does this make sense or is the difference non-existing.
Thanks for all the hand holding and help, Nikolay
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Fixed some stuff and added some for the Think City. There is still more to be done but here is the status so far. https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/150 On Wednesday, August 1, 2018, 9:46:12 PM GMT+2, Michael Balzer <dexter@expeedo.de> wrote: Forgot: the streaming mode (feature #8 / config vehicle stream) is an option to raise the location update frequency when the car is on. It's now interpreted as the interval in seconds, so "1" will give you per second updates. Regards, Michael Am 01.08.2018 um 21:40 schrieb Michael Balzer: Nikolay, see config → server v2 → update intervals. Regarding speed, you do provide it: StandardMetrics.ms_v_pos_speed->SetValue(((unsigned char) d[5]) / 2); …that's line 65 of the thinkcity module. There is no fallback to GPS speed. Regards, Michael Am 01.08.2018 um 21:10 schrieb Nikolay Shishkov: That same module has not crashed in almost a week now. So maybe there was something that was not connected to Think City code and got fixed by some of the library fixes. I noticed that it takes almost half a minute for the gps location to update in the app. The same goes for the speed and other parameters. Is there a setting to make that more frequent? Also - I can see speed, but I am not providing it - is it coming from the GPS? Thanks again! On Wednesday, August 1, 2018, 1:11:49 AM GMT+2, Nikolay Shishkov <nshishkov@yahoo.com> wrote: Thanks Michael, I did not refresh the mail thread and saw you answer after I posted my solution. I see about the states and the timing now... I may need to adjust this accordingly. I thought it was in milliseconds... These are all temperatures that are changing quite slow. So every 1 second or 4 seconds is perfectly fine. Hopefully I will have access to a car tomorrow and can test this. Thanks again, Nikolay On Wednesday, August 1, 2018, 1:06:32 AM GMT+2, Nikolay Shishkov <nshishkov@yahoo.com> wrote: I think I found a solution. Have not tested it yet. static const OvmsVehicle::poll_pid_t obdii_polls[] = { // 0x753 03 22 49 65 - charger temp { 0x753, 0x75B,VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4965, { 0, 999, 999 } }, // 0x753 03 22 49 66 - pcu heat sink temp { 0x753, 0x75B,VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4966, { 0, 999, 999 } }, // 0x753 03 22 49 67 - motor temp { 0x753, 0x75B,VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4967, { 0, 999, 999 } }, // 0x753 03 22 49 68 - sli batt temp and volts { 0x753, 0x75B,VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4968, { 0, 200, 200 } }, { 0, 0, 0x00, 0x00, { 0, 0, 0 } } }; On Tuesday, July 31, 2018, 8:57:51 PM GMT+2, Nikolay Shishkov <nshishkov@yahoo.com> wrote: Quick question. How do I convert this: while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x65; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx) while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x66; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx) while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x67; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx) while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x68; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx) To the new polling framework? I took a look at the leaf code, but the configuration is a mystery to me. What are the input parameters? Maybe there is a document that I am missing? Thanks in advance, Nikolay On Saturday, July 28, 2018, 11:42:13 PM GMT+2, Nikolay Shishkov <nshishkov@yahoo.com> wrote: Thank you! Yes the carid is TC003. I was not running anything extraordinary - just followed the developer tutorial, but never flashed directly - always flashed from edge branch OTA. I will run the commands and provide output, but it will be with the newer firmware. I will need to see if updating will have same problems. On Friday, July 27, 2018, 3:07:09 AM GMT+2, Mark Webb-Johnson <mark@webb-johnson.net> wrote: Note that I store the .elf files alongside the .bin, for edge/eap/main builds. For example: http://api.openvehicles.com/firmware/ota/v3.1/edge/3.1.008-29-gaf41242.ovms3... Regards, Mark. On 27 Jul 2018, at 5:51 AM, Michael Balzer <dexter@expeedo.de> wrote: Nikolay, you need to keep the .elf files for your builds to be able to analyze a backtrace. Do not use addr2line, it shows wrong line numbers. Use the script "a2l" I posted previously (I'll include it again below). Just feed it the .elf file and the backtrace. Example: a2ltmp/3.1.008-32-g2fa3ab8-elf/ovms3.elf 0x400dc8ec 0x4008f43d 0x4008e181 0x400818cc 0x40082163 0x40083c4d 0x400dc8e9 (I don't have the -28- version, so my output doesn't make sense) @Mark: spurious task WDT crashes and heap corruption crashes still occur, but it seems they have become less often with the internal RAM rework. How is performance and power usage affected when using StandardMetrics.xxxxx->SetValue in the IncomingFrameCan1 method? Most of the messages update value every 100ms, and except maybe speed, battery current and voltage, most of the parameters are not changing that often. And even for the speed, current and voltage, it is probably enough to update StandardMetrics in the 1 second ticker... does this make sense or is the difference non-existing. Extending Mark's answer: It's normally OK to directly set metrics from IncomingFrameCan1(), but be aware metrics listeners will be executed synchronously in the context that changes the metric. Standard metrics listeners are now for example the automatic notification generators in the vehicle base class. These may need quite some stack and time. If you spend too much time handling frames on a high volume bus, your vehicle task may lose frames. It's possible to raise the queue size (currently 20 frames) and the vehicle task stack size, but it's better to keep the CAN processing simple. TL;DR: if you need to handle many CAN frames, I recommend changing metrics that trigger notifications or other complex actions from the ticker. If you encounter crashes on some CAN frames that may be due to the vehicle task stack being too small (CONFIG_OVMS_VEHICLE_RXTASK_STACK=6144). Regards, Michael Script a2l: #!/bin/bash elf=~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms3.elf for adr in $* ; do if [[ "$adr" =~ "elf" ]] ; then elf="$adr" else cmd+=" -ex 'l *$adr'" fi done cmd+=" -ex 'q'" echo "Using elf file: $elf" evalxtensa-esp32-elf-gdb -batch $elf $cmd 2>/dev/null #| grep "^0x.* is in " Am 26.07.2018 um 09:59 schrieb Nikolay Shishkov: Quick update: I managed to do a not so quick update on one of the ovms v.3 boxes that sits in a Think and can confirm that the porting seems to work. I could see speed, parking time, ambient temperature. I had very strange problems doing the OTA update. The firmware start download and I can see the messages progressing, but it would halt in between 700kB and 1600kB and then stay there until I refresh the browser. And when I refresh the browser I am asked of my password which leads me to that there must have been a crash in the meantime. I was finally able to get the OTA update work by disconnecting the box from the car and powering it via USB. This is a single data point but it kind of points to a problem with the code that communicates with the car. I was not able to get a laptop connected to checkout the console, but managed to get the following log - not sure how to interpret it. Last boot was 87 second(s) ago Time at boot: 2018-07-25 18:07:43 GMT This is reset #3 since last power cycle Detected boot reason: Crash (12/12) Crash counters: 3 total, 0 early Last crash: Alloca exception on core 0 Registers: PC : 0x400dc8ec PS : 0x00060234 A0 : 0x8008f440 A1 : 0x3ffc45b0 A2 : 0x00000020 A3 : 0x00000001 A4 : 0x00000000 A5 : 0x3ffb44b8 A6 : 0x3ffb47e4 A7 : 0x3ffb458c A8 : 0x3ffb44d4 A9 : 0x3ffc4590 A10 : 0x00000000 A11 : 0x7fffffff A12 : 0x8008e65b A13 : 0x3ffcc450 A14 : 0x00000003 A15 : 0x00060023 SAR : 0x00000000 EXCCAUSE: 0x00000005 EXCVADDR: 0x00000000 LBEG : 0x00000000 LEND : 0x00000000 LCOUNT : 0x00000000 Backtrace: 0x400dc8ec 0x4008f43d 0x4008e181 0x400818cc 0x40082163 0x40083c4d 0x400dc8e9 Version:3.1.008-29-gaf41242/ota_1/edge (build idf v3.1-dev-987-g55d915e Jul 6 2018 00:14:59) Running partition: ota_1 Boot partition: ota_1 Firmware:3.1.008-29-gaf41242/ota_1/edge (build idf v3.1-dev-987-g55d915e Jul 6 2018 00:14:59) How is performance and power usage affected when using StandardMetrics.xxxxx->SetValue in the IncomingFrameCan1 method? Most of the messages update value every 100ms, and except maybe speed, battery current and voltage, most of the parameters are not changing that often. And even for the speed, current and voltage, it is probably enough to update StandardMetrics in the 1 second ticker... does this make sense or is the difference non-existing. Thanks for all the hand holding and help, Nikolay -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
participants (3)
-
Mark Webb-Johnson -
Michael Balzer -
Nikolay Shishkov