Having "BIT" in the name gives the impression we are using the macro is
the bit position; however they have the values for those actions, not
the bit position. Rename BIT to VAL to be less confusing.
This is the equivalent of sleep and wait for the conversion time,
after had triggered a new sample request. However it also has the added
benefits of sharing a thread with other sensors on the same bus.
Now we don't read the status register anymore since we have a guaranteed
wait time.
- Make sure device is reset while initializing.
- Give better names to register macros
- Average X, Y and Z by 16: sensor is internally running at 200 sps
(theoretical, ~160 pratical). The wait time is ~6msec averaging
by 16. We do 10msec.
Just setting up the periodic callback sampling time on initialization
may not work well for sensors that need to request for a sample with a
bus transaction, sleep and then read the new data. That's because the
function will be kept calling at a periodic rate, while the time in
which we can read the value is not really that sampling time, but rather
the time in which sensor was last read + the time spent in the function
before sending a new sample request.
Instead of creating a new type of thread to handle this case, just
implement the minimal and easy case of updating the period for this
callback, that can only be called from inside the callback function.
Differentiating if the path should be relative to the build dir or the
ROMFS dir based purely on the type of the item is not a good approach.
This prepares the way to have more files on ROMFS with different names
on src and dst.
Standardize on the following sequence for allowing different startup
sequences:
board-specific file
etc/rc on microSD card
etc/rc.txt on microSD card
Also remove comment about MODE variable that is not used by ArduPilot
Randy Mackay
Jonathan Challinger
Jacob Walser
Lucas De Marchi
Tom Pittenger