External Interrupt

How do I external interrupt an ATmega 328p-AU to wake up from sleep (using any sensors like ADXL345)?

Im using 328p standalone IC running at 3.7V using battery.I tried but its not waking from sleep...Im using I2C connection (ADXL) but not getting the wakeup.

Can we see your code and schematics?

I DuckDucked "How do I external interrupt an ATmega 328p-AU to wake up from sleep" and found this:

If you wanted to know how to do this on the raw MCU, using some language other than Arduino Sketch, perhaps enquirer on an Atmega forum, like AVR Freaks.

AVRFREAKS

AttachInterupt()

I tried but its not waking from sleep...Im using I2C connection (ADXL) but not getting the wakeup.

What did you try?

How do I external interrupt an ATmega 328p-AU to wake up from sleep (using any sensors like ADXL345)?

What conditions do you want to have happened to wake it up?

As the I2C dosn't work in sleep mode you can't read your sensor. I think the only hope would be to use the chip's interrupt pin when you tap or double tap the sensor. See the chip's data sheet for how that works.

As the I2C dosn't work in sleep mode you can't read your sensor. I think the only hope would be to use the chip's interrupt pin when you tap or double tap the sensor. See the chip's data sheet for how that works.

Yeah, no kidding. It's kind of hard for an I2C device to wake up the processor that is running it.
That's a Catch-22 if ever I heard of one...

raschemmel:
Yeah, no kidding. It's kind of hard for an I2C device to wake up the processor that is running it.
That's a Catch-22 if ever I heard of one...

Reading the datasheets for the ADXL345 (and MCP23017) I get that once the interrupt behavior is set up the device then handles its own interrupts and signals the processor through a dedicated line when one arrives. So, as long as the I/O device has interrupts configured and remains powered it should be able to wake a sleeping AVR. Is this wrong?

Reading the datasheets for the ADXL345 (and MCP23017) I get that once the interrupt behavior is set up the device then handles its own interrupts and signals the processor through a dedicated line when one arrives. So, as long as the I/O device has interrupts configured and remains powered it should be able to wake a sleeping AVR. Is this wrong?

No, actually it looks like you are right about that. I didn't think the ADXL345 could continue taking measurements without the SCL clock., but it looks like it only needs it to talk to the cpu.

raschemmel:
Yeah, no kidding. It's kind of hard for an I2C device to wake up the processor that is running it.
That's a Catch-22 if ever I heard of one...

What about an Interrupt-on-change? Not sure if this can be done on an input that is dedicated, but offering just in case. Sometimes called a Change Notification [CN] (I bounce between PIC and Arduino -- and too lazy to look up right now :stuck_out_tongue: )

What about an Interrupt-on-change?

This does bring up a interesting point. The ADXL345 datasheet says that the default interupt signal is a high:

INTERRUPTS
The ADXL345 provides two output pins for driving interrupts: INT1 and INT2. Both interrupt pins are push-pull, low impedance pins with output specifications shown in Table 13. The default configuration of the interrupt pins is active high. This can be changed to active low by setting the INT_INVERT bit in the DATA_FORMAT (Address 0x31) register. All functions can be used simultaneously, with the only limiting feature being that some functions may need to share interrupt pins.

but the arduino interupt supports the following:

mode: defines when the interrupt should be triggered. Four constants are predefined as valid values:

LOW to trigger the interrupt whenever the pin is low,

CHANGE to trigger the interrupt whenever the pin changes value

RISING to trigger when the pin goes from low to high,

FALLING for when the pin goes from high to low.

(none of which are HIGH)