Question: I'm about to look into ARM development. I'd like to get fairly low level (after maybe a few Hello Worlds in PlatformIO).
What would you suggest?
On build systems/environments/cicds...
All build platforms suck.
I was exposed to Makefiles after a period without seeing one. It wasn't a pleasant revival. I mean, when you are spending your days working with Makefiles you sort of get used to it, but on the surface is a syntax from when bytes were expensive and variables had single or double mnemonics! Operators and expressions are contracted into symbols with implicit and explicity intermixed in a big fragile tree of of usually script generated non-sense, thousands of C files compiled by "configure" which are ALL recusively generated from automake/conf m4, awk et. al 1960s script languages which ALL suffer from compaction to save memory/disk because it cost $100,000 a megabyte back them!
It doesn't matter what one you choose it will always have unpleasant side effects.
If you are learning, sure, go for a glitzy "black magic" IDE like Arduinno/PlatformIO. However, do also pause a take a trip down manually building it with an open build platform, like gcc. But start with a shell script! I swear when you are learning, by the time that shell script becomes untainable, your first dozen projects will be collecting dust anyway.
In day job I use Java + Eclipse + Maven and I get paid to fiddle with by build tools. In fact I'd say 90% of my job is either waiting on build tools or trying to figure out why they aren't working. Especially as those build tools the full CI/CD is shared and locked down with dozens of layers of security. Maven and Java in enterprise produce deployables sometimes in the multiple gigabytes, mostly code depenencies! My own project (last touched) had 450 dependencies and produces a 300Mb tar.gz. The actual application is a single class of about 200 lines and does very simply things. Recently they demanded we remove ALL vulnerable jars from all projects. Fine. But wait. They scanned the build environment manifest, NOT the deployable manifest. So if you had a dep with a vulnerable dep included, you override it and upgrade it. Test it works. Oh, but no... too late.. you accessed it. Your build is marked "Out of compliance" and your name appears beside it on a spreadsheet sent out to name and shame! So even if a build tool like a compiler pulls in an old version of, say, beanutils. It's over, build fails. Took me a WEEK! to fix that across 4 projects. Tedious, unnecessary, dogmatic, bureaucratic BS!
At home I've just come out of a session of "bare metal x86 programming". Where yes, I spent time with gcc, ld, make, including managing my memory segments and executable format. I still managed to get a "Hello World", full 64bit long mode, "OS", not much more than a bootloader, but a bit more.... using a shell script. It had like 10 lines in it. clean it up, compile/assemble/link make boot.bin run the qemu.