Return to Question

Background: I'm using the L3GD20H MEMS gyroscope with an Arduino through a library (Pololu L3G) that in turn relies on interrupt-driven I2C (Wire.h); I'd like to be able to handle each new reading from the sensor to update the calculated angle in the background using the data ready line (DRDY). Currently, I poll the STATUS register's ZYXDA bit (which is what the DRDY line outputs) as needed.

General question: With some digital output sensors (I2C, SPI, etc.), their datasheets and application notes describe using a separate (out-of-band) hardware line to interrupt the microcontroller and have it handle new sets of data. But on many microcontrollers, retrieving data (let alone clearing the flag raising the interrupt line) requires using the normally interrupt-driven I2C subsystem of a microcontroller. How is the sensor's interrupt line intended to be used if the microcontroller can't handle the interrupt from an ISR using an interrupt-driven I2C subsystem?

Possible workarounds:

1. Use nested interrupts (as @hauptmech mentioned): re-enable I2C interrupt inside of ISR. Isn't this approach discouraged?

2. Use non-interrupt-driven I2C (polling)--supposedly a dangerous approach inside of ISRs. The sensor library used depends on the interrupt-driven Wire library.

3. [Edit: professors' suggestion] Use a timer to interrupt set to the sample rate of the sensor (which is settable and constant, although we measure it to be e.g. 183.3Hz rather than 189.4Hz per the datasheet). Handling the I2C transaction still requires re-enabling interrupts, i.e. nested interrupts or performing I2C reads from the main program.

[Edit:] Here's a comment I found elsewhere on a similar issue that led me to believe that the hang encountered was from I2C reads failing inside an interrupt handler: https://www.sparkfun.com/tutorials/326#comment-4f4430c9ce395fc40d000000

…during the ISR (Interrupt Service Routine) I was trying to read the device to determine which bit changed. Bad idea, this chip uses the I2C communications which require interrupts, but interrupts are turned off during an ISR and everything goes kinda south.

Background: I'm using the L3GD20H MEMS gyroscope with an Arduino through a library (Pololu L3G) that in turn relies on interrupt-driven I2C (Wire.h); I'd like to be able to handle each new reading from the sensor to update the calculated angle in the background using the data ready line (DRDY). Currently, I poll the STATUS register's ZYXDA bit (which is what the DRDY line outputs) as needed.

General question: With some digital output sensors (I2C, SPI, etc.), their datasheets and application notes describe using a separate (out-of-band) hardware line to interrupt the microcontroller and have it handle new sets of data. But on many microcontrollers, retrieving data (let alone clearing the flag raising the interrupt line) requires using the normally interrupt-driven I2C subsystem of a microcontroller. How can new sensor data be retrieved from the ISR for the interrupt line when also using the I2C subsystem in an interrupt-driven manner?

Possible workarounds:

1. Use nested interrupts (as @hauptmech mentioned): re-enable I2C interrupt inside of ISR. Isn't this approach discouraged?

2. Use non-interrupt-driven I2C (polling)--supposedly a dangerous approach inside of ISRs. The sensor library used depends on the interrupt-driven Wire library.

3. [Edit: professors' suggestion] Use a timer to interrupt set to the sample rate of the sensor (which is settable and constant, although we measure it to be e.g. 183.3Hz rather than 189.4Hz per the datasheet). Handling the I2C transaction still requires re-enabling interrupts, i.e. nested interrupts or performing I2C reads from the main program.

[Edit:] Here's a comment I found elsewhere on a similar issue that led me to believe that the hang encountered was from I2C reads failing inside an interrupt handler: https://www.sparkfun.com/tutorials/326#comment-4f4430c9ce395fc40d000000

…during the ISR (Interrupt Service Routine) I was trying to read the device to determine which bit changed. Bad idea, this chip uses the I2C communications which require interrupts, but interrupts are turned off during an ISR and everything goes kinda south.

Background: I'm using the L3GD20H MEMS gyroscope with an Arduino through a library that in turn relies on interrupt-driven I2C (Wire.h); I'd like to be able to handle each new reading from the sensor to update the calculated angle in the background using the data ready line (DRDY). Currently, I poll the STATUS register's ZYXDA bit (which is what the DRDY line outputs) as needed.

General question: With some digital output sensors (I2C, SPI, etc.), their datasheets and application notes describe using a separate (out-of-band) hardware line to interrupt the microcontroller and have it handle new sets of data. But on many microcontrollers, retrieving data (let alone clearing the flag raising the interrupt line) requires using the normally interrupt-driven I2C subsystem of a microcontroller. How is the sensor's interrupt line intended to be used if the microcontroller can't handle the interrupt from an ISR using an interrupt-driven I2C subsystem?

Possible workarounds:

1. Mask the interrupt (if level-triggered), so that interrupts (and I2C subsystem) can be re-enabled without jumping back into the ISR, and then eventually unmask the interrupt.

2. Use non-interrupt-driven I2C (polling)--supposedly a dangerous approach inside of ISRs.

3. [Edit: professors' suggestion] Use a background timer to interrupt at approximately the interval that the sensor updates--as it is, the DRDY does not provide critical timing information, since the sample rate is settable and constant (although we measure it to be e.g. 183.3Hz rather than 189.4Hz per the datasheet). Handling the I2C transaction still requires re-enabling interrupts, i.e. temporary redirection of the program somehow.

[Edit:] Here's a comment I found elsewhere on a similar issue that led me to believe the hang encountered when attempting to use I2C reads inside an interrupt handler failed: https://www.sparkfun.com/tutorials/326#comment-4f4430c9ce395fc40d000000

…during the ISR (Interrupt Service Routine) I was trying to read the device to determine which bit changed. Bad idea, this chip uses the I2C communications which require interrupts, but interrupts are turned off during an ISR and everything goes kinda south.

Background: I'm using the L3GD20H MEMS gyroscope with an Arduino through a library (Pololu L3G) that in turn relies on interrupt-driven I2C (Wire.h); I'd like to be able to handle each new reading from the sensor to update the calculated angle in the background using the data ready line (DRDY). Currently, I poll the STATUS register's ZYXDA bit (which is what the DRDY line outputs) as needed.

General question: With some digital output sensors (I2C, SPI, etc.), their datasheets and application notes describe using a separate (out-of-band) hardware line to interrupt the microcontroller and have it handle new sets of data. But on many microcontrollers, retrieving data (let alone clearing the flag raising the interrupt line) requires using the normally interrupt-driven I2C subsystem of a microcontroller. How is the sensor's interrupt line intended to be used if the microcontroller can't handle the interrupt from an ISR using an interrupt-driven I2C subsystem?

Possible workarounds:

1. Use nested interrupts (as @hauptmech mentioned): re-enable I2C interrupt inside of ISR. Isn't this approach discouraged?

2. Use non-interrupt-driven I2C (polling)--supposedly a dangerous approach inside of ISRs. The sensor library used depends on the interrupt-driven Wire library.

3. [Edit: professors' suggestion] Use a timer to interrupt set to the sample rate of the sensor (which is settable and constant, although we measure it to be e.g. 183.3Hz rather than 189.4Hz per the datasheet). Handling the I2C transaction still requires re-enabling interrupts, i.e. nested interrupts or performing I2C reads from the main program.

[Edit:] Here's a comment I found elsewhere on a similar issue that led me to believe that the hang encountered was from I2C reads failing inside an interrupt handler: https://www.sparkfun.com/tutorials/326#comment-4f4430c9ce395fc40d000000

…during the ISR (Interrupt Service Routine) I was trying to read the device to determine which bit changed. Bad idea, this chip uses the I2C communications which require interrupts, but interrupts are turned off during an ISR and everything goes kinda south.

Background: I'm using the L3GD20H MEMS gyroscope with an Arduino through a library that in turn relies on interrupt-driven I2C (Wire.h); I'd like to be able to handle each new reading from the sensor to update the calculated angle in the background using the data ready line (DRDY).

General question: With some digital output sensors (I2C, SPI, etc.), their datasheets and application notes describe using a separate (out-of-band) hardware line to interrupt the microcontroller and have it handle new sets of data. But on many microcontrollers, retrieving data (let alone clearing the flag raising the interrupt line) requires using the normally interrupt-driven I2C subsystem of a microcontroller. How is the sensor's interrupt line intended to be used if the microcontroller can't handle the interrupt from an ISR using an interrupt-driven I2C subsystem?

Possible workarounds:

1. Mask the interrupt (if level-triggered), so that interrupts (and I2C subsystem) can be re-enabled without jumping back into the ISR, and then eventually unmask the interrupt.

2. Use non-interrupt-driven I2C (polling)--supposedly a dangerous approach inside of ISRs.

3. [Edit: professors' suggestion] Use a background timer to interrupt at approximately the interval that the sensor updates--as it is, the DRDY does not provide critical timing information, since the sample rate is settable and constant (although we measure it to be e.g. 183.3Hz rather than 189.4Hz per the datasheet). Handling the I2C transaction still requires re-enabling interrupts, i.e. temporary redirection of the program somehow.

[Edit:] Here's a comment I found elsewhere on a similar issue that led me to believe the hang encountered when attempting to use I2C reads inside an interrupt handler failed: https://www.sparkfun.com/tutorials/326#comment-4f4430c9ce395fc40d000000

…during the ISR (Interrupt Service Routine) I was trying to read the device to determine which bit changed. Bad idea, this chip uses the I2C communications which require interrupts, but interrupts are turned off during an ISR and everything goes kinda south.

Background: I'm using the L3GD20H MEMS gyroscope with an Arduino through a library that in turn relies on interrupt-driven I2C (Wire.h); I'd like to be able to handle each new reading from the sensor to update the calculated angle in the background using the data ready line (DRDY). Currently, I poll the STATUS register's ZYXDA bit (which is what the DRDY line outputs) as needed.

General question: With some digital output sensors (I2C, SPI, etc.), their datasheets and application notes describe using a separate (out-of-band) hardware line to interrupt the microcontroller and have it handle new sets of data. But on many microcontrollers, retrieving data (let alone clearing the flag raising the interrupt line) requires using the normally interrupt-driven I2C subsystem of a microcontroller. How is the sensor's interrupt line intended to be used if the microcontroller can't handle the interrupt from an ISR using an interrupt-driven I2C subsystem?

Possible workarounds:

1. Mask the interrupt (if level-triggered), so that interrupts (and I2C subsystem) can be re-enabled without jumping back into the ISR, and then eventually unmask the interrupt.

2. Use non-interrupt-driven I2C (polling)--supposedly a dangerous approach inside of ISRs.

3. [Edit: professors' suggestion] Use a background timer to interrupt at approximately the interval that the sensor updates--as it is, the DRDY does not provide critical timing information, since the sample rate is settable and constant (although we measure it to be e.g. 183.3Hz rather than 189.4Hz per the datasheet). Handling the I2C transaction still requires re-enabling interrupts, i.e. temporary redirection of the program somehow.

[Edit:] Here's a comment I found elsewhere on a similar issue that led me to believe the hang encountered when attempting to use I2C reads inside an interrupt handler failed: https://www.sparkfun.com/tutorials/326#comment-4f4430c9ce395fc40d000000

…during the ISR (Interrupt Service Routine) I was trying to read the device to determine which bit changed. Bad idea, this chip uses the I2C communications which require interrupts, but interrupts are turned off during an ISR and everything goes kinda south.