Does BBB have a counter, which simply keeps running count of input pulses?
I can implement this in loop, of course, very similar to reading push button which I’m already doing now. But, I’m wondering if BBB can be used as electronic version of those mechanical hand held “tally counter clicker”. And, yes, Amazon sells those, both mechanical and electronic, but BBB is much better choice for “automated QA testing”.
I saw something called a counter on an older image with the 5.10.x kernels in /dev/bone/counter/.
/dev/bone/counter exists in 5.10.168-ti-r83, 6.12.57-bone40, and 6.17.9-bone17 (all Debian 13.2). But, it’s empty in all 3 images.
I would not be surprised if what you’re missing is a loaded kernel driver.
I think you should go over the AM335x TRM and have a good look at the periphirals
governing the Timer/Counter hardware, and then take a good look at whatever
drivers are available in the kernel tree.
From there you can either insmod it or, you’ve guessed it, craft a DT overlay
to configure it automatically.
There is a newer ‘counter’ subsystem that we don’t have very many good examples showing how to use it:
If you take the pwm0 example overlay, just add:
&eqep0 {
status = "okay";
};
Regards,
“eQEP” seems to pops up a lot, but without much instruction. All I know is, BBB has 3 eQEP modules. So, probably, a better question is
Kernel modules: There are 2 kernel modules: ti-eqep (top level) and counter (dependent). I don’t see any change, after loading them. Maybe, I’m not looking at right places. I was hoping to see something in
/dev/bone/
/dev/uio/
/sys/class/pwm/
/sys/class/uio/
/sys/bus/counter/
Nothing.
Device tree overlay: In my current image (Debian 13.2, kernel 6.17.10-bone-18),
$ find /boot /opt -iname '*eqep*'
/opt/source/overlay-utils/eqep2.dtsi
/opt/source/overlay-utils/uio/ecap0-eqep0a-P9_42.dtsi
/opt/source/overlay-utils/uio/eqep2.dtsi
/opt/source/overlay-utils/uio/eqep0.dtsi
/opt/source/overlay-utils/uio/eqep1.dtsi
/opt/source/py-uio/other-examples/eqep-test.py
/opt/source/py-uio/src/uio/ti/eqep.py
of which
/opt/source/overlay-utils/eqep2.dtsi
looks most promising.
Hey guys/gals,
I found this online: Motors — BeagleBoard Documentation
without the interface specification called bone-buses, I think that link may be a mute point.
But…if you do not need HDMI, try to comment it out in a file called uEnv.txt and write the eqep DTS file(s).
Making sure you're not a bot! <<< This will get you to a HDMI set of peripheral access understandings in DTS usage. Anyway, enough fancy talk, I hope you know what to do from that point forward.
@RobertCNelson showed to use this DTS installation:
&eqep0 {
status = "okay";
};
It gets more complicated but it just takes time to learn DTS files and how they include one another.
/opt/source/overlay-utils/eqep2.dtsi is something I can test soon.
I will get the 6.17.x-* kernel(s) and test it on the BBB.
I’d appreciate if you report what happens.
My BBB just died. Barrel power or USB power, neither brings it alive.
Hey, I am up! Anyway, notta:
Module Size Used by
ti_eqep 12288 0
counter 24576 1 ti_eqep
I cannot get past the ti_eqep module, i.e. as counter is not showing up yet.
Dang.
When in doubt, gloss over the driver code to divine what it’s supposed to do…
You may have to wait for others to help. My board did a no-boot on the power button and it just kept the computer beeping. I am not sure the response I was supposed to get…
The board is booting fine again. Phew. Anyway, the overlay-utils repo is nice and it has timers and eqep files in it.
I am not so sure how to handle the Makefile so far. I am still trying.
It would be nice if a simple install in the Makefile would work and then adding the .dtbo to the uEnv.txt file is easy but simply, I am out of answers for now. Sorry to waste your time.
I checked the gpioinfo on kernel 6.12.x so far. I have not gotten to the kernel you are using.
Anyway, the output of gpioinfo states no, I repeat, no eqep files available no matter what I tried. It might just work as is? Plausible but highly irregular. On with the testing!
/opt/source/overlay-utils/eqep2.dtsi contains
&epwmss2 {
status = "okay";
};
&eqep2 {
status = "okay";
...
Does that mean, “eqep2” uses PWM2?
The eqep peripheral is under the PWMSS.
15.4 in the TRM shows this to be evident. Read on! And…
I was reading. So, there is one PWMSS with child peripherals under it like eCAP and eQEP and then eHRPWM.
I think because of what beagleboard personnel does now, there are more than one PWMSS being utilized. From my personal understandings, there is only one PWMSS on the am335x. Now, how that is done and configured, no clue.
lots of bits, offsets, and clocks would be my guess. Then, one would need the .dtsi file to prove its actual application.
That link posted is for the bbb-bone-buses.dtsi on their repo at openbeagle.org.
So, there is also this file: #include <dt-bindings/board/am335x-bone-pins.h>
I do not know about this file yet. Then, one would need to read about the clocks and make that part of the .dtsi file (presumably).
One last thing, epwmss2 seems to be an input only but it is not populated and not supported.
What I think it should be is this: pwmss and pwmss only and it should be one only.
Correct
Followup questions…
BB-EHRPWM2-P8_13-P8_19.dtbo, and leave the pin P8_13, 8_19 unconnected?eqep2.dtbo use PWM2 internally, and not make it available for user? eqep2.dtsi says it’ using pins P8_11, P8_12, P8_15, P8_16. So, does that mean, PWM2 would be using those pins, and not the default P8_13, P8_19?I got a “loaner” BBB, so I can continue experimenting…
So eqep pins…
P9_42B 0x9a0 eQEP0A_in (mode 1)
P9_27 0x9a4 eQEP0B_in (mode 1)
P9_41B 0x9a8 eQEP0_index (mode 1)
P9_25 0x9ac eQEP0_strobe (mode 1)
AM33XX_IOPAD(0x9a0, PIN_INPUT | MUX_MODE1) /* (B12) mcasp0_aclkr.eQEP0A_in */
AM33XX_IOPAD(0x9a4, PIN_INPUT | MUX_MODE1) /* (C13) mcasp0_fsr.eQEP0B_in */
AM33XX_IOPAD(0x9a8, PIN_INPUT | MUX_MODE1) /* (D13) mcasp0_axr1.eQEP0_index */
AM33XX_IOPAD(0x9ac, PIN_INPUT | MUX_MODE1) /* (A14) mcasp0_ahclkx.eQEP0_strobe */
P8_35 0x8d0 eQEP1A_in (mode 2)
P8_33 0x8d4 eQEP1B_in (mode 2)
P8_31 0x8d8 eQEP1_index (mode 2)
P8_32 0x8dc eQEP1_strobe (mode 2)
AM33XX_IOPAD(0x8d0, PIN_INPUT | MUX_MODE2) /* (V2) lcd_data12.eQEP1A_in */
AM33XX_IOPAD(0x8d4, PIN_INPUT | MUX_MODE2) /* (V3) lcd_data13.eQEP1B_in */
AM33XX_IOPAD(0x8d8, PIN_INPUT | MUX_MODE2) /* (V4) lcd_data14.eQEP1_index */
AM33XX_IOPAD(0x8dc, PIN_INPUT | MUX_MODE2) /* (T5) lcd_data15.eQEP1_strobe */
P8_41 0x8b0 eQEP2A_in (mode 3)
P8_42 0x8b4 eQEP2B_in (mode 3)
P8_39 0x8b8 eQEP2_index (mode 3)
P8_40 0x8bc eQEP2_strobe (mode 3)
AM33XX_IOPAD(0x8b0, PIN_INPUT | MUX_MODE3) /* (T1) lcd_data4.eQEP2A_in */
AM33XX_IOPAD(0x8b4, PIN_INPUT | MUX_MODE3) /* (T2) lcd_data5.eQEP2B_in */
AM33XX_IOPAD(0x8b8, PIN_INPUT | MUX_MODE3) /* (T3) lcd_data6.eQEP2_index */
AM33XX_IOPAD(0x8bc, PIN_INPUT | MUX_MODE3) /* (T4) lcd_data7.eQEP2_strobe */
P8_12 0x830 EQEP2A_IN (mode 4)
P8_11 0x834 eQEP2B_in (mode 4)
P8_16 0x838 eQEP2_index (mode 4)
P8_15 0x83c eQEP2_strobe (mode 4)
AM33XX_IOPAD(0x830, PIN_INPUT | MUX_MODE4) /* (T12) gpmc_ad12.eQEP2A_in */
AM33XX_IOPAD(0x834, PIN_INPUT | MUX_MODE4) /* (R12) gpmc_ad13.eQEP2B_in */
AM33XX_IOPAD(0x838, PIN_INPUT | MUX_MODE4) /* (V13) gpmc_ad14.eQEP2_index */
AM33XX_IOPAD(0x83c, PIN_INPUT | MUX_MODE4) /* (U13) gpmc_ad15.eQEP2_strobe */
I’m just a newbie. Where I do add these, or check that it’s there?
My BBB only has P9_42, P9_41 pins, not P9_42B, P9_41B. So, skip.
I assume it’s using PWM1. But, I’m already using PWM1 with the following entries in /boot/uEnv.txt:
enable_uboot_overlays=1
uboot_overlay_addr4=BB-EHRPWM1-P9_14-P9_16.dtbo
disable_uboot_overlay_video=1
disable_uboot_overlay_audio=1
I assume, I would need eqep1.dtsi, similar to eqep2.dtsi. Okay, I can copy and edit.
Question:
What does /boot/uEnv.txt look like?
uboot_overlay_addr4=BB-EHRPWM1-P9_14-P9_16.dtbo
uboot_overlay_addr5=eqep1.dtbo
or just
uboot_overlay_addr4=eqep1.dtbo
This is what eqep2.dtsi configures, I think. It already mentions pins P8_12, P8_11, P8_16, P8_15 in “mode4” (I think).
USES_PIN( P8_12 );
USES_PIN( P8_11 );
USES_PIN( P8_16 );
USES_PIN( P8_15 );
...
&am33xx_pinmux {
eqep2_pins: eqep2 {
pinctrl-single,pins = <
PIN_PULLDN( P8_12, 4 ) // A
PIN_PULLDN( P8_11, 4 ) // B
PIN_PULLDN( P8_16, 4 ) // index
PIN_PULLDN( P8_15, 4 ) // strobe
>;
};
};
Question:
What does my /boot/uEnv.txt look like?
enable_uboot_overlays=1
uboot_overlay_addr4=BB-EHRPWM1-P9_14-P9_16.dtbo
uboot_overlay_addr5=BB-EHRPWM2-P8_13-P8_19.dtbo
uboot_overlay_addr6=eqep2.dtbo
disable_uboot_overlay_video=1
disable_uboot_overlay_audio=1
which loads PWM2 for eQEP2 to use?
Or, just eqep2.dtbo by itself, where I’m assuming eQEP2 will be using PWM2 internally? (I think, this is more correct way).
enable_uboot_overlays=1
uboot_overlay_addr4=BB-EHRPWM1-P9_14-P9_16.dtbo
uboot_overlay_addr5=eqep2.dtbo
disable_uboot_overlay_video=1
disable_uboot_overlay_audio=1
NOTE: I’m a newbie, just a member from general public. Device Tree and Firmware are not my area.
That depends on whether PWM1/2 and eQEP1/2 are two different modes of the same peripheral or they’re separate but use the same pins on the other side of the PINMUX.
You keep saying that you’re just a newbie, but that doesn’t exempt you from doing some research.
I already pointed you to the TRM once, so now go and apply what’s in there.
what kernel are you on? uname -r i got pulled from work to help ship due to the snow up here.