Now, this is working perfectly when thePINtoUseForInterrupts is defined as PC13 and not at all when defined as PB15 (or the other way around, can’t check right now), meaning I’m not getting any interruption in this case even though it’s the exact same thing connected to the PIN (swapping it from PIN to PIN) and the exact same (very simple by the way) handler.
I’m unfortunately not able to perform the proper tests right now to make sure whether there is any potential hardware issue involved or not but to avoid losing time, I’d like to make sure in advance:
is there any restriction on the digital PIN to get interrupts working or can it work on any digital PIN?
is there any restriction (beyond performance) to the number of parallel interrupts that can be set with attachInterrupt() or could there theoretically be an interrupt for each digital pin of the device ?
If the answer is positive to both questions, I guess I really have an hardware issue of some sort and will take the time to investigate more in details any potential hardware issue before eventually coming back here to report.
Things are very strange, and, from my point of view at least, very bad.
So, the behavior is like this:
when I’m trying to set the interrupt PIN as PB15 or PB7 (at least these 2, haven’t made too many tests on other PINs), at the moment when I’m doing the “attachInterrupt”, the program simply hangs, and it’s not even possible to update the firmware in the easy way. That happens whatever is connected to these PINs
with the same things connected, PB6 and PC13 are working properly BUT they sometimes (very rarely) also seem to hang (just when doing the attachInterrupt)
with other things connected, PA11 and PA12 are working properly for interrupt also without ever creating the slightest issue
this is tested with multiple chips, all on the latest firmware, all with RUI3 4.1.0 on Arduino.
all the PINs are working well as e.g. digital output PINs
So, I’m asking again: what are the conditions for using interrupts? It is all but clear what is a legitimate way of using interrupts and I can’t make my whole application at risk because attachInterrupt would randomly hang the program. I have seen nothing explained on the topic in terms of restrictions, neither on the website doc, nor on the forum.
Sorry, I can’t share all the details. But here is what I can tell you after further testing:
I’m sending at the same time 2 square signals of different freqs for 100ms towards 2 different PINs and asking them to detect the LOW state with interruptions (while sleeping the rest of the time). Please note that from some (not extensive) testing, the problem is the same with FALLING and RISING
the square singals, while of different frequencies are both between 0 and VCC and are kind of symmetric (I mean spending roughly the same time in 0 and VCC) but they’re not perfect / clean. The frequencies range from almost 0 to about 10kHz
the 100ms is controlled by a timer (which, by the way is badly explained in the doc but is NOT a real interrupt because it won’t behave like a real interrupt as it won’t interrupt a function -like delay() for instance- in the middle but will wait until it’s finished)
the timer, which is one shot, is NOT initialized within an noInterrupt() section, neither are the attachInterrupt functions
there are other interrupts active at the same time (PA11 and PA12 in particular) but they are not receiving “much traffic” and not square signals (more like Diracs)
in the main loop there is only sleep all () as per the low power example you provided. All is managed through timer as per the example with “opportunistic” sleeping whenever possible.
at each timer cycle, the attachInterrupt and detachInterrupt happen. Depending on testing, there can be between 1 and 10k cycles in a raw. Usually when it hangs, it hangs immediately (on the first cycle and call of attachInterrupt) but sometimes after many cycles. When it doesn’t detect anything (see later) it doesn’t detect ANYTHING, ever.
Now for the results (that are simply catastrophic to me):
at this stage PA9 seems to be the only PIN working perfectly: not hanging the program when calling “attachInterrupt()” on it AND actually detecting interrupts when setup
with the exact same code (just changing the declaration of the PIN and resoldering), PB10,PB11, PB6, PB7 are hanging most of the time when doing the attachInterrupt(). PC5,PC6 and PC13 are not hanging when raising attachInterrupt() BUT are then not detecting ANYTHING
this is all tested on 2 chips (3272-SiP)
I secretly hope that for the cases where it doesn’t detect anything, it’s just a matter of the PINs not being labeled properly in the data sheet but unfortunately that’s not too realistic (even though we initially had such cases due to the mess in the overview doc - cf the other thread- but we quickly found out).
I shall manage to do more testing today and will try and report back for news. Please investigate ASAP as it’s a real pain not to be able to use interrupt in a flexible way.
I’m telling you, there are different types of frequencies. From testing, it can handle easily up to 10kHz in terms of measurements, probably not much more than 20kHz though.
Anyway, here is my final assessment of the situation:
when dealing with interruptions, everything hangs when the PINs get a signal above 10kHz. That’s for the PIN who can actually handle interruptions…
most (if not all, didn’t test everything) of the PC PINs are just not able to handle interruptions. So you can send them whatever frequency you want, they won’t hang as they’re just not detecting anything
The second issue, as long as it would be clarified in the documentation wouldn’t be much of a big problem. The first one certainly is as it can affect the stability of the whole setup.
I don’t think much of it is difficult to reproduce:
checking whether PC PINs accept interruptions is straightforward
checking whether, from a certain freq, a square signal (or any other) overloads the PINs waiting for interruptions and crashes the device shouldn’t be that much of an endeavor either
If you guys at RARWireless don’t do it, can anyone else test it and report back whether they have the same findings ? It will probably not allow for as deep explanations as if RAKWireless would do the full work of analyzing AND explaining what’s going on but it would probably help characterize the issue.
but unfortunately that’s not too realistic (even though we initially had such cases due to the mess in the overview doc - cf the other thread- but we quickly found out).