is it possible to add a push button switch in arduino port 0 or 1

is it possible to add a push button switch in arduino port 0 or 1 becoze all other port is reserved

What are you using D2-D13 for? What are you using A0-A5 for?

.

A0 to A13 are fully reserved also i have to use a push button switch

I asked, what are you using them for.

.

Hi, What model arduino are you using? What is the application that has used all your I/O.

Have you looked at a port expander?

https://www.sparkfun.com/products/13601

Pins 0 and 1 are the tx/rx pins used to program the controller.

Tom... :)

I know people are trying to get around the problem and steer him to the possibilities of using other ports. However I think that Thachuthas has asked a good question that deserves a straight answer. If there is a straight answer that is :).

To be honest, this is something that I've also wondered about. How easy is it to re-purpose pins 0 and 1 (aka tx and rx on the uno).

Looking at the schematic I see that these pins are "isolated" from the USB chip by 1k resistors, so it seems that it should be safe to do so, provided that you aren't trying to do serial comms at the same time that the button is pressed.

I would be cautious about using too lower value of pull up resistor, as the USB chip will have to be able to "overcome" this while driving though the 1k resistance. At least if you still want to retaining even the possibility of serial comms while the button circuitry is connected. Personally I would just use the ports internal pull up option and run the push button to ground.

Let me point out that I've never tried this, so the above are just my hunches. I'd be interested to hear from anyone who has done this, and in particular if you can reconfigure the pins within the sketch to switch between "button listening" and "serial comms allowed" modes.

@stuart0 We need answers to questions. The OP was asked what he was using the other pins for a reason. If he says one of the other pins is a LED indicatetor, I would suggest he look at this link: http://forum.arduino.cc/index.php?topic=439838.msg3039381#msg3039381

You can use 0 and 1, however I would recommend the sketch be downloaded using ICSP which gets rid of the bootloader. Also there is a hardware connection between the 328 RX TX and the USB converter if an UNO. This hardware has to be considered in the design.

We do not know if the OP is using serial either.

.

LarryD: @stuart0 We need answers to questions. The OP was asked what he was using the other pins for a reason. If he says one of the other pins is a LED indicatetor, I would suggest he look at this link: http://forum.arduino.cc/index.php?topic=439838.msg3039381#msg3039381

I know Larry. I was thinking about your LED/PushButton expanded circuit as soon as I saw you ask the question. :)

I'm still not sure that using rx/tx for a push button would be as difficult as some people think. I can see no reason why uploading via the bootloader wouldn't still work, provided that you have a reasonably large pullup resistor and that you don't press the push button while trying to upload.

I'd recommend using the inbuilt pullups and running the push button to ground through a 1k series resistor. That should make it very safe.

But yes, we certainly need to know whether the op needs to use serial comms within his sketch. That certainly complicates things.

Yes, you can use these in sketches, you just have to design things around the hardware.

eg: Lets say you used TX, D1 as and input that went to a N.C. switch then to GND. This would not be a good thing if reset was pushed or you did a power fail restart. So, you add a 220R resistor in series with the N.C. switch to protect the pin. Stuff like this has to be designed around.

.

Want to use pins 0 and 1 for other than Serial?

Fine, just don't use them for Serial as well and maybe don't connect them until after loading the sketch. There should be no big problem.

What that will do is make debugging harder by eliminating the ability to print trace info during execution.

Smarter solution is to use multiplexing or "pin multipliers" (port expander(s), shift registers, etc) to free pins or use/make some other solution such as using a single analog pin for multiple inputs that all deliver differing voltage to that pin.

Easier solution is get a board with more pins. The usual next step is to use a Mega2560.

Another route is to add a stand-alone AVR to handle extra load if pin multipliers are too slow.

What that adds up to is that if your design hits limits, change the design!

Today I tested connecting push buttons to the rx and tx ports (pins 0 and 1 on my uno).

The results were very good. When appropriately connected I could still upload programs and read and write from the serial monitor within the sketch.

Obviously I couldn't have simultaneous button press detection and serial communications, but apart from that limitation it works very well. My test sketch prompts the user for the number of button presses to detect, then counts each button press and writes to the serial monitor to report each occurrence. The operation was 100% flawless for both the rx and the tx implementations.

If anyone is interested in the code I can upload the sketches (and describe the very simple hardware used).

