Currently I'm working on a application for my RPi which will be monitoring a set of GPIOs in real-time where the exact time when the GPIO turns HIGH is crucial for my application.
The actual date is not important when the specific event happen, instead the exact time relative to the other events is. (i.e the data recorded will be shown in a graph where the spacing between the events should be as exact as possible.)
I believe it will help if I create a separate listener thread for each GPIO I want to monitor. What can be a bit tricky is that two events might occur on two (or more) different GPIOs simultaneously, which my belief is that it can be solved somewhat by using different threads.
Another piece of information worth sharing is that I'm using Java with the PI4J library. Is there a better way to implement this specifically or is this way fine for my particular application? I don't know very much about the RPi hardware and what it really is capable of, so my ultimate goal is to find the fastest and the least CPU demanding solution as possible. And where the most important thing is time, my tolerance of accuracy is about 5-10 ms AT MOST.
Because of the fact my application is multi-threaded if this is the way to go I believe the accuracy might drop the more threads I have, because it will put more stress on the poor little RPi. Is this significant for this kind of application?
To break this down, my question is if a multi-threading environment is a ideal/decent solution when listening separately to multiple GPIOs in real-time?
I'd like your input on this because performance in this application is very significant to keep the real-time functionallity.