tl;dr When running the code below, the macro for abs defined in wiring.h interferes with the use of std::abs().
I stumbled across an issue which leaves me baffled I must admit. I was working for the last 2 years on a project with stepper motors that make use of std functions and so far everything was fine. However, yesterday I decided to come up with a complete clean platformio environment and deleted the .platformio folder (stupid me). After re-installing the platformio-extension in VSCode I got plenty of compiler errors. It turned out that the #define abs in wiring.h is in conflict with std::abs() as it tries to replace abs with the macro, which does not make sense with regards to the std namespace. What I really don’t understand is, how is this now an issue and it has not been an issue before.
Unfortunately, I have no specifics about the platformio environment before the cleaning. The current (!) platformio dependencies and verbose build are shown below.
I understand that I could change all std::abs() to abs as a workaround but I really want to understand and solve the problem.
What am I missing here and why is there all of a sudden this issue?
I am very thankfull for any advice what could be going on.
Cheers,
Daniel
src/main.cpp
#include <Arduino.h>
void setup() {
// abs(-6); // macro from wiring.h
// std::abs(-6); // should work fine, but triggers compiler errors due to macro
// std::cos(0.1); // for testing that std functions work in general
}
void loop() {
}
Functions and macros defined in Arduino.h conflicting with standard functions are not uncommon, especially min, max, etc.
Judging from Releases · platformio/platform-teensy · GitHub, by deleting .platformio, you’ve enabled PlatformIO to download the current most recent version of the teensy platform (and with it Arduino core).
I already tried various platform versions. Starting from 4.18.0 down to 4.13.0. No version did resolve the issue regarding abs() and std::abs()
On another machine where I have the project code compiling (still successfully) I realised that it compiles differently even though platformio.ini is the exact same (different OS though).
Compiling the here mentioned code (on Win 11, e.g. with -nostdlib flag)
Compiling a slightely different code making use of std::abs() with the same platformio.ini as above, but no conflict (e.g with flag -lstdc++ machine is a mac).
This is not related to PIO. The new toolchain and/or the new Teensyduino (1.58 / 1.59beta) reveiled a lot of those issues for other build systems as well. It looks like the recent changes somehow changed the order of includes which hid those issues in older toolchains. Which libraries show the effect?
well, it is actually your TeensyStep-Library we are using. I just created a plain new and empty Teensy 3.6 project in platformio (VSCode) and added TeensyStep as a lib dependency (see below).
As soon as I #include <TeensyStep> and build the compiler throws tons of errors, first of which is ds = std::abs(targetPos - currentPos); in line 38 of LinStepAccelerator.h. Hovering over the function tells me, that the compiler is trying to insert the macro from wiring.h which is obviously not part of std. I assume all subsequent errors are due to wrong syntax of this one (except other potential usages of std).
Well that was very fast. Thank you. I used Release v2.3.3 · luni64/TeensyStep · GitHub as a normal project lib instead of adding the most recently published version via platformio lib_deps and it compiles fine.
I am going to mark your response as the solution to my problem even though I was expecting this to be a more general issue that would happen anywhere std ist used (for now). I also edited the title to make it a bit more related to the particular library.
Glad that it works now.
Of course this is a general issue. Since abs is #defined as a macro in wiring.h things like std::abs will not work after #including Arduino.h. I assume that some recent changes led to an inclusion of Arduino.h somewhere it wasn’t before. Anyway, pushing / undefining / popping the offending macros is probably the best solution to this issue.