How to capture on the scope the SINGLE square wave from ON to OFF?

Go To Last Post
10 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

 

I am trying to time a block of code using my Raspberry PI 3b+ running at 1.2Ghz.  The easiest way for me to do is to put out a HIGH on a GPIO pin.  Then time the block of code that I want.  Then put out a LOW on the GPIO pin.  The delta time shown on the scope from HIGH to LOW on the GPIO pin should tell me how long that block of code took place.  I am using the ATTEN ADS1102C 100Mhz scope.  (https://www.sparkfun.com/product...).

 

I am having a hard time setting up the scope to capture the below one cycle of square wave.  I setup my trigger as a pulse, but no luck.  THANK YOU for any tip from scope gurus on how to do this, especially with the ATTEN ADS1102C scope.  The scope's manual is at http://cdn.sparkfun.com/datashee...(1.3).pdf.  I am NOT being lazy of not reading the manual here.  Stuck even going through the manual.

 

 

Delta T is what I want.

 

                     Delta T     

                   <-------->

                    _______

                   |            |

                   |            |

                   |            |

                   |            |

---------------             ---------------------

 

 

 

 

Attachment(s): 

Last Edited: Wed. Jun 1, 2022 - 11:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Use triggered mode. Delay should allow you to see ahead of the trigger point. For the signal you show, rising edge trigger should do it.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Last Edited: Wed. Jun 1, 2022 - 09:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:

Use triggered mode. Delay should allow you to see ahead of the trigger point. For the signal you show, rising edge trigger should do it.

 

Jim

 

Is that possible with a 100Mhz while my code runs at 1.2Ghz?  My 100Mhz scope has the horizontal time div of lowest setting of 2.50ns, and it can't catch the square period generated by asserting a HIGH then LOW on the GPIO pin, since the code executes so fast.  When I made the horizontal div of, say 10.0s per div, yes, I do the see the square period.  However, at this point, the timing granularity is too large to know the exact time.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

unebonnevie wrote:
I am trying to time a block of code using my Raspberry PI 3b+ running at 1.2Ghz.  The easiest way for me to do is ...
read the APU's cycle counter (monotonic); clock generator is likely PLL from one crystal so will be reasonably accurate.

monotonic · PyPI

Monotonic timestamps in C# · antonymale.co.uk (Windows)

Linux likely has monotonic time though IDK the particulars.

Monotonic Time (Ada2012 Reference Manual)

https://github.com/AdaCore/bb-runtimes/tree/community-2021/aarch64/rpi3

 

edit : maybe the CMSIS physical counter

https://www.keil.com/pack/doc/CMSIS/Core_A/html/group__PL1__timer__functions.html#gac66bd336d2353f70aa8ebfc73aa3fc43

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Thu. Jun 2, 2022 - 01:46 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If pulse width is an issue, then say so, up front. Why hide things? Is the counter or logic that generates that pulse really running at 1.2GHz? If so, and it is important, then figure out how to get your hands on a fast scope or logic analyzer. If you can't, then you can't, and move on!

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Last Edited: Thu. Jun 2, 2022 - 01:44 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Make sure scope is set to DC mode & DC rising rigger  Make sure the trigger level is set correctly.  You prob want rising edge trigger.   Do NOT use autotrigger mode, unless you have repeating pulses.

 

Before messing with this pulse use the scope's probe cal signal pin (they usually have one) to experiment with triggers, etc.

 

The RPI GPIO  makes waveforms "very slow " with python...so you will prob be able to see it.  

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Two more thoughts in addition to the above:

 

I don't use the Simulator, but I believe from other posts it can count the number of clock cycles in a block of code.

Knowing your micro's clock frequency, you then know the execution time.

 

Another option would be to put the block of code in a loop, and time 100 times through the code, (for example).

That doesn't give one an exact time, but it can be pretty close if the block of code is significantly longer than the loop overhead.

 

(Or just in-line copy several copies of the code, to lengthen the block of code.)

 

Recall, also, that if the block of code is an ISR, then using an O'scope to time the ISR's block of code is also an approximation.

It will skip the time for the PUSHes and POPs at the start and end of the ISR, as your pin setting and clearing takes place inside this ISR overhead.

 

JC 

 

 

Last Edited: Thu. Jun 2, 2022 - 03:03 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If the trigger mode is set to 'auto', then odds are the scope does trigger on the pulse but the data subsequently gets over written before you get a chance to look at it. You can try using 'normal' trigger mode. That will not over write data until another trigger occurs. Alternatively, use 'single' trigger mode (button in the upper right corner.) In that mode, the scope will trigger once then stop. If you want to trigger again, press 'single' again.

 

Set the scope to trigger on rising edges.

Brian Fairchild wrote:

It's at this point that we really do need the OP to come back and engage with us. So many questions..........

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DocJC wrote:
Another option would be to put the block of code in a loop, and time 100 times through the code, (for example).

That's probably not useful, especially if the code doesn't itself loop much. The first time the code is executed could be quite slow but subsequent runs could exhibit significant speed increase due to CPU and DATA cache.

 

The CPU hi-res timer counter may be worth investigating, but Linux has many CPU Profiling Tools available so you don't have to "roll your own".

 

I found this interesting blog: http://euccas.github.io/blog/20170827/cpu-profiling-tools-on-linux.html

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Good point!

 

I was thinking AVRs... but this is an RPi question!

 

JC