[Ovmsdev] P/R 859 - Moving polling to separate thread & More polling ideas

[Michael Balzer]

Michael,

I'm sorry I currently don't have the time to support you properly. I had 
a look at your PR some days ago, saw some issues and got the impression 
something must be missing either from your PR or in my understanding of 
your goal with that PR – it seemed the changes now wouldn't have any 
effect on poll frequency at all, which I assumed was the initial goal. I 
didn't have the time to do a proper analysis.

Regarding moving the poller to a job worker/client model, that's very 
welcome. I recommend taking a look at my CANopen implementation, which 
implements that model and provides workers per bus, asynchronous and 
synchronous client APIs and a general shell interface. While CANopen is 
quite different from ISOTP, the basic principles are the same.

CANopen usage: 
https://docs.openvehicles.com/en/latest/components/canopen/docs/index.html

That was my first larger FreeRTOS application, so may be improvable, but 
it works nicely (currently only used by the Twizy adapter).

Regards,
Michael


Am 06.04.23 um 11:45 schrieb Michael Geddes:
> This is an example of where I'm headed.  This creates and activates a 
> Once-off poll entry that doesn't block (and removes itself from the 
> poll list once it is done).
> A success will call Incoming_Full with a std::string buffer  and a 
> fail calls Incoming_Fail.
>
>     bool OvmsHyundaiIoniqEv::PollRequestVIN()
>     {
>       if (!StdMetrics.ms_v_env_awake->AsBool()) {
>         ESP_LOGV(TAG, "PollRequestVIN: Not Awake Request not sent");
>         return false;
>       }
>       auto poll_entry = std::shared_ptr<OvmsVehicle::OnceOffPoll>(
>           new OvmsVehicle::OnceOffPoll(m_can1,
>     std::bind(&OvmsHyundaiIoniqEv::Incoming_Full, this, _1, _2, _3,
>     _4, _5, _6),
>     std::bind(&OvmsHyundaiIoniqEv::Incoming_Fail, this, _1, _2, _3,
>     _4, _5, _6),
>     VEHICLE_OBD_BROADCAST_MODULE_TX, VEHICLE_OBD_BROADCAST_MODULE_RX,
>     VEHICLE_POLL_TYPE_OBDIIVEHICLE,  2,
>             ISOTP_STD, 0, 3/*retries*/ ));
>       PollRequest("!xiq.vin", poll_entry);
>       return true;
>     }
>
>
> On Tue, 4 Apr 2023 at 07:13, Michael Geddes 
> <frog at bunyip.wheelycreek.net> wrote:
>
>     Hi all,
>     I was after some feedback on
>     https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/859
>
>     which moves the ISOTP polling into what is currently the ISOTP
>     response thread.
>
>     This is part of a larger rework I have been doing to add
>     flexibility to the loop and to move the poll-loop operations
>     behind a clean interface.
>
>     I'm interested in feedback on the mechanism in the p/r directly,
>     but I'm also happy to provide the usage examples I have (which
>     would be the follow-up commits for Ioniq 5).
>
>     I'm also interested in other people's thoughts on where they see
>     what improvements might be had to the poll-list mechanism.
>     Already Done:
>       * Clean up the blocking poll mechanism
>       * Allow for multiple concurrent poll lists (still executed
>     sequentially)
>       * Add once-off non-blocking poll mechanism
>       * Add a poll-list that allows repeating more-frequently than the
>     primary poll
>
>     Ideas:
>       * Add a user-configurable poller that could possibly utilise the
>     DBC framework (on top of the existing vehicle framework) to allow
>     exploring/experimenting with both passive data as well as polled
>     data. (Given that the DBC framework already does the heavy lifting
>     of interpreting data - adding a poll request to that seems to be a
>     nice way of going)
>       * ??? Have a poll thread per bus ???
>     //.ichael
>
>

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20230407/7ae338d3/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20230407/7ae338d3/attachment.sig>