Forum Rule: Always post complete source code & details to reproduce any issue!
Page 2 of 2 FirstFirst 1 2
Results 26 to 31 of 31

Thread: STRANGE GPIO speed perfomance with digitalWriteFast() (ring oscillator example)

  1. #26
    Senior Member KurtE's Avatar
    Join Date
    Jan 2014
    Wondering out loud,

    Would it make sense to use BITBAND to do digitalReadFast?

  2. #27
    Quote Originally Posted by PaulStoffregen View Post
    Here's one more try to see the 120 MHz waveform. Same setup as #20. This time, I took the spring clip off the scope probe and touched the probe point directly to pin 14. Then I used the lead of a resistor to short from the GND pin next to pin 13 to the ground shield of the scope probe, which makes a *huge* improvement, much less overshoot & undershoot.

    Attachment 9579

    Of course, my scope is still only 200 MHz bandwidth. Not much I can do about that!
    Paul, looking at your waveforms here, as compared to post #18, it's "quite obvious" you've greatly reduced the ground bounce by using the short stub ground lead. For reference, you can take a look at the following youtube, starting at 8:40 to 9:20.

    Even without going to a faster scope, you can view the separation between response and complication due to ground bounce simply by making your pulses longer and with a delay in between them. With the longer ground lead, the ground bounce will be an obvious superposition on the signal.

    EDIT: also, if you approximate the front-end of a 200-MHz scope as a basic RC low-pass filter, then the signal risetime can be approximated from F=1/(2*pi*RC), where RC = the time-constant Tau [0..63%]. IE, Tau ~ 0.8 nsec in this case, and the rise-time would be a bit longer. So, you should be seeing something on this order.
    Last edited by oric_dan; 02-10-2017 at 12:54 AM.

  3. #28
    Quote Originally Posted by PaulStoffregen View Post
    Here's a quick test, running on a Teensy 3.6 running at 180 MHz CPU speed.

    You'll notice I put 8 digitialWriteFast() in a row. This should take advantage of the hardware's optimization for faster access on successive STR instructions.

    void setup() {
      pinMode(14, OUTPUT);
      CORE_PIN14_CONFIG = PORT_PCR_MUX(1); // no slew rate limit
      noInterrupts();  // look pretty for the oscilloscope trigger
    void loop() {
      while (1) {
        digitalWriteFast(14, HIGH);
        digitalWriteFast(14, LOW);
        digitalWriteFast(14, HIGH);
        digitalWriteFast(14, LOW);
        digitalWriteFast(14, HIGH);
        digitalWriteFast(14, LOW);
        digitalWriteFast(14, HIGH);
        digitalWriteFast(14, LOW);
    Here's what I see on my oscilloscope.

    Attachment 9576
    (click for full size)

    Looks like each digitalWriteFast really is taking only a single cycle, since two of them occur in ~11ns. But the loop & other overhead takes about 22ns. In practice, you can usually only get these incredibly fast speeds in bursts.
    Yes, this is the obvious way to see where the delays are. It shows that the pulses are very fast, and while-loop overhead is quite short. You could also, of course, show the overhead in the main loop() function by using the same sequence of 8 fast writes but remove the while statement.

    Personally, I see these speeds as phenomenal as compared to the other microcontrollers that I've been using for some years, :-).

    One additional thing. The guy doing the measurements on the page originally cited didn't seem to have a very good grasp of using proper scope probe grounding [ie, properly short ground leads], as mentioned in the other posts.

    However of interest, his traces do show a certain amount of overshoot on the leading edge of some of the signals. I would be interested to see what longer pulses [eg, 1-usec, etc] look like on the Teensy with the present setups. Overshoot or no.

    If overshoot, a good way to deal with such ringing is to use "source-series termination", ie try the same measurement with a 22 or 47 ohm series-R tied directly at the I/O pin with very short lead between the pin and resistor body. Try metal-film R.

  4. #29
    This thread made me wonder how MY scope would compare so I just had to try a test.

    As always, the first issue is how do you actually probe the signal without having the scope probe ground lead ruin your measurement ?? I found an interesting article on a simple probe technique that suggests you can get a good very high bandwidth probe without introducing significant ground inductance AND without spending a ton of money.

    See Probing High-Speed Digital Designs at for some background and ideas.

    I built the suggested 21:1 Probe and attached it to the Teensy 3.6 pins 14 and ground as Paul did above.

    Click image for larger version. 

Name:	HighSpeedProbe.jpg 
Views:	18 
Size:	92.2 KB 
ID:	9664

    I then ran the four pulse test program from #18 above. My Agilent MSO-X 3024A 200MHz Scope is similar to Paul's but I wanted to see what my new probe would do. This is what I saw when running the Teensy 3.6 at 180MHz. Overclocking to 240MHz produced similar looking results with just the expected faster pulse time.

    Click image for larger version. 

Name:	t36_180mhz_4pz.png 
Views:	34 
Size:	37.9 KB 
ID:	9665

    The trace was much "smoother" than I expected so I decided to dig in the back room and resurrect an old HP 500MHz scope and do a quick compare. The HP54503A is a really old dog but is kinda fun to use AND its timebase will go down to 200ps per division!! This is a 10x faster horizontal sweep than my newer scope will go. It has been left in the dust by newer scopes but my budget does not allow....... It's inputs have not been calibrated for sometime so we should take the risetime response with a little grain of salt but the Teensy 3.6 Overclocked to 240Mhz measurement is interesting.

    Click image for larger version. 

Name:	HP54503.jpg 
Views:	42 
Size:	115.8 KB 
ID:	9666

    Perhaps someone with a "real" scope will add to this adventure.
    Last edited by drmartin; 02-11-2017 at 07:24 AM.

  5. #30

    Question Teensy 180 Mhz GPIO performance

    Quote Originally Posted by Frank B View Post
    I'm wondering for which "real-world" application, pin-toggle "as fast as possible" is useful ? And if yes, why it has to be done in software, not hardware (for example SPI, I2S.., external oscillator..)

    For me, it's a pretty useless kind of benchmark..
    Hi Frank,

    I am doing this on the Raspberry Pi in order to utilize the pins as a bus to communicate with other devices faster than the different serial protocols allow. On the Pi 3, for example, I can achieve approximately 60 Mhz via GPIO by setting the 32-bit register directly. However, I am currently utilizing one of the cores for this and I would like to free the full Pi up for other purposes so I would like to offload this functionality to a 180 Mhz Teensy. Have you been able to benchmark the maximum toggle speed on a 180Mhz Teensy? If so I would appreciate a post of your results as I'd like to see whether the speeds are sufficient for my needs.

    Many thanks in advance!


  6. #31
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Quote Originally Posted by AnthonyPaulO View Post
    Have you been able to benchmark the maximum toggle speed on a 180Mhz Teensy?
    The answer is yes. Yes, we have been able to benchmark this.

    Please read the prior messages in this thread. You'll discover they are indeed benchmarking the maximum pin toggle speed, at 180 MHz and overclocked to 240 MHz.

    I recommend reading carefully about some of issues with how the compiler implements loops and allocates registers. All benchmarking has caveats, and in this case those are pretty big ones. There's a lot of good info in this thread. Please, read it.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts