Detect and store sudden impacts

[nvandoorn]

Sudden impacts can occur at any time, and we need to be sure to capture and report each one. This can be achieved by using an interrupt pin from the accelerometer (1), or by polling frequently enough to catch all impacts (2).

Please have a look at #4 first as it contains some additional constraints.

1. Interrupt Pin

This solution seems like the better one as it avoids burning CPU time and cuts down on i2c bus traffic (few other devices on the same bus as well). It's conceptually simple as well: bind a callback to a change on this pin, and then in that callback, handle the change.

Unfortunately it seems this pin is not triggering. I've tried a few times and never seen it change. This can likely be configured in the BMI160 driver code, but this isn't for the faint of heart. More details about changes to the driver code will be captured in a separate issue.

2. Polling

This solution avoids any work on the driver, but overall this solution seems "technically" worse, however sometimes shipping is truly better than perfection (though this seems like a good starting point).

Threaded Synchronous Polling

Timed reads are performed within a never ending loop that runs within a thread. This thread synchronizes its results back to the global scope using some synchronization data structure (e.g mutex). Some other service later retrieves these values using our defined API.

Asynchronous Polling

A timer is started with a callback that reads the value. The callback can safely store and modify things in the global scope since it's running in the main thread. If another service makes a call to retrieve a value while the timer is running the read callback, this request will be queue'd until the callback is done reading the values. After the read is done, the request from another service will be handled, and the timer will queue another execution of the read callback.

This may seem more confusing, but it avoids requiring synchronization between threads.