It always struck me as odd that the point of Arduino was to try to abstract the hardware away from the sketch
and yet turning on the pullup without something like INPUT_PULLUP is not supported by Arduino
and therefore becomes a processor specific non portable operation that is outside the
scope of Arduino.
Not sure why the Arduino team never saw it that way.
Prior to the INPUT_PULLUP change the method shown for arduino users to enable the internal pull-up resistor on a pin was with a two command sequence:
How was that "not supported by Arduino and therefore becomes a processor specific non portable operation that is outside the scope of Arduino." ?
You demonstrate the point perfectly.
There was no Arduino core function to create an input with the pullup enabled
so the users that needed it had to dink with the AVR register bits directly.
That sequence above is assuming that attempting to write a HIGH to a pin that is programmed
to be an input enables a pullup resistor.
While that sequence is using Arduino core functions to do it, digitalWrite() in this case, it
still doesn't change the fact that this operation is AVR specific so
in reality "Arduino", or arduino core code more specifically,
is not setting the pullup, the code sequence is setting
it by using an available Arduino core function to step outside Arduino
capabilities and talk to the AVR hardware register bits directly.
Not all micro-controllers work that way.
which is why I stated that input pullups pre 1.0.1 are:
"not supported by Arduino and therefore becomes a processor specific non portable operation that is outside the scope of Arduino"
Arduino is supposed to provide an abstraction for the hardware to ensure that
sketch code doesn't have to be aware of the internal specifics of the hardware.
In the case of enabling the pullup, the core code failed to provide a mechanism
to enable input pullups, because of this, the sketch code was on its own
for how to do this.
Since Arduino started out on AVRs , and on an AVR the pullups
can be enabled by writing a 1 to the PORT register bit when the DDR register bit is programmed
for input, the sketch could use the digitalWrite() sequence above to write to the
PORT register to enable the pullups.
Now that other processors are being used, it creates a nasty backward compatibility issue.
Other processors often don't work that way.
So now this mechanism that sketches have used because of the missing Arduino functionality
must be emulated in s/w by in order to provide backward capability on non AVR cores.
It means that instead of having a nice streamlined digitalWrite() that sets the output pins,
the core code will have to emulate the AVR PORT/DDR register behavior in s/w.
This requires maintaining state information for the pin mode, and then looking
at the pin mode and the data value on every digitalWrite() operation to try and detect
that pullups are being enable vs being able to just update the output state of the pin.
Whereas if there is a mechanism for the core code set the pullups
it wouldn't have to do this AVR register emulation on non AVR processors.
That is why I said:
"Not sure why the Arduino team never saw it that way."
I think the Arduino team was not all that great at looking forward and
considering the implications of using Arduino on non AVR processors.