BeagleBone Encoders

GoogleGroups
1

This is a heads-up to anyone working on BeagleBone based interfaces for
LinuxCNC. I am working on code to support encoders on the BeagleBone,
allowing true servo operation (within limits). Encoders can be
supported on the BeagleBone via hardware or software (via the PRU).

There are three hardware encoders on the BeagleBone:

* eQEP2, on P8 pins 11, 12, 15, 16

* eQEP0, on P9 pins 25, 27, 41.1, 42.1 (BeagleBone Black only)

* eQEP1, on P8 pins 31, 31, 33, 35 (conflicts with HDMI)

The eQEP2 pins conflict with the typical BeBoPr step/dir pinout (re-used
by several CNC capes), but could be used if desired, since step/dir pins
from the PRU can be freely assigned.

The eQEP0 pins do not conflict with the standard BeBoPr pinout, and
might make a good primary encoder input for the spindle or other
high-speed axis.

Sadly, eQEP1 cannot be used without disabling HDMI. :frowning: I don't
generally intend to run without a display, but I'll make sure the HAL
BeagleBone encoder logic will support all three hardware encoders if you
don't need a display.

In addition to physical hardware support for encoders, it is possible to
support encoders via the PRU. I expect to be able to fairly easily
support up to 100 KHz or so count rates (25 KHz encoder A/B signals),
and may be able to go as much as 10x faster, depending on how complex
the PRU code becomes and how many channels are enabled. Regardless, the
encoder A/B/Index signals will need to be on direct PRU input pins. On
the BeagleBone Black, PRU0 has 9 direct inputs available on P9 (only 7
for the BeagleBone White), meaning it would be possible to support 3
encoders with index, or 4 plain encoders on the 'Black.

Feel free to contact me directly if you are working on a design and are
concerned about your pinout.

2

Hi Charles,

I am studying the possibilities of having 3 axes with step/dir and encoder signals A/B/I to control servos. It’s a shame about the eQEP1, I saw the pin overlapping too :frowning:

I have followed your work with PRU’s and I’ll try by this way. I think it is possible to use the PRU0 for 9 encoder signals and PRU1 to step/dir, 6 signals, although I think it will not be compatible with Bebopr for example, but make my own interface board not think it was a problem.

I have to study in depth the programming of PRU for encoders. I think you have something about this (PRU encoder program). Is it working properly? maximum frequency that you got reading? any problem if I want to read 3 encoders at time?

Thanks a lot.

3

My PRU encoder code can be found here:

https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_pru_generic/pru_encoder.p

The PRU code is working as expected, although I have only tested it
without index. Maximum frequency will depend on the PRU task period the
way my HAL code is setup, but there's no reason it couldn't run really fast.

The only limit to supporting multiple encoders is how many PRU direct
input pins are available. You should be able to do three encoders with
index assuming there are no pin conflicts with other required functions.

More encoders could be supported if you used a single GPIO bank and did
one GPIO read with the PRU each loop of the encoder logic. This adds
about 160 nS to the loop time, but if the PRU isn't doing much else you
should still be able to support encoder rates fast enough to be very
useful (easily into the hundreds of KHz).

4

Hi Charles,

I don’t understand exactly what do you mean here:

More encoders could be supported if you used a single GPIO bank and did
one GPIO read with the PRU each loop of the encoder logic. This adds
about 160 nS to the loop time, but if the PRU isn’t doing much else you
should still be able to support encoder rates fast enough to be very
useful (easily into the hundreds of KHz).

I’m using for the 3 encoders the 9 pins of PRU0 without conflicts because PRU1 is overlapped with display and it is used for step/dir pins. How can I add more encoders if I don’t have more free PRU pins?

Thanks,

Vicente.