<mattb0ne>
i am getting the ValueError Not a directory: /dev/uio/pwmss1
<mattb0ne>
that is a rules thing right
<mattb0ne>
do I need to copy something over like I did for the GPIO pins
brook has joined #beagle
brook has quit [Remote host closed the connection]
<mattb0ne>
zmatt: if you get a chance can you drop a message on what is going on here. If there is a rules file or a helper script you gave me I must of lost it
<mattb0ne>
I went back aways looking at pastebins i did not see anyhting
<set_>
Here: https://pastebin.com/xUZcgWWx shows some source but how can I configure what does what in it? Does PWM control the start or does GPIO control the start. Is there anyway to control the linear motion of back and forth w/ this current source?
mattb0ne has quit [Ping timeout: 248 seconds]
brook has joined #beagle
<set_>
Okay.
<set_>
I configured that PWM handles the movement in one direction and GPIO does nothing for whatever reason. blah.
<set_>
I guess I need to use source so that GPIO handles the on/off functionality and then use two separate PWM channels to handle the linear back/forth.
<set_>
Argh...!
mattb0ne has joined #beagle
brook has quit [Ping timeout: 276 seconds]
<set_>
I also need to set rising or falling w/ GPIOD. Blah.
<set_>
Off to read more...
<set_>
"I Have a Button!"
<mattb0ne>
???
<set_>
mattb0ne: Hello!
starblue has quit [Ping timeout: 276 seconds]
brook has joined #beagle
<mattb0ne>
hey set
<mattb0ne>
what are you up to these days
starblue has joined #beagle
<set_>
Trying motors.
<set_>
w/ a PWM lib from @zmatt and some GPIOD ideas.
<set_>
I have a motor that listens to PWM so far and no gpio for whatever reasoning it has so far.
mattb0ne has quit [Remote host closed the connection]
<set_>
in Linux, I see %e handles events.
<set_>
and 0 for falling edge
brook has quit [Remote host closed the connection]
<set_>
It is working but only in one linear motion... If it was a line, it would be great!
<set_>
Ha.
Shadyman has joined #beagle
<set_>
well, it has some type of buzzer on it...
<set_>
That is good news I guess.
<set_>
I controlled it in both ways simultaneously!
<set_>
Oops.
mattb0ne has joined #beagle
vagrantc has quit [Quit: leaving]
mattb0ne has quit [Ping timeout: 255 seconds]
mattb0ne has joined #beagle
<set_>
Whelp, the yelling of the motor went down to a hush!
<set_>
Does anyone see the issue in my source I am trying to create?
mattb0ne has quit [Ping timeout: 276 seconds]
mattb0ne has joined #beagle
mattb0ne has quit [Ping timeout: 268 seconds]
Shadyman has quit [Quit: Leaving.]
Stat_headcrabed has joined #beagle
Stat_headcrabed has quit [Client Quit]
chococandy has joined #beagle
chococandy has quit [Client Quit]
chococandy has joined #beagle
chococandy has quit [Client Quit]
chococandy has joined #beagle
chococandy has quit [Client Quit]
Stat_headcrabed has joined #beagle
<set_>
It still does not make sense. The motor turns both directions but only when it wants to turn. I am commanding the machine but it will not listen to what I think it should be doing...
<set_>
Off to keep trying!
mattb0ne has joined #beagle
<mattb0ne>
all quiet on the western front
<set_>
Well...I got it but it still makes no sense. It listens when it wants...
<mattb0ne>
Mattb0ne still has no idea what is wrong as well
<set_>
One command, it runs fine and then returns to its previous place. Then, I run it again and it does something different.
<mattb0ne>
arrrgggghhhhhhh why doesthe beaglebone just work
<set_>
Same source, same commands, and it is not repliacating its moves...
<set_>
Hmm.
<set_>
What are you doing mattb0ne?
<set_>
GPIO should turn on/off the driver. PWM should make it move one way and then the other pwm peripheral makes it move the other way...
<set_>
GPIO does not do this for some reason. PWM seems to only work when it wants. It is difficult to figure out... I am using TB6600 w/ the BBBW.
<set_>
I left a message/post on the forums in case anyone is willing to assist!
<zmatt>
mattb0ne: "/dev/uio/pwmss1" .. I assume that's because the pwm is used by pru?
<zmatt>
anyway, configuring pwm to uio requires the appropriate overlay from my overlay-utils repository
<zmatt>
that symlink also requires an udev rule but I'm pretty sure that rule is already a standard part of images
<mattb0ne>
so I am wondering if I missed a step somewhere but I am not sure what
<zmatt>
pwm.dtbo doesn't use uio, it's for controlling the pwm from linux using the normal pwm interface
<mattb0ne>
i do both
<zmatt>
since your program is trying to open /dev/uio/pwmss1 it evidently requires it to be configured to use uio, presumably because you're controlling the pwm from pru
<mattb0ne>
right
<zmatt>
you can't do both, not safely anyway
<mattb0ne>
out of the two I need the PRU to use it more
<mattb0ne>
i think you warned me but I said the non pru use was sporadic and rare no chance both would use it
<zmatt>
uhh I have you no idea what you're referring to, I think that sentence must be missing some context
<zmatt>
maybe you mean that non-pru use of pwm *via uio* is rare... the "rare no chance both would use it" makes no sense since that's not up to chance but entirely up to you
<mattb0ne>
pwm control from the uio is rare and would never conflict with the pru
<zmatt>
anyway, to reconfigure pwm to be used via uio and/or by pru (probably you're using uio to do the setup on pru's behalf) you'll want to enable the appropriate overlay from the uio/ directory of overlay-utils
<zmatt>
again the "would never conflict with the pru" is nonsensical... obviously if you're going to access it via uio at the same time as pru there's going to be a conflict
<mattb0ne>
is it not hte pwm1.dtbo?
<mattb0ne>
or did you make something custom for me
<zmatt>
14:23 <@zmatt> pwm.dtbo doesn't use uio, it's for controlling the pwm from linux using the normal pwm interface
<zmatt>
14:18 <@zmatt> it sounds like you probably want uio/ehrpwm1-P9_14-P9_16.dtbo (or uio/ehrpwm1.dtbo if you're using config-pin to mux pins)
<mattb0ne>
sooo maybe you helped me tinker with it
<mattb0ne>
though i did not see anyhting like that in the logs
<mattb0ne>
I do need to do some configuration up front right ? or are you saying with proper init of the pruss everything will take care of itself
<zmatt>
I'm assuming you're opening the uio device from python to perform initial setup of the pwm peripheral so pru doesn't need to
<zmatt>
since that's the most likely reason you're opening the uio device from python (which we know you are since you were getting an error because the pwm wasn't enabled for uio using the appropriate overlay)
<zmatt>
my guess would be you previously used uio/ehrpwm1-P9_14-P9_16.dtsi or a custom overlay based on it (e.g. if you want to enable only one of the two pins it configures)
<zmatt>
hopefully this time you'll carefully note what overlays and other configuration is required to make your project work
<mattb0ne>
yes sir!!!
<mattb0ne>
this hidden trove of overlays
<mattb0ne>
i am typing all of this down zmatt so I will never trouble you again with these questions
mayab has quit [Quit: Connection closed for inactivity]
Stat_headcrabed has quit [Quit: Stat_headcrabed]
<mattb0ne>
if you fry a board is the SD card protected
<mattb0ne>
just curious
<mattb0ne>
it would be a major point for not using the flash memory
<zmatt>
generally yes. technically frying the SoC typically also won't affect the eMMC, but the eMMC is just a bit harder to access ;) not impossible though, we've done it when needed to recover the eMMC of a board after frying it
<mattb0ne>
good to have that in my back pocket
<zmatt>
but it required desoldering the SoC since it was shorting a power supply rail. with the short cleared the board could power on and eMMC can be accessed via the P9 header by wiring it up to another beaglebone
<zmatt>
P8 header
<mattb0ne>
sounds like a lot of work
<zmatt>
more like you need the right tools
<mattb0ne>
are the tools used beagle specifc or they generic tools every embedded person should have access too
<mattb0ne>
like a multi meter or soemthing
<zmatt>
a hot air rework station to remove a BGA chip from a pcb
<zmatt>
I guess you could try some form of violence instead of hot air, but dunno if that's effective
<jkridner>
“industrial equipment for children “ haha
<zmatt>
the nice thing in this scenario is that much of the board can be ruined as long as the eMMC and the power supply parts remain okay, and no shorts are created on supply rails
<zmatt>
but yeah, it's still a fair bit of work and not a guaranteed success due to the risk of causing problematic damage
<zmatt>
and then you need a bunch of wires to hook up the dead board's eMMC to the MMC2 interface of another beaglebone, and a DT overlay to configure it
<zmatt>
and then it just appears as /dev/mmcblk2 and you can either image it to sd card or mount it and recover files
<zmatt>
of course desoldering the SoC is only required if it can't power on due to an internal short in the SoC, if the power can be powered on then you only need to hold the board in reset to be able to safely access the eMMC
<zmatt>
*if the board can be powered
<mattb0ne>
i see
<mattb0ne>
well I will just try and not fry the board
<mattb0ne>
lol
<mattb0ne>
but I do not need the fast boot from the eMMC anyway
<zmatt>
yeah, and backup relevant data
<mattb0ne>
learning that the hard way
<mattb0ne>
I was good about it and I slacked off
<mattb0ne>
still not sure how the board borked since it was working and shut down normally, it just wasnt used for a few months
<mattb0ne>
the pwm overlays
<mattb0ne>
i added them but should I see any changes in the show pins out put from including them
<zmatt>
"them" ?
<mattb0ne>
or just ehrpwm1-P9....
<zmatt>
you definitely should. unless you have a conflicting overlay
<zmatt>
that's already using one of the two pins
<mattb0ne>
so I added and disabled all my other overlays so no conflict and no dice
<mattb0ne>
very puzzling
<mattb0ne>
would disabling the hdmi or emmc flags hurt anything
<mattb0ne>
i can post my uEnv.txt
<zmatt>
the only thing that can hurt is if the pins are already in use by another overlay, or you just failed to correctly configure the pwm overlay in your uEnv.txt
<zmatt>
obviously if you want me to check your uEnv.txt you'll need to post it
<mattb0ne>
yeah i am going to post just want to check the obvious first
<mattb0ne>
ie overlay in the firmware folder and yatta yatta
<mattb00ne>
i can post the overlays I plan on using but this one is not loading by itself
<mattb00ne>
ehrpwm1.dtbo
<zmatt>
you sure? does /dev/uio/pwmss1 not exist?
<mattb0ne>
yeah it is not there
mattb000ne has joined #beagle
<zmatt>
since you chose to configure ehrpwm1.dtbo (which configures no pins0 rather than ehrpwm1-P9_14-P9_16.dtbo (which configures two pins) it won't show anything in show-pins obviously
<zmatt>
okay that is strange
mattb00ne has quit [Read error: Connection reset by peer]
<mattb0ne>
right I was just trying with both
<mattb0ne>
just to see if it was GPIO think
<zmatt>
how many /dev/uio* devices exist?
<mattb0ne>
thing*
<mattb0ne>
just pruss
<mattb0ne>
that is in the /dev/uio folder
<zmatt>
I didn't ask about the directory
<zmatt>
but never mind can you just pastebin ls -ld /sys/class/uio/*
<zmatt>
mattb00ne: other than that I don't see an obvious problem, so check show-pins to see if the pin is being occupied with anything, double-check that you configured the right path in /boot/uEnv.txt
<zmatt>
btw it's generally preferred to use dashes rather than underscores in DT node names, e.g. magnet-dir rather than magnet_dir
<zmatt>
also, you can check the names and build-dates of the overlays loaded for the currently booted system using:
<zmatt>
if an overlay is loaded but it somehow doesn't seem to have taken effect (e.g. pinmux doesn't show up in show-pins) then check kernel log for errors, search for node names defined by your overlay (e.g. in this case search for "magnet")
xet7 has joined #beagle
xet7 has quit [Remote host closed the connection]
xet7 has joined #beagle
Guest72 has joined #beagle
<Guest72>
I've been trying to get an AI-64 up and running, been following the included guide but have been running into problems. When I flash the microSD card with balenaEtcher I get "opps, flash failed" at the end, and the computer does nothing when connected to a monitor. Any ideas?
<zmatt>
if etcher is saying it failed to flash the sd card then there's probably something wrong with that sd card
<Guest72>
It's brand new
<Guest72>
It's failed on two different brand new cars
<zmatt>
hmm that's odd
<zmatt>
it does seem there are some reports on the internet of people getting flash failed from etcher when in fact it succeeded
<zmatt>
just to check, what's the name of the image file you flashed?
<Guest72>
The exact file I downloaded is: bbai64-debian-11.3-xfce-arm64-2022-06-14-10gb.img.xz
<zmatt>
ok
<Guest72>
I tried inserting the sd card into the board and booting it, nothing shows up on the connected monitor though some LED's blink
<zmatt>
oh, hold on... is the monitor native displayport or are you using some dp-hdmi cable?
<Guest72>
the latter
<zmatt>
yeah, it's probably booting just fine, your issue is getting display output
<Guest72>
what should I be doing?
<zmatt>
to connect a hdmi monitor you need an actual active dp-hdmi converter. most dp-hdmi cables are for "DP++" ports that are actually dual-mode DP/HDMI, so the port detects that a dp-hdmi cable is attached and outputs HDMI instead
<zmatt>
but the AI-64 has no HDMI transmitter
<zmatt>
it's pure DisplayPort
<Guest72>
Interesting, I didn't know that. So, I need to get a miniDP-DP cable, correct?
<zmatt>
yeah, connecting a native DP monitor will avoid the issue
<Guest72>
Thanks for your help, never would have thought the cable is the issue
<zmatt>
it's confusing
<zmatt>
especially since the distinction between DP and DP++ is often glossed over, and DP++ ports often aren't even marked as such
<Guest72>
I wasn't even aware DP++ existed until now
<zmatt>
and I don't even know the right terminology for the cables... like sometimes people will call the DP++-to-HDMI cables "passive cables" but technically they're actually active too
<zmatt>
but the DP++-to-HDMI cables merely have to do some level shifting since the DP++ port will output the HDMI signalling but using DP output drivers which are electrically not compatible
<zmatt>
what you'd need for the AI-64 is something that actually converts a DP video signal to a HDMI one
<Guest72>
Definitely sounds easier to just get a DP cable and avoid all that