Configurable data processor, at least for libRd53b
The RD53B allows for data to be formatted in several specific ways, to name a few:
- hitmap compression or not
- dropping ToT
- with or without end of stream markers
- chip id encoded in the data stream or not
- number of events per stream
Right now, the Rd53bDataProcessor effectively handles only a single decoding, as a result of (at least) hard-coding a few parameters here.
Make the Rd53bDataProcessor configurable, such that it is simple to change it as the need arises. This will also make it easy to test the various decoding schemes to ensure that they are always valid.
In the most generic case, when considering link sharing or handling multiple input rx links, the data from different chips may not be formatted the same. For example: chip 1 may have hitmap compression and chip 2 may not.
As we move towards an improved dataflow to handle link sharing with dedicated data processors per front-end, it may be good to ensure that they are separately configured according to the expected data format of the front-end that they are associated with.