Can't detect short pulses with GPIO

Troubleshooting
22

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.

23

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.

24

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.

25

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

26

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

27

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

28

Thanks. Good idea with the PWM.

29

If I just poll the pin normally,

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

I get a 2.36ms delay.

30

EDIT: comments removed to avoid confusion :slight_smile:

31

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

32

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

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
34

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
35

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

36

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.

37

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?

38

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

39

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.

40

@Arthur_dent_42_121, so a reflow oven is not ideal then? It sounds like the best approach is oven for everything else and hot air for P1, correct? How are you heating it - from the sides, top…?

41

A reflow oven would be much, much better. As long as you have a known amount of solder paste and the P1 is perfectly aligned, if you heat it up gently and do not move it on the board while it’s hot, I’m sure it would be fine. The main reason why I’m having trouble is because I need to manually re-position the IC on the board because the airflow of the hot air gun shifts it around a bit. When I do that, and it’s already a bit warm, everything on the P1’s board just slides off.

I’m heating from the top. I haven’t tried heating from the bottom- might be a bit easier, actually.