Determining the board type being used, revisited

This is my first bark here, although I've been lurking for quite some while. Please don't kick me too hard if I'm asking or suggesting the obvious :slight_smile:

I'm currently evaluating a number of "Arduino-like" boards, one of the factors under consideration being how accurate the free-running clock is (i.e. mSec drift per hour, sometimes called regulation). In order to put sensible messages at the start of each run I started investigating how to extract the name of the board at compilation time, but could find nothing more useful than Roger and Nick's exchange at Determining which board type is being used? - Programming Questions - Arduino Forum

I know that other people have looked at this in the past, but generally speaking their solution rapidly starts suffering from "bitrot" and there is a risk that it consumes scarce memory space unless very carefully implemented.

I started looking at the overall toolchain, as used both by both the Arduino IDE and alternatives such as the Eclipse CDT. Having determined that there was useful information in the boards.txt etc. files I decided that it was probably viable to parse them using e.g. Perl, but in order to do that I had to use the correct compiler's preprocessor to handle the pinouts file, and eventually decided that the only possible way to handle the job (semi-)automatically was to start off with the platform.txt files.

Then I realised that by adding this to each of the platform.txt files I had a couple of invariant defines which could be expanded in an Arduino program with minimal overhead:

# These can be overridden in platform.local.txt. Be careful to not lose any
# platform-specific options already in the platform.txt file.

compiler.c.extra_flags=-DARDUINO_BOARD_NAME={build.board} "-DARDUINO_BOARD_TEXT={name}"
compiler.c.elf.extra_flags=-DARDUINO_BOARD_NAME={build.board} "-DARDUINO_BOARD_TEXT={name}"
compiler.S.extra_flags=
compiler.cpp.extra_flags=-DARDUINO_BOARD_NAME={build.board} "-DARDUINO_BOARD_TEXT={name}"
compiler.ar.extra_flags=
compiler.objcopy.eep.extra_flags=
compiler.elf2hex.extra_flags=

hence in the .ino or .cpp source file e.g.

  Serial.print("Board: ");
#define STRINGIZE_HELPER(x) #x
#define STRINGIZE(x) STRINGIZE_HELPER(x)
  Serial.print(STRINGIZE(ARDUINO_BOARD_NAME));
  Serial.print(" (");
  Serial.print(STRINGIZE(ARDUINO_BOARD_TEXT));
  Serial.print(") ");
  Serial.print(F_CPU / 1000000.0, 2);
  Serial.println(" MHz");

which results in output like

Board: AVR_UNO (Arduino/Genuino Uno) 16.00 MHz

This should, obviously, go into a platform.local.txt file but the impression I get is that they are the very least poorly documented and I suspect that Eclipse doesn't support them at all.

As I think I've already said, my apologies if I'm stating the obvious and wasting everybody's bandwidth. But at the very least this is something that appears to work efficiently for me.

MarkMLl

MarkMLl:
Please don't kick me too hard if I'm asking

It's not clear to me what you're asking. From reading your post, it seems like you found a solution to something you wanted to accomplish, and shared your findings here, which is great. But if you do have a question, I'd like to understand what it is so that I (and the rest of the forum crew) can try to answer it.

It's more an observation about something that works (at least for me) than anything else. However I notice that it's something that other people have raised in the past, so hopefully it will help somebody in the future.

From a bit more tinkering I'm pretty sure that the Eclipse CDT stuff doesn't support a platform.local.txt file, which I'll discuss with the developer elsewhere.

If I do have a question it's about where the platform.local.txt file should be put. My understanding from the documentation is that it /should/ be in the same directory as the active platform.txt file, but I've seen suggestions that sometimes the situation is a bit more nuanced than that.

As I understand it, there is no provision for a platform.local.txt to be in a user's home directory, or in a project/sketch directory.

Would you say that's an accurate summing up?

MarkMLl

MarkMLl:
It's more an observation about something that works (at least for me) than anything else. However I notice that it's something that other people have raised in the past, so hopefully it will help somebody in the future.

Thanks for sharing the knowledge!

MarkMLl:
From a bit more tinkering I'm pretty sure that the Eclipse CDT stuff doesn't support a platform.local.txt file, which I'll discuss with the developer elsewhere.

That's unfortunate if they don't support it. Ideally, the 3rd party alternatives to the Arduino IDE would mirror its functionality as much as possible. Arduino has been working on a project to make this easier and more efficient. They are moving all the functionality of the Arduino IDE into a separate tool named arduino-cli, so that the remaining Java code of the Arduino IDE code is only for the GUI. This means that all of Arduino's IDEs (Arduino IDE, Arduino Web Editor, Arduino Pro IDE), as well as the 3rd party alternatives can all share this tool, rather than having to reinvent the wheel or have a dependency on the Arduino IDE (which has a less powerful CLI interface and also is unnecessarily big for that purpose due to the GUI code). arduino-cli does correctly use platform.local.txt, so if 3rd party projects use arduino-cli, then they get platform.local.txt support automatically.

Thanks for reporting it to the Eclipse plugin developer.

MarkMLl:
If I do have a question it's about where the platform.local.txt file should be put. My understanding from the documentation is that it /should/ be in the same directory as the active platform.txt file, but I've seen suggestions that sometimes the situation is a bit more nuanced than that.

