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
On Wed, 19 Oct 2016 16:50:14 -0700 (PDT), Arthur Caio
<arthuki@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).
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
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
Oh, and right. For all intents and purpose concerning application performance. cout with C++ and printf() in C would roughly be the same.
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.
eCAP is the right module to use.
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! 