How can I momentarily pull a pin down?

NETMF & Gadgeteer
1

I have a TTL switch which is at 3.3v nominal and is triggered when pulled to ground.

I was previously using my Arduino to trigger this switch with the following:


  digitalWrite(7, LOW);
  pinMode(7, OUTPUT);
  delay(2000);
  
  delay(100);
  pinMode(7, INPUT);

I’m attempting to do the same on my panda 2 but not having much luck


var pow = new OutputPort((Cpu.Pin)FEZ_Pin.Digital.Di13, false);
pow.Write(false); //should be redundant
Thread.Sleep(200);
pow.Dispose();
var p2 = new InputPort((Cpu.Pin)FEZ_Pin.Digital.Di13, false, Port.ResistorMode.Disabled);

I can probably get away with writing low and then writing high but because the device being switched and the panda have different power supplies I’d like to avoid it and return the pin to a free state.

2

What is your issue? I’ve used OutputPort and InputPort definitions as you have and it works fine in the emulator ?

OutputPort pow = new OutputPort((Cpu.Pin)2, false);
pow.Write(false); //should be redundant
Thread.Sleep(200);
pow.Dispose();
InputPort p2 = new InputPort((Cpu.Pin)2, false, Port.ResistorMode.Disabled);
3

So you need an open collector/drain output.
I don’t think you can configure the pin in this way. Maybe using it as an output for low level and as an input for high impedance state.
You could also use a transistor (and the port as normal output) to achieve this.

4

Thanks for the feedback guys.

Using an input (high impedence) should be fine as it’s what I was doing with the Arduino.

I actually found that the issue is probably somewhere else. After I program the panda and go plug it into the rest of my project, the switch triggers once and once only. Subsequent resets/power cycles seem to leave it hanging in some state before the Main function is called. The first thing I do in Main is power off the onboard LED and yet it stays lit after the first run.

My code has a bunch of other stuff but the gist here is to turn off the onboard LED as soon as Main is called, pulse pin 13 to ground as I described, turn the onboard LED back on, and go off into unrelated potentially buggy code.

One key difference is that I short the MODE (pin 70) to ground after programming so that I can use USB client functionality, but I can’t think of how this would cause the behavior I’m describing.

I’m not sure what could be causing this, any hints would be great! Could this be some sort of crash and/or state persisting between power cycles and resets?