**** BEGIN LOGGING AT Wed Nov 17 02:59:57 2021 Nov 17 03:26:46 I am too scared to open them. What if they are not as they are stated to be in resemblence? Nov 17 03:27:01 Too shakes! Nov 17 03:27:24 * set_ shakes in agony Nov 17 03:30:21 They are gorgeous and not black? Nov 17 03:30:28 THey are purple. Nov 17 03:30:29 Hmm. Nov 17 03:30:48 Well, time to make something... Nov 17 03:31:06 Settle for ashes and receive volcanos! Nov 17 03:35:32 States Made In Germany but I know! Nov 17 04:35:51 Hi, Anyone here has experience with programming PRU on BBB Nov 17 04:36:46 I am going through PRU cookbook and having trouble toggling the GPIO pins with the PRU Nov 17 04:48:38 I do have a fair bit of experience with pru... I'm not really awake yet though -.- Nov 17 04:49:33 Thats great, happy to wait whenever you are Nov 17 04:51:03 (I've also written the py-uio python library that can be used to load code onto PRU, and inspect/control PRU ... https://github.com/mvduin/py-uio ) Nov 17 04:52:30 Thats nice to know, Handy to test with. Nov 17 04:53:09 I was looking at doing some realtime work on the PRU with userspace app controlling the high level inputs Nov 17 04:53:35 So got my first BBB, have done a bit of driver work on linux in past, but first time into BBB Nov 17 04:53:44 realtime work is what PRU excels at Nov 17 04:53:51 True Nov 17 04:54:19 Usually, I design microcontroller boards which plug via usb to linux, with PRU its all inbuilt, which is nice Nov 17 04:54:45 yep, you can interact with pru simply via shared memory. Nov 17 04:55:14 true, i am running into issues with gpio Nov 17 04:55:29 pru's dedicated gpio, or just the regular gpio? Nov 17 04:55:30 Looks like my firmware is getting loaded, but no response on the gpio pins Nov 17 04:56:25 i would expect it to be general gpio, since I am using p9_11 Nov 17 04:56:42 I am picking my way using PRUcookbook examples Nov 17 04:56:44 p9.11 indeed does not have a pru in/out mode Nov 17 04:57:13 you might have a point there, i tried config-pin pru out on that gpio and it spit an error Nov 17 04:57:35 but I tried another GPIO which did support pruout, hit the same issue Nov 17 04:58:19 you can use pruout mode or use general gpio (i.e. leave pinmux at default), either works although the details on how to use them are quite different Nov 17 04:58:20 I believe it was p9_27 Nov 17 04:58:23 are you using C or assembly? Nov 17 04:58:28 C Nov 17 04:59:39 This example in particular Nov 17 04:59:40 https://github.com/MarkAYoder/PRUCookbook/blob/master/docs/06io/code/gpio.pru0.c Nov 17 05:00:39 be sure to configure the pin as output before running the test Nov 17 05:00:48 He used p9_11 in that example and I followed suit Nov 17 05:01:09 also, this example looks broken Nov 17 05:01:27 is it because of using P9_11? Nov 17 05:01:31 at the very least gpio0 should be declared as "uint32_t volatile *" Nov 17 05:01:55 without volatile the C compiler is allowed to optimize out these writes Nov 17 05:02:56 ok, I made that change Nov 17 05:03:07 -       uint32_t *gpio0 = (uint32_t *)GPIO0; Nov 17 05:03:07 +       volatile uint32_t *gpio0 = (uint32_t *)GPIO0; Nov 17 05:03:22 >be sure to configure the pin as output before running the test Nov 17 05:03:37 Did you mean using config-pin P9_11 gpio? Nov 17 05:03:54 no, the pinmux is configured okay by default Nov 17 05:04:27 (in general, avoid using config-pin to set a pin to "gpio" since annooyingly that means "gpio with internal pullup/down disabled" which is generally undesirable since it can lead to floating pins) Nov 17 05:04:58 ok, would you reccomend doing it in the C code itself? Nov 17 05:05:07 no it needs to be done from linux Nov 17 05:05:34 via /sys/... Nov 17 05:05:43 echo low >/sys/class/gpio/gpio30/direction sets gpio0.30 (which is P9.11) to output-low Nov 17 05:05:55 or you can similarly echo high to set it to output-high Nov 17 05:06:57 ok, Nov 17 05:07:14 I can see the pull up happening when writing high, for pullup Nov 17 05:07:18 The led lights up now Nov 17 05:08:39 I presume now the gpu is in an OUTPUT_PULL_UP state Nov 17 05:08:47 *GPIO Nov 17 05:08:53 no, you're confusing unrelated things Nov 17 05:09:48 Sorry, could you clarify where i am going wrong Nov 17 05:10:00 pinmux merely controls 1. peripheral is controlling a bit 2. whether the input receiver should be enabled 3. whether weak internal pullup/pulldown should be used to keep undriven pins from floating Nov 17 05:10:19 ehh, 1. which peripheral is controlling the pin Nov 17 05:11:10 the PIN_INPUT_ and PIN_OUTPUT_ macros are kinda badly named, they are PIN_INPUT_ENABLED_ and PIN_INPUT_DISABLED_ while having no influence on the output driver whatsoever Nov 17 05:11:40 ok Nov 17 05:11:52 I am following so far Nov 17 05:12:06 each configurable pin has a gpio mode which puts the pin under control of one of the four gpio controllers Nov 17 05:12:32 So from my understanding, we need to assign the GPIO to PRU peripheral? Nov 17 05:12:49 no, PRU is simply controlling the gpio peripherals Nov 17 05:13:17 however it cannot safely change the direction of a gpio (from input to output or vice versa) without risking a race condition Nov 17 05:13:31 which is why you should setup the direction from linux in advance Nov 17 05:14:14 the gpio controller has atomic-set and atomic-clear registers for the output value, which is why pru can safely toggle the output level of pins that are configured as output Nov 17 05:14:25 ok, so writing /sys/class/gpio/gpio30/direction does that Nov 17 05:14:33 yes Nov 17 05:15:22 ok that is now set to low, which should get the GPIO pin to the state I want Nov 17 05:15:24 that attribute reads as "in" or "out", and when writing you set it to "in", "low", or "high" since when changing a pin from input to output it also needs to know the initial output level Nov 17 05:15:59 cat /sys/class/gpio/gpio30/direction now reads out Nov 17 05:16:13 exactly Nov 17 05:16:23 so now the pru program should toggle the pin Nov 17 05:17:09 Now when I load the program, It does not change the LED state Nov 17 05:17:21 But logs confirm it went through Nov 17 05:17:37 [ 2690.367240] remoteproc remoteproc1: powering up 4a334000.pru Nov 17 05:17:37 [ 2690.367558] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, size 32296 Nov 17 05:17:38 [ 2690.367592] remoteproc remoteproc1: remote processor 4a334000.pru is now up Nov 17 05:18:16 I did notice it doesn't enable PRU's master port in this example... I wonder if that's needed for some versions of remotepru-pru but not others, or something, or if it's really just been omitted by accident Nov 17 05:18:42 I don't use remoteproc-pru myself since it doesn't have the features uio-pruss does Nov 17 05:18:55 (e.g. it lacks facilities for shared memory mapping) Nov 17 05:19:30 I suspect this example was recently broken, As this was used succesfully in the past by others Nov 17 05:19:52 Not sure if any kernel changes did that Nov 17 05:20:15 it's also possible people ran it successfully because they previously ran an example that enabled the pruss master port (which is persistent until you reboot) Nov 17 05:21:02 py-uio enables the pruss master port by default Nov 17 05:21:34 https://github.com/MarkAYoder/PRUCookbook/blob/master/docs/02start/code/hello.pru0.c#L14-L15 Nov 17 05:21:37 this Nov 17 05:22:23 Its a good point Nov 17 05:22:38 From the flow of the tutorial, 06io seems to be run first. Nov 17 05:22:58 I added this line suggested Nov 17 05:23:00 +       /* Clear SYSCFG[STANDBY_INIT] to enable OCP master port */ Nov 17 05:23:01 +       CT_CFG.SYSCFG_bit.STANDBY_INIT = 0; Nov 17 05:23:25 But the results still are as before Nov 17 05:23:57 weird Nov 17 05:25:06 I could try changing the GPIO Nov 17 05:25:15 and see if that makes any difference Nov 17 05:25:25 that doesn't really make sense Nov 17 05:25:40 >that doesn't really make sense Nov 17 05:25:45 You mean the behaviour Nov 17 05:26:23 I mean, whatever the problem is is presumably a problem with this example code... trying a different pin is nonsensical unless you suspect the pin itself is physically broken, but you already know it isn't Nov 17 05:27:21 Picking another GPIO is meant to rule out if this one is a special GPIO's which the PRU has issues toggling Nov 17 05:27:35 there's no such thing Nov 17 05:27:44 pru has full access to all gpios and all peripherals Nov 17 05:27:59 and there's no difference between one gpio and another Nov 17 05:28:20 You should know better, lets go with your point of view Nov 17 05:31:08 I also made this header for controlling gpios: https://pastebin.com/anqLbyav ... I don't remember if it has been tested, like, at all though :D Nov 17 05:33:36 Ok, now since I have tried known methods Nov 17 05:33:52 I might try your python lib and see if it is able to toggle the GPIO Nov 17 05:34:14 If that does, it would mean the C program needs work Nov 17 05:34:22 it *shouldn't* make much difference if code is loaded using remoteproc-pru or py-uio... Nov 17 05:34:26 if not it might mean something has changed underneath in the kernel Nov 17 05:34:46 (other than that py-uio will enable the master port for you) Nov 17 05:35:00 agree, so its good to verify that Nov 17 05:39:36 I will go away and give that a try, Nov 17 05:39:44 Thanks for your inputs zmatt Nov 17 05:44:05 * zmatt falls back asleep Nov 17 06:38:34 zmatt Nov 17 06:39:03 Hit errors while loading the py-uio Nov 17 06:40:09 did you follow the installation instructions in the README ? Nov 17 06:40:19 I should really include an install script or something Nov 17 06:43:47 I had done the uEnv settings to enable uio, Nov 17 06:43:57 the udev rules were missing, will add them in Nov 17 06:44:12 Yes an install script would be helpful Nov 17 06:48:19 Hello. I have a BeagleBone Black Wifi. It's untouched, never flashed or anything. Sometimes, plugging it to the computer via USB turns it on and shows the new USB device with instructions. But most of the times it doesn't. Is there something I could try to do? Nov 17 06:49:12 AlejandroExojo[m: you could try reflashing it with the latest image just in case. with a fresh device you never know what firmware is on there... Nov 17 06:50:20 Thanks! I'm still a bit lost on the beagleboard.org page, but I'll search for that Nov 17 06:50:24 easiest way is by downloading the "AM3358 Debian 10.3 2020-04-06 4GB eMMC IoT Flasher" image from the "Flasher Debian images" section of https://beagleboard.org/latest-images then write that to microSD card using Balena Etcher (https://etcher.io/) Nov 17 06:50:49 then boot the beaglebone from that sd card and it should automatically proceed to reflash the eMMC and then it will turn itself off Nov 17 06:51:33 Excellent, thank you. Ultimately I want to use my own image, as I'm starting with Yocto. I have it built, but I don't have SD card yet. I'll start reading on that. Nov 17 06:51:58 if the firmware currently on the beaglebone is really old it may be necessary to force it to boot from SD card by holding down the S2 button (the button closest to the sd card slot) while powering on (you can let go of the button once the power led turns on) Nov 17 06:52:27 that may also be necessary to get it to boot a yocto image if debian is flashed to eMMC or vice versa Nov 17 06:53:17 another way to force it to boot from SD card (without having to fiddle with the S2 button) is by just wiping eMMC entirely using "sudo blkdiscard /dev/mmcblk1") Nov 17 06:54:13 Thank you. That would be when logged into the device, right? Nov 17 06:54:19 yes Nov 17 06:55:10 OK. I've never done that yet. I suppose a power source is gonna be better than plugging via USB, so I can free that port for keyboard/mouse Nov 17 06:55:48 uhh, keyboard/mouse plug into the usb-A port, which cannot be used to power the beaglebone Nov 17 06:56:08 (in the rare case you want to plug keyboard/mouse into a beaglebone in the first place) Nov 17 06:56:46 I'm afraid that yes, as I want to try out some GUI app (that's what I do 🙂 ) Nov 17 06:57:06 Well, I need to do that on a device for a customer, but I don't have the customer's device Nov 17 06:57:11 powering the beaglebone is done either via the usb-B port (more precisely mini-B on the BBB and micro-B on the BBBW) Nov 17 06:57:18 or the 5V barrel jack Nov 17 06:57:30 (or the P9 header) Nov 17 06:58:28 Thanks! Much appreciated help 🙂 Nov 17 13:18:16 hi there Nov 17 13:20:42 I have a beaglebone black where usb0 does not show up (even though enabled in /etc/network/interfaces) Nov 17 13:26:22 oh looks like g_ether is required in /etc/modules Nov 17 16:34:36 markand: normally g_ether should not be in /etc/modules nor should usb0 be configured in /etc/network/interfaces ... doing either of those things will cause failures in the normal way usb0 is setup on beagleboard.org images Nov 17 16:37:53 normally generic-board-startup.service runs /opt/scripts/boot/generic-startup.sh which runs /opt/scripts/boot/am335x_evm.sh which sets up the composite usb gadget based on configuration variables in /etc/default/bb-boot Nov 17 16:41:13 /etc/network/interfaces should normally not be touched on a beagleboard.org image since connman is used as network manager (except for the usb interfaces, which are setup as mentioned above) Nov 17 16:41:29 I'm not sure why ifupdown is even installed, normally it makes no sense to have multiple network managers installed at the same time Nov 17 19:58:32 zmatt, nothing is normal at $JOB x) Nov 17 19:58:43 they use very *VERY* deprecated images Nov 17 20:01:02 hmm that can be problematic Nov 17 20:08:21 it is, but that's life when you already have hundreds of those running in the wild Nov 17 20:08:43 especially since the last dev left the company leaving his crap all over the place Nov 17 20:08:51 not mentioning his terrible code Nov 17 21:11:51 Hello! Is there a way to create a PRU -> ARM exception with the BBB using C, without polling (or other blocking methods)? I've found this in the py-uio driver using asyncio, but is this possible with C as well? Nov 17 21:41:04 giort: yes, when using uio interrupts are delivered via a file descriptor Nov 17 21:42:30 markand: well in that case your question should begin with "I have a custom image where.." instead of "I have a beaglebone black where..." :P Nov 17 21:43:48 giort: the old crusty libprussdrv has functionality for it, although you could also use py-uio to do initialization and then pass the relevant file descriptor from python to a C executable... I've been meaning to make an example for that but haven't gotten around to it yet Nov 17 21:56:21 zmatt: and using C, how do I "get" the interrupt event from the file descriptor? By reading a specific bit/flag periodically? Nov 17 21:57:57 zmatt: i got that nwtork issue resolved Nov 17 21:58:16 the issue was network manager was not managing the connections conman was Nov 17 21:58:31 and for some reason conman was not working well with the beaglebone Nov 17 22:03:51 mattb0ne: none of what you said makes sense Nov 17 22:05:46 giort: the interrupt makes the file descriptor readable (so you can use any event handling mechanism you want, similar to how you'd asynchronously receive data from a socket) and you read an uint32_t from it (and discard it). you also then need to reenable the interrupt output in the pruss intc. lemme see if I can quickly hack an example for this since I've wanted one anyway Nov 17 22:06:47 zmatt: that would be great! Nov 17 22:16:15 having stuff in interfaces file caused network manager not to work Nov 17 22:16:19 it was there by default Nov 17 22:16:26 anyways just passing that along Nov 17 22:16:33 I do have a question for you Nov 17 22:16:52 do you understand the difference between write and writelines in streamwriter Nov 17 22:17:07 if you define an interface in /etc/network/interfaces then network manager will not touch that interface Nov 17 22:17:29 but why did you mention connman? (which is not installed on any normal debian system) Nov 17 22:18:01 i guess it is now in debian 11 Nov 17 22:18:29 no, it's not Nov 17 22:18:41 what on earth makes you think it is? Nov 17 22:18:41 ok Nov 17 22:18:46 the debian people Nov 17 22:18:51 ?? Nov 17 22:19:00 debian irc channgel Nov 17 22:19:10 they probably misunderstood you because you were talking about beaglebones Nov 17 22:19:17 oh Nov 17 22:19:18 that would be my guess Nov 17 22:19:28 well I needed to clear out that interfaces file Nov 17 22:19:37 now everything works Nov 17 22:19:38 yes but that interfaces file has nothing to do with connman Nov 17 22:19:46 oh Nov 17 22:20:06 /etc/network/interfaces is the config file of ifupdown Nov 17 22:20:19 so oh Nov 17 22:20:39 well I like network manager better than ifupdown Nov 17 22:21:31 I can't think of a reason you'd want to use ifupdown Nov 17 22:21:47 well they had that in there by default Nov 17 22:22:04 it had config for eth0 in there? on a desktop debian install? Nov 17 22:22:04 now I know to check that Nov 17 22:22:12 yes Nov 17 22:22:19 that sounds very odd to me Nov 17 22:22:45 i mean it was a guided install only so much I can mess up Nov 17 22:23:21 anyways I have a problem with streamwriter.write not sending all my data for a 1 time transmission Nov 17 22:23:48 I was thinking of switiching to writelines but that gives an error Nov 17 22:23:55 writelines appears weird and badly names Nov 17 22:24:04 yeah Nov 17 22:24:18 I cannot find any examples Nov 17 22:25:02 is there a way I can get write to not close prematurely Nov 17 22:25:07 stream.writelines(data) is equivalent to stream.write( b''.join(data) ) Nov 17 22:25:42 i.e. completely pointless Nov 17 22:26:58 arg Nov 17 22:27:20 how did you figure that out Nov 17 22:28:05 or maybe my issue is on the read Nov 17 22:28:09 let me check that **** ENDING LOGGING AT Thu Nov 18 02:59:56 2021