<zmatt> you'll obviously also need to fix your lcd_ctrl_pins ... hopefully from this example it should be clear to do so, just look up the pin names in the spreadsheet I linked
<metgros> yes i will
<zmatt> also, remove that master@0 block in your &i2c1, it is complete nonsense
<zmatt> nothing about that declaration makes sense
<metgros> do you have a good documentation on the syntax of DTS please ?
<zmatt> https://pastebin.com/XC8vB33d is a summary of the syntax of DTS in general
<zmatt> (but doesn't include anything specific to any binding)
<metgros> thanks
mattb0ne has quit [Ping timeout: 260 seconds]
<metgros> don't know if it is working or not
<metgros> but now it is saying
<metgros> can't parse 'enable-gpios' property of node '/backlight
<zmatt> that's rather odd since you didn't declare any (and it's not a required property)
<metgros> i corrected the lcd_ctrl_pins
metgros has quit [Ping timeout: 256 seconds]
Shadyman has joined #beagle
nparafe has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
nparafe has joined #beagle
<set_> Is there a simple script to handle the spidev_test file instead of compiling the entire kernel?
<set_> I tried to just compile the script but it is not making "waves" so far.
<set_> Yay!
<set_> The source has changed to mean/differ a bit.
<set_> Why would OCTAL not be okay but DUAL be okay in the spidev_test.c file for testing in a loopback interface?
<zmatt> none of dual/quad/octal are supported
<set_> b/c of it not being ASCII, 8-bit/1-byte? Or is that a short?
<set_> Oh.
<set_> I got DUAL to work.
<zmatt> no you didn't
<set_> Oh?
<zmatt> the hardware doesn't support it
<set_> The source compiled.
<set_> Oh.
<set_> Got you.
<set_> Hmm.
<set_> What should be in its place?
<set_> QUAD is out too. Okay.
<zmatt> nothing, just the defaults
<zmatt> spidev_test is not particularly useful anyway
<set_> I compiled the source w/ the defaults and it did not work. I got the errors about OCTAL...oh.
<set_> Okay.
<zmatt> ehm, these are all commandline options passed when you run it
<zmatt> not when it's compiled
<set_> Let me show you the source.
<zmatt> why? I know what program you're referring to
<set_> But...
<set_> In that file, the octal is not compiling while the dual is compiling.
<zmatt> what do you even mean by that?
<set_> What does this mean?
<set_> Okay. Let me show you.
<zmatt> this is a single program, it either compiles or it doesn't
<set_> I changed the source to handle what compiles due to what is on the BBAI.
<zmatt> oh I see, the SPI_TX_OCTAL and SPI_RX_OCTAL are fairly new and not in the older headers installed on the current image
<set_> if (mode & SPI_TX_QUAD) is a line to handles modes. But, when I installed the source on the BBAI, it seemed that the, right.
<set_> Right.
<set_> Okay.
<set_> So, SPI_TX_OCTAL was not working b/c of some header files that are "out-dated".
<zmatt> well the mode itself won't work regardless since it's not supported, but to get the code to compile you'd need a small fix of the source code to provide those constants if missing from the header
<set_> Right.
<set_> That is all I did.
<set_> So, I was moving back in time when I thought I was moving forward. Ha.
<set_> I am trying to help this person handle their /dev/spidevX.X peripherals on their BBAI but it seems hopeless right now.
<set_> Mine works but this person keeps trying to use two peripherals that cannot work for his/her /dev/spidevX.X instances.
<zmatt> set_, I'm not going to try to debug a vague issue by someone else that's being paraphrased confusingly by you
<set_> I know.
<set_> I just wanted to discuss it. No issue.
<set_> Off to try to debug someone else's issue(s).
vagrantc has joined #beagle
starblue has quit [Ping timeout: 250 seconds]
starblue has joined #beagle
thinkfat_ has joined #beagle
thinkfat has quit [Ping timeout: 260 seconds]
lucascastro has joined #beagle
lucascastro has quit [Remote host closed the connection]
vagrantc has quit [Quit: leaving]
ikarso has joined #beagle
buzzmarshall has quit [Quit: Konversation terminated!]
<set_> Otay...I got the BBBlue on but the pru needs to be attached or not to the receiver?
<set_> I am using librobotcontrol.
<set_> I am trying DSM2 RX on the BBBlue and a DSM2 TX to control it.
<set_> Anyway, when people wake up, please say something.
nparafe has quit [Ping timeout: 256 seconds]
nparafe has joined #beagle
nparafe has quit [Ping timeout: 256 seconds]
nparafe_ has joined #beagle
vd has quit [Ping timeout: 256 seconds]
ikarso has quit [Quit: Connection closed for inactivity]
otisolsen70 has joined #beagle
set_ has quit [Remote host closed the connection]
Shadyman has quit [Remote host closed the connection]
lucascastro has joined #beagle
lucascastro has quit [Ping timeout: 252 seconds]
lucascastro has joined #beagle
lucascastro has quit [Remote host closed the connection]
mattb0ne has joined #beagle
<mattb0ne> zmatt: my ring buffer keeps overflowing!!!!
<mattb0ne> i tried option 1 of the two pastebins and just changed the data emmitter to just a write of the string with no delays and stuff. I can run for about 2 minutes before the ring buffer causes the PRU to abort
<mattb0ne> if I run without sending data over the TCP it runs fine. The key from my testing is that widx updates properly. when I do not send data widx updates with the same frequency as ridx and I never have a problem with the buffer spilling over
meta has joined #beagle
meta is now known as Guest1268
<mattb0ne> when it crashes I notice that widx updates less and less frequently and eventually ridx == widx and the code blows up. I am not sure what causees widx to slow down that is controlled by the PRU right?
<mattb0ne> when just deleting msg from the buffer ridx and widx run in lock step. When it is going to blow up the jumps in the widx counter increases in increments of a few 100 to 8000 or so over the course of 2 minutes before crashing. How can I avoid this ?
<Guest1268> Hello, i'm trying to connect a TFT ili 9341 to my BBB i ve modified the device tree as bellow and added the PWM backlight and the ili9341 drivers
<Guest1268> here is the output of dmesg
vd has joined #beagle
<zmatt> mattb0ne: I guess I underestimated how much data is being buffered by the kernel, so the write() calls never end up doing buffering in python but instead pass the data to the OS every time (which is slow)... solution is to do batching in the writer, like I showed in another pastebin
<mattb0ne> ok
<mattb0ne> will try that
mattb0ne has quit [Ping timeout: 256 seconds]
lucascastro has joined #beagle
xet7 has quit [Ping timeout: 250 seconds]
xet7 has joined #beagle
otisolsen70 has quit [Quit: Leaving]
ikarso has joined #beagle
mattb0ne has joined #beagle
<mattb0ne> zmatt: I do not understand how the batch code works
<mattb0ne> how does it even interface with the ring buffer
<zmatt> what do you mean? that part hasn't changed at all
<mattb0ne> oh
<zmatt> note that to keep things as simple as possible I also changed the message format slightly
<zmatt> but I also provided matching client code
<mattb0ne> i guess how the write from recv_messages connect to the other code
Guest6 has joined #beagle
<zmatt> instead of doing a .write() per message I just gather the data to be written into one big string and write that
<zmatt> I also save time by not updating the user interface for each message but only once per batch
<zmatt> that way make the update rate adaptive: the more time the user interface update takes, the larger the next batch will be
<mattb0ne> ok that makes sense since I do not need that resolution anyway
<mattb0ne> ok I think i get it
<mattb0ne> what was throwing me off was that it was split as two separate pastebins
<mattb0ne> but they are meant to go together
<zmatt> one for the server and one for the client you mean?
<zmatt> I mean, you can batch on either side independently of the other side
<mattb0ne> yeah thoes last two pastes
<zmatt> the only sense in which they "go together" is that both of them use the same message format "timestamp_cycles,force,angle\n"
<zmatt> while you previously used "time,timestamp_label,force_angle\r"
<zmatt> but the choice to batch or not is an implementation detail, the client doesn't know or care whether the server uses batching, the server doesn't know or care whether the client uses batching
<zmatt> it's just done to improve performance
Shadyman has joined #beagle
<Guest1268> Can anyone relate on my thread please ?
<Guest1268> here is the kernel log https://pastebin.com/DqXgUzzU
<Guest1268> and the device tree: https://pastebin.com/KS2fiNSJ
<Guest1268> in fact i'm trying to use a ili9341 TFT display with BBB
<zmatt> Guest1268: first of all, when I said to remove the master@0 node in &i2c I mean the entire node including contents, not move its nonsensical properties to the parent node
<zmatt> and it looks like your gpio controllers are failing to register for some reason
<zmatt> so something is very broken
<zmatt> hmm, it's getting EPROBE_DEFER
<zmatt> hmm okay it looks like they do eventually get registered, but... ugh what a mess
russ has quit [Ping timeout: 250 seconds]
<Guest1268> :/
<zmatt> yeah dunno what's going on here, probably something particular to these 5.x kernels, I haven't yet tried to run one on a beaglebone yet
<zmatt> all these parse errors suggest to me maybe the format for gpio references has also changed, which would be incredibly rude but they already broke backwards compatibility in other ways so who knows
<Guest1268> hummm okay
<zmatt> it used to be policy to maintain backwards compatibility, but I guess they stopped caring
<Guest1268> what kernel shall i use ?
<zmatt> I mean, that's up to you. the kernel series used on current beagleboard.org images is the 4.19-ti series
<Guest1268> okay
<zmatt> why are there #address-cells and #size-cells properties in your lcd node? that doesn't make sense, an lcd panel is not a bus
<Guest1268> i took the from the internet
<zmatt> https://pastebin.com/1gXJpMr5 your dts with broken indentation fixed and nonsense properties removed :P
<zmatt> (and I moved the backlight declaration closer to the lcd panel)
<zmatt> that's not going to fix your problems obviously, but at least it makes the dts easier to read
<Guest1268> Thanks :)
<Guest1268> do you have a github project with a maintained 4.19 kernel ?
<zmatt> me personally? why do you ask?
<Guest1268> not a personal project ?
<Guest1268> i mean a project that i can integrate to my buildroot
<zmatt> note that I'm just a random beaglebone user, if you meant to ask whether beagleboard.org has a maintained 4.19 kernel then the answer is yes
<zmatt> but *I* don't have a github project with a maintained 4.19 kernel no
<zmatt> also, I don't know anything about buildroot or how it deals with different kernels
<Guest1268> from what i understand that the problem of interfacing with the ili9341 comes from the kernel that i'm using
<zmatt> the primary repo for the 4.19-ti kernel series used on beagleboard.org images is https://github.com/RobertCNelson/ti-linux-kernel-dev/tree/ti-linux-4.19.y which contains patches and scripts that directly build a debian package for the kernel
<zmatt> Guest1268: I have no idea what your problems are, but there's clearly issues with your dts and the errors seem to imply there's a problem with your gpio declarations (even though they look fine to me), so my wild guess is that maybe they changed the structure of gpio references
<zmatt> hmm, the gpio controllers still have #gpio-cells=<2> so maybe that's not it
<zmatt> then I have no idea what's going on
<Guest1268> :/ i will check the driver of ili9431 too
<Guest1268> thanks anyways :D
<zmatt> it looks like most if not all of these errors are temporary ones though
<zmatt> your driver seems to load:
<zmatt> [ 4.283029] graphics fb0: fb_ili9341 frame buffer, 320x240, 150 KiB video memory, 16 KiB buffer memory, fps=50, spi1.0 at 25 MHz
<Guest1268> yes it is loading the device ... i have the /dev/fb0
<zmatt> these "errors" from of_get_named_gpiod_flags() seem to be erroneous... are they logged as actual errors or are they logged as debug messages?
<Guest1268> but the backlight is not working
<zmatt> well there's nothing in the kernel log (or at least the part you pastebinned) that suggests why
<zmatt> does the backlight device show up but not work, or does it not show up at all?
<zmatt> in /sys/class/backlight/
<Guest1268> it is empty
<Guest1268> the /sys/class/backlight is empty
<zmatt> hmm, like it's still getting EPROBE_DEFER or something
<zmatt> yeah dunno
<Guest1268> how can i change it to PWM1B ?
<Guest1268> the pwm_bl_pins
<zmatt> change the second argument of the pwms property of the backlight from 0 to 1, and indeed fix the pinmux
<zmatt> pwm1b is available on P9.16 (also mux mode 6)
<Guest1268> AM33XX_PADCONF(AM335X_PIN_GPMC_A3, PIN_OUTPUT_PULLDOWN, MUX_MODE6)    /* P9_16: ehrpwm1a, MODE6 */
<Guest1268> and
<Guest1268> pwms = <&ehrpwm1 1 500000 0>;
<zmatt> yup, except the comment on the pinmux is wrong obviously since it's ehrpwm1b
<Guest1268> yeah xD
<Guest1268> ouch
<Guest1268> i think that pin-ctrl is enable-gpios
<Guest1268> on 5.10.23
<zmatt> enable-gpios is a separate thing
<zmatt> only relevant if your backlight has an enable gpio (separate from the pwm)