next topic »

[on:]

I'm having an issue that I'm sure is just a problem with my understanding of Arduinos.  I have a Due and I need to use almost all of the pins.  I'm setting the pins as output and then calling digitalwrite(pin, high) on them like this:

//NUMBUTTONS = 49
//BUTTONS = an array of uint8_t
    for(uint8_t index = 0; index < NUMBUTTONS; index++)
    {
        pinMode(BUTTONS[index], INPUT); //this sets the pin to input mode
        digitalWrite(BUTTONS[index], HIGH); //this turns on the resistor
    }

What I'm finding is that pins 13, 12, 8, 9, and others work great as expected, but pins 5, 2, 17... are floating.

Am I missing something?

[Reply #1 on:]

Your description says "output" but the code says "INPUT". Assuming it's input that you want, I believe INPUT_PULLUP *should* do what you want in one function call.

Is the old way of enabling the input pullups still supported on the Due? I presume so, because the documentation doesn't say otherwise.

[Reply #2 on:]

Yes, I meant INPUT.  But I didn't realize that the code I had was deprecated.  I swapped it out and it made no difference anyway.  I'm still stuck with floating pins.

[Reply #3 on:]

Am I missing something?

Well we are missing bits of your code.
Please read the how to use this forum sticky at the start of this section and post all the code so we can check it out independently. Your BUTTONS array initialization can not be seen.
Incidentally the use of all capital letters on a name is normally reserved for a #define value not a variable. Yes it will still work but it is bad style.

How are you coming to the conclusion that they are floating?

[Reply #4 on:]

Yes, I meant INPUT.  But I didn't realize that the code I had was deprecated.  I swapped it out and it made no difference anyway.  I'm still stuck with floating pins.

I don't think it's so much a matter of being deprecated, but rather the vast difference between AVR chips and ARM chips. I have no acquired knowledge of how one enables internal pullups for input pins of the Due board but I would be very surprised if the old way (setting pin to input mode and then writing a HIGH to the pin) used on AVR based boards would work for the Due?

Lefty

[Reply #5 on:]

I've read the sticky.  There's really no sense in posting the entire application here: it's a hundred lines or so across 5 .INOs.  I'll pull out the relevant stuff:

I use all caps for constants.  The BUTTONS array is defined as such:

Code:

const uint8_t BUTTONS[] = {
    PI_OUTH,    PI_TROR,    PI_TROMR,   PI_TROM,    PI_TROML,   PI_TROL,    PI_SLANE,
    PI_REOS,    PI_LEOS,    PI_OPTLDRN, PI_OPTLRET, PI_LSLING,  PI_RSLING,  PI_OPTRRET,
    PI_OPTRDRN, PI_DRACD,   PI_DRACR,   PI_DRACA,   PI_DRACC,   PI_DRACU,   PI_DRACL,
    PI_DRACA2,  PI_VUK,     PI_DROPA,   PI_DROPB,   PI_DROPC,   PI_BELMB,   PI_BELME,
    PI_BELML,   PI_BELMM,   PI_BELMO,   PI_BELMN,   PI_BELMT,   PI_ORBLO,   PI_RAMPEX,
    PI_ORBLI,   PI_BOSS,    PI_CENTEX,  PI_CENTSC,  PI_ORBRI,   PI_CANDLE,  PI_RIGHTEX,
    PI_ORBRO,   PI_ORBTO,   PI_LPOP,    PI_TPOP,    PI_RPOP,    PI_LFLIP,   PI_RFLIP};

PI_XXXX is another constant defined in the Pins.ino like so:

Code:

#if DUE
const uint8_t PI_OUTH     = MYPIN_48; // Outhole                     1.1
const uint8_t PI_TROR     = MYPIN_47; // Right Trough                1.2
const uint8_t PI_TROMR    = MYPIN_46; // Middle Right Trough         1.4
// and on and on...

MYPIN_XX is defined as a uint8_t as well with a specific number like

Code:

const uint8_t     MYPIN_48      =     48;

Let's be a little kinder about marking 'style' points, okay?

My conclusion about them floating is because they are floating.  Any static interference near the pin changes its value.  Floating.  Wiring the same firmware up to a physical, external pullup resistor fixes the problem.  Some pins float (5, 3, 2) and some don't (13, 8, 9, 10).

[Reply #6 on:]

I don't think it's so much a matter of being deprecated, but rather the vast difference between AVR chips and ARM chips. I have no acquired knowledge of how one enables internal pullups for input pins of the Due board but I would be very surprised if the old way (setting pin to input mode and then writing a HIGH to the pin) used on AVR based boards would work for the Due?

Lefty

Yeah.  I haven't tried this code on my Mega yet, but this might be a Due-only issue.  I would be surprised to find this to be true, since there's no record of it that I can see.  It's also why I posted it here in the Due forum instead of in a more circuitry related forum. 

Lefty, do you have a Due you can test this out on?

[Reply #7 on:]

Lefty, do you have a Due you can test this out on?

While I do have a Due board, I've yet to install it and play with it. I'm happy with my herd of AVR based boards and they keep me busy enough. My plan for the Due board is to wait until it's IDE and libraries gets well out of beta status and someone or several people posts some kind of killer Due applications that I can't pass up trying.

 So far I just read the mail here on the Due section to see how the current state of the art of Due development is going, but so far I haven't been tempted by anything I've seen posted. I don't think the Due board has left the parking lot yet, let alone cruising the highways of cool shared projects. 

I'm not anti Due, just old and tend to resist change. 

Lefty

[Reply #8 on:]

Let's be a little kinder about marking 'style' points, okay?

I pointed it out, that's all. I didn't criticise you, or lambast you, or call you any names, so how do you do this kinder?
 

There's really no sense in posting the entire application here: it's a hundred lines or so across 5 .INOs.  I'll pull out the relevant stuff:

The point is that I can't take that code and try it on my Due, if it is too long or irrelevant to post then why not write some code that will illustrate the problem. Often that crystallizes where you are going wrong. If a simple sketch can't illustrate the problem then it is not likely there is a fundamental.

Looking at the data sheet all the I/O pins have internal pull up resistors, or at least they all have a register pin that correspond to it.

[Reply #9 on:]

I have tried this code on my Due and using both methods of setting the pull up resistors I get a solid signal from pin 5. That is touching a wire to pin 5 and my other hand pressing over the board does not change the reading.

Code:

/* Due digital read speed test
*/

void setup(){
  Serial.begin(9600);
  Serial.println("Hi from Due");
//  pinMode(13,INPUT_PULLUP);
//  pinMode(5,INPUT_PULLUP);
  pinMode(13,INPUT);
  digitalWrite(13,HIGH);
  pinMode(5,INPUT);
  digitalWrite(5,HIGH);

}

long startTime, Time;
void loop(){
  int sample1,sample2;
  startTime=millis();
  for(int i = 0; i<1000; i++){
    sample1 = digitalRead(13);
    sample2 = digitalRead(5);
  }
  Time = millis() - startTime;
    Serial.print("1000 readings in ");
    Serial.println(Time);
    Serial.print(sample1,HEX);
     Serial.print("  ");
    Serial.println(sample2,HEX);
}

[Reply #10 on:]

Well, that's a good point.  A sketch that does 2 things; define pin 5 as INPUT_PULLUP and pin 13 as OUTPUT, and loop() just outputs state of pin 5.  Classic "Button" example.

... 3 hours later...

Okay, I found the issue.  I was reusing MYPIN_5 (and others) based on some overlooked pragmas which were setting those pins LOW again.  Totally my bad.  I also got a chance to rewrite my serial protocol, which is nice.

The answer for any one else coming through this thread is:

Yes, the Due supports pullup resistors using pinMode(pin, INPUT_PULLUP);

If it's not working, chances are somewhere else you've re-set the pin to LOW.  Thanks for your help.  I ended up using the example Button sketch to confirm that it was my code, and that uint8_t isn't the problem, and that an array of uint8_t constants as pin numbers works fine as well.  At that point it was just a matter of commenting out most of my sketch to only execute the switch handling section.

(there was a moment that I thought I was perhaps using a Serial-dedicated Pin (not 0, or 1*) and didn't know it.  My Max32 crowbars if you Serial.Read while using DSPI so it's not unheard of.  But no, I am able to use all 52 pins I have dedicated to INPUT_PULLUP [not 100% tested yet])

*As far as I know you can't use pin 0 and pin 1 if you're using Serial as well.

Thanks again Grumpy_Mike and Lefty