Debian bullseye Quadrature Encoder not counting on BBBlue

picked up some BBBlue a few weeks ago
trying to get Quadrature Encoder to count

Linux xxxxx 5.10.168-ti-r77 #1bullseye
Debian Bullseye IoT Image 2023-10-07

in “/dev/bone/counter/0/count0/” i have
enable: 1
function: quadrature x4
signal0_action: both edges
signal1_action: both edges
count: 0

i’m simulating the quadrature encoder output with 3v3 micro controller, verified that the two square wave forms are 90 degrees apart (out of phase) from each other with an oscilloscope. the square wave is running at about 24 Hz.
this is to just verify that eQEP can be read by BBBlue

the connection on the BBBlue is eQEP Encoder Plug E1, which is next to the end of the board and closes to the motor connectors.

Question is: what am i missing ??

Thanks in advance for any help,

Did you load the correct overlay?
Post your code. I am assuming you might be using the gpio pins?

the “/dev/bone/counter/0/count0/” are exported by the counter driver.
based on searching and some comments by RCN @RobertCNelson in other posts, bullseye changed some naming. librobotcontrol has not been updated for 5.10 (bullseye) ( to the best of my searching on the web)
as for my code, it’s simple c-code that just opens and reads and/or writes to the names in the above directory. if things are working i should be able to just ‘cat’ the ‘count’ name for the corresponding eqep connection.

@foxsquirrel
you got me thinking,
enable_uboot_cape_universal=1
is the only overlay in uEnv.txt
might need to check to see if the right overlay is loaded
gpioinfo
||line 8: EQEP_1A unused input active-high |
||line 9: EQEP_1B unused input active-high |
||line 12: EQEP_2A unused input active-high |
||line 13: EQEP_2B unused input active-high |
||line 18: EQEP_0A unused input active-high |
||line 19: EQEP_0B unused input active-high |
indicates there are 6 eQEP pins exported, thought that was enough.
will look into it some more.
the ‘unused’, is the same i get for the motor control pins, so i disregard that.

That might not work until you turn the sys file access on in the kernal. It might be off, I am using libgpiod to access the gpio lines. I believe it is still in the kernel, read somewhere it was going to be removed.

Does this work?

$gpiodetect

You have to be in the gpio group.

If that does work than do this for each gpiochip

$gpioinfo gpiochip0

That will tell you what to do next, if you see all the pins correctly assigned you will will have to possibly fix the code. Since you are in c it might not be too bad.

per the schematic and am335x-boneblue.dts the pins are defined and correct
and yes, the am335x-boneblue.dtb is being loaded at boot

GPIO3_18_B12 EQEP_0A
GPIO3_19_C13 EQEP_0B

LCD_DATA12_V2 EQEP_1A
LCD_DATA13_V3 EQEP_1B

GPIO1_12_T12 EQEP_2A
GPIO1_13_R12 EQEP_2B

/* E1 */
eqep0_pins: pinmux_eqep0_pins {
	pinctrl-single,pins = <
		AM33XX_PADCONF(AM335X_PIN_MCASP0_AXR0, PIN_INPUT, MUX_MODE1)		/* (B12) mcasp0_aclkr.eQEP0A_in */
		AM33XX_PADCONF(AM335X_PIN_MCASP0_FSR, PIN_INPUT, MUX_MODE1)		/* (C13) mcasp0_fsr.eQEP0B_in */
	>;
};

/* E2 */
eqep1_pins: pinmux_eqep1_pins {
	pinctrl-single,pins = <
		AM33XX_PADCONF(AM335X_PIN_LCD_DATA12, PIN_INPUT, MUX_MODE2)		/* (V2) lcd_data12.eQEP1A_in */
		AM33XX_PADCONF(AM335X_PIN_LCD_DATA13, PIN_INPUT, MUX_MODE2)		/* (V3) lcd_data13.eQEP1B_in */
	>;
};

/* E3 */
eqep2_pins: pinmux_eqep2_pins {
	pinctrl-single,pins = <
		AM33XX_PADCONF(AM335X_PIN_GPMC_AD12, PIN_INPUT, MUX_MODE4)		/* (T12) gpmc_ad12.eQEP2A_in */
		AM33XX_PADCONF(AM335X_PIN_GPMC_AD13, PIN_INPUT, MUX_MODE4)		/* (R12) gpmc_ad13.eQEP2B_in */
	>;
};

gpiodetect:

gpiochip0 [gpio-0-31] (32 lines)
gpiochip1 [gpio-32-63] (32 lines)
gpiochip2 [gpio-64-95] (32 lines)
gpiochip3 [gpio-96-127] (32 lines)

gpioinfo gpiochip3

||line 18: EQEP_0A unused input active-high |
||line 19: EQEP_0B unused input active-high |

same as i posted before

the “/dev/bon/counter/0/count0” directory has

ceiling function signal0_action_component_id
ceiling_component_id function_available signal1_action
count name signal1_action_available
enable signal0_action signal1_action_component_id
enable_component_id signal0_action_available

putting C-code aside, ‘echo’ and ‘cat’ should be enough to access these files
using ‘cat’ i get the same results as using C-code
‘echo’ val > [name] changes things, just like the C-code

So there’s something else that’s missing

ok, maybe i don’t understand Quadrature Encoders
though two square wave 90 degrees out of phase would make it count
if i set ceiling == 10 and
i do a ‘watch -n .1 “cat count”’ then the value will toggle between 9 and 10

will have to study Quadrature Encoders some more.

First I would just do a pulse train from a function generator using one or two hz, start with 50% duty cycle. echo that high and low to the console. When that works test it on all the pins you will use for the encoder. Do that before digging into the code.

When you go into your code be sure to add a try and catch around the tricky stuff and add some debug statements to the console. Save your file as .cpp and compile and link c++ to get the exception handling.

none of the different counter modes seem to work.
already using 50% duty cycle, lowered it to 10 Hz
doing C code, with error handling.
i’ll just keep at it, was hoping someone with bullseye work would have feed back.
Thanks,

correction:
the increase and decrease counters work, the ceiling must be set to something other than zero
increase counts from 0 to ceiling value then resets to 0
decrease counts from ceiling to 0 and then resets to ceiling value

still can’t get quadrature x4 to work
did not try pulse-direction

being all i wanted was to get increase counter to work for a generic wheel encoder, i’ll leave the other two for another day

hope this helps anyone working with bullseye.

I cannot find a BBblue, did find a servo hat for the RPI. It is 16 channels, however it has i2c bridging the gap. If your using something that is not extremely demanding this could be an option. Big negatives would be the latency since it is bridged to i2c. If the system can live with that this might be an excellent choice for the beagley. I am going to order one any way, it looks interesting and will try to get it running on the beagley-ai.

1 Like