Ideas for improved filtering

Currently, only the SocketCAN plugin allows to specify filters. These filters specify, which frames received from the CAN controller are finally received by the user application. Filtered frames are discarded by the SocketCAN layer. In contrast to other implementations, the SocketCAN layer does a software filtering; that allows different applications to listen to the same CAN interface with different filters.

For QCanBus, I see the following possible improvements:

• Allow also to specify a range of CAN-IDs to filter, instead specifying a CAN-ID together with a mask.
• Allow transforming the CAN-ID range to (the next possible) CAN-ID/mask representation and vice versa
• Implement filtering in the other plugins (PeakCAN, VectorCAN, SystecCAN) also
• As hardware filtering only provides limited features [1], implement a software filtering for all plugins within QCanBusDevice. This would also allow some statistics about received/filtered/delivered messages

[1] Some quotes about hardware filter limitations from the PCAN-Basic help file:

• Take in account that configuring the message filter cause the CAN controller to enter the Reset state. This will affect other applications that communicate with the same PCAN hardware.  
• There is only one filter for standard and extended CAN messages. It seems that the ID from a standard message uses the most significant 11 bits (bit 18 to 28) of the 29 bits. I.e. the standard ID 400h is also received by indicating an extended ID 10000000h. For this reason it is not recommended to mix standard and extended filters, since it can increase the risk of receiving unwanted messages.
• Multiple calls of FilterMessages expand the reception filter.
• It is not guaranteed that an application only receives CAN messages in the range of FromID to ToID. This is caused by the operating principle of the SJA1000's acceptance filter. See also Philips Data Sheet "SJA1000 Stand-alone CAN-controller".