interrupt mystery with sensebender micro
-
I used pins 3 and 4 for the interruptible input from sensors. What does D2 have to do with this in my case, if none of the code is using it for interrupts?
I brought d2 and d3 up because some sample codes for sensors mentioned that only those can be used for interrupts. But I assume now this is not the case for SB, thanks to the pic above.
-
The CHANGE interrupt can only be used on pin 2,3 of the Atmeta328
https://www.arduino.cc/en/Reference/AttachInterrupt
There are other ways of trigger wakeup on all pins, but they are not supported by the MySensors sleep function and requires out to keep track of which pin that was triggered manually.
-
+1 on what said @Hek ;)
there is Pin change Int for other pins but you'll need to use raw registers stuff. There exists a lib for this but not supported by MYS sleep. And it's more efficient for memory consumption to use only what you need :)
I will publish soon my multisensor sketch where I use D2/int0,D3/int1 and two others pinchange int but in case you will find everything you need for this here : : http://www.gammon.com.au/forum/?id=11497 -
The CHANGE interrupt can only be used on pin 2,3 of the Atmeta328
https://www.arduino.cc/en/Reference/AttachInterrupt
There are other ways of trigger wakeup on all pins, but they are not supported by the MySensors sleep function and requires out to keep track of which pin that was triggered manually.
-
Good news and bad news... I got change based interrupts to work by moving the motion to D2. That required cutting off the radio IRQ. Naturally I lost one radio there cutting too much....
So now it works initially. But after some rounds the serial text gets garbled, and it stops sending anything quite soon then.
isMetric: 1 TempDiff :127.31 HumDiff :151.00 T: 27.31 H: 51 TempDiff :0.01 HumDiff :0.00 Door :0 Motion:1 TempDiff :0.01 HumDiff :0.00 Door :0 Motion:0 TempDiff :0.07 HumDiff :0.00 Door :0 Motion:1 TempDiff :0.10 HumDiff :0.00 Door :0 Motion:0 x00�����x00�����x00�x00x00��x00��x00x00�x00x00�x00x00x00�x00x00x00x00�x00�x00x00x00x00��x00x00�x00x00x00���������```the last line contines for long. Any ideas what could cause it? Some trick I missed with interrupts?
Again, the fixed code is here, it's almost the original SB Micro sample:
https://github.com/ikke-t/sensebender/blob/master/SenseBender/SenseBender.ino -
Solved the scrambled test. I removed the interrupts, and made it loop faster. It always got screwed after five rounds, so it seemed to be due the clock speed change in the template:
#ifndef MY_OTA_FIRMWARE_FEATURE if ((measureCount == 5) && highfreq) { clock_prescale_set(clock_div_8); // Switch to 1Mhz for the reminder of the sketch, save power. highfreq = false; } #endifRemoving that takes it further. I suppose the sample code is missing something to fix the serial speed after prescaler change. I also wonder if the radio would require some reconfig after clock speed change?
-
But weird still. If I set the sleep time to 10 secs, without interrupts it works just fine. If interrupts are enabled, it stops always in less than ten rounds. So could it be the interrupts break the radio part somehow? E.g. if interrupt comes during transmit? Are interrupts safe in arduino, or should there be some lock set or disable interrupts for time of radio transmit?
-
But weird still. If I set the sleep time to 10 secs, without interrupts it works just fine. If interrupts are enabled, it stops always in less than ten rounds. So could it be the interrupts break the radio part somehow? E.g. if interrupt comes during transmit? Are interrupts safe in arduino, or should there be some lock set or disable interrupts for time of radio transmit?
-
@ikkeT Have a look at the other pin interrupt related post: https://forum.mysensors.org/topic/4999/solved-latest-git-snapshot-causes-freezes/38
I fixed an issue that might also bother you.
