brook has quit [Remote host closed the connection]
brook has joined #beagle
set_ has quit [Remote host closed the connection]
starblue has quit [Ping timeout: 255 seconds]
starblue has joined #beagle
Shadyman has joined #beagle
brook has quit [Remote host closed the connection]
brook has joined #beagle
brook has quit [Ping timeout: 276 seconds]
vagrantc has quit [Ping timeout: 256 seconds]
brook has joined #beagle
brook has quit [Remote host closed the connection]
brook has joined #beagle
brook has quit [Remote host closed the connection]
ikarso has joined #beagle
brook has joined #beagle
rajulun has joined #beagle
rajulun has quit [Client Quit]
Shadyman has quit [Quit: Leaving.]
ikarso has quit [Quit: Connection closed for inactivity]
set_ has joined #beagle
Guest1822 has joined #beagle
<Guest1822>
Anyone in here?
Guest1822 has quit [Client Quit]
Guest41 has joined #beagle
<Guest41>
Hi. how to i install and use a tp-link tl-wn722n wifi adapter on my beaglebone black?
<Guest41>
rev c*
Guest41 has quit [Quit: Client closed]
Guest41 has joined #beagle
Guest16 has joined #beagle
<Guest16>
I am trying to boot debian image on my beaglebone black but it is taking a long time, while booting only the first and third LEDs are glowing (first LED blinking, 3rd LED is dimly lit)
<Guest16>
is the process happening?
<Guest16>
Can someone help
balrog has quit [Read error: Connection reset by peer]
balrog has joined #beagle
<Guest16>
help pls
Guest16 has quit [Quit: Client closed]
Guest41 has quit [Quit: Client closed]
<set_>
hello!
<set_>
Good morning. Did anyone ever get to look over the PWM/GPIO instances on the am335x w/ config-pin that I was suffering from currently?
<set_>
It may be serious... I mean, it is not serious to health but to an issue I am trying to resolve.
Stat_headcrabed has joined #beagle
Guest17 has joined #beagle
<Guest17>
hello
<Guest17>
any body there
<Guest17>
?
Guest17 has quit [Client Quit]
Stat_headcrabed has quit [Quit: Stat_headcrabed]
Patater has quit [Quit: Explodes into a thousand pieces]
Patater has joined #beagle
mvaittin has quit [Ping timeout: 265 seconds]
mvaittin has joined #beagle
Stat_headcrabed has joined #beagle
Stat_headcrabed has quit [Client Quit]
brook has quit [Remote host closed the connection]
brook has joined #beagle
vvn has quit [Quit: WeeChat 3.8]
Stat_headcrabed has joined #beagle
Stat_headcrabed has quit [Client Quit]
balrog has quit [Read error: Connection reset by peer]
balrog has joined #beagle
jfsimon1981_c has quit [Remote host closed the connection]
jfsimon1981_c has joined #beagle
balrog has quit [Quit: Bye]
ikarso has joined #beagle
balrog has joined #beagle
buzzmarshall has joined #beagle
Stat_headcrabed has joined #beagle
Stat_headcrabed has quit [Client Quit]
<zmatt>
set_: your problem statement is too vague to give any meaningful answer
<zmatt>
you'll indeed probably need a 3.3v-to-5v level shifter given that the TB6600 seems to be designed for 5V control signals
<zmatt>
it will require two gpios (for DIR and EN) and a pwm (for PUL)
<zmatt>
as always I'd recommend using sysfs for gpio, not gpiod
<zmatt>
(do keep in mind that if you use gpiod it'll break sysfs gpio for those pins, afaik it takes a reboot to fix it)
<zmatt>
you'll want to use the "common-cathode" connection scheme, i.e. EN-/DIR-/PUL- all connect to ground, EN+ and DIR+ connect to gpios (via level shifter) and PUL+ to the pwm output (via level shifter)
<zmatt>
it looks like connecting EN is optional, it can be used to disable the motor driver so that you can rotate the motor shaft manually
<zmatt>
I'm also a bit concerned about the impact a bidirectional level shifter will have in this situation, since the control inputs of the motor driver are current-driven (optocouplers)... this is certainly a situation where normal (unidirectional) level shifters would be more desirable
<zmatt>
hmm, maybe it would actually be better to use common-anode rather than common-cathode in this case then
<zmatt>
i.e. PUL+/DIR+/EN+ to 5V and PUL-/DIR-/EN- to level shifter
<zmatt>
but I'm also concerned about the current... the TB6600 says you need to ensure the control outputs can drive 8-15 mA, but that's definitely outside the comfort zone of the beaglebone
<zmatt>
(which is another reason to use a normal level shifter with push-pull outputs)
brook has quit [Remote host closed the connection]
brook has joined #beagle
Guest33 has joined #beagle
Guest33 has quit [Ping timeout: 260 seconds]
vvn has joined #beagle
ikarso has quit [Quit: Connection closed for inactivity]
<set_>
@zmatt: I am using the TB6600 w/ the BBBW.
<set_>
I have a level shifter attached so far.
<set_>
It seems that there are two PWM pins and one GPIO for use w/ this controller?
<set_>
They have some odd hook-up guide. Let me get it.
<set_>
Further down the page(s), there is a Cathode or Anode only hookup guide: chrome-extension://efaidnbmnnnibpcajpcglclefindmkaj/https://dfimg.dfrobot.com/nobody/wiki/0bcc0b661ce7750ff7d0134bfc3e88b3.pdf
<set_>
Does that make sense?
<set_>
No ground or no PWR (3.3v or 5.0v) and either/or. Heh?
<set_>
It is one of those times where adding in GND w/ 3.3v does not work or putting in 3.3v w/ GND...blah. You get it.
<set_>
Oh!
<set_>
Hmm.
<set_>
@zmatt: I have the two PWM signals on the level shifter and the one GPIO on the level shifter also.
<set_>
All I know for now, things used to work w/ your older model PWM sysfs driver and w/ my own Path(/dev/bone/pwm/1/a) set of commands...
balrog has quit [Quit: Bye]
<set_>
Then, I booted w/ the same hardware. Drained battery. I set up a DC Digital PSU and nothing. No movement. Just some odd sounds and some excited motors but just excitement, i.e. nothing in the form of commands being attained.
<set_>
...
<set_>
I thought it was the source but it already worked. Slowly in a linear fashion, yes. But! It still worked.
<set_>
Is it still not safe to use gpiod in python3 on the armhf am335x (BBBW)?
<set_>
Now...for the GPIO input, I have a resistor only. It is a button, a GND, w/ a 3.3v GPIO input done up on P8.14.
<set_>
I used gpiod and config-pin to handle the button and the other gpio on P9.12.
<set_>
I think gpiod and config-pin must have some banding issues...I am not aware.
<set_>
I also tried config pin for p9.14 and p9.16 to handle the two PWM pins.
<set_>
The BBBW boots. I can start the machine. I can alter files, change up some source, and still w/ what I presume I understand...
<set_>
BLAMO, notta.
<set_>
It was in b/t boots which makes me think that gpiod in python3 is not playing nice. I think there are some source I may need to alter or add to readjust the gpiod GPIO enabled pins...
<set_>
...
<set_>
I am posting the source as it is currently used. Laugh at loud but this is all I needed for now to then move on in what would be the future now. I am stuck in the past still b/c of gpiod, presumably.
<set_>
I am using the "common-cathode" w/ GND instead of common-anode w/ 5v.
<set_>
would pu work better for the GPIO pins?
<zmatt>
pu/pd is irrelevant since you're configuring them as outputs
<set_>
I have one input.
<zmatt>
again, I advise against gpiod. I'm sure it can work, but it has no benefits over sysfs-gpio and some annoying behaviour (e.g. the kernel changing the gpio state on program exit) that can cause problems
<set_>
Oh.
<set_>
Does the button in question need three pins to be activated (3.3v, GND, GPIO) or can I use GPIO and GND only?
<zmatt>
button? I thought you were trying to get the motor driver to work?
<set_>
Well, I need a stop. In case things get odd, I need to be able to stop it from source and from hardware.
<set_>
Usually try / except and canceling the enablement does it.
<zmatt>
for a button, connect it between a gpio (configured as input) and gnd, use config-pin to configure the pin to gpio_pu
<set_>
gpio_pu. Got it. Okay.
<set_>
Thank you.
<zmatt>
but I don't see how or why you're going to integrate the functionality of a button in your program when you don't even have a basic test of the motor driver working
<set_>
I understand.
<set_>
I think having extra security in this circumstance is worth it since I am connected to a motor.
<zmatt>
and my preference would go to common-cathode if it works, but I don't know if that will actually work with your bidirectional level shifter
<set_>
Aw!
<set_>
I do have a bi-directional shifter over here.
<set_>
Dang it.
<zmatt>
... but there's no extra security unless you manage to implement functionality to have your program detect the button press and disable the motor output, which I don't see happening if you don't even have a basic test working
<set_>
Right. Okay. Understood but how can I use GPIO in the sysfs if it is no longer being utilized?
<zmatt>
what do you mean by "no longer being utilized" ?
<set_>
I have some kernel, 5.10.162-ti-r58, that I thought kicked it out?
<set_>
Hmm.
<set_>
This may be my mistake.
<set_>
I have everything in /dev/bone/ outside of GPIO.
<set_>
I was wrong.
<set_>
I see them in their shinny glory now!
<set_>
so, /sys/class/gpio/* has many available and even an export file.
<set_>
Off to test! brb.
<zmatt>
you normally never need the export file
<set_>
Hmm. Okay!
<set_>
Brb!
<set_>
it is like I fell off the boat.
<set_>
I did. I fell off the dang boat.
<set_>
Okay...
<set_>
So, the source runs. The motor does not move.
<set_>
I may have busted the driver w/ gpiod. Who knows?
brook has quit [Read error: Connection reset by peer]
brook has joined #beagle
<set_>
@zmatt: This is what I have currently, i.e. I fell off!