That's what I was afraid of. However, 32u4 Serial (which actually uses USB) runs without problems inside an ISR, although that was just for debug purposes only.
No, not really. The serial output is most definitely NOT running in the ISR. Interrupts are disabled in the ISR, so the serial output can't possibly be running.
The way the serial output works, the data you are sending gets placed in an output buffer. An interrupt routine then takes characters from the output buffer and sends them out the serial port each time that the hardware interrupts signalling that it's ready for a new character.
So, in reality, what's happening is that in the ISR the Serial command is putting those three characters into the output buffer. It fits, so after queuing the data, it returns and your ISR continues. Once the ISR is over, the serial interrupts take that queued data and send it out. It sounds like picky semantics, but the data is NOT being sent during the ISR.
Where this becomes important is when you try to send more data than what can fit in the serial output buffer: the print() call will block until there is room. But if you are calling print() inside an ISR, interrupts are disabled and no characters will be removed from the buffer to be sent, so room will never be made available, therefor the print() call will never return. You are deadlocked.
The Bridge fail even if there is no Serial output.
The Bridge communications may send more data than will fit in the Serial1 output buffer, so that could cause a deadlock there. But even if the output buffer doesn't fill, the Bridge communications is waiting for a response from the Linux side. That will never happen for two reasons in an ISR: first off, the request won't actually be sent to the Linux side because interrupts are disabled, and secondly any response from Linux won't be received, also because interrupts are disabled.
That still doesn't 100% completely explain why I can't receive Serial data with the Bridge code present.
Hopefully this additional explanation covers the reasons 100%. If not, please let us know what is still confusing.
in reality it is doing a lot more and I need to register this interrupt as soon as possible and report it to the MPU, where my Linux application takes over.
But using an interrupt to send the notification to Linux is a waste of effort since the Bridge communications takes time, and Linux is not a real time operating system. You will never get serial communications to Linux working reliably in an ISR. The actual communications MUST happen in loop(), not in an ISR. That means that even if you use an ISR to set the flag, the state of the flag will still be polled - using an ISR accomplishes nothing in this case other than adding complexity, unless you are also doing some other real time processing like controlling other hardware outputs, or calling micros() to capture the time that the interrupt occurred.
Even if you do start the Bridge communications immediately, you still have no control over how long it will take to complete, or how quickly Linux will actually service the request and respond. It may be fast, but it will not be a reliable real time event.
PS. One more question: Is the Pin 7 (Handshake) used or will ever be used in any intrinsic functions of Arduino Yun in the future?
It is not currently used, and I have no insight to anyone's future plans for it.
But the pin can easily be used. I have used it for the stated handshaking purpose, where the sketch monitors the line waiting for the Linux side to indicate that it is ready. I need to hit the road right now, and I don't have time to give a reasonable answer and example, but I will when I get back.[/quote]