07:35 <Guest30> Hi I need some assistance regarding interfacing of lcd with beagle bone black can someone please help me ?

08:24 <Guest55> i can not power on my beaglebone，what the problem

08:42 <set_> The quad is on a paint can and moving!

08:42 <set_> Ha.

08:43 <set_> It is freakin' scarier than once anticipated.

08:43 <set_> Ha.

08:43 <set_> The source needs altering, i.e. as usual.

08:43 <set_> It tried to alter my paint bucket.

08:52 <set_> 45 degrees was the secret for the servos that turn the legs in and out at 180 degrees!

08:56 <set_> wait for video!

09:02 <set_> It was way more intense the second time I sent commands to it. Now, watching the video, notta. Cool beans!

09:09 <set_> anyway, do not laugh too hard. IT is my first one...

09:10 <set_> The 3D stuff came out incorrect and the battery is put on top for testing purposes w/ rope. Yes...rope.

09:21 <set_> Laugh ahoy! https://vimeo.com/801890542

09:24 <set_> I do not have wifi on the pup yet... Time will tell...

09:27 <set_> Something has changed too. The .py file runs fine as a server but the .service file no longer runs.

09:27 <set_> I will try to dig into why this is taking place.

11:01 <Guest55> Hello guys I am new to beaglebone black can any1 help me to get started with it

11:44 <set_> I g o t it!

11:44 <set_> server...she be a runnin' man!

11:57 <set_> I keep forgetting, if you use a specific kernel version, one would also need to research what was available when that kernel was around...

11:58 <set_> Odd days! note to my future self: Wake up GenTooMan to see the quadruped!

14:26 <petrosky> Hi everybody.  I am working with PRU on beaglebone green. I have some issuses when I try to use the timer on ECAP.  How can I read some manual about resource table configuration?

14:26 <petrosky> sorry, where I can found a manual about resource table configuration?

14:27 <petrosky> I had looking for information on google,  but I cannot found nothing.

15:44 <zmatt> petrosky: I don't really know much about remoteproc-pru (I use uio-pruss), but why would you need any resource table configuration for ecap timer usage? isn't the resource table for declaring stuff that's shared between linux and pru?

15:58 <zmatt> the pru ecap isn't even declared in DT so the linux kernel can't possibly know or care about your usage of the pru ecap

16:01 <petrosky> zmatt: You are right, eCAP is a peripheral inside PRU that doesn't share resources with linux, I readed something about it on this link:

16:01 <petrosky> https://software-dl.ti.com/processor-sdk-linux-rt/esd/AM335X/08_02_00_24/exports/docs/common/PRU-ICSS/Resource_Tables.

16:01 <petrosky> html

16:01 <petrosky> Do you have information about how to configure a resource table?

16:01 <petrosky> https://software-dl.ti.com/processor-sdk-linux-rt/esd/AM335X/08_02_00_24/exports/docs/common/PRU-ICSS/Resource_Tables.html

16:02 <zmatt> I don't see anything there about ecap

16:05 <zmatt> though the page does explain that the resource table is only relevant if you use RPMsg or (in kernel 5.4 or earlier) need the intc configured

16:05 <zmatt> and they reference specific examples you can examine

16:07 <zmatt> the resource table is just a data structure declared by your PRU program with information for the linux kernel

16:09 <petrosky> I have 2 codes, one for rpmsg and works fine, second one uses a timer on eCAP and works fine, but when I put together these 2 codes, the timer doesn't work, I think is something about intc. intc is configurated into resource table, right?

16:10 <zmatt> intc is configured in the resource table yes... typically you wouldn't use the intc for ecap but I suppose you might if you're doing rpmsg on the same pru core

16:12 <zmatt> or maybe you're just doing something wrong with how you're combining the two programs

16:13 <zmatt> honestly even if you're doing rpmsg on the same core, I still don't see much reason to route it via intc

16:20 <petrosky> zmatt: I need to launch some processes at exactly the right time, this is why I use a eCAP timer not a delay for example. I am going to find how to use eCAP timer without intc

16:22 <zmatt> petrosky: so, in the rpmsg examples there's a main loop (the while(1) in main()) that checks if the INTC has an event, it then assumes this event is the rpmsg kick event (it doesn't check whether this is true), clears this event, and proceeds to process rpmsgs in a loop until there are no more available

16:22 <zmatt> if you want to use ecap as a timer you can just check whether your timer has expired in the top-level of that loop

16:23 <zmatt> I'd also suggest making sure at most one rpmsg is processed per loop iteration to minimize jitter of your timer event handler

16:26 <zmatt> petrosky: something like https://pastebin.com/JdXRdujN

16:27 <zmatt> (this rpmsg handling is of course just the echo example, you should substitute your own handling)

16:28 <zmatt> this also means you can just have ecap be free-running and don't need to configure your timer deadline in ecap, you can just keep it in software (which also makes it easy to have multiple timers if needed)

16:33 <zmatt> you could instead use ecap as actual timer and have it generate an event in intc, but then you'd either need to route it to the other r31 bit (there's an intc output that goes to bit 30 of r31 of both pru cores and an output that goes to bit 31 of r31 of both pru cores) or you'd need to actually check in the intc what event has been triggered and dispatch accordingly

16:35 <zmatt> this is more complex and the time saved by not checking the time each main event loop iteration is negligible (a few cycles) and almost certainly negated by the additional time spent in the more complex interrupt dispatching (and additional work you'd need to do in the ecap registers)

16:37 <zmatt> note that rpmsg is slow and non-deterministic (since it involves reading from ddr3 memory) so using rpmsg will unavoidably reduce the timing accuracy of anything else you do on the same pru core

16:38 <zmatt> oh I just noticed I fucked up the code I just pastebinned

16:38 <zmatt> fixed -> https://pastebin.com/eeE6ScGJ

16:40 <petrosky> zmatt:  Thanks a lot for your explanation

17:13 <zmatt> petrosky: https://pastebin.com/ssWyGgVZ .. something like that would be the idea... there's many ways of course to implement timers with different trade-offs

17:17 <zmatt> lol I misspelled timestamp as timerstamp

23:46 <set_> Did anyone see my fun video?

23:47 <set_> And by see "my fun video," I mean add salutations and/or poor remarks?

23:48 <set_> It is not beagleboard.org worthy...

23:48 <set_> YET!

23:48 <set_> It will get there in time. First come, first serve.