Firmware Next Steps

This page lists suggested improvements to make on the device firmware that are known at this time.

Improvements

  • Default values in header files are flagged as errors and won't build properly. Investigate why this is happening (couldn't find anything in forums) and change . Example: it would be nice to have KX134_1211.h have bool print = 0 at the end of read_from_XOUT, …YOUT, …ZOUT, etc., and remove the need for a print value in all subsequent calls. default_arg_error.PNG
  • In the accelerometer driver, specifically the power-on function, there is a recursive loop with no way to escape from it if something goes wrong. There should be an escape condition (probably a simple count-down) and then a mechanism that will tell the gateway that the accelerometer isn't working in the event of a malfunction.

Further Research

  • It may be necessary to apply a transformation on the tick function at some point to make up for temperature fluctuation (see Timing page).
  • If acceleration data is looking weird, it might be important to go back into the product specification manual, specifically for timing:
    • "Enable to Valid Outputs (Start-Up Time) - After the part is enabled (PC1 bit in Control Register 1 is asserted), it takes from 2 ms to 1300 ms depending on the ODR and Power Mode setting before the acceleration outputs are valid. (See the relevant Product Specification for details)" [1]
  • When we transition to power optimization and start experimenting with different energy modes (EM1 and up), we will likely need to employ the use of the Peripheral Reflex System (PRS) that

See Also

Bibliography
1. Kionix; Getting Started [with the KX134-1211]; https://d10bqar0tuhard.cloudfront.net/en/document/AN101-Getting-Started.pdf
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License