Dev

…t finished yet...code will not compile.

… a defined run status of the internal thread

…orward a detected event to the daemon. With this, all basic functions of the daemon seem to work.

Not working yet and to be implemented in the new gpio readout scheme:
- pulse rate limitation for high freq. bursts
- sampling trigger signals (for triggering the ADC readout)
- time and time difference measurements for the population of two histos

Note: For the daemon to work with the new libgpiod based readout, several things have to be changed from the pigpiod scheme:
- the user who is executing the daemon (usually muonuser) must be added to the system group 'gpio' with 'sudo usermod -a -G gpio muonuser'
- the pigpiod daemon must be switched off
- the libgpiod-dev package must be installed on the system prior to compilation

…rom the former callback function are not yet forwarded, but the core mechanism of event detection works. Pins may be registered/unregistered during runtime and set/get gpio functions also seem to work. Note, that the executing user must be member of gpio group.

…tion:

- implemented trigger for ADC sampling
- implemented GPIO inhibit
- default eventTrigger signal is now GPIO_UNDEFINED_PIN, i.e. no trigger set up. This still has to be implemented as valid selection in the GUI

…plemented for the tracking of the XOR and AND rates in the daemon.

… by an instance of this class now. RateBuffer contains a smart rate throttling which prevents lock-up of daemon and GUI at excessive rates.

This branch should now privide equal or better functionality compared to the pigpiod daemon.
However, the following features are not yet implemented:
- Measurement of the system time deviation from GNSS (timpulse) time
- Measurement of the GPIO event interval (as in the histogram under statistics tab of the GUI with the same name). This may be implemented easily with the help of the RateBuffer class.

…val"). Adjusted scaling of several histograms.

…signal is explicitly not bound to a fixed GPIO pin.

Corrected some wrong assignments in the GPIO pin list for HW Ver 1.

…class

…d for running the daemon with access to the gpio kernel subsystem.

- added measurement of time pulse to system time

… the range -0.5s...+0.5s, instead of 0...1s as before

Co-authored-by: Daniel Treffenstädt <[email protected]>

Co-authored-by: Daniel Treffenstädt <[email protected]>

Co-authored-by: Daniel Treffenstädt <[email protected]>

Co-authored-by: Daniel Treffenstädt <[email protected]>

Co-authored-by: Daniel Treffenstädt <[email protected]>

Co-authored-by: Daniel Treffenstädt <[email protected]>

Co-authored-by: Daniel Treffenstädt <[email protected]>

Co-authored-by: Daniel Treffenstädt <[email protected]>

Co-authored-by: Daniel Treffenstädt <[email protected]>

Co-authored-by: Daniel Treffenstädt <[email protected]>

Co-authored-by: Daniel Treffenstädt <[email protected]>

Co-authored-by: Daniel Treffenstädt <[email protected]>

Co-authored-by: Daniel Treffenstädt <[email protected]>

- removed separate the samplingTrigger handling in PigpiodHandler
- merged slots for gpio events in daemon into one onGpioPinEvent() slot
- removed unregistering interrupts in PigpiodHandler before registering them again. This would be the cleanest procedure but somehow it doesn't work from gpiod side

…eBuffer classes to more descriptive event and filteredEvent.

- Added transmission of interrupt timestamp to event and filteredEvent signals.

- moved all event handlers to separately spawned threads for each interrupt line
- added map to store the last time intervals between events from different gpios in RateBuffer class
- changed filling of gpioTimeIntervalShort histogram to time intervals measured between the currently selected eventTrigger and the rising edge of TIME_MEAS_OUT signal

…ile success

…prior merge conflict. Added ratebuffer.cpp file which was not commited properly during the last big PR.

…ge descriptor) to make this libgpiod-development branch discernible from the mainstream packages

…e to 10ms

…is in gpio group

V2.1.0