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

[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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20230406/53aa924d/attachment.htm>