Here's how to get the fastest interrupt response by directly configuring the port register. I took the code from msg #3, removed all the unused stuff, then substituted these lines for the slow attachInterrupt(). I also added an analogWrite() on pin 2, for a test signal to cause the interrupt to happen.
Code:
void setup() {
pinMode(29, OUTPUT);
pinMode(30, INPUT);
attachInterruptVector(IRQ_PORTB, &pulse); // directly attach function, all Port B pins
CORE_PIN30_CONFIG |= PORT_PCR_IRQC(9); // 9=Rising Edge
NVIC_SET_PRIORITY(IRQ_PORTB, 0);
analogWrite(2, 128); // connect pin 2 to pin 30 for testing
}
FASTRUN
void pulse() {
digitalWriteFast(29, HIGH);
CORE_PIN30_CONFIG |= PORT_PCR_ISF; // clear interrupt status
digitalWriteFast(29, LOW);
}
void loop() {
}
Here's the hardware on my desk, running this code on a Teensy 3.5.
As you can see in this photo, I used a clip lead to connect the PWM on pin 2 to the interrupt input on pin 30.
Now for the bad news. Teensy 3.5 running at 120 MHz probably isn't fast enough to meet your needs. At least not using interrupts. Here's what I see on the scope.
This still image probably needs a little explanation. A video probably would be better, but you're going to have to use your imagination to visualize the pulse jumping round. I tried to capture it as best as possible using the scope's variable persistence setting.
The important point is the delay between the rising edge and the pulse varies. It's *usually* just a little over 200 ns (1 division on this horizontal scale), but it sometimes is as much as ~350 ns.
This sort of variability is very hard to see with a logic analyzer. You'd need to perform dozens, maybe hundreds of trials and somehow composite them. Of course, with good oscilloscope the screen shows every run as the PWM exercises the code hundreds of times per second.... so we see a bright blue waveform where the pulse is most of the time, and faint blue shadows that appear to bounce around for the unusual cases where bus latency of some other effect caused the interrupt to have more latency.
Unfortunately, there is quite a bit of variability in the latency (and a *lot* more without the NVIC priority setting). I'm afraid the worst case is quite far beyond the 220 ns you wanted.