<set_>
Look at the actual loop back test pin(s) being sourced along w/ the CS line: https://imgur.com/a/wSYXRpB .
<set_>
Wild!
<zmatt>
looks like you're zoomed out too far
<zmatt>
horizontally
<set_>
Argh.
<zmatt>
(and zoomed in too much vertically)
<set_>
Hahah. I cannot describe what actually happened yet. I am studying.
<set_>
I put the channels at 200mV.
<set_>
It was off the screen and i had to put it back once i captured the frequency.
<set_>
Hmm.
m-atoms has quit [Ping timeout: 256 seconds]
<set_>
I got it!
<set_>
Please hold.
<zmatt>
I still have no idea why you're looking at spi signals with a scope in the first place
<zmatt>
everything I've seen so far looked fine to me
<zmatt>
to the (limited) extent this could be determined from your captures
<zmatt>
it's difficult to examine spi properly with a scope that has only two channels
<set_>
Ha. Please hold for this last capture. I finally got it nailed down. Oh?
<set_>
Okay.
<set_>
No issue.
<zmatt>
like, why are you doing this?
<set_>
B/c for one, I need to learn things and secondly, if I am going to handle electronics, I need to know they work to the specified instances of the datasheets, right?
<set_>
@zmatt: Will you please look at this last capture? I am feeling needy!
<zmatt>
I mean, generally you'd assume things work as specified in their datasheets unless you have a specific reason to examine things, e.g. because you're trying to debug a problem
<set_>
Oh.
<set_>
Me on the other hand, right. No, I get it. I get what you are saying. Why me, why would I be doing this now?
<set_>
Well, the BBAI has contenders that do not to this day believe it works, for whatever reason and I am trying to describe it in more ways than just commands, txt files, and explanations.
<set_>
Well, I would not say they believe it is broken/does not work even though I typed it out. I would say people have complications at times w/ hardware and software.
<zmatt>
plenty of people have spi working just fine on the bbai, and now that cape-universal is supported it should be basically as simple as on the bbb
<set_>
Right!
<set_>
I know and it is outstanding.
<set_>
But, the forum people are not understanding it or not believing me for whatever reason. Anyway, I was spreading good cheer.
<zmatt>
set_: ehm, that capture still uses the same terrible scaling
<zmatt>
I still have no idea what you're trying to capture or why, but nobody can tell anything from this
<zmatt>
decrease the time scale (zoom in horizontally) until the signal isn't an amorphous blob anymore and you can actually see anything, reduce the voltage scale (zoom out vertically) for both channels until you can position them to neither go offscreen nor overlap each other
<zmatt>
if the probe gain is correctly configured I'd expect 1V per division to be appropriate instead of 200 mV
<hnv>
Both probes and the scales should be set to x10
<set_>
Whelp. That did it.
<set_>
Okay.
<set_>
Oh.
<set_>
x10. Okay.
<set_>
I had them at x10 and changed it to x1.
<set_>
Well...I will have to learn more before proceeding. I took a break and handled some Bela stuff.
<set_>
Broke it, flipped it, cracked it, and I only have one string to attach! But, I need to get another string, i.e. as I broke that too.
<set_>
Blah.
<set_>
Sometimes I am so close to "stardom" and then flattened like being under a steamroller.
<hnv>
x1 you have an order of magnitude less bandwidth than your scope... x1 may be helpful measuring low amplitude signals, which aren't your case
vagrantc has quit [Quit: leaving]
<set_>
Aw. Okay.
Shadyman has joined #beagle
<set_>
Well, I tried this time to do nothing and got somewhere. I small somewhere but somewhere!
<set_>
I = A. Blah.
thinkfat_ has quit [Ping timeout: 252 seconds]
thinkfat has joined #beagle
<dmh>
im developing on a BBB, was wondering if anyone knows of any docs for the PowerVR SGX530. nothing on imgtec site, well search at least
<dmh>
im not hoping for much other than reverse engineering linux driver mailbox messages or such
<dmh>
ahh it appears to be closed source blob still hrm
<zmatt>
dmh: yeah, the kernel driver is open source (but will make you want to wash your eyes with bleach), the userspace libs are closed
<zmatt>
(I know there's also been a source leak at some point, though you should obviously think carefully before exposing yourself to that if you want to actually _do_ anything with the info)
<dmh>
ah got it thx
rob_w has joined #beagle
fakuivan_ has joined #beagle
ft_ has joined #beagle
dinuxbg_ has joined #beagle
fakuivan has quit [*.net *.split]
johanhenselmans has quit [*.net *.split]
Posterdati has quit [*.net *.split]
ft has quit [*.net *.split]
dinuxbg has quit [*.net *.split]
denix has quit [*.net *.split]
ft_ is now known as ft
Posterdati has joined #beagle
johanhenselmans has joined #beagle
denix has joined #beagle
starblue1 has quit [Ping timeout: 256 seconds]
starblue1 has joined #beagle
Shadyman has quit [Remote host closed the connection]
Guest65 has joined #beagle
<Guest65>
Looking into AI and considering the Beaglebone X15 and AI but both seems to be either obsolete or end of life, is there a new product in the pipeline ?
<zmatt>
Guest65: neither is obsolete or end-of-life
<zmatt>
Guest65: however, manufacturing moved to Seeed Studio, and distibutors may list the same board from the previous manufacturer as EOL
rob_w has quit [Remote host closed the connection]
<rcn-ee>
zmatt: so that "specific" was built by Element 14, and sold thru Seeed, at some point Seeed will actually build a version.
buzzmarshall has joined #beagle
<zmatt>
and that results in again a new product code? o.O
<zmatt>
confusing
Guest65 has joined #beagle
m-atoms has joined #beagle
Guest65 has quit [Ping timeout: 256 seconds]
argonautx has quit [Quit: Leaving]
Guest65 has joined #beagle
Guest65 has quit [Client Quit]
CrazyEddy has quit [Ping timeout: 250 seconds]
argonautx has joined #beagle
CrazyEddy has joined #beagle
buzzmarshall has quit [Ping timeout: 240 seconds]
buzzmarshall has joined #beagle
buzzmarshall has quit [Client Quit]
buzzmarshall has joined #beagle
otisolsen70 has quit [Quit: Leaving]
Angel_Sosa has joined #beagle
<Angel_Sosa>
Does anyone have an idea why GPIO mapping would be remapped so that they are not consistent
<Angel_Sosa>
I am using Linux beaglebone 5.10.90-bone-rt-r60 #1buster SMP PREEMPT Fri Jan 28 06:47:22 UTC 2022 armv7l GNU/Linux
<Angel_Sosa>
I have disabled all of the overlays to no avail
<zmatt>
I mean, gpio numbering was never guaranteed to be consistent, people merely just assumed it was, though this is the first time I've heard of that finally manifesting itself for platform gpio devices.... is it specific to the -rt kernel? maybe it uses multi-threaded probing of devices
ikarso has joined #beagle
<zmatt>
Angel_Sosa: it's why I personally use an udev rule to create symlinks by name, e.g. with cape-universal that yields: https://pastebin.com/raw/0pawbJK2 although I personally prefer declaring the gpios in DT myself instead of using cape-universal, allowing them to be individually named by function and be given appropriate setup: https://pastebin.com/YKW7Wcqu
argonautx has quit [Quit: Leaving]
<Angel_Sosa>
If you look hard enough you will find articles. I have read a handful with vary valid reason why the GPIO mapping are thrown off
<Angel_Sosa>
I learned how to figure out what the actual mapping are so thats a good thing
<zmatt>
I've only ever seen it happen with i2c/spi-attached gpio controllers
<Angel_Sosa>
I had already started to consider creating my own version of a DT. Possibly I could guarantee the mapping that way
<zmatt>
platform gpio controllers normally get probed in predictable order, at least on any kernel I've used... but it makes sense if newer kernels spread device-probing across multiple threads (either in general or specifically in -rt)
<Angel_Sosa>
I cant explain why it has happened . I just know it has. No big deal I am adapting
<zmatt>
no, you can't guarantee the mapping, but using gpio-of-helper (if it's been forward-ported to 5.10 yet) you can provide names and custom config
<Angel_Sosa>
Got it
<Angel_Sosa>
It could be because I am using beaglebone 5.10.90-bone-rt-r60 version. The good thing is that I have another SD card and mount another image type and see the results. but in the end it taught me how to rediscover the mapping and associations
<zmatt>
and with an udev rule to create symlinks, applications can open individual gpios by name without having to know or care about gpio numbering
<Angel_Sosa>
I am with you
<Angel_Sosa>
Its like DNS use the name and let the underlying mapping change all day long
<zmatt>
exactly, which is particularly nice if you have multiple revisions of a custom pcb and needed to move gpios around... you then only need to update the DT but applications can work the same across revisions
<hnv>
out of curiosity, why a recent kernel by rcn is needed for your gpio-demo.dtsi?
<zmatt>
I mean, in the time that has passed, "recent" now means "not ancient"
<zmatt>
like. 4.9 or later iirc
<zmatt>
I submitted some patches to gpio-of-helper back then
<zmatt>
it used to require more verbosity / pointless redundancy in its DT declarations
<zmatt>
my patch also added the label property in sysfs used by the udev rule
Angel_Sosa has quit [Quit: Client closed]
Angel_Sosa has joined #beagle
<hnv>
that's a really nice repository zmatt (overlay-utils)
<set_>
Hmm. It seems when I use sudo ./spidev_test, the system now thinks I can only r/w to that char device for SPI under root. Does this sound normal?
<zmatt>
set_: no, you broke things probably, you should not use sudo for spi