Can't detect short pulses with GPIO

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?)

Maybe @peekay123 or @BDub can help out with a P1.

I don’t have a photon, unfortunately.

I have tracked down the problem a bit more. Ran this code:

void setup()
{
  pinMode(D0, OUTPUT);
  digitalWriteFast(D0, HIGH);
  pinMode(D1, OUTPUT);
  pinMode(D3, INPUT);
  attachInterrupt(D3, interruptHandler, CHANGE);
}

void loop()
{
}

void interruptHandler() 
{
  digitalWriteFast(D0, pinReadFast(D3));
}

And then shorted D3 high.

I got a… wait for it…

1.25ms delay before D0 went high.

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.

void setup()
{
  pinMode(D0, OUTPUT);
  digitalWriteFast(D0, HIGH);
  pinMode(D1, OUTPUT);
  pinMode(D3, INPUT);
  attachInterrupt(D3, interruptHandler, CHANGE);
}

void loop()
{
}

void interruptHandler() 
{
  digitalWriteFast(D0, pinReadFast(D3));
}

By the way, thanks for all the help, everyone. This is an awesome community.

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%.

Do you know if there was a batch of P1s made with an 8khz oscillator? :grinning:

@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.

Thanks. Good idea with the PWM.

If I just poll the pin normally,

void loop()
{
    digitalWriteFast(D1, pinReadFast(D3));
}

I get a 2.36ms delay.

EDIT: comments removed to avoid confusion :slight_smile:

@BDub, interrupts not working on D3/4/5 IS a real issue!! Can you setup a PWM pin an connect that as the D5 interrupt trigger and report on the delay?

@Arthur_dent_42_121, if you are not using a non-AUTOMATIC system mode, some of that 2.36ms delay is probably caused by the cloud routines.

But the remaining rest is still odd and Brett migh have found some issues here.

1 Like

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 :blush: Was using the wrong pins entirely!

Should of grabbed my Sparkfun P1 Redboard :smile:

One sec while I go back to square one with interrupts.

4 Likes

Ok this code works fine on my P1 breakout… the D7 pin toggles about 1us after the D5 input rises.

void setup()
{
    pinMode(D7, OUTPUT); // JTAG_TMS
    digitalWrite(D7, HIGH);
    
    pinMode(D5, INPUT); // JTAG_TDI
    attachInterrupt(D5, myHandler, RISING);
}

void loop()
{
}

void myHandler() 
{
    digitalWriteFast(D7, !pinReadFast(D7));
}

Code like this is not going to be very predictable, since the D5 input may not hold the same state for very long.

void myHandler() 
{
    digitalWriteFast(D7, pinReadFast(D5));
}
3 Likes

@BDub, any chance you can use a PWM output as the trigger instead of a single shot event? :wink:

I’m going to try another P1 chip, there’s probably something wrong with this one if two people can’t reproduce the problem. One sec.

Well, I cannot begin to comprehend what sort of problem would cause the P1 to work perfectly but slow all I/O down, but I just put a new P1 on a bare board and:

Problem solved. Thanks so much everyone for all the help.

Edit:

This new chip has firmware V4.6. I manually downgraded the old one to V4.5. Did I botch the downgrade somehow?

@Arthur_dent_42_121, may I ask how you put the P1 on a bare board? More specifically, how did you reflow it?

I used a hot air gun for this. Soldering these things is really annoying, because if you move it at all while heating it, the shield and everything inside slides right off the P1 board. I’ve gone through about 5 P1s trying to seat it properly. I was using the P1 on a product we’re developing, so I had a few bare boards left.

However, it’s well worth the added soldering annoyance. Having an fcc-certified wifi chipset and micro for $10 is amazing.