That's correct. Keep in mind that each hardware package has its own platform.txt. So there is one for Arduino SAMD Boards, and a different one for the Arduino ESP8266 core. If you don't know how to find it, let me know and I'll provide instructions. The other tricky thing is that in the case of Arduino AVR Boards, you might have two copies of that hardware package on your computer, but only one is active. The reason for this is that the Arduino IDE comes with a copy of Arduino AVR Boards (to make it easy for beginners to get started with the classic AVR boards without needing to go through an extra installation step), but you can also install updates to Arduino AVR Board via Boards Manager. When you install the Arduino AVR Boards update, it's saved to a different location on your computer than the version that was bundled with the Arduino IDE. The version installed via Boards Manager is then used and so the platform.txt in the Arduino IDE installation folder is no longer in use (and neither will platform.local.txt be if you put one there).

MarkMLl:
As I understand it, there is no provision for a platform.local.txt to be in a user's home directory, or in a project/sketch directory.

There's no way to put the platform.local.txt file anywhere other than the same folder as the platform.txt file. However, you do have some control over where the hardware packages are installed, which would allow you to save it to a subfolder of either of those locations with a bit of effort:

In the normal state, the Arduino IDE will only install hardware packages installed via Boards Manager to a fixed location, however, if you run the Arduino IDE in portable mode, then it will install the hardware packages to a subfolder of the portable folder you created. With Windows (not the Microsoft Store version of the IDE) or Linux, you can install the Arduino IDE anywhere you like, and thus have some control over the location of that portable folder. It's either difficult or impossible to run the IDE in portable mode on macOS. More information on portable mode:
https://www.arduino.cc/en/Guide/PortableIDE

Hardware packages can also be manually installed to the hardware subfolder of the sketchbook folder. You can set the sketchbook folder to any location you like in the Arduino IDE at File > Preferences > Sketchbook location.

Thanks for the extra detail. In general I don't think that finding the platform.txt files below a certain installation root and creating installation-local files is going to be an issue.

Slightly more worrying are some comments I've seen in the past (which I naturally can't find any more) about platform.local.txt having to go into something like the 1.5 subtree even if the current IDE was 1.8.9 since the file formats etc. were locked down by the 1.5 release.

In any event, at least it's easy to check that the definitions in the platform.local.txt file have stuck by inspecting the generated command lines.

MarkMLl

They were probably talking about the Arduino15 or .arduino15 (depending on OS) folder. That means "Arduino IDE 1.5.x and up", rather than "Arduino IDE 1.5.0 specifically", so nothing to worry about.

Some years ago, Arduino made major changes to the way the Arduino IDE worked and bumped the version from 1.0.x to 1.5.x at that time. So now the new systems put in place are generally referred to as "1.5" (e.g., the 1.5 Arduino library format). Really, it should have been a bump to 2.x.x, but I've notice that developers in general seem to have an irrational phobia of major version bumps, even when they are faithful about following the semver specification when it comes to the minor and patch version.

pert:
Thanks for reporting it to the Eclipse plugin developer.

Upstreamed as 558309 – Feature request: support for Arduino platform.local.txt file

MarkMLl

As an update: the Eclipse CDT maintainers have marked the issues (not using platform.local.txt etc.) as WONTFIX and closed them, with the comment

"The Arduino component is no longer maintained and will be
removed from CDT 10 (Bug 562498). The final Eclipse CDT version that will
include Arduino support is the CDT 9.11 series.

"Please consider using The Arduino Eclipse IDE and plug-ins named Sloeber
(https://marketplace.eclipse.org/node/2637354) for your future Eclipse CDT
powered Arduino development."

I've not investigated to see whether that has fewer bugs yet.

MarkMLl

MarkMLl:
As an update: the Eclipse CDT maintainers have marked the issues (not using platform.local.txt etc.) as WONTFIX and closed them, with the comment

"The Arduino component is no longer maintained and will be
removed from CDT 10 (Bug 562498). The final Eclipse CDT version that will
include Arduino support is the CDT 9.11 series.

"Please consider using The Arduino Eclipse IDE and plug-ins named Sloeber
(https://marketplace.eclipse.org/node/2637354) for your future Eclipse CDT
powered Arduino development."

I've not investigated to see whether that has fewer bugs yet.

MarkMLl

I would guess it has different bugs. I use Sloeber 3 years now. It doesn't support platform.local.txt. And it has a major flaw in not using .a linkage for libraries which require it. it leads to strange problems with some of these libraries. (I declared that I fix it, but can't find free time to do it)

Juraj:
I would guess it has different bugs. I use Sloeber 3 years now. It doesn't support platform.local.txt. And it has a major flaw in not using .a linkage for libraries which require it. it leads to strange problems with some of these libraries. (I declared that I fix it, but can't find free time to do it)

Thanks for that. I'll try to find time to take a look at it- if nothing else so that I can re-raise that bug.

All in all I wasn't all that impressed by Eclipse: it tries to be "all things to all men", with too many functions which superficially looked the same etc.

MarkMLl

MarkMLl:
Thanks for that. I'll try to find time to take a look at it- if nothing else so that I can re-raise that bug.

All in all I wasn't all that impressed by Eclipse: it tries to be "all things to all men", with too many functions which superficially looked the same etc.

MarkMLl

As a professional software developer I use Eclipse for Java 15 years :-). So it is a tool I am use to.

Juraj:
As a professional software developer I use Eclipse for Java 15 years :-). So it is a tool I am use to.

There is that. But comparing "mega tools" like Eclipse with even 1980s DOS editors (MultiEdit, anybody?) and IDEs... OK, so I guess that a lot of extra project management stuff has been added but I can't help but feel that the developers have lost sight of what everybody needs.

I notice that Sloeber claims to be better focussed, so it will be interesting to see what it looks like. Not today and probably not tomorrow...

MarkMLl