Add timestamps to measured values

[moritz-h]

This PR extends the firmware to address two problems when using the bricklet in measurement setups in order to increase measurement accuracy, i.e. for use in scientific work¹.
First, the current firmware reads the results from the INA226 when ever a new value is available, but the callback trigger runs fully asynchronous of this. This could lead to an unpredictable delay of the measured values. E.g. using a configuration of 588us conversion time for voltage and current and an averaging value of 4 will provide a new value from the INA226 every ~4.7 ms. If the callback triggers every 5 ms the measured value could be something between 0 and 4.7ms old already. In addition, as the time spans from the configuration and the time spans from the callback do not match, some values may be lost or send multiple times, which may is suboptimal when using the measured values for integration over time.
Further, when using many of these bricklets (>10) with a high temporal resolution connected to a stack of multiple master bricks, the transfer speed may is limited which leads to observable jittering of the time spans when measured values are received. This makes it inaccurate when time stamps are added only when receiving values.

To solve this a new callback is added, which is triggered directly when the INA226 has a new value instead of using a time based callback and, further, a timestamp is stored and transmitted for the measured values. The get_time function allows to read the bricklet time to synchronize.
Limitation: A timestamp is stored internally to detect value changes, therefore if the conversion/averaging times provide multiple values per millisecond, still only a single callback is triggered.

This PR is made as draft because currently the new functionality is only added for the power values. Before continuing work, you may have some feedback if you are interested in these features for the official firmware or if it is too special interest to be merged.
If this is interesting for you we are of course also open for feedback to the actual implementation. For testing we generated the bindings here: https://github.com/UniStuttgart-VISUS/generators/tree/power-time

Footnotes

1. Müller et al. "Power Overwhelming: Quantifying the Energy Cost of Visualisation," https://doi.org/10.1109/BELIV57783.2022.00009 ↩

[borg42]

I have no objections to the changes. If possible please also make a pull request for the config in the generator git after you changed the "since_firmware" field to [2, 0, 4] and added some documentation :).

[moritz-h]

I have added functions including a timestep also for voltage and current now.

[borg42]

Looks good! I will probably have time on next Wednesday to try it out and write a small test and then merge it afterwards.

[moritz-h]

Hi, do you have any update on this, if there is still interest in getting this merged?