next topic »

[Reply #30 on:]

In fact, I wish it had been accepted by the Arduino team sooner.

The issue wasn't with acceptance.  The idea was proposed and approved within days on the developer mailing list.  It just took that long for someone to propose a good solution in the proper channel.

Without it, code that needs pullups enabled, is having to step outside Arduino and do AVR register specific operations
which makes the code non portable to other processors.

There are plenty of things you can do that makes the code non-portable to other processors.  Pull-ups resistors is not the gatekeeper from portability.

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

digitalWrite(pin,HIGH); has always been supported. 

The real problem is it wasn't accepted as a solution to a real problem and implemented soon

Again, you are really off base.  There "real problem" was that the current solution wasn't suggested until after 1.0.  Instead of just spouting nonsense from a soapbox., read the mailing list.

for porting existing arduino code that runs on AVR to non AVR like ARM and PIC.

Because how often do we see that actually happen in practice?   [sarcasm]We can all think of the time we tried to port some code from one processor to the other, but lost months of development time because of how internal pull-ups were handled.[/sarcam]

The issue with emulating the AVR pullup enables in s/w is that it slows down the digital write code

How is turning on a resistor in hardware, emulating in software?

[Reply #31 on:]

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:

pinMode(pin#,INPUT);
digitalWrite(pin#,HIGH);

How was that "not supported by Arduino and therefore becomes a processor specific non portable operation that is outside the scope of Arduino." ?

Lefty

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.

--- bill

[Reply #32 on:]

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.

I think you are placing a higher burden on the arduino platform then the original arduino designers ever envisioned. The 'pin abstraction' idea was just something they 'borrowed' from the Wiring open source project and it's reason for being had nothing to do with allowing for future hardware independence, but rather to just make things easier for the intended original users of the arduino, artists and non technical creative types, so they would not have to deal with learning port.pin concept and just concentrate of the labeled input/output pins available on the shield connectors so they could get stuff blinking and moving in a quicker learning curve manner.

 The fact that later people found ways to modify and stretch the IDE to allow for more hardware independence is more a factor of specific individual's initiative and desire rather then an a original goal for the arduino platform. I would be pretty certain the 'arduino language' would have been designed quite differently from the start if hardware independence was a key specification to begin with. So like any software system where goals and functions keep being added as time goes on there are sure to be rather crude and crusty methods used to keep hanging on new features and functions that go well beyond anything envisioned in the original release.

 I suspect that for a truly hardware independent 'arduino like' IDE to emerge that it would have to be taken on by a new open source group not tasked with having to support past and current board products, shields, functions, and libraries.  Where they would then have the freedom to break legacy software stuff if that leads to the best solution to the overall goal. Laying future hardware independence onto the 'official arduino developer team' seems to be just asking for conflict of interests and lack of resource allocation problems. I suspect they will be struggling for some time just getting the Due support/functions/libraries to work as 'arduino like' as possible as it is.

So it just seems to me that your concepts and desires have good intentions but they would probably best be met via a new open source IDE project rather then expecting/coercing/shaming the arduino developers to do more then their mandate and function actually is?

Lefty  

[Reply #33 on:]

In fact, I wish it had been accepted by the Arduino team sooner.

The issue wasn't with acceptance.  The idea was proposed and approved within days on the developer mailing list.  It just took that long for someone to propose a good solution in the proper channel.

I remember it a bit differently. I remember there being quite a discussion about it and many opposed
to adding this capability.
INPUT_PULLUP existed in Teensy and even Paul was getting frustrated at the opposition to it.
What I don't remember is if that discussion was happening on the mailing list or in the issues list
but I do remember that the some of the Arduino team were participating in the discussion.

Without it, code that needs pullups enabled, is having to step outside Arduino and do AVR register specific operations
which makes the code non portable to other processors.

There are plenty of things you can do that makes the code non-portable to other processors.  Pull-ups resistors is not the gatekeeper from portability.

Yes, but this is a pretty basic function that was missing from the beginning.
The core code simply didn't provide a mechanism to turn on a pullup.

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

digitalWrite(pin,HIGH); has always been supported. 

But that is not a primitive to turn on a pullup.
As far as the AVR core code is concerned,digitalWrite(pin, HIGH); sets the output pin.
When combined with a pinMode(pin, INPUT); it has the side effect of enabling the pullup
because of the way the AVR registers work. But that is totally AVR specific and it is
not the Arduino core code that is actually turning on the pullup but rather the sketch.

BTW, when  INPUT_PULLUP was aded, INPUT now disables the pullup.
This is a behavioral change than can potentially break some existing code.

Bottom line is Arduino core code lacked a way to turn on pullup from the very beginning
and the kludge that was used was AVR specific and fixing it now, is coming with a price
of backward compatibility issues.

The real problem is it wasn't accepted as a solution to a real problem and implemented soon

Again, you are really off base.  There "real problem" was that the current solution wasn't suggested until after 1.0.  Instead of just spouting nonsense from a soapbox., read the mailing list.

I remember there was quite a discussion about it and quite a bit of opposition to it.
I can't remember if it was on the mailing list or in an issue but this discussion was quite some time
before 1.0

for porting existing arduino code that runs on AVR to non AVR like ARM and PIC.

Because how often do we see that actually happen in practice?   [sarcasm]We can all think of the time we tried to port some code from one processor to the other, but lost months of development time because of how internal pull-ups were handled.[/sarcam]

Well I guess I live in a different world.
I write always strive to write portable code. Even in embedded environments. I guess that is part of what happens
having been involved in embedded development for more than 30 years where commercial products need
to be migrated to new platforms.
I currently have Arduino library code that runs on AVR, ARM, and PIC so I'm very familiar with
with it takes to write portable code.

The issue with emulating the AVR pullup enables in s/w is that it slows down the digital write code

How is turning on a resistor in hardware, emulating in software?

Seriously?
I guess the entire point of having a need for an abstracted way to set a pullup is
still not understood.
The problem is that without an abstracted mechanism to set the pullup,
the sketch code has to use processor specific mechanisms.
On the AVR that means writing to the AVR port bits directly to do this
while it can be done using digitalWrite() it is still AVR specific.
Other non AVR processors don't work that way.
Remember it wasn't' the AVR core code that was turning on the pullup it
was the sketch.

So in the core code for the other processors, in order to maintain that AVR
specific pullup enable behavior, they will have to maintain state
information and look at the pin updates to detect that the user is using an AVR
specific register setting and then do the corresponding function for the other processor.
This takes code in the runtime path and slows things down quite a bit from what could be done if
this AVR emulation of pullup enables isn't supported.

--- bill

[Reply #34 on:]

Back on topic.
With the newer AVR core that supports INPUT_PULLUP the behavior of INPUT on AVR has changed.
INPUT use to just force the pin to input mode and it left the port register bit alone so if it was 1 it remained a one and
the pullup would be enabled.

I mention this because in the
the keypad library there is this sequence:

Code:

// Set pin to high impedance input. Effectively ends column pulse.
pin_write(columnPins[c],HIGH);
pin_mode(columnPins[c],INPUT);

This will not result in the same pin state in pre 1.0.1 vs 1.0.1 and beyond.
In pre 1.0.1 the pullup woud be enabled. With 1.0.1 and beyond the pullup
will be disabled.

In this code, I don't believe it will matter since at this point it is done
with the pin and so the pin just needs to be an input to allow the
other columns to be scanned.
The actual needed pullup is on the rows, and those are all still enabled.

I think for clarity it might be useful to remove the setting of the colum pin back to HIGH
before the change to input mode.

But the behavior change for INPUT is something to keep in mind.


--- bill