Yep, I'll update the documentation. About timer I suggest you to use the afb-helpers library which provides some functions to start and stop a timer setting an interval and count. May be it could suit your need:
https://docs.automotivelinux.org/docs/en/master/devguides/reference/afb-helpers/afb-timer.html
Regards.
Okay, thanks, Romain. You may want to update the documentation to indicate that the send_same flag will not yield the implied behavior. I'll think about whether adding the complexity of a timer and/or thread to drive the volume controls asynchronously is worth it for the CES demo.
Scott
On Fri, Dec 13, 2019 at 8:04 AM Romain Forlot [IoT.bzh] <romain.forlot@xxxxxxx> wrote:
I've checked and the flag is fine. This behavior comes from the use of the BCM socketCAN that prevents receiving two consecutives frames with the same data.
The socket doesn't process frames if data haven't changed. This is the design of the BCM socket that wants that. Timeout could be used to ensure that messages are sent within a time interval but frames without modification wouldn't be processed anyway. At this time timeout aren't handled.
I got a suggestion to handle your use case, why not handle that in your function that receives the event and you just have to increase the volume regularly until the release event are received. No ?
Regards.
On 12/12/2019 20:19, Scott Murray wrote:
Thanks, Romain. I notice in application-generated.cpp that all the messages seem to have send_same set:
...
frequency_clock_t(0.00000f),// frequency
true,// send_same
false,// force_send_changed
...
Which I would have thought would mean they'd be sending all the time without changes, but we're not seeing that. Before I dig around in low-can, is it possible the flag is reversed (i.e. send_same needs to be false to send all the time)?
Thanks,
Scott
On Thu, Dec 12, 2019 at 5:52 AM Romain Forlot [IoT.bzh] <romain.forlot@xxxxxxx> wrote:
Hi Scott,
Sorry for the delay, yes indeed, the low-can only generate events if the
value/data has changed so you only get the first messages. You can use
the 'send_same' property of the signal to get it sent even if there is
no changes :)
I have to improve the documentation to fully describe the JSON property
when you define your signals and messages. Yes :/
Regards.
Romain.
On 10/12/2019 23:38, Scott Murray wrote:
> Romain,
>
> I have a question about the behavior of the low-can binding. For the
> steering wheel button CAN messages, the polling done by the LIN setup
> generates a message every 100 milliseconds. When one of the steering
> wheel buttons is held down, I do see with candump that the message
> repeats with the bit for the button set, but I see with the low-can
> monitoring page that only one event is generated for the first
> message, and no more are generated until the button is released.
> Ideally, we'd like to get events from low-can for every incoming
> steering wheel message, even if there is no change to its contents, so
> that we can handle usecases like increasing the sound volume if the
> volume+ button is held down. Is there a way to do that with low-can?
> I thought I'd seen a mention of a flag for it at one point, but I
> can't find it in the documentation now.
>
> Thanks,
>
> Scott
--
Romain Forlot - Embedded Engineer - IoT.bzh
romain.forlot@xxxxxxx - www.iot.bzh - +33675142438
-- Romain Forlot - Embedded Engineer - IoT.bzh romain.forlot@xxxxxxx - www.iot.bzh - +33675142438
-- Romain Forlot - Embedded Engineer - IoT.bzh romain.forlot@xxxxxxx - www.iot.bzh - +33675142438
Links:
You receive all messages sent to this group.
View/Reply Online (#7904) |
Reply To Group
| Reply To Sender
|
Mute This Topic
| New Topic
Your Subscription |
Contact Group Owner |
Unsubscribe
[list-automotive-discussions82@xxxxxxxxxxx]
