I imagined that "DigitalIn Pretrig(p26);" would configure pin 26 as a digital input, but neither a 33K pullup nor even a 1K pullup will pull the pin voltage far from 0v. It seems to me it is still driving out? What have I done wrong?

By default, IO pins have an internal pull-up. So if you define an input and leave it floating (unconnected) it should read as "1". Connecting it to ground will then make it read as "0". See this link to change how the pull-up works.

My pin is staying low despite an external pull-up, even 1K only shifts it fractions of a volt from zero. I'm assuming DigitalIn configures the pin to input?

Hi Andy, Alex,

To clarify, DigitalIn defaults to having an internal pull-down resistor, so an unconnected pin will read as 0. See the DigitalIn details section:

• /handbook/DigitalIn

I suspect you are therefore fighting with that. You can change the setting of the pull mode using the mode() method if you wish.

Simon

Thanks Simon - I've not brought the oscilloscope home with me but it is looking promising on the Mbed alone, it must be a stong internal pull-down?

The pulldown (and pullup) resistors are quite weak -- they sink or source a few hundred microamperes, if memory serves. (Update: 150uA pulldown maximum, -85uA pull up current. See I_pd and I_pu in the table 7, page 45 of the LPC1768 data sheet.)

An external 1K should be more than enough to overcome them.

I suspect that somehow p26 is being driven as an output...any chance you have enabled the PWM functionality on that pin?

I'm still not convinced it is working, tests without the benefit of a meter or scope are suggesting it isn't.

The code below only works if I test for a low level on "Trig", toggling the level externally has no effect.

#include "mbed.h"
DigitalIn Trig(p25);
BusOut myleds(LED1, LED2, LED3, LED4);

int main() {
int Channel;
Channel = 0x0001;
Trig.mode(PullUp);

while (1) {
while ( Trig == 1 ) {} // trig rising edge
myleds = Channel;
wait_us( 880 );
myleds = 0;
while ( Trig == 1 ) {} // trig falling edge (when input bug fixed)

Channel = Channel << 1;
if ( Channel > 8 ) Channel = 1;
wait_ms( 10 );
}

This is virtually my entire code, so I don't believe the PWM should be getting involved. However I do believe something is making my input pins drive out.

I'm using P21-24 as a BusOut, and P25-26 as inputs. This ought to be OK?

The behaviour you are reporting certainly seems strange. To gain more confidence in why is going on, I'd run the following:

#include "mbed.h"

DigitalIn input(p5);
DigitalOut led(LED1);

int main() {
  while(1) {
    led = input;
  }
}

Have a fiddle connecting p5 to 3.3v and 0v. And you can perhaps also try some different pins, incase you zapped something.

Simon

As it stands, your program turns on an led, then turns it back off, with a duty cycle of 0.88mS ON / 10.0 mS OFF.  So you should see a faint glow in the leds.

This is true as long as Trig is low -- i.e., when the program falls through the two "while(Trig ==1) {}" statements.

If Trig goes high, then the program will stall in one of those same while() statements, and the lights will stay turned off.

Try changing both wait statements to "wait(0.5)". That should at least let you verify visually that the leds cycle correctly when Trig is low.

I like Simon's suggestion of basically echoing the input directly to the led, that is a good idea.

Re. my program extract - the intention is that it puts a pulse sequence sequentially onto one of four outputs, each pulse sequence triggered by a cycle of the Trig input, and at the moment, the input appears to be held pretty firmly low by the chip, when I'd expect a high impedance pin with maybe a weak pull-up. I started with a 33K pull-up, but even 1K doesn't budge it far from zero. The leds are simply a diagnostic aid, as is the 10mS delay. Once I've got the code responding to an input pin, I'll substitute digital outputs for the leds. My mBed board has only done an mBed workshop and a few very basic exercises at home, so it shouldn't have been damaged. I realise that the whole idea of the mBed is to hide the complexity of coding micros, but at times I miss being able to lift the skirt and examining what is actually going on at low level.

Interesting - following Simon's suggestion, I did a simple hardware test and echoed an input straight to a led. Pin 5 works, Pins 25 and 26 don't. I've moved my input signal to pin 6 and it is controlling my program flow.

A 1K pull-up to pin 26 only raised the pin abot 230mV, as thought it is still trying to drive out. I'm using pins 21 to 24 as an output bus, these are working correctly. I'm not aware of any damage done to my mBed.

Isn't it great having "The Creator" active on the forum? Thanks, Simon.

Ok, here's where I discover that I'm an idiot. I'd a misconnection, the connection to my ground reference for input signals was instead going to +V. Why some inputs worked and others didn't I don't know, I'm surprised it worked at all. As usual, something very simple was screwing things up. Thanks to everyone especially Simon for their help.

I used pin26 with a 10K pullup to +5 V for digital output. Now I am thinking this pin is ..may be damaged. like Alex wrote I always get low (few mV) . Is it possible? Is my pin damaged.