Bonjour,
I have some code running on Arduino nano ESP32 and ESPP-32-WROOM DA.
Both use ISR and I want to add the attribut IRAM_ATTR to the ISR routine.
void IRAM_ATTR second_sharp()
{// routine d'interruption toute les secondes exactes
affiche_flag = true; // debloque l'affichage
pps_cnt = 0; }
When I do so, compilation ends with message
error: 'second_sharp' was not declared in this scope
Eroor accurs on both boards.
Board manager is at vaersion 2.017
What did I do wrong ?
Alternately does this attribut applies to all boards and if not, I suggest there is a list of boards where it applies.
Not a board issue, it's simply a macro that tells the compiler where to place the 'second_sharp' function in memory.
Show all the code and all the error log both posted in code tags.
I suspect, without looking too deeply, that you may be a victim of the automatic prototype generation "feature" which haunts Arduino users from time to time.
Is that source code in a .ino or .cpp file ?
Anyway, try moving the definition of second_sharp() above the function setup().
In C++ you need to declare stuff before you can use them.
if the function secondsharp is declared after being used (in the setup) then it's a programming mistake, the compiler does not know what you mean.
The IDE tries to be smart and will look at your code, find the functions and inject a declaration of the function at the beginning of the code for you so that all goes well. But the IDE is not always smart and here the IRAM_ATTR probably throws it off.
It's a good practice to learn not to depend on the IDE to fix your code for you through some magic and start coding by honouring the C++ rules. Your programmer's life will be much easier.
usually you would go like this, with the setup() and loop() at the end
#define timepulse D3 // 1 nterrupt every second
volatile int affiche_flag = 0;
volatile int pps_cnt = 0;
void IRAM_ATTR secondsharp() { // routine d'interruption toute les secondes exactes
affiche_flag = true; // debloque l'affichage
pps_cnt = 0;
}
void setup() {
attachInterrupt(timepulse, secondsharp, RISING);
}
void loop() {
if (affiche_flag) {
affiche_flag = false;
Serial.println("tick");
}
}
PS: note that pps_cnt was not volatile in your code, you probably need that and also critical sections when you use that value.
I regard this issue as one of the Arduino "sins of the past" with a similar ranking to :
Default suppression of compiler warning in the IDE
The header spacing on the Uno board making it impossible to use standard 0.1" prototype boards as shields.
. . .
But don't get me wrong. In general I'm very happy with the Arduino concept and that a relatively simple abstraction layer can cover a huge variety of different MCUs together with excellent support via, of course, this forum.
@J-M-L thanks for the advise. It reminds me in the late 60's the rigid structure of the Divions in Cobol! Z/OS assembler can have the declaratives anywhere provided that the address can be resolved.
You misunderstand the meaning of the label @6v6gt. The "type: imperfection" GitHub Issues label identifies items related to any defect whatsoever. The name was intentionally chosen to be applicable to any component of the project, at any severity on the spectrum from "missing comma in the readme" to "Skynet is waging war on humanity".
The label does not in any way indicate level of severity. We have a separate set of "criticality" labels for that purpose. "criticality" labels are assigned by a manager during the planning process, while "type" labels are assigned by a maintainer during triage.
OK. Thanks for replying. Yes indeed I did. I (erroneously) assumed that the term "imperfection" in this context was a diminutive to imply that it was an issue of little consequence and that the person raising it was effectively moaning about nothing. Maybe "reported defect" or similar would, in retrospect, have been a better choice of label but, anyway, that is not something I want to spend any time discussing.
I see, incidentally, that the issue has, in the meantime, been migrated to Arduino-CLI, re-titled and closed to non-collaborators. I added examples of different manifestations of this problem as I noticed them so that anyone attempting a fix would have access to a series of test cases, not to hammer the point that the feature is buggy. In the future, if I see such a case raised in this forum, I'll attempt to assist the OP but leave him/her to report the issue as he/she sees fit.
Well, kind of. First, macros are evaluated by the preprocessor, not the compiler. IRAM_ATTR is indeed a macro that the preprocessor evaluates to: __attribute__((section(".iram1" "." "13"))). This is a directive that I'd bet is acted upon by the linker, not the compiler.
The problem is that, just as the reporter of a bug tends to be biased towards thinking their bug is of high criticality, the developer who wrote the buggy code tends to be biased towards thinking it is of low criticality. Previously when the label was "type: bug", I ended up in a situation where developers would dispute my applying that label to the issue on semantics of the term "bug" (essentially the classic "it's not a bug, it's a feature" tactic). So when I had the opportunity to rework Arduino's issue labeling system I intentionally chose the term that would be minimally threatening to even the most fragile of developer egos.
As you yourself suggested:
Yes, I think the new title provides a better summary.
The maintainers of Arduino's repositories must carefully monitor all the issue and pull request threads. There are tens of thousands of issues across hundreds of repositories so we get a ton of notifications. For this reason, I lock any thread in which there is likely to be further replies (which often happens when an issue is linked to from the forum), and where further replies won't add anything of value to the issue. In this case, the problem is very clear already so the issue as it is now will be completely sufficient to allow the managers to triage, and the developers to work on.
Don’t you have a weighting system where the number of impacted projects and customers will take part into / influence the prioritization process?
Authorizing more input or a « me too » data collection does not hurt in my opinion. (Unless you of course reached top priority already and the team is busy solving for it).
I'm not a project manager, so I'm not really the person to answer that question, but yes.
I always add links in the GitHub issues to additional reports of a bug that I see here on the forum or elsewhere, and one of the reasons for doing that is to provide a metric of impact for the managers.
"Me too" comments absolutely do hurt because they waste the time of everyone who is monitoring the repository by generating a pointless notification. Making them in Arduino's issue tracker is a sure way to get me to lock an issue thread.
But everyone is very welcome to add a to an issue they find impactful as an indicator. You can do that using GitHub's "Reactions" feature (which is just a matter of clicking, like the equivalent features on any other platform):
Unfortunately reactions are disabled when the issue is locked.
Definitely. For example, if you look at @6v6gt's issue report, you'll see I did a survey for other reports of the same bug and added a list of links to all of them under an "Additional reports" section:
I am pretty diligent about adding additional links to these lists as I find other reports. Just by looking at the length of these lists, the managers can quickly get some sense of the impact.
Of course, the number of reports is not equal to the number of impacted users. A report may be the "tip of the iceberg", with many other impacted users not making a report because they took the time to search and found it had already been reported. But I think the ratio of reports to impacted users is probably pretty constant across issues, so the number of reports still serves as a useful metric of relative impact.
Ok, thanks, but I'd just like to point out that my additions to the original incident report were not "Me too" comments. These were different failure cases affecting the same feature, namely automatic prototype generatation. By the nature of this feature, it is prone to misbehaviour as it is exposed to different constructs which were not previously foreseen, the one in this thread being the lastest example. I don't see it linked in your list Generated function prototype injected before declaration of custom parameter type · Issue #2696 · arduino/arduino-cli · GitHub (but maybe I missed it) so I am wondering if it will be considered. Or maybe it should be in a separate incident but then it may be that there is a risk of it being dismissed as a duplicate.
In the case of the automatic prototype generation, most of the common failure cases have already been addressed and it will normally only be when someone is doing something exotic that errors will become manifest so normally only experienced users are caught. Perhaps the issue in this thread is an exception.
to an issue they find impactful as an indicator. You can do that using GitHub's "Reactions" feature (which is just a matter of clicking, like the equivalent features on any other platform):