Filter for crossfireTelemetryPop()

[wimalopaan]

Using more than one widget that deques messages out of the LUA crossfire telemetry fifo can led to unwanted results, because a widget can only decide if the message belongs to it after it has already removed the message from the fifo. So, another widget may miss messages that were directed to it.

The widget must decide to extract the message or not before it does so: it must peek into the messsage queue.

The simplest and less intrusive way would be to introduce an optional argument to crossfireTelemetryPop() that holds a table with e.g. up to 8 bytes that are compared to the first 8 bytes (or less) of the first message in the LUA telemetry fifo. If they match (they may also contain wildcard bytes), the message is returned from the call to crossfieTelemetryPop().

But if there is still a grab-all widget running among the set of active widgets, it will still steal messages that would belong to another widgets, if it calls crossfireTelemetryPop() often enough.

So, the solution must be to have a sorting of messages based on a filter into different message queues.

For this I suggest to introduce a new LUA function crossfireTelemetryFilter() with one table argument that creates a dedicated message fifo for the calling widget (if possible, returning true otherwise returning false) and installs the filter for that queue. I suggest to allow no more that 8 such dedicated message fifos (each 256 bytes), so that at most 2K of additional memory is needed. Every time a new crossfire telemetry message arrives, that is not a well know telemetry package is then routed to the decicated message queue if its filter criteria matches. If not, it is routed to the unfiltered queue as before.

This requires to store a handle to the dedicated message queue in the widget datastructure, because this queue must be destroyed when the widget gets destroyed.

The next call to crossfireTelemetryPop() then should pop a message out of this dedicated message queue. This requires that this call can get the origin of the call (the widget) and can decide which dedicated message queue to use.

A subsequent call to crossfireTelemetryFilter() replaces the filter, if there is already a dedicated message queue for the calling widget (otherwise a new one is created, see above).

There is no explicit way to destroy the decicated queue, this is done when the widget ist destroyed.

The filtering compares up to the first 8 bytes of a crossfire telemetry package after the sync byte. So one can filter according to length, type, ext-destination, ext-source, and 4 additional bytes (e.g. Ardupilot tunneling ID). Value 0 serves as a wildcard as this value is uselss for the first 4 bytes.

My actual questions are:

• how to store the handle to the dedicated message queue or how to insert a cleanup-callback in the widget?
• how can the LUA functions figure out the calling widget?

Help very much appreciated ;-)