Two Arduinos using I/O pins to signal each other

I want to set up a test fixture that has an Arduino Uno and a couple of Nanos or Pro Minis as slaves. One of the slaves may run a motor or servo in a particular routine and i don't need to burden the UNO with that task. Instead, I plan to program a slave to listen to a particular I/O pin and act when that pin changes state. It would then set another I/O pin to signal back to the UNO that the message was received or that the task was completed.

My question here is whether or not I can tie an Arduino digital pin on one board to a digital pin on another Arduino. Let's say that I configure pin 10 on the Nano (slave) as INPUT with a 10K pullup or INPUT_PULLUP without the external 10K resistor, and tie it to pin 10 on the UNO, which is configured as OUTPUT.

If I set the UNO output to LOW, the input on the slave should go low. If I set the UNO output to high, the slave input should also go high. Can I do this without burning out either of the output pins? Do I need to put a series resistor between them just in case?

Yes, connecting one output to another input is not a problem. Some might suggest a small resistor in between in case you accidentally set both to outputs, with one high and one low, will limit the current and not burn one out. 1K should do, keep current down to 5V/1000 ohm = 5mA.

I don't bother myself, just practice careful coding. Don't even need the pullup, the OUTPUT device will drive the INPUT device High & Low without any extra help.

Don't forget to connect the GNDs

...R

Thank you guys for your input. I will set up a sample project to refine what it is I want to do. Of course, I should not forget to run a common ground.

Another thought I had is to use a hardware interrupt line on the UNO to react to something the slave boards do, like signal the motor is in the right position, or a physically moving part has reached a limit switch. The possibilities are numerous. I like using simple techniques to have the boards talk to each other.

Interrupts can be very useful. But they can also be very difficult to debug unless you are not already good at debugging, have a good understanding of the microprocessor and are willing (an able) to study the Atmel datasheet.

I suggest you get a system working using polling before you try to get the same thing to work with interrupts.

...R