Timers in beaglebone green

Hi everyone. I need to measure the frequency with a BeagleBone (400 kHz) and for this I would like to use the BeagleBone timers (F = 1/((timer1+timer2)/2)). The beaglebone has four timers (TIMER4, TIMER5, TIMER6, TIMER7). But I can’t find how to read the timer value. I found how to do this only for the 3.8 kernel, and the osp.3 file is missing in the fourth kernel (GitHub - ddrown/pps-gmtimer: Linux kernel module PPS Client Driver using OMAP Timer hardware).

PS: I would like to measure the frequency using timers without installing any additional libraries. But if it is not possible to do this with the help of timers, then please tell me how can such a frequency be measured at all?

We have overlays for these 4 timers…

Edit, sorry, that’s only for pwm output…

Wonder if the counter supports this yet…


@RobertCNelson I’m sorry, I understand you correctly that with this code I can read the value of timer 4-7?

Hi @BONKoff no i messed up, when i initially replied, i was thinking… Timer…PWM…

So only PWM works today… i don’t know if anyone tried to do a counter option on mainline yet…


@RobertCNelson , wow, I found little information on the Internet, how to measure the frequency using a timer4-7 (https://github.com/ddrown/pps-gmtimer). If no one here knows how to do it… Then I will collect kernel 3.8 or look for another way (without use beaglebone, mabe). Thanks for the answer.

P.S.: Beaglebon can measure such a frequency?(400KHz). Are there built-in tools for this (maby not timer, maybe something else)?

Hardware-supported frequency measurement is also available in the CAP and QEP modules in the PWM subsystems. That’s on P8_12, P8_35, P8_41, P9_28, P9_42 (and SD_10), so six channels in total.

Find details at

@DTJF , as I understand it, these actions are performed using a non-built-in libpruio library. But I’m interested in solving this problem using the built-in beaglebone development tools. Anyway, thanks for the answer.

@JCarlton the kernel module for libpruio is shipped and installed by default… (since like forever, in every kernel build for the bbb…)


The library is working in a few thousand projects all over the world.

This looks pretty awesome from the surface … Do you want this included the default image? (Jason Kridner, 09.05.2014, 17:42:50)

Everything is prepared, just ask Robert to build the tool in … or feel free to invent the wheel twice.


@DTJF it’s the master branch of this repo right https://github.com/DTJF/libpruio ? at this point it should just be installed by default… Today’s looking busy so it wouldn’t be till later tonight…


The branch is correct. One more night doesn’t matter. The users are waiting since 2014.

Do not hasitate to ask for support, if required.


@RobertCNelson, sorry for another question, but what parameters should I pass to CapMod::Value() and CapMod::config().
I enter CapMod::config(), but the BB is waiting for input.
Could you show an example of values? Or I misunderstood how to work with СAP?

Robert isn’t keen on using that lib.

What’s wrong with the documentation? Just click on the links:
example code

@DTJF , nothing wrong. This is good documentation. But still, I would like to clarify what is “Ball The CPU ball number to configure”.
Your links also do not provide a concrete answer to my question.

For beginners a ball is a header pin. That’s explained in the first section on that page. For experts ‘ball’ indicates that libpruio can also control internal lines, ie the user LEDs or pins at the JT header/in the SD card slot. That terminology is from the CPU docs, read there for further information.

Who can provide concrete answers without knowing the programming language you’re refering to? The parameters vary depending on the API (C, FreeBASIC or Python).

Since you’re refering to an OOP member function, I guess you don’t use C. In that case you need two parameters

  1. Ball: The pin to wire the frequency signal (P9_28, P9_42, SD_10 → see table).
  2. FLow: The smallest frequency (timeout in case of no input).