digitalFastWrite not working on Teensy 3.2

[kalle_wirsch]

Sorry for another very basic question. Because digitalWrite() is not very fast with the Teensy 3.2 (about 400 ns) I replaced it with digitalFastWrite(). But it did not work and I made some basic tests to understand what's going on.

This very simple program

void setup()
{
  pinMode(2, OUTPUT);
  test();
}

void test()
{
  while(true)
  {
    digitalWrite(2, LOW);
    digitalWrite(2, HIGH);
  }
}

void loop()
{
}

produces this output (Ok, that's my expectation).

View attachment 15670
(Sorry, inserting of images does not work in this forum. See first attachment)


Then I tried this:

void setup()
{
  pinMode(2, OUTPUT);
  test();
}

void test()
{
  while(true)
  {
    digitalWriteFast(2, LOW);
    digitalWriteFast(2, HIGH);
  }
}

void loop()
{
}

and I got this:

View attachment 15671
(Sorry, inserting of images does not work in this forum. See second attachment)

So, what's going on her?

 

[PaulStoffregen]

I can't see your attachments, but I'm pretty sure you're seeing the effect of the slew rate limiting feature.

I can your program. Here's what my scope sees.



By default pinMode configure the pin with a feature called slew rate limiting. It slows the rate of voltage change slightly. Normally this is a good thing, because it greatly reduces noise and signal quality issues, especially if you connect wires longer than about 1 inch without a ground plane (like a 4+ layer PCB).

But if your code tries the change the pin very quickly, as you can see the result is the voltage can't change all the way from high to low before it starts going back to high again.

Here's your program with 1 line added to turn off the slew rate limit feature.

void setup()
{
  pinMode(2, OUTPUT);
  CORE_PIN2_CONFIG &= ~PORT_PCR_SRE;
  test();
}

void test()
{
  while(true)
  {
    digitalWriteFast(2, LOW);
    digitalWriteFast(2, HIGH);
  }
}

void loop()
{
}

This is the result I see on my scope.



Obviously this looks much better if you really did want to create a 20 MHz waveform. But if you don't take care to use proper grounding or shielding, this sort of waveform connected to a wire several inches long can radiate quite a lot of RF interference. The huge current needed for driving those very fast changes into the capacitance and whatever "antenna load" the wire creates can also put quite a lot of extra noise onto the power supply. If you really do need this, you can get it from the hardware - but those bad side effects are the reason why the default setting enables the slew rate limiting hardware.

 

[PaulStoffregen]

Ah, for some reason now I can see your attachments. On top of these high speed issues, I'm going to guess your scope isn't fast enough to see those ~40ns pulses.

Here's one more capture with the slew rate limit turned on, and the scope zoomed out to a wider time scale (similar to what you used)



This ~0.8us pulse where the signal is low is due to one of the interrupts (likely systick) causing the main program to stop momentarily.

Before the program stopped, and after it resumes, you can see those half-pulses from 3.3V down to ~1.8V due to the slew rate limiting. Those are the digitalWriteFast changing the pin, but it's not able to change all the way due to slew rate limiting.

Those little half pulses are missing from your image. I can also see the corners where the pulse hits 0V and where it goes high again aren't sharp in your capture. These differences are very likely due to lack of sufficient bandwidth, either in your scope or in its probes (eg, using 1X probe instead of 10X).

You need a pretty good scope to see these sorts of very short pulses. I don't recognize which one you have from that image. We've seen plenty of issues before on this forum "USB scope" products from some vendors like Hantek.

 

[kalle_wirsch]

Ah, for some reason now I can see your attachments. On top of these high speed issues, I'm going to guess your scope isn't fast enough to see those ~40ns pulses.

Yes, sorry. I had some problems with the forum editor and edited the posting several times.

Ok, 40 ns. I did not expect the Teensy to be this fast and that explains why my low cost Hantek scope can not handle it.
So the noise I see in my signal is the frequency from the Teensy and the few visable pulses are caused by interrupt delays?

Thanks for the explanation. Also for the quick answer concerning my question about the timers.