After spending a lot of days trying to make eCAP modules to read (not generate as everyone does) a PWM signal (period+duty cycle), I have to ask:
Someone has made this functionality works? Can be via sysfs, via PRU program handling the register, via CPU program handling the registers, or any other method?
If yes, can give me an example or the environment details?
PS: eCAP module is the most undocumented function of Beaglebone…
You’re correct, eCAP is pretty much undocumented and unsupported.
Find examples in the libpruio project at
The first example measures a pulse train generated by a PWM subsystem output (31 kHz), and the second measures a pulse train generated by PRU firmware (20 MHz).
We had an awesome university student Darren Schachter participating in
Major League Hacking  last summer write a eCAP kernel driver for
the iio subsystem . It has progressed beyond the initial review
but you should find it to be useful.
Robert - are you building that driver in our beaglebone kernel?
*It has _not_ progressed beyond the initial review [..]
sorry for the typo,
As Drew mentioned, I worked on a driver for eCAP support last summer.
I submitted a preliminary patch to mainline Linux for this driver and
received some feedback. Unfortunately, around that time, my classes
started again and things got very busy so I have not yet had a chance
to implement the requested changes. However, the driver itself is
fully functional -- the feedback mostly centered around formatting /
adopting newer Linux IIO standards. I hope that the driver code is
still useful. Please feel free to reach out to me if you have any
questions about it.
Adafruit_BBIO has some type of example plus the library has its
The eQEP is a different creature from eCAP.
eQEP is to read quadrature encoded inputs (rotary knobs producing two
step waveforms in which the changes between the two identifies which
direction the knob is rotating, and how far it has been turned). From the
BBB TRM (SPRUH73P)
A single track of slots patterns the periphery of an incremental encoder
disk, as shown in Figure 15-130. These slots create an alternating pattern
of dark and light lines. The disk count is defined as the number of
dark/light line pairs that occur per revolution (lines per revolution). As
a rule, a second track is added to generate a signal that occurs once per
revolution (index signal: QEPI), which can be used to indicate an absolute
position. Encoder manufacturers identify the index pulse using different
terms such as index, marker, home position, and zero reference.
eCAP is, as the TRM describes it
184.108.40.206 Purpose of the Peripheral
Uses for eCAP include:
• Sample rate measurements of audio inputs
• Speed measurements of rotating machinery (for example, toothed sprockets
sensed via Hall sensors)
• Elapsed time measurements between position sensor pulses
• Period and duty cycle measurements of pulse train signals
• Decoding current or voltage amplitude derived from duty cycle encoded
To clarify for anyone finding this thread in the future.
eQEP (encoder input) driver is in mainline Linux kernel thanks to David Lechner:
eCAP (pulse input) driver is available as patch posted by Darren
Schachter that is known to work:
… and - to be complete - that proven eCAP + eQEP features - well documented (including example code) and with similar programming interfaces (not changing in new kernels) - are available in libpruio since years at