Interrupt, Debug, Example updates

[nomakewan]

Corrects interrupt setter so that it does not try to set the STPOL bit and correctly sets the IEA bit for INT pin polarity, makes it so that the interrupt data rate will try to match the user-specified IMU data rate (up to 100 Hz) as this is what the current documentation states will happen, and corrects KXTJ3_DEBUG preprocessor directive so that it will obey the Serial port that was passed to it by the user in their sketch.

Also updates basic example sketch to remove interrupt handling (this is not a 'basic' function and did not work in the example sketch as-written), corrects the successful data read checks for reading each of the axes in loop(), and corrects as well as adds comments to the sketch.

Eventually the intention is to implement arbitrary user-configurable Wake-Up Output Data Rates as well as additional interrupt modes, but this PR will allow the current implementation to match its current documentation.

[pbdaran]

@nomakewan Please try to the test the library along with example code on actual hardware. I tried to test it. After printing "IMU initialised", there is no message getting printed. I didn't verify the code and hardware. If time permits, will try from my side.

[nomakewan]

That's very strange; the post-initialization code was untouched. After printing "IMU initialized." it should then immediately print "Who am I? 0x[addr]". "IMU initialized" shouldn't print unless the actual initialization process was successful, so the WhoAmI call should likewise be successful.

The rest of the example code changes were simply correcting bugs where if for some reason communication with the IMU failed, instead of printing nothing, it would print partial messages with stale data from memory.

I guess today's project will be reconfiguring the lab and running this code on hardware.

[nomakewan]

@pbdaran The problem has been resolved. It turned out to be an artifact of just "fixing" the old code grammar-wise instead of actually reading what it was doing. It was checking to see if IMU_SUCCESS was false for each loop rather than true. This has now been fixed, pushed, tested on real hardware, and confirmed working. Thank you!

[pbdaran]

I too tested the code on actual hardware and works fine. Thank you, @nomakewan!

[nomakewan]

I have converted this to a draft as I have discovered that my fixes for HIGH_RESOLUTION and KXTJ3_DEBUG are not taking effect as intended. It would appear that still if you define in the sketch context, the changes produced by those defines are not kept when the CPP context includes the header. They are considered two wholly separate contexts and as such even global variables are not retained between context switches.

I have confirmed that the underlying code does work by defining HIGH_RESOLUTION and KXTJ3_DEBUG in the CPP context; it produced all the expected output in the serial monitor. So the code itself works, it's just that you cannot access that code from the Sketch context.

As such, I will need to change these settings from being preprocessor definitions to being parameters passed to Begin(). I hope to be able to finish the rewrite and test on hardware later today.

[nomakewan]

Okay, I have updated the code so that now the High Resolution and Debug modes work.

begin() now has four parameters, with the last two having defaults so as not to break compatibility with existing code.

begin(sampleRate, accelRange, highRes, debugMode)

The last two are booleans that default to false. Due to the Adafruit Trinket M0 not using the HardwareSerial object (it emulates a serial port using the Serial_ object instead) it is not possible to pass a Serial port via the sketch. As such, the cpp file now contains a global define to allow the user to change which Serial port they want to use in case they do not want to use the default.

This update has been tested on real hardware and works both in a default state with no booleans (as with earlier Basic sketch), as well as with booleans set to any value. I have also added a debug printout for High Resolution mode so that if Debug mode is enabled, you can tell whether or not High Resolution mode has been set straight from the serial monitor.