This PR implements multi-threading for sensor data collection. This has a few benefits:
Scheduler Control
The scheduler handles which threads get to run, so multiple operations can be performed concurrently when the I2C bus is not locked, speeding up the program. Any sensors (like the system clock) that do not use the I2C bus can run significantly more often.
Additionally, threads can be given higher or lower priorities, which is useful for prioritizing certain data to collect when fetcher is modified to receive commands eventually.
Better sensor interface
The original sensor interface/API developed for fetcher has limitations, such as reducing precision into only three options, allowing only a single piece of data to be read at a time using polling, etc.
Now, the sensor drivers can be written as C utilities for full control over the sensor implementation, making use of all the options a sensor can offer. Additionally, for sensor with batch read operations (like the GPS), these batch read commands can be sent and then the thread can block until the data is prepared, relinquishing the bus to other sensors in the meantime.
This additional thread of control allows InSpace devs to put whatever logic they want to control how a sensor collects data into its own thread of control, removing any limitations of the previous API.
Notes
In the future, sensor threads should communicate with the main thread of control using message queues instead of printing the information themselves. This is a temporary fix while I wait to enable mqueue in the microkernel image.
This PR implements multi-threading for sensor data collection. This has a few benefits:
Scheduler Control
The scheduler handles which threads get to run, so multiple operations can be performed concurrently when the I2C bus is not locked, speeding up the program. Any sensors (like the system clock) that do not use the I2C bus can run significantly more often.
Additionally, threads can be given higher or lower priorities, which is useful for prioritizing certain data to collect when fetcher is modified to receive commands eventually.
Better sensor interface
The original sensor interface/API developed for fetcher has limitations, such as reducing precision into only three options, allowing only a single piece of data to be read at a time using polling, etc.
Now, the sensor drivers can be written as C utilities for full control over the sensor implementation, making use of all the options a sensor can offer. Additionally, for sensor with batch read operations (like the GPS), these batch read commands can be sent and then the thread can block until the data is prepared, relinquishing the bus to other sensors in the meantime.
This additional thread of control allows InSpace devs to put whatever logic they want to control how a sensor collects data into its own thread of control, removing any limitations of the previous API.
Notes
In the future, sensor threads should communicate with the main thread of control using message queues instead of printing the information themselves. This is a temporary fix while I wait to enable
mqueuein the microkernel image.