**** BEGIN LOGGING AT Sat Dec 11 02:59:56 2021
Dec 11 06:25:34 <set_> Otay...I got the BBBlue on but the pru needs to be attached or not to the receiver?
Dec 11 06:25:38 <set_> I am using librobotcontrol.
Dec 11 06:26:05 <set_> I am trying DSM2 RX on the BBBlue and a DSM2 TX to control it.
Dec 11 06:26:18 <set_> Anyway, when people wake up, please say something.
Dec 11 14:23:32 <mattb0ne> zmatt: my ring buffer keeps overflowing!!!!
Dec 11 14:25:02 <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
Dec 11 14:26:33 <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
Dec 11 14:28:53 <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?
Dec 11 14:33:05 <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 ?
Dec 11 14:33:44 <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
Dec 11 14:34:10 <Guest1268> https://pastebin.com/vCDJRUTQ
Dec 11 14:37:11 <Guest1268> here is the output of dmesg
Dec 11 14:37:13 <Guest1268> https://pastebin.com/DqXgUzzU
Dec 11 18:40:08 <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
Dec 11 18:48:06 <mattb0ne> ok
Dec 11 18:48:14 <mattb0ne> will try that
Dec 11 21:34:39 <mattb0ne> zmatt: I do not understand how the batch code works
Dec 11 21:34:52 <mattb0ne> how does it even interface with the ring buffer
Dec 11 21:35:29 <zmatt> what do you mean?  that part hasn't changed at all
Dec 11 21:36:27 <mattb0ne> oh
Dec 11 21:36:29 <zmatt> note that to keep things as simple as possible I also changed the message format slightly
Dec 11 21:36:42 <zmatt> but I also provided matching client code
Dec 11 21:36:45 <mattb0ne> i guess how the write from recv_messages connect to the other code
Dec 11 21:37:24 <zmatt> instead of doing a .write() per message I just gather the data to be written into one big string and write that
Dec 11 21:38:08 <zmatt> I also save time by not updating the user interface for each message but only once per batch
Dec 11 21:38:49 <zmatt> that way make the update rate adaptive: the more time the user interface update takes, the larger the next batch will be
Dec 11 21:38:50 <mattb0ne> ok that makes sense since I do not need that resolution anyway
Dec 11 21:39:42 <mattb0ne> ok I think i get it
Dec 11 21:40:05 <mattb0ne> what was throwing me off was that it was split as two separate pastebins
Dec 11 21:40:11 <mattb0ne> but they are meant to go together
Dec 11 21:40:20 <zmatt> one for the server and one for the client you mean?
Dec 11 21:40:41 <zmatt> I mean, you can batch on either side independently of the other side
Dec 11 21:41:06 <mattb0ne> yeah thoes last two pastes
Dec 11 21:41:37 <zmatt> the only sense in which they "go together" is that both of them use the same message format "timestamp_cycles,force,angle\n"
Dec 11 21:42:15 <zmatt> while you previously used "time,timestamp_label,force_angle\r"
Dec 11 21:43:41 <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
Dec 11 21:43:57 <zmatt> it's just done to improve performance
Dec 11 23:13:43 <Guest1268> Can anyone relate on my thread please ?
Dec 11 23:14:04 <Guest1268> here is the kernel log https://pastebin.com/DqXgUzzU
Dec 11 23:15:00 <Guest1268> and the device tree: https://pastebin.com/KS2fiNSJ
Dec 11 23:15:25 <Guest1268> in fact i'm trying to use a ili9341 TFT display with BBB
Dec 11 23:15:30 <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
Dec 11 23:16:22 <zmatt> and it looks like your gpio controllers are failing to register for some reason
Dec 11 23:16:29 <zmatt> so something is very broken
Dec 11 23:16:58 <zmatt> hmm, it's getting EPROBE_DEFER
Dec 11 23:18:11 <zmatt> hmm okay it looks like they do eventually get registered, but... ugh what a mess
Dec 11 23:18:51 <Guest1268> :/
Dec 11 23:19:05 <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
Dec 11 23:19:52 <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
Dec 11 23:20:04 <Guest1268> hummm okay
Dec 11 23:20:29 <zmatt> it used to be policy to maintain backwards compatibility, but I guess they stopped caring
Dec 11 23:21:28 <Guest1268> what kernel shall i use ?
Dec 11 23:22:46 <zmatt> I mean, that's up to you.  the kernel series used on current beagleboard.org images is the 4.19-ti series
Dec 11 23:23:42 <Guest1268> okay
Dec 11 23:23:54 <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
Dec 11 23:24:33 <Guest1268> i took the from the internet
Dec 11 23:28:26 <zmatt> https://pastebin.com/1gXJpMr5   your dts with broken indentation fixed and nonsense properties removed :P
Dec 11 23:28:43 <zmatt> (and I moved the backlight declaration closer to the lcd panel)
Dec 11 23:29:31 <zmatt> that's not going to fix your problems obviously, but at least it makes the dts easier to read
Dec 11 23:29:51 <Guest1268> Thanks :)
Dec 11 23:30:32 <Guest1268> do you have a github project with a maintained 4.19 kernel ?
Dec 11 23:30:47 <zmatt> me personally? why do you ask?
Dec 11 23:31:21 <Guest1268> not a personal project ?
Dec 11 23:31:42 <Guest1268> i mean a project that i can integrate to my buildroot
Dec 11 23:32:00 <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
Dec 11 23:32:11 <zmatt> but *I* don't have a github project with a maintained 4.19 kernel no
Dec 11 23:33:46 <zmatt> also, I don't know anything about buildroot or how it deals with different kernels
Dec 11 23:35:03 <Guest1268> from what i understand that the problem of interfacing with the ili9341 comes from the kernel that i'm using
Dec 11 23:35:06 <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
Dec 11 23:36:18 <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
Dec 11 23:37:43 <zmatt> hmm, the gpio controllers still have #gpio-cells=<2> so maybe that's not it
Dec 11 23:37:51 <zmatt> then I have no idea what's going on
Dec 11 23:38:48 <Guest1268> :/  i will check the driver of ili9431 too
Dec 11 23:38:55 <Guest1268> thanks anyways :D
Dec 11 23:39:22 <zmatt> it looks like most if not all of these errors are temporary ones though
Dec 11 23:40:38 <zmatt> your driver seems to load:
Dec 11 23:40:41 <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
Dec 11 23:42:20 <Guest1268> yes it is loading the device ... i have the /dev/fb0
Dec 11 23:42:23 <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?
Dec 11 23:42:50 <Guest1268> but the backlight is not working
Dec 11 23:43:38 <zmatt> well there's nothing in the kernel log (or at least the part you pastebinned) that suggests why
Dec 11 23:44:15 <zmatt> does the backlight device show up but not work, or does it not show up at all?
Dec 11 23:44:44 <zmatt> in /sys/class/backlight/
Dec 11 23:44:54 <Guest1268> it is empty
Dec 11 23:45:12 <Guest1268> the /sys/class/backlight is empty
Dec 11 23:45:23 <zmatt> hmm, like it's still getting EPROBE_DEFER or something
Dec 11 23:45:32 <zmatt> yeah dunno
Dec 11 23:48:03 <Guest1268> how can i change it to PWM1B ?
Dec 11 23:48:28 <Guest1268> the pwm_bl_pins
Dec 11 23:49:11 <zmatt> change the second argument of the pwms property of the backlight from 0 to 1, and indeed fix the pinmux
Dec 11 23:50:37 <zmatt> pwm1b is available on P9.16 (also mux mode 6)
Dec 11 23:52:17 <Guest1268> AM33XX_PADCONF(AM335X_PIN_GPMC_A3, PIN_OUTPUT_PULLDOWN, MUX_MODE6)    /* P9_16: ehrpwm1a, MODE6 */
Dec 11 23:52:26 <Guest1268> and
Dec 11 23:52:38 <Guest1268> pwms = <&ehrpwm1 1 500000 0>;
Dec 11 23:53:44 <zmatt> yup, except the comment on the pinmux is wrong obviously since it's ehrpwm1b
Dec 11 23:53:58 <Guest1268> yeah xD
Dec 11 23:58:46 <Guest1268> ouch
Dec 11 23:59:09 <Guest1268> i think that pin-ctrl is enable-gpios
Dec 11 23:59:13 <Guest1268> on 5.10.23
Dec 11 23:59:21 <Guest1268> https://elixir.bootlin.com/linux/v5.10.23/source/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml
Dec 11 23:59:27 <zmatt> enable-gpios is a separate thing
Dec 11 23:59:41 <zmatt> only relevant if your backlight has an enable gpio (separate from the pwm)
Dec 12 00:00:33 <zmatt> it's an optional property
Dec 12 00:02:38 <Guest1268> humm okay :/
Dec 12 00:55:04 <mattb0ne> zmatt:
Dec 12 00:55:13 <mattb0ne> that map line is no good
Dec 12 00:55:24 <zmatt> which one?
Dec 12 00:55:42 <mattb0ne> mat(str,txdata).join(',') + '\n'
Dec 12 00:55:50 <zmatt> oh you're right
Dec 12 00:55:54 <mattb0ne> getting map object does not have join
Dec 12 00:56:03 <zmatt> I tested the client but not the server
Dec 12 00:56:03 <mattb0ne> trying to rewrite it but not getting what I want
Dec 12 00:56:13 <mattb0ne> no biggie
Dec 12 00:56:20 <mattb0ne> i will eventually get it
Dec 12 00:56:28 <mattb0ne> may need multiple lines though =(
Dec 12 00:56:33 <zmatt> wrap the map() in a list(), i.e. list( map( str, txmsg ) ).join(',') + '\n'
Dec 12 00:56:45 <zmatt> or replace both lines by what's in the comment immediately below it
Dec 12 00:58:03 <mattb0ne> ok
Dec 12 00:58:13 <zmatt> honestly the variant in the comment might be clearer
Dec 12 00:58:28 <zmatt> although that's up to you
Dec 12 00:59:21 <mattb0ne> AttributeError: 'list' object has no attribute 'join'
Dec 12 00:59:28 <zmatt> uhh what
Dec 12 00:59:29 <zmatt> hold on
Dec 12 01:00:01 <zmatt> ahhh
Dec 12 01:00:17 <zmatt> txdata += '\n'.join( map( str, txmsg ) )
Dec 12 01:00:53 <zmatt> ehh
Dec 12 01:00:57 <zmatt> txdata += ','.join( map( str, txmsg ) ) + '\n'
Dec 12 01:01:43 <zmatt> in python it's   separator.join( list )  while in javascript it's  list.join( separator )
Dec 12 01:05:36 <mattb0ne> got ya
Dec 12 01:11:45 <mattb0ne> server side is working welll
Dec 12 01:12:08 <mattb0ne> zmatt you are too good
Dec 12 01:12:30 <mattb0ne> I will tackle the client tomorrow
Dec 12 01:12:48 <zmatt> the client should just run
Dec 12 01:13:10 <mattb0ne> yeah I need to drop it in but I want some cake
Dec 12 01:13:11 <mattb0ne> lol
Dec 12 01:13:14 <mattb0ne> and watch TV
Dec 12 01:13:31 <zmatt> that's fair, cake is important
**** ENDING LOGGING AT Sun Dec 12 02:59:56 2021