Can an interrupt pin be changed from an input to an output while code is running
receive an interrupt
pinMode(myInterruptPin, INPUT);
...
Send out an interrupt
pinMode(myInterruptPin, OUTPUT);
Using same interrupt pin myInterruptPin.
Send out an interrupt
The whole point of an interrupt is that it is received
Do you meant that you want to cause the function that is called on receipt of an incoming interrupt to be called from within the program and not as the result of an external interrupt ?
What is it that you are trying to do ?
romarshmallow:
Send out an interrupt
You can't send out an interrupt.
You can cause an I/O pin to go from LOW to HIGH (or vice versa) and that could be arranged to trigger an interrupt on another microprocessor. There is no need to use the interrupt pin for the LOW to HIGH change.
...R
The technical answer to your question is, sure. It's referred to as a soft interrupt, where any change of state on the pin will trigger an interrupt. The question that always gets asked though, is that since you (or your code) control the state of an output pin, can't you just as easily invoke the function that might otherwise be called by the interrupt?
Where this might change in a case like yours, is if you multiplex the function of a pin and wish whatever code attached to the interrupt to still be called. Sometimes this method is employed when using a rotary encoder on the lead screw of a stepper motor. A simple latch can turn the encoder pin to a pulse output for micro-stepping the motor to it's final position while the ISR maintains a pulse count.
Let us take the case of DPin-2 which works as INT0 line when this instruction:
attachInterrupt(digitalPinToInterrupt(2), ISRName, TriggerLevel); is executed. The DPin-2 is automatically configured as an interrupt input line and it loses its digital IO capability. To regain the digital IO capability, we must execute this instruction: detachInterrupt(digitalPinToInterrupt(2));.
GolamMostafa:
Let us take the case of DPin-2 which works as INT0 line when this instruction:
attachInterrupt(digitalPinToInterrupt(2), ISRName, TriggerLevel); is executed. The DPin-2 is automatically configured as an interrupt input line and it loses its digital IO capability. To regain the digital IO capability, we must execute this instruction: detachInterrupt(digitalPinToInterrupt(2));.
If you use the Arduino functions. At the board level you have more control than that.
Send out an interrupt
pinMode(myInterruptPin, OUTPUT);
So assuming that your hardware is driving this pin, then changing it to an output is a very bad idea. you could burn out the pin.
DKWatson:
The technical answer to your question is, sure. It's referred to as a soft interrupt, where any change of state on the pin will trigger an interrupt.
No it is not. A software interrupt SWI is a software machine instruction that performs all the stack operations of an interrupt and is vectored. But it is just a machine instruction. What you are describing is a "pin change interrupt" and as this works when some hardware signal changes it is not a SWI.
The AVR instruction set has no SWI instruction but the ARM chip does. In the original ARM computer's operating system it was used to implement a comprehensive set of operating system calls, with an SWI instruction followed by a 32 bit number. The SWI vectored to a routine that pulled the following number off the stack and interpreted it. Then the return stack was manipulated so the return address pointed one 32 bit word further from where it should have been. Very neat I thought.
Hey Grumpy. Please note the keyword 'referred'. As the OP is evidently not fully comfortable with interrupts, the intricacies of instruction sets seemed a bit much. And yes, it is a misnomer, as interrupts are caused by state changes in the hardware. However, if the pin is moded as output with a PCI attached, the interrupt will fire when that state is changed. Perhaps a better term to use would be a software generated interrupt as the state is changed by code rather than external event.
Delta_G:
No it doesn't lose any capability. No, you don't have to detach interrupt first. You can even set the interrupt on an output pin and trigger it by writing the pin high or low. How that's useful I don't see, but it is certainly possible.
The following experiment speaks in favor of the above statements. I have seen something new in my many years of playing with ATmega32A/328P. As I was knowing that INT0 is the alternate function of pd2 of Port-D Register, there should not be anything as the digital IO functionality of pd2 line. Is it logical for the interrupt line to be configured as OUTPUT?
Setup : NANO + (D2 ---> LED+2k2+GND) + (D2 --->2k2 + GND)
volatile bool flag = 0x00;
void setup()
{
Serial.begin(9600);
attachInterrupt(digitalPinToInterrupt(2), ISRINT0, HIGH);
interrupts();
}
void loop()
{
if (flag == 0x01)
{
Serial.println(flag, HEX); //shows 1
flag = 0x00;
pinMode(2, OUTPUT); //
digitalWrite(2, HIGH); //LED is ON
}
}
void ISRINT0()
{
flag = 0x01;
}
Remember too that an alternate function of PD2 is PCINT18.
From datasheet,
The External Interrupts are triggered by the INT pins or any of the PCINT pins. Observe that, if enabled,
the interrupts will trigger even if the INT or PCINT pins are configured as outputs. This feature provides a
way of generating a software interrupt.
SWI for INT0 interrupt can also be generated by activating the INTF0 flag bit of EIFR Register while the pd2 line is working as a general purpose digital IO line.
That's a pro-active move. If you're going to do that, why not just call the function. The idea of a software generated interrupt is in reaction to some other event that caused the output to change state.
If you're going to do that, why not just call the function
Because a function does not have the preservation of the state by using the stack. A function is not as isolated from the main code as an ISR.
Sorry but you can’t wriggle out of it, you used the wrong words, an SWI has a specific meaning and it is not the one you attributed to it.
Just keep in mind that you’ll be pushing 5V or Gnd back ‘in’ to the interrupt source device.
Make sure your circuit is designed not to protect the AVR and the other device output pins feeding into each other.
Grumpy_Mike:
Sorry but you can’t wriggle out of it, you used the wrong words, an SWI has a specific meaning and it is not the one you attributed to it.
I'll inform Atmel/Microchip. May I quote you?
Delta_G:
There are a few things that you drive as an output and then switch to input to listen to. It's all about impedance. But for the most part this whole idea is a good way to burn a pin.
It's the way all one-wire half-duplex communication works, but yes, you do need some external circuitry.
Make that single-wire. Not to be confused with Maxim's 1-wire protocol (stave off the pedants).
After the execution of the attachInterrupt(0, arg2, arg3); instruction, the pd2 line is solidly connected with the INT0 interrupt logic of the MCU. At the same time, the external 'hardware 'interrupting circuitry/device' is also connected with the pd2 line. Under this circumstance, an attempt to use the pd2 line as an output line without detaching it first from the interrupt logic could be considered as an useless fabricated idea because an active state of the pd2 line will collide with the 'interrupting circuitry' and will also activate the interrupt flag (INTF0). It is hard to believe for me that the ATmega328P designers have thought that the user might operate the pd2 line in this conflicting/destructive way.
If someone wants to check the functionality of all the interrupt software chain without installing the external hardware interrupting device for INT0/INT1 or any other interrupt, he may artificially generate the cause of the interrupt by activating the corresponding interrupt flag bit. This is something that may be seen as a Software Interrupt (SWI).
Who frightened off the OP ? 
...R
Atmega data sheet, section on interrupts:
Observe that, if enabled, the interrupts will trigger even if the INT0 and INT1 or PCINT23...0 pins are configured as outputs. This feature provides a way of generating a software interrupt.