Time beween pulses

[Arthur Caio]

Hello you all!

I need to calculate hot much time it takes for an input to go from LOW to HIGH and then to LOW again. Basically, I want to know the period of a square wave generated by the LM555 timer.

I am using Qt Creator and programming in C++.

I am having trouble at programming this code in C++ for the beaglebone.

Do you guys have any piece of code in C++ that may help me?

Than you very much

[Dennis Lee Bieber]

On Wed, 19 Oct 2016 16:50:14 -0700 (PDT), Arthur Caio
<art...@gmail.com> declaimed the following:

>Hello you all!
>
>I need to calculate hot much time it takes for an input to go from LOW to
>HIGH and then to LOW again. Basically, I want to know the period of a
>square wave generated by the LM555 timer.
>

Do you have some idea of what range the 555 is operating within?

I ask as a benchmark program I've been running on various boards
includes a step that determines the apparent resolution of time available
to the program -- and for my runs, the average as I recall (C
gettimeofday() is used by the program) was around 5uSec (I can't be more
precise as the data files are at work). That alone translates to a 200kHz
clock.

There are, no doubt, faster ticks available at a lower level of
programming.

>I am using Qt Creator and programming in C++.
>
>I am having trouble at programming this code in C++ for the beaglebone.
>

If using a polling loop with the file system access, you may be limited
to quite slower rates. The /sys filesystem is much too slow for precise
timing -- what with having to loop over open(), read(), close() while
looking for a state change.

MMIO (based upon a library for the DHT11) might be fast enough to
detect the transitions -- but then you have to worry about the resolution
of your accessible time base/counter (the DHT11 library didn't even bother
with timers -- the protocol is based upon short and long HIGH, with a fixed
length LOW, so it just counted loop cycles to compute a median, and
anything less than median was a short/0, anything longer than median was
long/1).

--
Wulfraed Dennis Lee Bieber AF6VN
wlf...@ix.netcom.com HTTP://wlfraed.home.netcom.com/

[William Hermans]

I do not personally know of any code for this specific case. However, and with that said. Your best bet aside from writing a Linux module specifically for this is to use and interrupt, and some form of Linux time API call.

As for userspace interrupts. This is not really possible. As this would slow down the OS too much because of application context switching. However, there is something very close to just as good. For this from a userspace application. You can setup a blocking read form the sysfs gpio "value" file. Like so:

 $ ls /sys/class/gpio/gpio2
active_low  device  direction  edge  power  subsystem  uevent  value

This is actually more complicated than it may seem initially however. As I believe poll(), and select() both will return immediately if you do not configure the "edge" file correctly. Instead of repeating what's already been described on the internet, I'll leave you with this link, which describes it this very well I think: https://www.linux.com/learn/beaglebone-black-how-get-interrupts-through-linux-gpio

Then once you have that figured out, all you really need is a before, and after timestamp. Which is described very well in the multiple answers to this stackoverflow question; http://stackoverflow.com/questions/11765301/how-do-i-get-the-unix-timestamp-in-c-as-an-int

[William Hermans]

Additionally, I'm not really sure if the above description I gave will be fast enough, If you're very careful in how you structure your code, and making sure not to use function calls that switch back and forth between userspace / kernel space. I think it could be. However, if it is not fast enough still, you can use one of the PRU's to trap interrupts on a pin. But here the only missing piece I am not sure how you could generate a time stamp in a timely fashion. No pun intended.

Something to be aware of. If you're going to use something like printf(). That would definitely slow down such an application. *UNLESS* you were to pipe the output of that application to a file. LIke: ./foo > somefile.txt

[William Hermans]

Oh, and right. For all intents and purpose concerning application performance. cout with C++ and printf() in C would roughly be the same.

[Charles Steinkuehler]

On 10/19/2016 6:50 PM, Arthur Caio wrote:
> Hello you all!
>
> I need to calculate hot much time it takes for an input to go from LOW to HIGH
> and then to LOW again. Basically, I want to know the period of a square wave
> generated by the LM555 timer.

Use an eCAP timer input pin. That's what the eCAP capture-compare
timers are for...they capture the rising and/or falling edges of
signals and record the time it happened with up to 5 nS resolution.

--
Charles Steinkuehler
cha...@steinkuehler.net

[TJF]

eCAP is the right module to use.

Am Donnerstag, 20. Oktober 2016 12:22:36 UTC+2 schrieb Charles Steinkuehler:

... record the time it happened with up to 5 nS resolution.

The resolution is up to 10 nS (100 MHz clock), so the maximum frequency is 50 MHz.

Find a code example (C syntax) in libpruio package, documentation here.

Regards

[Charles Steinkuehler]

On 10/20/2016 12:44 PM, TJF wrote:
>
> eCAP is the right module to use.
>
> Am Donnerstag, 20. Oktober 2016 12:22:36 UTC+2 schrieb Charles Steinkuehler:
>
> ... record the time it happened with up to 5 nS resolution.
>
> The resolution is up to 10 nS (100 MHz clock), so the maximum frequency is 50 MHz.

Oops...I've been using the eCAP in the PRU sub-system, which does have
5 nS resolution (200 MHz clock). I forgot the normal system timers
have a slower 100 MHz clock, so only 10 nS resolution.

Still *WAY* better than anything a software loop can mange! ;-)

--
Charles Steinkuehler
cha...@steinkuehler.net