<lucascastro>
zmatt: It doesn't have memory offset or I'm wrong?
<zmatt>
for the pinctrl register you mean?
<lucascastro>
yes.
<zmatt>
the first column ("Pin") is the index into the pinctrl register array, so the pinctrl register address is 0x44e10800 + 4*pin
<lucascastro>
Got it.
<lucascastro>
I recall I already read about that.
<zmatt>
what do you need the offset for though?
<zmatt>
for DT it's better to use named constants, e.g. those from <dt-bindings/board/am335x-bbw-bbb-base.h>
<lucascastro>
I set pins using AM33XX_IOPAD
<lucascastro>
zmatt: I wasn't aware of that macros.
<zmatt>
annoyingly they're not compatible with AM33XX_IOPAD() ... you can either just not use that macro or redefine it to be compatible for both kinds of offsets
<zmatt>
AM33XX_IOPAD(a, b) is equivalent to (((a) & 0xffff) - 0x800) (b)
<zmatt>
redefining it as ((a) & 0x7ff) (b) would make it accept both the AM335X_PIN_* constants from <dt-bindings/pinctrl/am33xx.h> and the BONE_* constants from <dt-bindings/board/am335x-bbw-bbb-base.h>
demirok has quit [Remote host closed the connection]
lucascastro has quit [Remote host closed the connection]
lucascastro has joined #beagle
vagrantc has joined #beagle
M-blaise has quit [Read error: Connection reset by peer]
M-blaise has joined #beagle
ikarso has quit [Quit: Connection closed for inactivity]
lucascastro has quit [Remote host closed the connection]
M-blaise has quit [Read error: Connection reset by peer]
agrue has joined #beagle
xet7 has joined #beagle
xet7 has quit [Remote host closed the connection]
demirok has joined #beagle
vagrantc has quit [Quit: leaving]
Steve_ has quit [Quit: Leaving]
SJFriedl has joined #beagle
sicelo has quit [Quit: Bye!]
Guest95 has joined #beagle
<Guest95>
Hello. I am looking for some help with my beaglebone blue board. Specifically regarding the encoder channels
sicelo has joined #beagle
sicelo has joined #beagle
akaWolf has quit [Ping timeout: 240 seconds]
<zmatt>
in general, the best way to get help is by asking a specific question such that if someone who knows the answer happens to glance at chat they answer can answer it
<zmatt>
(asking for "help with X" is effectively asking someone for a commitment to help you with something largely unknown in scope, hence has a much lower success rate... or at least will on average require a lot more patience and/or luck)
<Guest95>
Thanks for the advice!
<ds2>
w/o a question, the only answer can be 'rtfm' :D
<Guest95>
I need help troubleshooting my encoder read-out.
<zmatt>
since it has a push-pull output at a supply voltage (min 3.6V typ 5V) which exceeds the I/O voltage of the beaglebone (3.3V)
<Guest95>
Push-pull output?
<zmatt>
as in, something that's actively driven low and high
akaWolf has joined #beagle
<Guest95>
Ohh, I understand
<zmatt>
exceeding the I/O voltage can easily cause permanent damage to the beaglebone
<Guest95>
Do you have any recommended encoders that would apply to the BBB? I have been having trouble finding ones with ppr > 1000
<zmatt>
it just needs to have either 3.3V output or use open-drain/open-collector outputs (i.e. only driven low, not driven high, in which case you'd add pull-ups to the 3.3V of the beaglebone)
<zmatt>
encoders exist in uncountable shapes, sizes, and resolutions
<zmatt>
or if you do want to use one with an incompatible output voltage, like I said you'd need to use a level shifter to convert the encoder's outputs from its I/O voltage to the I/O voltage of the beaglebone
<zmatt>
what supply voltage did you use for the encoder? 5V ?
demirok has quit [Ping timeout: 255 seconds]
<zmatt>
also, rc_encoder_read() returns the position... it doesn't really indicate an error in any useful way since -1 is also a valid return value
<Guest95>
Thanks for the advice.
<Guest95>
Regarding the compatible encoders... I understand there are many out there, I haven't been able to find any. Do you have any recommended websites or sources to share?
<zmatt>
I haven't had any need to search for one myself, so no
<Guest95>
Regarding the level shifter, so the A and B channels would have to be bumped down under 3.3v?
<zmatt>
yeah, high level should be around 3.3V ... minimum value to be considered logic-high is 2.0V
<zmatt>
input must never be exposed to more than 0.3V above the supply voltage (which will be around 3.3V when powered on, and around 0V when powered off)
<Guest95>
Ok. And I will still need to supply the encoder with 5v, right?
<zmatt>
your encoder specifies a minimum supply voltage of 3.6V
<zmatt>
according to its datasheet
<Guest95>
Yup. 3.6V min and 5V typ
<Guest95>
So I will still need a separate supply voltage for that? I guess what I am confused about is what each pin is for on the BBB encoder input. I know there must be an A and B channel, supply voltage, and ground. But, I am not sure which is which
<zmatt>
(and pray you haven't already damaged the pins you've apparently exposed to overvoltage)
<zmatt>
uhh this sounds like we're heading into electronics 101 territory here ;)
<zmatt>
unless you're asking about the pinout of the beaglebone, which I'd need to look up myself, I know there are overviews of that
<Guest95>
Haha possibly. If you have any resources you can point me to, that would be appreciated. As you can tell, I am fairly new to all of this. This is my first project with a BB
<zmatt>
yep.. pin 1 (GND) of each of those headers is also marked with a white dot on the board
<Guest95>
So, to bring it back into to using my current (incompatible encoder).
<Guest95>
I can step up the supply voltage from the beaglebone to apply at least 3.6V to the encoder.
<Guest95>
Then, I can step down the outputs from the encoder channels to be in the range of the beaglebone (about 3.3V)
<Guest95>
Is this reasonable?
<zmatt>
it doesn't really matter from where you obtain the supply voltage for the encoder, as long as it's an appropriate voltage for the encoder.. e.g. the beaglebone also has 5V supply outputs
<zmatt>
you always need a ground interconnection, since all voltages are relative to ground
<zmatt>
of course the best solution is to use an encoder which supports a 3.3V supply voltage... which is also why 3.3V supply is made available on each encoder connector
<Guest95>
Thanks for the reminder on the ground
<Guest95>
Where are these 5V pins on the BBB?
<zmatt>
bbblue ... (BBB = beaglebone black)
<Guest95>
Yeah, 3.3V encoder is ideal if I could find one...
demirok has joined #beagle
<Guest95>
zmatt, could you show me where the 5V pins are on the bbblue?
<zmatt>
but yeah, otherwise use a level shifter... I guess maybe you could get away with using a voltage divider, but there's also the issue of power supply sequencing (the 5V supply comes up before the 3.3V supply comes up) so a proper level shifter would be better
<zmatt>
hrmpf... is sys_5v not available on a header somewhere....
<Guest95>
I see the power out connecter. Do you know what type that is?
<zmatt>
I just remembered that pin 4 of the PWR header and pin 5 of the GSM header are always-on 5V supplies (i.e. they stay powered as long as a battery or power supply is connected, even if the board is shutdown) ... which is not great
<zmatt>
but, what were you using to supply the encoder right now then?
<Guest95>
Alright, just making sure I am looking at the right thing.
<Guest95>
No external supply right now, just the 3.3V from the encoder header
<Guest95>
So, I think I saved the board from getting ruined :)
<zmatt>
ah, yep that means there's no risk you damaged the beaglebone... but presumably you were not getting useful behaviour because the encoder isn't designed to run on 3.3V
<Guest95>
Yup, so I am glad we had this chat before I connected to 5V!
<Guest95>
zmatt, I really appreciate your help with all of this! I look forward to finishing this project! Here is an idea of what I am making: https://www.youtube.com/watch?v=IC8PydEJCXM
<zmatt>
yep, exposing I/O to overvoltage is one of the most effective ways to destroy a board short of using a hammer
buckket has quit [Quit: buckket]
buckket has joined #beagle
Guest95 has quit [Quit: Client closed]
<ds2>
heh... an open collector would solve the sequencing issue nicely
<zmatt>
yep
<zmatt>
I mentioned that earlier
brook has quit [Read error: Connection reset by peer]
brook_ has joined #beagle
<set_>
Hey!
<set_>
I am booting into the AI-64 now.
<set_>
It is hung. How long does it take to handle the boot process for SD Card?
<set_>
Oh. rcn-ee: Also, the etcher source says that the EDGEAI image from the forums "fails."
<set_>
I will try another image.
<set_>
Oops. That booted fast.
<set_>
@zmatt: Is it mmcblk0 or 1 when using blkdiscard?
<zmatt>
on the BBB mmcblk0 = sd card, mmcblk1 = eMMC
<set_>
Oh.
<set_>
I am using the BBAI-64.
<set_>
Oh.
<set_>
mmcblk1 = emmc. Okay.
<zmatt>
I have no idea how the boot process behaves on the AI64
<set_>
Me neither but neither of those commands work.
<set_>
Oh well.
<zmatt>
why are you trying to blkdiscard something?
<set_>
I thought the AI-64 came preinstalled w/ an image on the eMMC.
<set_>
I just wanted to make sure I am using the SD Card.
<zmatt>
is there a reason to assume that would require erasing something?
<set_>
Nope.
<set_>
I attached some random WiFi module from a Lenovo computer to the AI-64.
<set_>
I cannot get the WiFi up yet.
yCrazyEdd is now known as willow
brook_ has quit [Remote host closed the connection]