stuart0: Today I tested connecting push buttons to the rx and tx ports (pins 0 and 1 on my uno).

The results were very good. When appropriately connected I could still upload programs and read and write from the serial monitor within the sketch.

Obviously I couldn't have simultaneous button press detection and serial communications, but apart from that limitation it works very well. My test sketch prompts the user for the number of button presses to detect, then counts each button press and writes to the serial monitor to report each occurrence. The operation was 100% flawless for both the rx and the tx implementations.

If anyone is interested in the code I can upload the sketches (and describe the very simple hardware used).

Sure, others will have the same question eventually.

.

By using Serial.end() after printing and and Serial.begin() before printing and likewise only moding and reading the same pins for buttons when Serial is off?

GoForSmoke: By using Serial.end() after printing and and Serial.begin() before printing and likewise only moding and reading the same pins for buttons when Serial is off?

Yes I'm just about to post the code. To be perfectly honest I expected to run into more problems than I actually encountered. I had predicted several types of anomalous behavior that might be induced, but during testing I didn't observe them, and I'm not really sure why.

Just uploading the code now ...

// A meaningless program to test the multi-use of the port D1 (tx) pin on the UNO.
// Connect a normally open push button from tx (pin 1 on UNO) to ground via a 1k series resistor.
// Note: It is important to use the series resistor in this example to avoid hardware damage!
// Set serial monitor to 115200 baud or change the define below to match you monitor settings.

#define baud 115200
#define txPin 1

int pressToWin;

void setup() {
  Serial.begin(baud);
  Serial.println("The button is not yet available!"); Serial.println();
  Serial.println("Enter the number of button presses to watch for ... ");
  
  while (!Serial.available());                          // Wait for reply
  pressToWin = Serial.parseInt();
  Serial.println();
  
  Serial.print("Ok, the 'game' ends after ");
  Serial.print(pressToWin);
  Serial.println(" button presses."); Serial.println();
  
  Serial.println("Button presses are now available."); Serial.println();
  Serial.end();
  delay(20);
  pinMode(txPin,INPUT_PULLUP);                        // Set tx (port D1) to input with pullup.
}

void loop() {
  static bool buttonHistory[3] = {true,true,true};    // Default state for N.O switch with pullup.
  static bool buttonState=true, lastButtonState=true;
  static unsigned pressCount = 0;                     // To count the button presses.
  
  debounceRead(txPin,buttonState, buttonHistory);     // Read input (tx port D1) to buttonState
  if (!lastButtonState && buttonState) {              // If rising edge.
    Serial.begin(baud);
    Serial.print(++pressCount);
    Serial.println(": Button was pressed.");
    if (pressCount == pressToWin) Serial.println("Yeah you win!");
    Serial.end();
    delay(20);
    pinMode(txPin,INPUT_PULLUP);                      // Set tx (port D1) to input with pullup.
  }
  lastButtonState = buttonState;
  delay(20);                                          // Limit the loop rate for sake of the debouncer.
}


void debounceRead(byte pin, bool &currentState, bool hist[]) {
  hist[2] = hist[1];
  hist[1] = hist[0];
  hist[0] = digitalRead(pin);                         // read button on D1 (tx)
  if ( (hist[0] == hist[1]) && (hist[1]==hist[2]) )
    currentState = hist[0];                           // return new state if history aligns
                                                      // otherwise leave state unchanged
}

rx_input1.ino (2.55 KB)

tx_input1.ino (2.31 KB)

stuart0: Yes I'm just about to post the code. To be perfectly honest I expected to run into more problems than I actually encountered. I had predicted several types of anomalous behavior that might be induced, but during testing I didn't observe them, and I'm not really sure why.

Just uploading the code now ...

I haven't looked, but how do you find out when the print output buffer and port are empty? Or full?

It could be possible to write a non-blocking print function that would let other tasks run rather than what serial does when the buffer's full.

How many times a second do you need to test a human activated button anyway? More than 10? How much text can you send to serial monitor in between? Read with debounce could take 2 to 20 millis out of the 100 from read to read. IDE 1.6.9 allows 25 chars per milli at 250000 baud but I dunno how long Serial.begin() and Serial.end() take and if there's a faster direct port alternative.

