SOLVED: Getting Error:- 'INPUT_PULLUP' was not declared in this scope

"The only difference" is the line that turns on the internal pull-up.

I'm not using INPUT_PULLUP myself at all.

In that case, define it as "INPUT".

tack:

PaulS:

TBH, do I need to do anything unless I actually add code, or use libraries that make use of the INPUT_PULLUP option.

No, you don’t. I thought you were doing this because you did need INPUT_PULLUP supported.

No, it was because the sketch that used keypad.h wouldn’t compile when I changed my board from Uno to 1284P.

The library itself was looking at Arduino version and expecting define of INPUT_PULLUP for IDE versions over 1.0.

I’m not using INPUT_PULLUP myself at all.

lefty, I might just try what you did and copy the cores across for my 1284P and 644P entries. I’ll back up what I have first.

I wasn’t brave enough to copy the complete core files, just the two I mentioned as I think that is the only two files that are involved with the INPUT_PULLUP addition.

LEfty

tack: No, it was because the sketch that used keypad.h wouldn't compile when I changed my board from Uno to 1284P.

The library itself was looking at Arduino version and expecting define of INPUT_PULLUP for IDE versions over 1.0.

I'm not using INPUT_PULLUP myself at all.

lefty, I might just try what you did and copy the cores across for my 1284P and 644P entries. I'll back up what I have first.

I thought INPUT_PULLUP == 0x02, not 0x20????

dhenry:
It masks the problem, not solving the problem.

Actually, it should be a resonable fix in the case of the keypad library. The offending lines in Keypad.cpp are:

// When sharing row pins with other hardware they may need to be re-intialized.
for (byte r=0; r<sizeKpd.rows; r++) {
	pin_mode(rowPins[r],INPUT_PULLUP);
	pin_write(rowPins[r],HIGH);	// Enable internal pullup resistors for Arduino<101
}

I did this to maintain some sort of backwards compatibility but my error was in deciding to test for Arduino versions instead of the existence of INPUT_PULLUP.

// See http://code.google.com/p/arduino/issues/detail?id=246
#if defined(ARDUINO) && ARDUINO < 101
#define INPUT_PULLUP INPUT
#endif

Becomes…

// See http://code.google.com/p/arduino/issues/detail?id=246
#if !defined INPUT_PULLUP
#define INPUT_PULLUP INPUT
#endif

My suggestion would be to not depend on it and fix the code not to depend on using INPUT_PULLUP or even use it all since it is only available on such a recent Arduino release and then only if the core supports it. There are many other cores, libraries, and IDEs for other processors (maple, chipkit) that may not have this recent addition. Also many linux environments, Debian Squeeze, Ubuntu 12.04, Linux Mint 13/14 all have Arduino 1.0 in their repositories, so they will not have this support if using the Arduino IDE in the repository.

Assuming you are using this code: http://arduino.cc/playground/uploads/Code/keypad.zip It looks like it already checks for the arduino revision and maps INPUT_PULLUP to INPUT on older arduino versions. However, the problem with that is that while the Arduino IDE version may be 103 not all the cores being used have all the support in 103. This is a great example of one of the many flaws in the Arduino build methodology. The Arduino version reflects the version of the IDE and not really the version of the underlying core being used. Libraries often need to know more than just the IDE revision. This problem is only going to get worse as other processor are introduced and the cores start to differ in revision and functionality.

What is odd is that keypad code is already is setting the pullups by writing to the port after setting the port to input mode. It seems crazy to be using the INPUT_PULLUP mode at all since it just adding to the confusion and is not needed.

I'd go in and rip out the all the INPUT_PULLUP stuff since it simply is not needed.


The saddest part of all this was that many people including the Arduino team fought adding this mode in literally for years. (Teensy had it but it was rejected for main line arduino)

And while the Arduino team added stuff that literally broke 100% of all the existing libraries when going from the beta release candidate to the 1.0 release, this useful simple addition still wasn't accepted and didn't make it in to 1.0

The crazy part now is that because this is such a new feature that wasn't in 1.0, library writers really can't depend on it being there and the other non AVR parts now have to have special code to emulate the AVR way of turning on pullups by looking for writes to a port that is input mode to support all the existing code that turns on pullups without using INPUT_PULLUP. This slows things down for the non AVR processors.

