where is software quality heading to?

[tooki]

Why is digitalWrite so slow? Couldn't they have just used a bunch of #ifdef arguments for every single different platform?

In Arduino, the implementation is already separated away into a “core” for a given MCU family, which in turn is used by a board definition. So there’s no situation where, for example, the digitalWrite() functions for an ESP32 and an AVR MCU are actually defined in the same file.

Of course, you can use #ifdefs, etc. in user code or when making a library. But the Arduino framework itself already relies on implementation-specific packages that get selected when you choose your target board in the IDE.

[Nominal Animal]

It is impossible to have only a single underlying "set GPIO output pin state" implementation even among ARM Cortex-Ms, because there are at least two completely different ways to control GPIO output pins that I know of.

One is where you have separate registers to set, clear, and sometimes even toggle the output pin state.  There, the pin will determine the bit, but the register depends on the value (high, low, toggle) and often the pin number (because there are more logical pins on a typical MCU core than fits in a single register).

The other is where the register is split in half, with upper half being a mask of bits to be modified, and the lower half defines the state of the corresponding bits.

No API or HAL can abstract the differences away for me.  I can use the data-toggle and the split-register approach to construct a parallel bus using a small look-up table (as many entries as the bus has possible states), although the implementations are completely different; but with the former without a toggle register, I have to use shadow registers in RAM to determine the new state.  The split register approach requires full native word wide accesses, which limits its use via DMA.  Each approach has their strengths and weaknesses, and I for one exploit them to the full.

[SiliconWizard]

Pin numbers in the Arduino sense are abstracted themselves and do not correspond to anything physical. They are defined as indices of an array of items describing each "pin" with parameters that are target-dependent.
To define those pins for a particular MCU and project if you don't want to use defaults, you have to define "variant" files.

And of course, this way of defining pins makes it inadequate for very fast GPIO toggling.

You can come up with a reasonably optimized way of abstracting say GPIO handling for a given (and restricted) set of MCUs, but that'll still be ad-hoc abstraction. Once you'll add support for MCUs that have completely different features, your abstraction will break and you'll either have to redo it entirely to efficiently handle all of the now supported MCUs (which can be very time-consuming and error-prone, usually developers prefer not rewriting code that works perfectly fine), or you'll just add yet another layer of specific cases, which will add more overhead yet.

All "cross-platform" libraries have the same kind of limitations: they are made to address the lowest common denominator, they add layers of overhead, and can't address platform-specifics unless going through hoops and making your code non-portable, which in turn defeats the point of using cross-platform libraries. That's pretty much the delusion of cross-platform frameworks.

[elektryk]

Pin numbers in the Arduino sense are abstracted themselves and do not correspond to anything physical.

The same way of GPIO numbering you can see in ESP(32) IDF, however, in ESP it is consistent with the datasheet.

[paulca]

The idea behind digitalWrite would in a similar vien to the low level sockets API on a Linux machine.  There are many different kinds of sockets many different things on the other end, but the sockets code abstracts this, so that all you need to know is how the sockets API works and you can work with any socket.  That's one of thousands of abstractions in even GLibc.

The trade off is that to support a wide feature set, at compile time, or worse at runtime, abstractions have overhead.  "DO we do this or that?  Are we dealing with a thing or a duffer?  Is the target this or that?". 

In something like Linux it is mostly macro soup, up as far as "compile time" support switching.  Runtime is handled by more layers and cooperation on agreed interfaces (Similar to the UART, SPI, layer. etc.)

But as you go up the stack towards the UI the permatation sky-rocket.  Different browers, phones, accessibility.  Different languages, timezones, character sets.  Layer and layers of GUI utilities.  But also layers and layers of seperation for security and scalability.

Where "performance" limited code exists abstractions are removed.  However, to date increasing hardware size has been cheaper than the developer time to optiimise, not least because you need a good dev.

Oddly, this is one thing AI has been marked for.  "Flattening."  Where you give it a "human written" heavily isolated and abstracted software stack, broken up that way so that developers could understand it and "Flattening" out the abstractions when given a more narrow set of actual use cases.