There are two ways to handle events: interrupts (hardware triggered) and polling (software triggered). Interrupts are much more efficient but also more difficult to use. SocketIoClient uses polling.
The necessary part of polling is... polling. That is, many times per second, you (or your library) needs to check if anything interesting is happening.
Been bashing my head with this one. And have searched the internet for a solution And tried for hours to program a solution.
From my tests the problem seems to be the Register 0x30—INT_SOURCE is populated with triggers. But the INT pin is only triggered when the Register 0x30—INT_SOURCE is read.
This means that firstly the Arduino can't be woken from sleep ...
John Romkey provided you an excellent answer. I am adding this just to
provide another perspective, hopefully complementary.
Interrupts are meant to handle the most time-critical tasks. Those tasks
that cannot wait for the next loop() iteration, such as counting a
pulse from an encoder, or getting a byte out of the UART receive buffer.
If you delay them too ...
Interrupts happen all the time and code works just fine without locking them out. It doesn't matter if it's at the exact moment that a function is saving something - a properly written interrupt handler will save any necessary state so that whatever was interrupted can continue without problems. If it doesn't, the software will crash hard.
You should lock ...
You are confusing Pin Change Interrupt pins with Pin Change Interrupt vectors. The two are very different.
Many Pin Change Interrupt pins are associated with just one Pin Change Interrupt vector.
You use the pin number (the value shown in the pinout) to decide if you want that pin to respond or not. You use the vector to respond any of the pins that are ...
That is simply the difference between an external interrupt INTx and a pin change interrupt PCINT. The first is an interrupt for a single pin. The second is an interrupt for a complete group of pins. Normally this group is a complete port. As the Attiny85 only has one port, this is the case here. So the whole group is only 1 single interrupt source. Thus it ...
You can enable/disable Pin Change INTerrupts for individual pins using the Pin Change Mask Register PCMSK.
The names on the pins map the bit in PCMSK to the physical pin.
You find more information in section 9.3.4 on p. 52 in the ATtiny85 Data Sheet
Look at the datasheet of the ATtiny45. In the section “Sleep Modes”,
there is a table that lists the wake-up sources available for each sleep
mode. For the mode “power-down”, INT0 is listed as a possible wake-up
source, but there is a small footnote:
For INT0, only level interrupt.
This means that the CHANGE mode you are trying to use will not wake-up
If you drive the speaker pin from an interrupt, you will inevitably have
some jitter, as the interrupt request will sometimes fire while the CPU
is processing another ISR. This can lead to one of the levels being held
for longer than expected, which in turn leads to spurious frequencies in
the output. Note that these are not really harmonics (harmonics ...
Looks like my tone frequency was possibly just too high for the buzzer I was using, causing strange output.
Adjusting the clock divider fixed the issue. That is, I changed the following:
TCCR2B = _BV(CS20); // clk/1
TCCR2B = _BV(CS22) | _BV(CS20); // clk/128
and now I get reasonable-sounding tones.
Note that the clock divider you choose is ...
I tried the code on an Uno and as you say, it does sound odd.
By my calculations, the frequency is 40kHz (16MHz/(200 x 2)), which is above the threshold of hearing. The sound we are actually hearing is probably the 3rd or 5th harmonic, at a reduced intensity and perhaps subject to jitter.
I tried changing
TCCR2B = _BV(CS20); // clk/1
TCCR2B = _BV(...