I get a signal-response delay of 800ns and can pick up and mirror a 200kHz 20% to 80% duty cycle square wave. When I change the duty cycle below 20% or above 80% the interrupt seems to stop being triggered.
Just a very heretic thought Could you double check if you’ve got the correct pins wired - I just tried another Photon and got odd readings, till I relized I was checking triggering D2 and had D3 floating (INPUT instead of INPUT_PULLDOWN)
Yup, the code I tested above was yours, with my triggering code.
In regards to your previous comment, I have confirmed that the pin I’m using is the right one, and I’ve tried using a different one.
D1 drives a h-bridge at 40khz, sending an ultrasonic ping out of a transducer. This bounces off a wall and goes into another transducer. Then, I have a notch filter and a two stage amplifier that brings the recieved pulse to 3.3v amplitude so we can detect it on D3 digitally. DAC1 sets the threshold on a comparator on the receiver.
I’m very puzzled about this and since I can even reduce to delayMicroseconds(1); and still get a near perfect mirror response on my Photon(s), I’d have to hand this over to someone who can test this on a P1 (or have you got a Photon you could repeat your tests?)
I'm not sure if this will help, but I implemented pulseIn() with interrupts like this:
Also, and non-interrupt driven pulseIn() will be available in 0.4.7 firmware.
I'm not exactly sure what you'd like me to test, can you spell it out please?
Also, digitalWriteFast(D0, HIGH/LOW) is not as fast as pinSetFast(D0) and pinResetFast(D0). If I remember correctly it's about 5 times slower at 200ns or so vs 41ns.
Just as a quick test, could anyone try uploading this code on a p1 or a photon, shorting D3 high, and see what the delay is before D0 goes high? I don’t know if it’ll be constructive, but I’m getting crazy delays of milliseconds or more before it fires the interrupt.
Brett, when I test the above code on my Photon (0.4.6) I see exactle the behaviour I’d expect (ignoring the speed gain with pin(Re)SetFast() rather than digitalWriteFast()) but Daniel can’t get anywhere near that behaviour with his P1.
What could be the reason for that?
@Arthur_dent_42_121, as said with my tested two Photons (0.4.5 & 0.4.6) I only get a delay of about 800 nano seconds - most of that probably cause be the reading of the pin state.
Just flipping a pin was 360ns, and given Brett’s advice this could be cut by another 70%.
@Arthur_dent_42_121, I have a P1 board I can test tonight. I’ll report back then. Shorting D3 seems less than ideal due to bounce. It may be better to use a PWM output pin as the trigger source to do the measurement. I’ll give that a shot.
Haha… I’m using a P1 break out board and none of the pins are labeled like D0-D7, they are all JTAG_TMS… etc… well there are two JTAG interfaces, ML_JTAG_TMS and M_JTAG_TMS… so, that’s why NOTHING is working Was using the wrong pins entirely!
Should of grabbed my Sparkfun P1 Redboard
One sec while I go back to square one with interrupts.