Use pin for both input and output?

I have no spare UNO pins. Most are in use as inputs, taken low briefly by buttons. But I need a way to take the UNO’s reset pin very briefly low. Could I briefly change an existing button pin to an output to achieve this, and then restore it as an input?

If the low pulse was a mere ms or two I’m reasonably confident it would not activate that button’s intended logic, but should be long enough to reset the UNO. I gather that Reset is internally connected high by a 30k resistor. So am I right that its permanent connection to the ‘dual purpose’ button pin (INPUT PULL_UP) should not be an issue?

Have you used all of the A* numbered pins ?

An Arduino pin can be changed from input to output and back again using pinMode( . . . );

You can try this for yourself.

If the purpose is to reset the UNO, you could also do that with code:

void reset() { asm volatile ("jmp 0"); }

void setup()
{
  //Boot loop
  reset();
}

Presumably, there is an output from "something else" connected to this input-pin and that will also be connected to the reset pin and that's likely to foul things up! It might cause unwanted resets.

In general you should not "short" two outputs together. When the Arduino-pin is an output you don't it want it "fighting" with another output.

If you are very-careful to make sure that only one output at a time is active it can be OK. Some chips have an output-enable pin but with the Arduino you'd have to switch it to an input.

And some chips are open-collector or open drain. These are used with a pull-up resistor and can be "or'd" together so one or the other or both can safely pull-down the shared signal line.

...It is OK to connect multiple inputs together.

1 Like

Unfortunately yes. Including A0 as loose wire input for seeding:


randomSeed(analogRead(0));

I’ve assumed that I should not use D0 or D1, as I have these Serial commands in setup():

mySoftwareSerial.begin(9600);
  Serial.begin(9600);

And these libraries:


#include "OneButton.h"
#include "Arduino.h"
#include "SoftwareSerial.h"
#include "DFRobotDFPlayerMini.h"

Multiplex the buttons. Also reading an analog port is not the only way to seed an RNG. Also why on earth do you want to hard reset the board?

If a peripheral device is connected with an input line, then is it useful to change the direction of the input line as output line?

It would be dangerous to do that. Apart from any usefulness.

1 Like

Thanks, very helpful, that’s given me pause for thought. And I’m guessing a 0.1 uF cap between Reset and Dn would not eliminate risk of conflict?

It begs the question why OP thinks it's necessary to reset the processor.

2 Likes

I cannot change the circuitry by adding another IC. The veroboard is in place already and has no free space. I’m intending when my breadboard development is ‘finished’, to simply mount the 328.

Can you advise those other seeding methods please?

As for why I need to reset, that’s probably going to be another post.

There are event based methods. Without your application details I can't advise.

Thanks, that sounds promising, I’ll try it asap.

A common approach is to have the user push one of the buttons at startup. Timing will be variable.

Please explain why you think you need to reset the processor.

1 Like

A jump to zero will not initialize all the registers. I agree, we don't need a separate thread to discuss the reason for reset.

The standard way to deal with the risk of uncontrolled execution, is by enabling and feeding the watchdog hardware. (guessing that's your game).

Thanks, and yes, I will reply to the natural questions several respondents have raised about why I want to reset. In a fresh post in the near future I will attempt to reduce my 700 line program to a minimum, but that still exhibits the problem I’ve been trying to fix. In brief: the program runs OK directly from the IDE upload, but when only external power is applied for startup, by any means, it does not. I have a few unsatisfactory work arounds, but…

It sounds like a hardware issue, anyways...

Please amplify. Why?

Because power supply changes it.