Trying to Read some Optical Encoders w/out Knowledge...

General Discussion
, , , ,
#1

Hello,

I feel new again. Anyway…

  1. I bought something new
  2. This “new” item is actually an older model optical encoder w/ stepper attachment
  3. …and here some more of it

Would I use eQEP or eCAP or both or neither for handling the optical portion of the sensor readings?

I know the BBB has these peripherals. Do I know how to use them? No, I surely do not.

I have been studying. I am starting to understand the theory behind how these computations take place.

…

Can eCAP/eQEP handle 20MHz frequencies down to 5MHz?

Seth

P.S. I know a ton of people already understand the older model in which this is derived. I am still out there floating in the sea on this one.

#2

This was something I saw in the updates to the BBB one day, i.e. recently. Is using UIO a thing on the BBB still?

I mean…is there a way to leverage this source to handle reading older Optical Encoders?

Seth

P.S. If so, are there any people in userland handling such a task and would you be inclined to share a snippet of ideas in source? I am asking only. I do not expect to be granted anything really. I would rather know that there is some type of lib. or another form of functions dedicated to making an older Optical Encoder work to my advantage.

#3

Once the users understand that UIO is much better to fulfill hard real-time requirements, they will ask for it and they will get it.

CAP → speed only (1 pin frequency)
QEP → speed and direction

Both clocks are working @ 100 MHz → low resulution @ 20 MHz.

Check out examples:
pwm_cap: measures frequency/duty cycle of pwm signal (replace pwm signal by your sensor to test)
qep: simulation of QEP signals (A, B, I) and showing the resulting measurement (disconnect the simulation and connect the real sensor for testing)
pruss_toggle: generates high speed toogling by pruss GPIO (20 MHz) and measures the output by CAP

Regards

1 Like
#4

@DTJF ,

This is more than I could have asked for currently. Thank you…

  1. I read over the examples sections.
  2. I am learning more about the eCAP and eQEP functionality slowly…

I will test at 20 MHz b/c of it being an older model sensor w/ the highest rate of frequency being 20 MHz…

Here is the datasheet, i.e. from here: Data sheet: RGH41 series readhead

and a photo of the connections that I should make, i.e. in case anyone is following along:

RGH41

and then the digital signals, respectively…

RS422A

#5

Hello Again @DTJF ,

I was looking over the ideas listed on the Wiki Page for libpruio.

Is there a python3 set of examples or is everything written and meant for only python?

I know Python is a bit slower to compile and run but I figured I would try it first.

Seth

P.S. I see mention of kernel 3.x.x in the docs. pages too. So, UIO gets used in /boot/uEnv.txt, I need to comment out the RPROC section, and then reboot. Are the packages already on the BBB or are the installs needing to be made by apt still should be used?

#6

Development started with kernel 3.8 in 2014. Here I use libpruio under different kernel version up to 5.x. Small adaptions are necessary when a sysfs path changes, but the libpruio API didn’t change all the time → single source for your project.

devbuild setup is included in the GIT-repo. RCN started to build the packages, but never finished (I don’t know why). Currently the best solution is to build/install from source.

The main part of the library is coded in PRU ASM and the API (text IO) is coded in FreeBASIC. All examples are coded in FreeBASIC. Additionally some examples (with text output, no grafics) are also available in C and Python code. The Python code is executing more than ten times slower than the compiled binaries (C/FreeBASIC).

Regards

PS: Does your sensor work at 3V3?

1 Like
#7

Hello @DTJF ,

No…

The sensor is 5v. I need to add some additional hardware to make it translate to 3.3v. I will build the repo. from git and see how far I get.

Seth

P.S. I just looked in /boot/uEnv.txt and the instances of PRU are not located in that file. I may need another, different image? Guidance is accepted on images that have UIO. I will post the uEnv.txt file soon…

debian@BeagleBone:~$ cat /boot/uEnv.txt
#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0

uname_r=5.10.162-ti-r56
#uuid=
#dtb=

###U-Boot Overlays###
###Documentation: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays
###Master Enable
enable_uboot_overlays=1
###
###Overide capes with eeprom
#uboot_overlay_addr0=<file0>.dtbo
#uboot_overlay_addr1=<file1>.dtbo
#uboot_overlay_addr2=<file2>.dtbo
#uboot_overlay_addr3=<file3>.dtbo
###
###Additional custom capes
#uboot_overlay_addr4=<file4>.dtbo
#uboot_overlay_addr5=<file5>.dtbo
#uboot_overlay_addr6=<file6>.dtbo
#uboot_overlay_addr7=<file7>.dtbo
###
###Custom Cape
#dtb_overlay=<file8>.dtbo
###
###Disable auto loading of virtual capes (emmc/video/wireless/adc)
disable_uboot_overlay_emmc=1
disable_uboot_overlay_video=1
disable_uboot_overlay_audio=1
disable_uboot_overlay_wireless=1
#disable_uboot_overlay_adc=1
###
###Cape Universal Enable
enable_uboot_cape_universal=1
###
###Debug: disable uboot autoload of Cape
#disable_uboot_overlay_addr0=1
#disable_uboot_overlay_addr1=1
#disable_uboot_overlay_addr2=1
#disable_uboot_overlay_addr3=1
###
###U-Boot fdt tweaks... (60000 = 384KB)
#uboot_fdt_buffer=0x60000
###U-Boot Overlays###

console=ttyS0,115200n8
cmdline=coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet

#In the event of edid real failures, uncomment this next line:
#cmdline=coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet video=HDMI-A-1:1024x768@60e

#Use an overlayfs on top of a read-only root filesystem:
#cmdline=coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet overlayroot=tmpfs

##enable Generic eMMC Flasher:
#cmdline=init=/usr/sbin/init-beagle-flasher

See… Oh and…

debian@BeagleBone:/etc/apt$ sudo apt install python-pruio libpruio-lkm libpruio-doc
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package python-pruio
E: Unable to locate package libpruio-lkm
E: Unable to locate package libpruio-doc

and…

Ign:5 http://beagle.tuks.nl/debian bullseye/ InRelease
Err:6 http://beagle.tuks.nl/debian bullseye/ Release
  404  Not Found [IP: 83.172.160.181 80]
Reading package lists... Done
E: The repository 'http://beagle.tuks.nl/debian bullseye/ Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

So, I think the error is the IP Address is not located there any longer. Git it is…

I cloned the git repo. but the dependencies are not available.

E: Unable to locate package fbc
E: Unable to locate package cmakefbc

and…

am335x-pru-package is no longer available.

#8

It’s much more easy with 4.x kernels. But in the Arch LINUX world there’re attempts to get uio_pruss running under 5.x kernels.

This is for the LED site of the photoelectric barrier. Perhaps the other site is working at 3V3? You could try to use pull-up resistors:

  1. call Qep->config() for pinmuxing
  2. call Io->setPin() (once for each pin) to add the pull-ups

Regards

#9

Build from source:

sudo apt install freebasic git cmake
git clone https://github.com/DTJF/cmakefbc
cd cmakefbc
mkdir build
cd build
cmake .. -DCMAKE_MODULE_PATH=../cmake/Modules
make
sudo make install

This dependency is obsolet. libprussdrv is included (and optimized) in libpruio since version 0.6.

Regards

1 Like
#10

Hello @DTJF ,

Okay…building will take place. Thank you for following up. I will report back.

Seth