<nmingotti>
i go to sleep, I will bring with me the AM572x manual ... and i hope for the best ;) tomorrow i will test with my other unit
<nmingotti>
if all go wrong i guess i need to use an Arduino to power-on / power-off the BB-AI, i would really prefer not to take that road
<nmingotti>
bye guys, goodnight
<nmingotti>
ds2, as for the "why", something you want them to be by default OFF, some others you want to be by default ON. That is the reason why i guess they are not all set to pullDown. (i am not an EE, i could be fully wrong).
nmingotti has quit [Ping timeout: 256 seconds]
<ds2>
i know how to toggle it
<ds2>
and 'why' is not about why a PD/PU is needed. It is more of - why was that decided as the default. It sounds like it is just the HW power on defaults not a beagle choosen default
ikarso has quit [Quit: Connection closed for inactivity]
<zmatt>
ds2: correct... why would you intentionally toggle the pull during boot? that just means external hw can't rely on the pin keeping its reset-default pull until properly configured
<zmatt>
pins will necessarily have their reset-default state for some amount of time (possibly indefinitely if boot fails) hence external hardware already needs to account for that state
<zmatt>
so it's better to just keep that state until the pin is intentionally configured by the user to be anything that isn't the reset default
vagrantc has quit [Quit: leaving]
Shadyman has joined #beagle
starblue1 has quit [Ping timeout: 250 seconds]
starblue1 has joined #beagle
<set_>
Hey!
<set_>
I just wanted to say, "Hey!"
thinkfat has joined #beagle
thinkfat_ has quit [Ping timeout: 256 seconds]
<set_>
The command reset works!
<set_>
brb
set_ has quit [Remote host closed the connection]
set_ has joined #beagle
<set_>
@zmatt: Did you see my latest post? I showed what happens on Win 11 machines w/ the cat /etc/dogtag and uname -r commands.
<set_>
I know it is not a Linux machine, yet. But...the machine I use to BBB' is showing some oddities.
<set_>
This may be useful for people not understanding this idea of error and malfunction.
<set_>
I know there are only five minutes left in chat time but...
<set_>
Here goes it!
<set_>
Do you think that the USB-C to USB 3.0 when not correctly sourced would create a "malfunction" like this post I made?
<set_>
For instance, it shows SS on the port but the port is black and not blue.
<set_>
I may have been tricked?
<set_>
Do you think that USB 3.1 v1 or v2 would be better for connection host to target for the BBAI, i.e. rather than USB 3.0?
<set_>
Anyway. Past 10:00. Until tomorrow!
dmh has joined #beagle
<ds2>
think that reasoning went out the window with the "no need to write your own DT/Uboot mod/x-loader mod idealogy"
<ds2>
but that at least is a sign of sanity
<zmatt>
?
<ds2>
sorry, <zmatt> ds2: correct... why would you intentionally toggle the pull ....
<zmatt>
whether the final configuration is applied by a custom DT, DT overlay, or using config-pin is immaterial
<zmatt>
I don't see your point
<ds2>
a custom x-loader would minimize the potential time of conflict
<ds2>
or MLO or whatever name of the day/flash :D
<zmatt>
"conflict" ? if there's "conflict" you misdesigned the hardware
<ds2>
there are times when you don't have a choice... i.e out of routing resources or free GPIOs :/
<zmatt>
if the reset-default pull is not what you need in a particular purpose, use a pin that has the desired default pull or override the internal pull with stronger external pull
<zmatt>
the internal pull is kinda mostly just to keep pins from floating anyway
<ds2>
i understand all that... I am just trying to see where the default images land things
<zmatt>
I'm assuming/hoping they preserve the reset defaults, I haven't actually verified
<ds2>
oh :D
<zmatt>
cape-universal is not devoid of flaws ;P
<ds2>
discovered this while trying to be lazy - wiring in push button switches w/o external pulls
<zmatt>
I mean, you can do that just fine as long as you setup the pin correctly
<ds2>
even resorted to use plug in breadboards and loose random plug in wires :D
<ds2>
for the next experiment - hot plug I2C :D
<zmatt>
ah, you want to test the driver's fault recovery code?
<zmatt>
since the omap-i2c controller's state machine will lock up if you pulse the sda line low :D
<ds2>
well, I am hoping it won't come to that... I am isolating it with a I2C 1:8 mux - sw will switch to a terminated port (just pull ups) and switch back when the new device is detected
<ds2>
I hope that condition is detectable and that block can at least recover with a block reset
<zmatt>
yeah the driver should detect it and recover
<zmatt>
iirc
<ds2>
if all goes well, I'll find out if the driver notices this weekend
<ds2>
what I am a bit worried about is - will the i2c device drivers propertly disconnect
<zmatt>
if you manually unbind them you mean?
<zmatt>
great question, that might not be well tested :D
<ds2>
yeah... that sysfs incantation
<zmatt>
ds2: cape-universal's defaults match the reset defaults for the non-eMMC non-HDMI pins (i.e. the pins for which cape-universal is enabled in the default config), but its defaults for the eMMC/HDMI pins (when these functions are disabled in /boot/uEnv.txt) could use improvement: https://pastebin.com/raw/UXa6U9ft
<zmatt>
pulling down the eMMC pins is pointless, it's overpowered by the external pullups
<zmatt>
and it probably ought to leave the sysboot-pins high-z, or at least not create a pull-up/down conflict with the external weak pulls
<ds2>
pulling down against external pull up is just a bad idea
<ds2>
(from a heat and a noise prospective)
<zmatt>
the internal pull is fairly weak anyway... but yeah it's definitely suboptimal
ikarso has joined #beagle
rob_w has joined #beagle
florian has joined #beagle
<zmatt>
set_: absolutely nothing in your long post in nmingotti's thread is even remotely relevant to the topic
<jfsimon1981>
Good morning,
<jfsimon1981>
Do you know if Gnd and Analog ground can be safely tied together ?
argonautx has joined #beagle
<zmatt>
jfsimon1981: in fact it's recommended to do so unless you're very confident you know what you're doing
<zmatt>
worst case if you tie them together you might end up picking up some digital noise on your analog inputs
<zmatt>
then again, if you don't worst case is you end up accidently making a nice antenna for picking up random crap on your analog inputs ;)
<jfsimon1981>
ok
<jfsimon1981>
no i don't intend to do so
<jfsimon1981>
it's better be stable, right i'll do the tie thanks
<jfsimon1981>
i don't intend to do rf listenig i mean, those are only analog inputs for pot and battery in fact
<zmatt>
right, but unfortunately just because you don't intend to do rf listening doesn't mean you won't pick any up ;)
<zmatt>
if only EMI were that easy
<jfsimon1981>
i learnt some type of capacitors are kind of shielded on one end, so that you put the pin on lower impedence or ground, and the capacitor behaves real properly.
<jfsimon1981>
Was measureing that yesterday and that's real, if the cap is measures on a scope in a way, it's reading 0V, on the other way, it picks up my noise a i serve antenna, about 1v 50 Hz
<jfsimon1981>
interesting. That's on another topic, old analog scope repairs from the 60's
starblue1 has quit [Ping timeout: 250 seconds]
starblue1 has joined #beagle
Shadyman has quit [Remote host closed the connection]
otisolsen70 has joined #beagle
zjason` has joined #beagle
zjason has quit [Ping timeout: 256 seconds]
zjason` is now known as zjason
otisolsen70_ has joined #beagle
otisolsen70 has quit [Ping timeout: 256 seconds]
otisolsen70 has joined #beagle
otisolsen70 has quit [Client Quit]
otisolsen70_ has quit [Ping timeout: 240 seconds]
buzzmarshall has joined #beagle
florian has quit [Quit: Ex-Chat]
Guest93 has joined #beagle
<Guest93>
I am working on the beaglebone AI to implement SPI pin outs with a dts overlay file. I am a little confused on where exactly I export the overlay for beaglebone AI I have seen many videos on BBB but they go into a directory that doesn't exist for BB AI.
<hnv>
in uEnv.txt: uboot_overlay_addr7=/lib/firmware/overlay.dtbo
<hnv>
with enable_uboot_overlays=1, also you should check if any pin is in conflict with cape-universal
<Guest93>
Thank you
<zmatt>
note that overlays and cape-universal on the BBAI is a fairly recent development and not in the official released image, I think you'd need a testing image or manually update certain stuff
<zmatt>
(also, with caoe-universal you don't really need an overlay for spi)
<zmatt>
8cape
<zmatt>
*cape
<Guest93>
caoe-universal?
<zmatt>
cape-universal
<zmatt>
the thing that makes runtime pin configuration using config-pin work
Guest93 has quit [Quit: Client closed]
<rasenrino>
you can get download the pinmux tool from ti and use it, just you will have to select am5728
Guest93 has joined #beagle
Guest93 has quit [Client Quit]
<zmatt>
you can, but that way sucks since you have to build a custom u-boot
<zmatt>
that's the official route, but not exactly convenient
<rasenrino>
fair enough, i usually use the one from the survival guide and just make additions to it and it has worked fine for me
<rasenrino>
although, any help with pru will be appreciated right now, i have hit a slump
<zmatt>
it's not clear to me what you're trying to do
<rasenrino>
okay so ...i am trying to communicate between the prus, using scratchpad , i try towrite using one of the core, but cant read from the another core
<zmatt>
but what you pasted contains both send and receive code in the same file, and you're also checking an interrupt bit but it's not clear what you're doing with that or how it's getting signalled
<rasenrino>
okay so what i do is i compile a binary with send commented, and put it in pru0 , and then i compile with recieve commented in pru1 , so pru1 gets the send part and pru 0 gets the recieve part
<rasenrino>
as you can see either send or recieve will be commented in the main function
<zmatt>
okay, that's rather unclear and inconvenient... why aren't you just using two separate files? anyway, core-to-core transfer using xfr 14 requires that one core executes the xin at pretty much the same time as the other core executes the xout... like, if the other side isn't ready the core will wait briefly, but only up to 1024 cpu cycles (after which an error is signalled)
<rasenrino>
pardon me for that. but if you take a look i am using mode 10
<zmatt>
ah, sorry
<rasenrino>
i am tyring to write to scratchpad bank 0 and read from it later
<rasenrino>
i can write to the same pru and read it back
<rasenrino>
but cant do it with a different pru core
<zmatt>
that's weird, the scratchpads should be shared between the cores... as long as you're using the two cores of one pruss (keep in mind the am572x has two independent pru subsystems)
<rasenrino>
about the subsystems , do you mean pru10 and pru01 are a part of a single subsystem and cant access stuff from the pru2x?
<rasenrino>
but the trm shows a scratchpad memory shared between both pru cores
<zmatt>
pruss1 and pruss2 are completely separate... the options for interaction between them are basically the same as the options for interaction between a pruss instance and the arm: shared memory and/or interrupts
<zmatt>
yes, between the two cores of one pruss
<zmatt>
each pruss has two cores
<zmatt>
but while the am335x has only one pruss (two pru cores total), the am572x has two pruss instances, each having two pru cores (for a total of four pru cores)
<zmatt>
and each pruss has its own scratchpads, shared between the two cores of that pruss
<zmatt>
(along with its own local memory, peripherals, interrupt controller, etc)
<rasenrino>
ouch , i get it now why it was not working , much thanks
argonautx has quit [Quit: Leaving]
nmingotti has joined #beagle
rasenrino has quit [Quit: Client closed]
rob_w has quit [Read error: Connection reset by peer]