FWIW, it's C++, not C. Not necessarily an improvement, but you can use the String class... if performance and memory isn't a factor :-)
It took me a while to understand the arduino build system. It's... complicated. And, being a cross-compiler, messy. The IDE hides a lot of messy details. Being a CLI user, myself, I tried to work out how to put all this into a Makefile. Needless to say, the result was fragile.
Nowadays there's an arduino-cli command that makes it easier, but even this isn't consistent between versions. I've had to update my Makefiles far too often as there are "breaking changes" between versions.
The big "requirement" is that if your code is in a directory "foo" then the main sketch needs to be "foo.ino" for things to be found automatically. (Note that $SRC isn't used in the command line, just to build the dependency list).
And working out the value for BOARD is where things get complicated.
Different boards may have different architectures; the cross compiler is in the platform directory. eg $HOME/.arduino15/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino7/bin/
If you want to compile for the esp8266 then you get $HOME/.arduino15/packages/esp8266/tools/xtensa-lx106-elf-gcc/3.1.0-gcc10.3-e5f9fec/bin/
and so on.
Yes, this is implicitly downloading a cross compiler from a third party site and running it on your machine. And support tools (eg python scripts). If you look at the json file you needed to point to for the IDE then you'll see references to the binaries it downloads to the %HOME/.arduino15/packages area.
Yes, this is curl|bash on steroids (binary files)... but at least it's not sudo bash :-)
Within each platform there can be variances; in particular pinouts, but other stuff. So inside $HOME/.arduino15/packages//hardware you'll see the core libraries for that platform plus the "variants/". This is what is picked by the "board" in the IDE (and what the --fqbn option in arduino-cli picks.)
Even more complicated is that you can change the memory map and the crystal speeds and more; these are all handled in a similar manner, as options to --fqbn
These options are defined in the "boards.txt" file hidden inside the packages platform directory (which the IDE parses to provide the relevant menu options)
Conclusion: The arduino ecosystem has a high barrier to entry, but not insurmountable. It's not really meant to be production stable because it's for hobbyists to learn and experiment. Heck, the whole ESP32/8266 setup is kinda an emulation layer on top of the espressif core; a bunch of compatibility libraries to make it _look_ like an arduino when it really isn't.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
(no subject)
Date: 2023-10-23 02:21 am (UTC)It took me a while to understand the arduino build system. It's... complicated. And, being a cross-compiler, messy. The IDE hides a lot of messy details. Being a CLI user, myself, I tried to work out how to put all this into a Makefile. Needless to say, the result was fragile.
Nowadays there's an arduino-cli command that makes it easier, but even this isn't consistent between versions. I've had to update my Makefiles far too often as there are "breaking changes" between versions.
But this sort of thing seems to work
BOARD=esp8266:esp8266:nodemcuv2 SRC = $(wildcard *.ino) PROJECT = $(notdir $(CURDIR)) TARGET = $(PROJECT).ino.bin $(TARGET): $(SRC) @rm -rf tmp @mkdir -p tmp @TMPDIR=$(PWD)/tmp arduino-cli compile --fqbn=$(BOARD) --output-dir=$(PWD) @rm -rf tmpThe big "requirement" is that if your code is in a directory "foo" then the main sketch needs to be "foo.ino" for things to be found automatically. (Note that $SRC isn't used in the command line, just to build the dependency list).
And working out the value for BOARD is where things get complicated.
Different boards may have different architectures; the cross compiler is in the platform directory. eg $HOME/.arduino15/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino7/bin/
If you want to compile for the esp8266 then you get $HOME/.arduino15/packages/esp8266/tools/xtensa-lx106-elf-gcc/3.1.0-gcc10.3-e5f9fec/bin/
and so on.
Yes, this is implicitly downloading a cross compiler from a third party site and running it on your machine. And support tools (eg python scripts). If you look at the json file you needed to point to for the IDE then you'll see references to the binaries it downloads to the %HOME/.arduino15/packages area.
Yes, this is curl|bash on steroids (binary files)... but at least it's not sudo bash :-)
Within each platform there can be variances; in particular pinouts, but other stuff. So inside $HOME/.arduino15/packages//hardware you'll see the core libraries for that platform plus the "variants/". This is what is picked by the "board" in the IDE (and what the --fqbn option in arduino-cli picks.)
Even more complicated is that you can change the memory map and the crystal speeds and more; these are all handled in a similar manner, as options to --fqbn
BOARD=esp8266:esp8266:nodemcuv2 XTAL=:xtal=160 EESZ=,eesz=4M1M ... TMPDIR=$(PWD)/tmp arduino-cli compile --fqbn=$(BOARD)$(XTAL)$(EESZ) --output-dir=$(PWD)These options are defined in the "boards.txt" file hidden inside the packages platform directory (which the IDE parses to provide the relevant menu options)
Conclusion: The arduino ecosystem has a high barrier to entry, but not insurmountable. It's not really meant to be production stable because it's for hobbyists to learn and experiment. Heck, the whole ESP32/8266 setup is kinda an emulation layer on top of the espressif core; a bunch of compatibility libraries to make it _look_ like an arduino when it really isn't.
TinyGo is another system that supports many of these microcontrollers, but it seems they don't support the WiFi chip on the ESP32/8266, which are my primary platforms these days (home-grown IoT). So I'm stuck with C(++) code for now (eg https://www.sweharris.org/post/2023-06-13-digital_safe_3/ with https://github.com/sweharris/esp8266-timer-safe as the source)