--- bill

bperrybap: It seems crazy to be using the INPUT_PULLUP mode at all since it just adding to the confusion and is not needed.

This is a very compelling argument. It seems that I was trying to fix a problem that didn't exist.

I'd go in and rip out the all the INPUT_PULLUP stuff since it simply is not needed.

I'm going to do this. I'm debugging a problem with the library right now and when I am finished I will also update the library with the INPUT_PULLUP stuff removed.

Thanks bperrybap

This is a very compelling argument. It seems that I was trying to fix a problem that didn't exist.

I think the often used expression is "a solution looking for a problem" applies. Not unlike the new Serial.flush command that is so popular with beginner programmers. ;)

Lefty

retrolefty:

This is a very compelling argument. It seems that I was trying to fix a problem that didn't exist.

I think the often used expression is "a solution looking for a problem" applies. Not unlike the new Serial.flush command that is so popular with beginner programmers. ;)

Lefty

Actually I think the INPUT_PULLUP is a very good thing and it does solve real-world problems. In fact, I wish it had been accepted by the Arduino team sooner. 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. 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.

The real problem is it wasn't accepted as a solution to a real problem and implemented soon enough in the mainline arduino core code so it didn't make it into the flagship 1.0 release (It was added in 1.0.1 )

It has now now created a difficult backward compatibility issue for porting existing arduino code that runs on AVR to non AVR like ARM and PIC. The non AVR processor core code writers have two choices. - Emulate the AVR pullup enable capability in s/w as well as support INPUT_PULLUP - Only support the new INPUT_PULLUP and break any code using the AVR specific pullup enable method which is what all AVR Arduino code did prior to INPUT_PULLUP

The issue with emulating the AVR pullup enables in s/w is that it slows down the digital write code by having to look to see if it is a write to an input pin vs just being able to write directly to the hardware. It is really sad because other processor like the ARM and PIC have better i/o capabilities than the AVR yet they can't be fully utilized when s/w has to do this AVR emulation.

From a library portability standpoint, the ideal solution would be to use ifdefs so the code would use INPUT_PULLUP if it exists and not do the extra write to the input pin. If it doesn't exist, assume AVR or AVR emulation is available and drop back to INPUT and do the AVR specific method of writing to the input pin to turn on the pullup. It's a bit ugly but it would then be fully compatible with pretty much anything out there.

As and alternative, you could actually hide it pretty well by playing a few games with macros. i.e

#ifndef INPUT_PULLUP
#warning "Using  pinMode() INPUT_PULLUP AVR emulation"
#define INPUT_PULLUP 0x2
#define pinMode(_pin, _mode) _mypinMode(_pin, _mode)
#define _mypinMode(_pin, _mode) \
do                             \
{                              \
 pinMode(_pin, INPUT);         \
 if(_mode == INPUT_PULLUP)     \
   digitalWrite(_pin, 1);       \
}while(0)
#endif

This allows code to always pinMode() with INPUT_PULLUP regardless of whether the core code supports it.

The tricky part with the keypad library is that the pin mode is done through a virtual function which can be remapped. If the virtual function may need to know if the pin is INPUT or INPUT_PULLUP. Using the above macros may be a better solution than simply eliminating the INPUT_PULLUP because the virtual function can now receive a 2 (INPUT_PULLUP) rather than a INPUT which is currently defined as 0 Just keep in mind that to do this, the code implementing the virtual function would also need to have something like the above macros to ensure the INPUT_PULLUP is defined to the same value in pre 1.0.1 environments.

--- bill

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

bperrybap: 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.

bperrybap: 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.

bperrybap: 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.

bperrybap: 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.

bperrybap: 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]

bperrybap: 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?

retrolefty:

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

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

[quote author=James C4S link=topic=142041.msg1070221#msg1070221 date=1358102435]

bperrybap: 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.

bperrybap: 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.

bperrybap: 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.

bperrybap: 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

bperrybap: 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.

bperrybap: 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. [/quote]

--- bill

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:

            // 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