Unipi/evok input change detection lagging

  • Hi @tomas_hora,
    I am continuing this discussion that was started in here in a separate topic as I think it might be useful for future reference.

    We have already established that above a proper hardware with I2C interface running at 12MHz, there is a bottleneck - a polling mechanism which scans for changes and triggers updates on all interfaces. The polling frequency can be adjusted in /etc/evok.conf.

    By default the polling freq. is set to 2 resulting in delays up to 0.5s before an input change is propagated to the websocket interface.

    Setting it to 7 results in a let's say acceptable delay of up to 0.1s but it also increases cpu usage above 10%. Even though the delays are now acceptable it still happens that a short key press and release is not reported to the websocket at all (counter is increased, but the change is not reported).
    I have measured the key press-release pulse duration. With my wall pushbutton I can not make a pulse shorter than 80ms, typically lasting around 100ms. Missing a pulse of 80ms makes this device useles for many industrial scenarios...

    So what can we do to detect shorter pulses? One option could be to use counter change as a trigger.
    DirectSwitch is not an option... I want some logic between input and output.

    You really don't have a hw change interrupt wired to raspberry gpios that would forcre immediate SPI update ;)? I am not familiar with rpi interrupt mechanisms, but from a perspective of an embedded systems designer this seems like the way to go.

    Best regards,

  • administrators

    @oversc0re Interrupt mechanisms are implemented only for some things like serial lines. The communication is designed like this because right now, the only communication interface is TCP Modbus (Evok is also using it) where you also cannot use interrupts - you have to poll for the changes.

    We might be able to implement interrupts for DIs but maybe later when the FileSystem access to all IOs is ready because it requires a huge amount of work and it would also have to be implemented on each SW platform - not only evok.

  • Ok, I understand. For now we will burn some cpu to avoid lagging :) Setting polling interval to 8 or 9 works for me at the moment.

    Although in my opinion if you want to be taken seriously on the market, you really have to improve this part. Other than that, so far I am really happy with the device.

    Thanx for your replies and support.