GoForSmoke: I haven't looked, but how do you find out when the print output buffer and port are empty? Or full?

I just used a "delay(20)" between Serial.end() and setting tx/rx for input. I think that gives it plenty of time to clear any pending transfers at 115200 (the baud I used).

The idea was that this would only be used for push buttons (normally open) that need relatively low sample rates.

BTW. Just let my clarify that I wasn't sure whether this was a good idea or not. TBH I had a lot of misgivings about it, but it was something that I wanted to test.

Here I summarize all the findings from my tests. In particular the problems that I expected to encounter, and in some cases did observe but others not.

  1. Hardware considerations.

a) TX button. The tx pin is normally an output, so it is important to connect the pushbutton through a series resistor to prevent any inadvertent shorting of an output pin.

The value of the series resistor is fairly flexible, because when tx is set to an input for button read mode there is only the internal pullup (approx 30k) to overcome. I used 1k, but you could probably go up to about 10k and still get a valid low level on button push.

One fortuitous feature of the input on the tx pin is that the button series resistance is large enough that the tx output can easily over-drive the button, even if it is held closed while serial tx operations are on going. This feature is not possible for button input on the RX pin btw.

b) RX button. The rx input is never directly connected to any output (though it is connected through a 1k resistor an output on the USB to serial chip), so there is no need for any series resistor. A series resistor may be included for safety (accidental wrong connection etc), but it's value has to be no greater than a few hundred ohms.

This is because the button on the rx pin has to overcome more than just the internal pull up resistor, it must also overcome the drive from the USB to serial converter chip which is only 1k. I would recommend 330 ohms or less, if any resistor at all is included.

One upshot of this is that we can never include enough series resistance to prevent a button press from interfering with received serial data. If the button is pressed while serial data is being received then it will corrupt the data. This is a fundamental limitation of the button input on rx.

  1. Possible sources of spurious operation.

I expected to see some spurious operation if either mode of operation occurred out of turn. For example with button presses while in serial transfer mode, or external serial input while in button listening mode. As it turned out this spurious operation was harder to detect than I thought.

a) Erroneous button press during serial transfer.

It's a "no brainer" that pushing the button that is directly connected to the rx pin will interfere with serial received data. This was trivial to observe. There is no corresponding limitation when the button is on the tx pin however, as the series resistance is enough to prevents this.

b) Erroneous serial input (receive) during button listening mode.

I definitely expected to see this problem if I sent data from the serial monitor while the RX pin was in button listening mode. This is because the USB to serial converter chip is still enabled, even when the MCU's internal usart is disabled (after serial.end). So any arriving serial data would be prone to causing a spurious (apparent) button press. The moderately high serial baud and the software denouncing seemed to mask this problem so it wasn't observed.

I did eventually manage to observe it, but only after completely removing the software debounce, removing almost all of the "safety" delay in the loop, and setting the baud rate right down to 1200. At that point I could reliably force a spurious button press every time I sent a "0" from the serial monitor.

c) Erroneous serial transmit when TX connected button is pressed.

None of the previously mentioned issues affect the TX connected button, so this one was expected to be the main shortcoming for the TX button. However I was never able to observe it. I pressed the button as furiously as I could, but never saw any spurious characters appear on the serial monitor.

The premise behind this one is similar to "b" above. Even when the MCU's internal usart is disabled the USB to serial convert is not (I think?). So I thought that pressing the button to pull tx low would cause the USB chip to transmit something spurious. I really don't know why I never observed it.

In hindsight I suspect that perhaps something spurious could have happened there, but I wouldn't have observed on the serial monitor if it was only null characters (0x00). If pulling tx low caused the USB chip to transmit something it would probably be a zero.

OP MIA

Thanks stuart0

stuart0: I just used a "delay(20)" between Serial.end() and setting tx/rx for input. I think that gives it plenty of time to clear any pending transfers at 115200 (the baud I used).

The idea was that this would only be used for push buttons (normally open) that need relatively low sample rates.

A non-blocking version could be useful if the sketch it is part of is going to run so many other things that pins 0 and 1 are needed for buttons.

The serial output buffer is 64 chars. 6 ms at 11.52 chars/milli more than empties it, but at that scale it takes micros() to be accurate as millis() occasionally skips a value to fit 1000 into 1024.

Last time I remember looking into the Serial code, it was Java.