On 11/03/2015 11:36 AM, Aleksander Morgado wrote: > Unrelated to all this, another key point in ARINC is the timing for > each label when transmitting. The common case you get is different > labels being sent continuously with a given rate for each. E.g. labels > 310 and 311 every 80ms, label 312 every 120ms and so on. I'm not sure > the HOLT chips have any specific way of configuring this, but I've > seen some USB devices which actually have APIs to say e.g. "send label > 310 every 80ms" and then you can just update the value being sent > without needing to take care of the TX rate. I'd have loved to see > that instead of the complex filtering :) I know this is way too much > for the generic kernel driver, though, so just a heads up of how this > usually works. >
The CAN stack already has a solution for this. The CAN_BCM socket is a programmable (content) filter for cyclic messages which are common in automotive setups to detect timeouts in cyclic messages (sender fails). An the best thing: You can use the Linux internal high-res timers to send messages - just by creating a TX_SETUP configuration for the BCM. Read this: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/Documentation/networking/can.txt?h=linux-4.2.y#n634 Just one more reason to use PF_CAN :-) -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
