PulseIn function

[Arthur Caio]

Hey everyone,

I have a project with a LM555 timer and need to calculate how 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 did it with Arduino using the function Pulseln. But I need to do this using a Beaglebone and programming in C++ (Using QtCreator).

Is there a way to "open" the function PulseIn so I know what it does? Moreover, do you guys have any piece of code that might help me?

Thank you in advance.

[Dennis Lee Bieber]

On Sun, 23 Oct 2016 13:30:55 -0700 (PDT), Arthur Caio
<art...@gmail.com> declaimed the following:

>Hey everyone,
>
>I have a project with a LM555 timer and need to calculate how 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 did it with Arduino using the function Pulseln. But I need to do this
>using a Beaglebone and programming in C++ (Using QtCreator).
>
>Is there a way to "open" the function PulseIn so I know what it does?

Sure... On my install it is found in:

C:\Apps\Arduino169\hardware\arduino\avr\cores\arduino\wiring_pulse.c

Though it invokes a hand-tweaked assembly routine for the main loop, in
wiring_pulse.S (for the AVR).

Strange -- I have all the boards installed in the board manager, but
can't find any files specific to the others.

>Moreover, do you guys have any piece of code that might help me?
>

You need to take into account that the Arduino is a microcontroller
(Atmel AVR for the most part -- the Due is an ARM M3, Zero is an ARM M0) --
you have direct access to the hardware I/O pins. The Beaglebone is a level
higher, using an ARM A-series (application, not microcontroller) processor
under an operating system.

The common pin access is via OS maintained "device files" (they act as
files to the user, but aren't real files on storage), and one uses plain
POSIX/C I/O calls to open/read/close those files. That throws in a lot of
overhead and latency. Enough overhead that common DHT11/DHT21 humidity and
temperature sensors can not be read (they use a weird protocol where 1 and
0 are determined by the length of HIGH following a start-of-bit LOW [1 is
~80uSec, 0 is ~24uSec]).

The next step up is the MMAP process -- where you directly map the
device registers into your program's address space, bypassing the OS file
system. You'll need to study the register layout to find which registers
control the pin you intend to read. You'll still be subject to OS
interference (it could swap your process out to run some other background
operation).

The third step is to write the pulse sampling code using the PRU (which
is a sort of microcontroller hiding in the same processor chip), and use
some form of IPC to have the main code tell the PRU to sample a pulse, then
send the result back to you.
--
Wulfraed Dennis Lee Bieber AF6VN
wlf...@ix.netcom.com HTTP://wlfraed.home.netcom.com/

[Jason Kridner]

There is pulse measurement hardware in the eCAP. 

Matt Porter submitted a kernel patch way back when: https://lkml.org/lkml/2014/1/29/413 

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/gcsr0cdv9au5ofbkulsddptjjfvcjohehd%404ax.com.
For more options, visit https://groups.google.com/d/optout.