**** BEGIN LOGGING AT Wed Jun 10 02:59:57 2020 Jun 10 07:46:38 GenTooMan: 200 MHz from the core PLL by default (which is its max clock freq), although it can be switched to be clocked by the display PLL instead Jun 10 07:50:18 thinkfat: ohh, the timer clock mux registers are warm reset insensitive... oof Jun 10 07:51:54 zmatt: yes, so the timer4 ends up being muxed to tclkin on reboot Jun 10 07:52:12 that's some abysmal design choice since the timers themselves do get reset I think, and more importantly the pinmux gets reset Jun 10 07:52:23 yep Jun 10 07:52:37 I'll have to go with a reboot notifier to work around that Jun 10 07:52:54 that won't catch a watchdog reset Jun 10 07:53:01 ? Jun 10 07:53:08 (which is also a warm reset) Jun 10 07:53:11 no, likely not Jun 10 07:53:24 yes, that could be a problem, but normal "reboot" command would still work Jun 10 07:53:40 my suggestion would be to reinitialize those clksel registers in u-boot Jun 10 07:53:50 definitely true Jun 10 07:54:08 since them being warm reset insensitive is pretty much just a chip erratum Jun 10 07:59:28 pressing the reset button is also a warm reset btw Jun 10 07:59:42 basically everything other than power-cycling Jun 10 08:04:49 hmok, can I file bug against u-boot? Jun 10 08:05:07 and will it ever become updated? Jun 10 08:06:24 possibly, though filing a patch is probably more effective... and sending one to rcn will probably have a lot faster turnaround on gettnig you a new beaglebone u-boot :) Jun 10 08:07:05 indeed Jun 10 08:07:25 beaglebone u-boot is on github? Jun 10 08:07:58 as a quick fix, the reboot notifier does what it's supposed to do ;) Jun 10 08:08:19 https://github.com/RobertCNelson/Bootloader-Builder is the official repository I think Jun 10 08:12:16 it could also be fixable in the kernel if the ti,mux-clock devices get instantiated early enough Jun 10 08:12:49 like, add a DT property indicating a specific mux option should be selected by default when the clock mux gets instantiated Jun 10 08:14:00 maybe ask tmlind on active about how to deal with this situation (warm-reset insensitive clock mux causing hang in hwmod stuff) Jun 10 08:24:07 (and by "ask tmlind" I probably mean send an email to the linux-omap list with a Cc to Tony Lindgren) Jun 10 11:02:33 m Jun 10 12:56:06 m 2 u Jun 10 12:56:36 zmatt Ok so atypically it's 200MHz thanks Jun 10 12:59:51 GenTooMan: yeah I think muxing it to the display PLL is intended to give PRU an independently configurable clock rate (on the assumption these use-cases do not require the am335x video output) to be able to get precise bitrates/timing for custom protocols Jun 10 13:00:06 I've never seen or heard of anyone using that option though Jun 10 13:06:05 zmatt the other possibility is syncing the PRU to the video timing if one needed that. Jun 10 13:08:36 I guess... that sounds like a very obscure use-case though Jun 10 13:10:54 like, doing any kind of graphics processing in PRU while making sure you know exactly how many cycles have passed (to be able to exploit being frequency-locked to the video) sounds painful Jun 10 13:11:27 and the only benefit would be avoiding 1 frame of latency Jun 10 13:12:17 (and 1 framebuffer of memory) Jun 10 13:12:17 but yeah, it's possible Jun 10 13:32:42 zmatt: Where are IP addresses to usb0 and usb1 interfaces defined on pocketbeagle? Jun 10 13:33:08 i want to change the IP Jun 10 13:33:10 uhh, I think rcn's setup script reads them from some config file nowadays, dunno where exactly Jun 10 13:33:22 I don't use those scripts myself Jun 10 13:34:01 hmm ok :) Jun 10 13:35:19 you really don't need to do the weird quoting thing, just saying "hmm ok :)" would have worked fine and be easier to read Jun 10 13:39:34 context can be useful if there's been a lot of unrelated conversation in between Jun 10 13:42:13 which was not the case here :P Jun 10 13:42:24 exactly Jun 10 13:42:51 will takecare Jun 10 13:50:52 is this indicative that my PRU is functioning Jun 10 13:50:52 https://pastebin.com/Vf6bCWv1 Jun 10 13:51:02 i tried to put some firmware on there Jun 10 13:51:11 doesnt look right Jun 10 13:51:33 lol wtf is that Jun 10 13:52:30 I think the technical term is "flapping" Jun 10 13:53:02 MattB0ne: can't help you with that I'm afraid, I don't use remoteproc-pru myself, I prefer to stick to uio-pruss Jun 10 13:53:14 i was hoping you could tell me Jun 10 13:53:24 bummer I was reading that UIO is like the old way Jun 10 13:53:33 remote proc is the future Jun 10 13:53:41 how about this Jun 10 13:53:42 MattB0ne: btw I tried to show this as example earlier of a simple (even if unelegant) quadrature decoder: https://pastebin.com/raw/aKn85xyC Jun 10 13:53:42 https://pastebin.com/ncJgSA7Q Jun 10 13:53:57 MattB0ne: if by "old" you mean "works on every kernel version, is stable, and has more functionality" then yes Jun 10 13:54:03 lol Jun 10 13:54:34 i am going to dedicate another day or two learning remote proc then I will bail and do UIO Jun 10 13:55:10 (the "common.h" included by the example I just linked to is the one in the pru-examples/fw/ directory of my py-uio project I also linked to earlier) Jun 10 13:55:11 a lot of the PRU stuff is dated like it had some momentum than it died off Jun 10 13:55:50 well there's not much reason to write new stuff about it when the old stuff is still perfectly valid Jun 10 13:56:03 uio-pruss is one thing that has hardly changed over time Jun 10 13:56:35 I don't know who exactly has been pushing for remoteproc-pru or why Jun 10 13:56:46 or the horror that is rpmsg Jun 10 13:57:01 You can check the status of pru by going in /sys/class/remoteproc/remoteproc1 and then cat the status Jun 10 13:57:24 note that making assumptions about what is "remoteproc1" is a bad idea since the numbering is not stable Jun 10 13:57:27 but wasnt there a draw back of uio was that when system memory wants to access stuff from PRU you could get collisions Jun 10 13:58:01 MattB0ne: no? the uio-pruss driver reserves a chunk of memory for use by pruss (of configurable size) Jun 10 13:58:15 something remoteproc-pru still isn't capable of I think Jun 10 13:58:36 Yes can check both remoteproc1 and remoteproc2. depends on the pru you are using Jun 10 13:58:38 yeah I dont know still taking it all in, just something I came accross Jun 10 13:58:54 I've seen too many projects swiching to remoteproc-pru and subsequently being forced to use /dev/mem to access pru shared memory, which just shows it was a mistake to switch in the first place Jun 10 13:59:08 deepankarmaithan: thanks Jun 10 13:59:26 also may be you should look at https://github.com/dinuxbg/pru-gcc-examples Jun 10 14:00:07 does pru-gcc generate better code than clpru? Jun 10 14:00:19 not sure if it does Jun 10 14:00:34 is syphilis a better disease than cholera? Jun 10 14:00:37 lol Jun 10 14:00:45 hahah Jun 10 14:01:02 the hardcore assembly guys Jun 10 14:01:14 so the consensus is stick to UIO? Jun 10 14:01:25 pru was designed to be programmed in assembly, and many of its advantages are lost when using C Jun 10 14:01:43 MattB0ne: depends on who you ask Jun 10 14:01:59 well I have access to you guys so you guys Jun 10 14:02:14 I can only offer you my personal opinion, not "consensus" Jun 10 14:02:14 i know where zmatt stands Jun 10 14:02:24 but mru and deepankamaithan Jun 10 14:02:53 of course I also try to plug my https://github.com/mvduin/py-uio project, which as the name suggests relies on uio Jun 10 14:02:53 i thought C was just readable assembly for the most part Jun 10 14:03:15 right that was my back up I only switched when I was hearing all the buzz on remote proc Jun 10 14:03:23 no, C is actually a very poor match to the PRU instruction set (which was never intended to be targeted by a C compiler), resulting in awful code Jun 10 14:03:36 granted everything is circa 2014-2015 and the winds may have blown in antoher direction Jun 10 14:03:47 I am not very comfortable with assembly and UIO so i prefer remoteproc. Jun 10 14:04:08 note that py-uio can also load ELF executables produced by clpru, so you can use C if you want to Jun 10 14:04:15 But zmatt is right in his concerns Jun 10 14:04:52 (but I don't parse the resource table yet and don't support rpmsg) Jun 10 14:07:50 but is it that bad. Do you have any performence comparision statastics Jun 10 14:10:03 deepankarmaithan: that would be a very difficult and subjective comparison, since the problem is that using the C language will encourage you to do things that PRU cannot possibly do efficiently Jun 10 14:10:24 (which gets amplified by the second problem, which is the stupidity of clpru) Jun 10 14:10:49 and even if it's reasonably efficient, you can't control exactly how many cycles things take Jun 10 14:11:32 so i am thinking assembly Jun 10 14:11:41 C works fine in a PRU if one's needs are modest, regardless of its match to the instruction set. Knowing precisely how many cycles something takes isn't "modest". lol Jun 10 14:12:03 with assembly you always know? Jun 10 14:12:33 My PRU are both driven by interrupts. As long as the code executes before the next interrupt I don't care. It was trivial to meet that requirement. Jun 10 14:12:34 on the pru, yes Jun 10 14:13:16 hmmmm Jun 10 14:13:24 is there a nice IDE for assembly Jun 10 14:13:32 i am not a fan of just a bare text editor Jun 10 14:13:33 emacs Jun 10 14:13:42 vim Jun 10 14:13:47 (wink) Jun 10 14:13:47 sed Jun 10 14:13:50 cat Jun 10 14:13:55 *ed Jun 10 14:14:08 you old farts stink Jun 10 14:14:12 magnetised needle Jun 10 14:14:49 i am going to give assembly a go Jun 10 14:14:59 still up in the air on uio vs remote proc Jun 10 14:15:03 I also used UIO b/c remoteproc had no decent docs years ago. It may be fine for all I know. Jun 10 14:17:09 I got C working in CCS for PRU dev. Still uses a make file, but it's something. I wouldn't be surprised if asm is doable as well, just don't know how. Jun 10 14:18:40 Take that back. PRU doesn't use a make file. The kernel module does. Sheesh. PRU projects gen a pair of bin I load straight in. Jun 10 14:19:46 huh? Jun 10 14:20:03 make does not care what you're building for Jun 10 14:20:20 and hardware doesn't care how you build the software Jun 10 14:20:42 I know. But I don't use make for PRU, that's all. MattB0ne was looking for an possible IDE. Jun 10 14:21:08 maybe you don't Jun 10 14:21:14 but someone else could Jun 10 14:21:21 Sure! Jun 10 14:23:13 well Looks like they haven't updated the PRU compiler for a long time and the compiler output is pretty poor. Jun 10 14:24:01 however you can write in the C code inline assembler so no big deal. Jun 10 14:25:05 I'm guessing they haven't updated the PRU either. lol I actually have some inline assembler but I'd have to call up the code to "remember" why. Iirc it's an interrupt thing. Jun 10 14:25:06 does clpru's assembler have the convenience facilities that pasm does? things like structs and variable-scopes Jun 10 14:31:44 is UIO and remote proc more general than just the beagle Jun 10 14:31:59 like a generic ARM thing so I could look at the TI website? Jun 10 14:37:37 I believe they are, but truth tell I've only used them on a B'bone. Jun 10 14:41:36 MattB0ne: mainline has a generic uio_pdrv_genirq driver which is usable for most peripherals Jun 10 14:42:17 (including PRUSS for that matter, i've considered tweaking py-uio to support use of it as alternative to uio-pruss) Jun 10 14:43:11 the uio_pruss driver is just a bit more specialized for IRQ handling, and it allocates a chunk of shared (DDR3) memory Jun 10 14:44:05 remoteproc is also a more general linux thing, it's for loading firmware onto and booting up auxiliary special-purpose cores on a system Jun 10 14:45:49 which is also why it gives userspace very little control and insight: it's more for treating them as blackboxes where it has little to do other than load some blob onto them, as opposed to being a development target for the end user to run code that needs tight interaction with userspcae code Jun 10 14:49:48 that makes sense Jun 10 14:50:06 i remember someone saying it was embracing the linux abstraction Jun 10 14:50:28 something about Linus not liking something about UIO and they came up with remote proc Jun 10 14:50:46 yes I can understand that, but it's caused by a severe difference of perspective Jun 10 14:51:15 linux kernel devs will see uio as a gross security risk Jun 10 14:51:31 remoteproc-pru users run all their shit as root and end up getting the interaction they want via /dev/mem Jun 10 14:51:40 :D Jun 10 15:20:05 these days security risks of anything running as root are far more real than making things easy. Jun 10 15:29:16 in production I create a separate uio device for the shared memory region and while full access to pru is actually limited to a small loader running as root, but for average users I'd rather have them be able to do their pruss stuff as normal user than being forced to run their stuff as root because of "security" getting in the way Jun 10 15:30:01 since that is in reality how most of them deal with any and all cases of EACCES Jun 10 15:46:19 * jkridner[m] kicks Riot for making it hard to detect/find mentions. Jun 10 15:46:33 * jkridner[m] is expecting MLH folks to show up here. Jun 10 15:47:28 https://github.com/beagleboard/Latest-Images/wiki/Guide-to-hacking Jun 10 15:56:19 I'm thinking using a systemd unit to detect a condition change during shutdown, and attempt to stop said shutdown, is a Bad Thing (tm)? Jun 10 15:57:19 not sure if you can stop it in time that way Jun 10 15:57:26 The goal is to detect said condition change, then have the system be online in the end, even though it was shutting down at the time the change happened. Jun 10 15:58:05 Research indicates "in time" is unlikely but I haven't gone so far as playing with units yet. Jun 10 16:00:17 An alternative could be to have the systemd unit set the watchdog on condition change and see if it will reboot the unit. Jun 10 16:00:37 uhh I don't understand that last part Jun 10 16:00:44 what exactly are you trying to accomplish? Jun 10 16:01:06 See line starting with "The goal" above. If that doesn't explain I'll try again. Jun 10 16:01:55 I am under the impression the watchdog can reboot the system independently of any other situation? Jun 10 16:01:57 well I thought I understood what that meant, although it sounded weirdly phrased, but now I'm not sure Jun 10 16:02:22 are you talking about the hardware watchdog (usually managed by systemd) or service watchdogs? Jun 10 16:02:56 if the hardware watchdog expires it's like pressing the reset button Jun 10 16:03:25 Ok. As the system is shutting down, a condition may occur that means I don't want it to shut down any longer. If that happens, I would like the system to be online in the end. It doen't matter if I stop the shutdown, or if I somehow cause a reboot, as long as it's online. Jun 10 16:03:41 oh like that Jun 10 16:03:53 that sounds like a race condition regardless Jun 10 16:04:10 It is. I'm trying to mitigate it. Jun 10 16:05:20 like, it sounds like that condition should just ensure the system powers on Jun 10 16:05:31 I suspect if I go the reboot route I want the hardware watchdog. Jun 10 16:05:42 That will work, yes. Jun 10 16:06:12 doing a hard reset during shutdown (where there's probably significant disk writes happening) sounds like a terrible idea Jun 10 16:06:24 initiating a restart would be a better idea Jun 10 16:07:49 When I search for "service watchdog" it's only giving me hardware watchdog hits. I thought the watchdog would restart, but it sounds like there's a different way. Researching. Jun 10 16:08:40 you mean hardware watchdog, but it doesn't restart, it hard-resets Jun 10 16:09:28 if you want that, you can just "reboot --force --force" instead, that would at least still sync to disk I think Jun 10 16:09:31 Right. But if it hard resets some time after shutdown completes, does that matter? Either way, if I can intercept the shutdown and convert it into a restart, that should be better. Jun 10 16:09:44 it won't reset after shutdown completes Jun 10 16:09:51 if shutdown completes the system is powered off Jun 10 16:10:42 you could replace systemd-poweroff.service by one that first does a check Jun 10 16:10:45 Ah. There's the rub then. For some reason I thought if power was still applied, the watchdog would still be working. Jun 10 16:11:12 the am335x has literally no power after shutdown Jun 10 16:11:27 so no, its watchdog won't be working then :D Jun 10 16:11:31 Clearly I skipped a groove. Jun 10 16:15:28 Ragnorok: https://pastebin.com/hMB6gX0J Jun 10 16:15:31 something like this maybe? Jun 10 16:16:38 I'll see. Thanks! Jun 10 16:17:07 actually, I have a better idea Jun 10 16:17:57 Huh. I don't see poweroff in /etc/systemd/system. I see a wants but no service. Jun 10 16:18:10 https://pastebin.com/Vt3QFkeH Jun 10 16:18:15 Ah. Wrong system. Jun 10 16:18:16 there isn't one Jun 10 16:18:20 Ok. Jun 10 16:18:28 placing one there would override the default Jun 10 16:18:41 but instead of overriding it, it's better to amend it instead Jun 10 16:18:46 Oooo. Very clean. Jun 10 16:18:46 which is what my second suggestion does Jun 10 16:19:27 I'll let you know what happens. (grin) Thanks! Jun 10 16:19:50 using ExecStartPre avoids having to specify Type=oneshot (which is the default in the absence of ExecStart) Jun 10 16:21:33 That's a nice feature. I've been searching/reading about systemd for a while but haven't stumbled on that yet. Jun 10 19:38:04 is there a way of not having to type out the ip of the BBB Jun 10 19:38:18 so instead of 192.168.7.2 I could just do debian@bone Jun 10 19:38:27 when I ssh Jun 10 19:41:49 beaglebone.local should usually work Jun 10 19:42:36 plain "beaglebone" may work too if the BBB is connected to an ethernet network (but probably not when connected via usb) Jun 10 19:56:08 what if you have more than one? Jun 10 19:57:02 will give it a shot Jun 10 19:57:14 also another question Jun 10 19:57:17 mru: then give them unique hostnames :P Jun 10 19:57:27 I am thinking of trying to do PWM with the PRUs Jun 10 19:57:38 to drive a DC motor Jun 10 19:57:54 zmatt: damn, that takes effort Jun 10 19:57:56 MattB0ne: sure, that's a really simple thing to do with PRU Jun 10 19:58:06 to get the power requirments of the motor Jun 10 19:58:28 I need to like a votalge follower right ? Jun 10 19:58:44 uhh, to drive a motor you'll generally want a motor driver Jun 10 19:58:54 what kind of motor are we talking about? Jun 10 19:59:05 118 rpm gear motor Jun 10 19:59:06 small Jun 10 19:59:35 plain DC with two wires? Jun 10 19:59:42 https://www.servocity.com/118-rpm-hd-premium-planetary-gear-motor-w-encoder Jun 10 19:59:47 has encoder Jun 10 19:59:49 but year Jun 10 19:59:50 yeah Jun 10 20:00:03 that's a lot more than 2 wires Jun 10 20:00:13 i want to have the encoder signal go back to the PRU Jun 10 20:00:27 well 4 of the wires are for the encoder Jun 10 20:00:31 why have PRU do PWM instead of just using one of the BBB's many PWM outputs? Jun 10 20:00:45 no pins left Jun 10 20:00:52 my LCD cape is eating it Jun 10 20:01:03 the PRUs are sort of a last resort Jun 10 20:01:28 the cape occupies _all_ of them? Jun 10 20:02:37 doesn't look like it to me Jun 10 20:05:01 you're using NHD-7.0CTP right? so P9.16, P9.21, P9.22, P9.28, P9.29, P9.31, P9.41, P9.42 all seem be unused by the cape Jun 10 20:05:14 (all of which are pwm-capable) Jun 10 20:05:19 NHD-7.0CTP-CAPE-V Jun 10 20:06:11 also P8.07, P8.08, P8.09, P8.10 Jun 10 20:06:47 well I also looking to have motor position control it with the PRU reeading the position Jun 10 20:07:09 so put a control loop reading the encoder and controlling voltage Jun 10 20:07:10 then I'd use PRU eCAP to generate the pwm I think Jun 10 20:07:40 generating pwm in software would be very awkward to combine with other activities Jun 10 20:08:38 PRU eCAP is software or hardware Jun 10 20:08:41 hardware Jun 10 20:08:48 a peripheral in the PRU subsystem Jun 10 20:09:10 (works the same as the other three eCAP instance on the system) Jun 10 20:09:36 cool Jun 10 20:10:04 is there an internal eQEP too? Jun 10 20:10:06 combining quadrature-decoding and control loop into one pru program is probably also quite awkward, depending a bit on the max frequency of the quadrature signal Jun 10 20:10:09 no Jun 10 20:11:26 could I just have one PRU do the decoding Jun 10 20:11:38 and one PRU with the PWM and Closed loop Jun 10 20:11:44 that is what I was going to try and do Jun 10 20:11:45 certainly Jun 10 20:12:19 well, one pru doing decoding, one doing the control loop and setting the pwm value in eCAP Jun 10 20:12:25 would be the simplest Jun 10 20:12:29 ok Jun 10 20:13:17 though if it's your first PRU project I'd just start with doing just decoding Jun 10 20:13:20 working through mark yoder cookbook at the moment Jun 10 20:13:25 but that will be my gameplan Jun 10 21:24:15 Hi all, I want to create a GUI for setting up wireless access settings on the Beaglebone Black Wireless. e.g. when the user accesses the hotspot, they see a webpage that helps them input connection settings for their WiFi so the BBBW can connect to it. I haven't done anything like this before - how can I get started thinking about it? Jun 10 21:26:54 one tip I can give you: the way to get phones to automatically direct the user to your setup page is by using iptables/nftables to forward all traffic (received via the hotspot) with destination port 80 of ANY ip to your webserver Jun 10 21:27:22 they detect that Jun 10 21:36:16 e.g. this is an nftables config I've used when I needed this: https://pastebin.com/raw/sDY5dwwk (though I'm not sure why I also redirect https traffic since I can't imagine that possibly working) Jun 10 21:37:04 cirrus72: in this case the AP portal provided by a nodejs application which also controls wpa-supplicant via dbus Jun 10 21:39:32 (note that that nftables config also performs firewalling, which obviously you don't have to do) Jun 10 21:41:13 Hi @zmatt - I'm sorry I'm too new to this to understand what you're saying exactly. I know the BBBW shows a page by default when you connect to its network when it's new. Is there some efficient way to modify that page to ask for wifi details then to save them using connmanctl or equivalent? Jun 10 21:42:05 i understand that you're talking about making it easier for a user to find that page - but I'm a step further back in that I don't yet know how to implement that page/functionality. Jun 10 21:42:52 I have no idea how the default web interface of the beaglebone is structured, we don't use it Jun 10 21:42:54 You mentioned "in this case the AP portal provided by a nodejs application which also controls wpa-supplicant via dbus" - is this anything that either currently exists, or where there is an example I can use to build from online? Jun 10 21:43:18 no we custom-built that Jun 10 21:43:24 OK - if you were to take a stab at building some simple solution, what would you use? Jun 10 21:43:31 of course there probably are off-the-shelf things for that Jun 10 21:45:39 no idea, we already had a nodejs application and plenty of experience with web interfaces as well as with dbus, and we use systemd-networkd as network manager (not connman), so all of those factors combined to make the obvious solutions for us to just command wpa-supplicant directly to scan for networks and to configure/connect it Jun 10 21:46:08 i see, ok Jun 10 21:46:11 thanks Jun 10 21:47:07 (unlike connman and gnome network-manager, systemd-networkd doesn't concern itself with wifi per se, leaving that to wpa_supplicant itself. it will configure the interface (e.g. acquire an IP via DHCP, if so configured) once wpa_supplicant brings the link up) Jun 10 21:50:04 I have to find a technical solution for showing the webpage and initiating the commands Jun 10 21:50:27 I'm going to keep researching Jun 10 21:51:00 I mean, showing the webpage just means making some form of web application Jun 10 21:51:06 there are lots of ways of doing that Jun 10 22:00:59 of course - I meant showing the webpage with the ability to scan for wifi networks, accept user's password entry, check it, tell user if it's wrong, etc. Jun 10 22:01:31 I build Rails apps regularly, but thought this might be better suited with something much more lightweight because it's so simple. Jun 10 22:03:58 I might play around with using a Rails app without an associated DB, just running system commands in response to user input Jun 10 22:05:34 I'm not sure how connmanctl communicates with connman Jun 10 22:05:54 oh I do, I see connman has a dbus interface Jun 10 22:08:37 albeit a weird one Jun 10 22:09:26 haha Jun 10 22:10:05 It seems to be recommended by a few sources as the WiFi connection mechanism for BBBW Jun 10 22:10:32 well, connman is the default network manager on the standard beagleboard.org images... for some reason Jun 10 22:10:49 I don't know of anyone who *recommends* it... it's just there :P Jun 10 22:13:16 you could open up "sudo busctl monitor net.connman" in a terminal window to sniff the dbus traffic to/from connman, and then in a separate window use connmanctl to scan for and connect to a wifi network Jun 10 22:13:45 to confirm that that's how connmanctl talks to connman, and if so what their interaction is like Jun 10 22:15:08 you can also use "busctl tree net.connman" to see its object tree and e.g. "busctl introspect net.connman /net/connman/technology/ethernet" to inspect an object (in your case that would be "wifi" instead of "ethernet" I presume) Jun 10 22:45:16 whats eCAP stand for Jun 10 22:45:25 trying to google a PRU example Jun 10 22:45:29 nothing is coming up Jun 10 22:46:15 ehh, enhanced... capture, I guess? it can do either capture or pwm depending on the mode it's configured in Jun 10 22:51:00 py-uio doesn't have an example involving pru ecap I think, but it does have definitions for it: https://pastebin.com/raw/LfZ0E9vx (this is with ecap configured just as a free-running timer) Jun 10 22:52:29 its structure declaration in py-uio: https://github.com/mvduin/py-uio/blob/master/src/uio/ti/ecap.py Jun 10 22:52:43 you find its official documentation in the AM335x TRM Jun 10 22:54:02 thanks Jun 10 23:06:35 mastermind: https://pastebin.com/raw/sMa8qvqa Jun 10 23:07:21 (pwm frequency is 200000000/PWM_PERIOD) Jun 10 23:09:13 (when using uio you can also initialize eCAP from linux userspace before loading the PRU program, thus reducing the amount of PRU code) Jun 10 23:12:32 its deceptively small amount of code to do PWM with the eCAP Jun 10 23:12:47 one question i had is the PRU reading data from a pin Jun 10 23:13:13 i thought the GPIO was digital with 1's and 0's Jun 10 23:13:32 so how could I pass info via pin Jun 10 23:13:36 if you use pru pins (configured to pruin mode) you can find the inputs in bits 0-16 of r31 Jun 10 23:13:40 uhhhh Jun 10 23:13:54 ok Jun 10 23:13:55 what do you mean? Jun 10 23:14:03 that question makes no sense to me Jun 10 23:14:06 so I can send bits Jun 10 23:14:06 "pass info" ? Jun 10 23:14:22 send bits? how? from what? in what format? Jun 10 23:14:22 say I have PRU1 decoding motor position Jun 10 23:14:36 and I want to pass that to PRU0 who has the control loop Jun 10 23:14:50 actually forget it Jun 10 23:14:51 uhh, store it in pru local memory Jun 10 23:14:57 i dont even know what I am saying Jun 10 23:14:59 yeah Jun 10 23:15:03 you are writing to memory Jun 10 23:17:08 pruss has three memories: a "private" ram for each of the two cores (8KB each) and a shared 12 KB ram, although both cores (and the cortex-a8) can access all three memories Jun 10 23:19:13 for each core address 0 (or constant register c24) is its own ram, address 0x2000 (or constant register c25) is the other core's ram, and address 0x10000 is the shared memory (this address isn't configured into any constant register by default, but you can configure it into c28) Jun 10 23:20:55 If I had a signal coming in on a serial line and I wanted the PRU to see it, I would need to put it in the shared memory some how. Jun 10 23:21:17 but the PRU can see everything if it wants I read Jun 10 23:21:22 just it has its own private area Jun 10 23:21:46 I guess that is where I was getting my pin reading. If I have data coming in via UART4 Jun 10 23:22:10 I would have the PRU read that pin and put it in its own memory for use Jun 10 23:22:15 ehm Jun 10 23:22:35 you want pru to receive serial data? why? Jun 10 23:23:02 the simplest way to do that would be by using the UART that's in the PRU subsystem Jun 10 23:23:13 well ideally i would like the ability to control the PWM signal either by position from the other PRU or force from my load cell Jun 10 23:23:20 oh yeah Jun 10 23:23:23 it has that too Jun 10 23:23:28 actually no Jun 10 23:23:44 i though I saw that somewhere Jun 10 23:23:44 the simplest way would be by receiving the uart commands in linux userspace and have it tell pru Jun 10 23:23:51 :P Jun 10 23:24:07 but you could have PRU directly receive serial commands if you wanted to Jun 10 23:24:07 that will be a down stream thing Jun 10 23:24:32 right now just trying to get the plan A of the two PRUs and the eCAP Jun 10 23:24:35 (in principle even via uart4 instead of the pruss uart, but that would be more hassle and less performance) Jun 10 23:25:16 a lot of possibilities with the PRU Jun 10 23:26:26 I'd just focus on the decoder first, if its writes the position value to local ram then you can observe it from linux using py-uoi Jun 10 23:26:29 *uio Jun 10 23:27:36 (and you could also test a control loop in linux userspace before pondering how to port it to PRU with its limited arithmetic abilities) Jun 10 23:42:39 ok Jun 11 00:13:55 If I want to use the crypto acceleration features that are built into the AM335x, is the out-of-tree OCF-Linux module still the way to do it? Jun 11 00:14:22 To expose to userspace Jun 11 00:14:45 you can also use the mainline api for it Jun 11 00:15:54 (using an AF_ALG socket) Jun 11 00:20:45 I hadn't thought of that. Thanks. **** ENDING LOGGING AT Thu Jun 11 02:59:59 2020