Interrupt Functions

[mrkaroshi]

Interrupt Codes:
ACC_NM - Accelerometer No Motion
ACC_SM - Accelerometer Slow Motion
ACC_AM - Accelerometer Any Motion
ACC_HIGH_G - Accelerometer High G
GYR_HIGH_RATE - Gyroscope High Rate
GYRO_AM - Gyroscope Any Motion

enableInterrupts() takes the type of interrupt code, such as ACC_NM (Accelerometer No Motion), and whether the developer wants the INT pin to trigger as two arguments.

enableInterruptAxes() takes the interrupt code, and the axes to allow to trigger it, as two arguments and enables them. Currently there is no 'disable' function but this is due.

setIntThreshold() takes the interrupt code and a threshold value, as well as a string to define the axis and sets the input to exceed in order to trigger an interrupt. Each type of threshold is different for each code, so there is a serial output comment to reflect when the developer has set an invalid value. This can be made unnecessary by adding the function usage case to the Wiki.

setIntDuration() take the interrupt code and a duration value, as as a string to define the axes (not implemented currently), and sets the duration for which the threshold must be exceeded in order to trigger.

checkInterruptStates() is a sanity check for all interrupt registers, allowing the developer to drop this into their code and check setup and runtime behaviours.

readIntStatus() is best used as the callback function for the interrupt service routine, reading the status code from the INT_STA register.

clearInt() clears and resets the interrupt so the pin will return to it's previous level.

printWithZeros() ensures the register values are printed with their leading zeros.

[microbuilder]

I would be interested in merging support for this in, but is there any chance the PR could be reformated as a single commit so that the code can be reviewed in one place before the merge? (Sorry for the very slow reply here as well).

[mrkaroshi]

Sorry I’m not really sure what you mean, PR? If the commits need tidying up a bit how would I achieve what you need to review them easier?

…

On 11 Jan 2018, at 14:18, Kevin Townsend ***@***.***> wrote: I would be interested in merging support for this in, but is there any chance the PR could be reformated as a single commit so that the code can be reviewed in one place before the merge? (Sorry for the very slow reply here as well). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#39 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGBwhdDfMewASVWfyNrMmgJ0fpk-pW7Kks5tJgojgaJpZM4MkCRS>.

[dhiltonp]

I think he wants you to squash your commits. https://forum.freecodecamp.org/t/how-to-squash-multiple-commits-into-one-with-git/13231 David

…

On Thu, Jan 11, 2018 at 8:48 AM, kA®0šhî ***@***.***> wrote: Sorry I’m not really sure what you mean, PR? If the commits need tidying up a bit how would I achieve what you need to review them easier? > On 11 Jan 2018, at 14:18, Kevin Townsend ***@***.***> wrote: > > I would be interested in merging support for this in, but is there any chance the PR could be reformated as a single commit so that the code can be reviewed in one place before the merge? (Sorry for the very slow reply here as well). > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub < #39 (comment)>, or mute the thread <https://github.com/notificati ons/unsubscribe-auth/AGBwhdDfMewASVWfyNrMmgJ0fpk-pW7Kks5tJgojgaJpZM4MkCRS >. > — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#39 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGyxCiLA-5tyKSk-MI2f8eBupZgXkVGks5tJi1DgaJpZM4MkCRS> .

[microbuilder]

It's OK, I can see all the changes in one place here so I'll review that: https://github.com/adafruit/Adafruit_BNO055/pull/39/files

[microbuilder]

Do you think it would be possible to add a simple example sketch to this pull request, demonstrating in a simple manner how the new interrupt API can be used? That would really help other people benefit from you work here.

[microbuilder]

Using an enum or a bit field (a uint8_t where x = 0b00000001, y = 0b00000010, z 0b00000100 or 1<<2, etc.) would probably be more natural for embedded systems, and less work for the MCU to manipulate???

[microbuilder]

I believe Wire.endTransmission() returns a byte which is normally uint8_t: https://www.arduino.cc/en/Reference/WireEndTransmission ... see Arduino.h for the typedef.

I'm hesistant to change the return type on this function though since it's already been published. Perhaps we can return 1 or 0 to stick to boollogic checking the state of status internally after calling Wire.endTransmission()?

[mrkaroshi]

@dhiltonp thanks for that, I'll use that as a best-practise in future.

@microbuilder I don't have the hardware available to give a 'golden' example, but I could work out something later today. The bit field makes way more sense to me, I didn't have much of a point of reference as to how a user would want those options formatted, that's a much better way of doing things IMO. How best should I make these alterations - Is it bad form to immediately push another master with small changes?

[microbuilder]

There are two possibilities for the updates:

If it's easier for you, you can just take the current master branch here (adafruit/Adafruit_BNO055), fork it again to your github account, make any changes you want, push them to your fork, then create a new PR and I can close this one without merging. It's been so long that maybe you don't have this branch anymore in your local git fork???? This will require you to redo the work in the original PR here though.

OR ... If you still have this code in your own personal fork, just make sure you are up to date with the master branch here, then make your small changes locally, and do a push to your repo and it will be added to this PR with your commit message automatically, and I can merge everything in.

I don't know what is easier for you, but either approach is fine.

Even a very simple example sketch would be good (just place it in the examples folder like the other ones), but I can merge without the example if you don't have time ... it would just be good documentation for other people.