**** BEGIN LOGGING AT Wed May 20 02:59:58 2020 May 20 05:22:54 hi May 20 09:25:59 Hello, recently I've tried out how to communicate between ARM and PRU with RPMsg. May 20 09:26:23 After that I've found that the RPMsg must be initialized from host side, which means the PRU cannot send message to the host in an active way. May 20 09:26:53 Are there any way to get around with this? May 20 09:28:22 For example some other ways of communication, like serial port or so? May 20 10:14:13 Watermelon: ehh, I'm pretty sure that's false, there's a separate vring for arm->pru messages and one for pru->arm messages, and the kernel should ensure the latter stays provided with buffers for pru to send messages to arm autonomously May 20 10:15:38 (I have to qualify that statement with "I'm pretty sure" since I use neither remoteproc-pru nor the bloated inefficient rpmsg protocol myself, I prefer uio-pruss and simple ringbuffers) May 20 10:16:53 TI have a knack for making nice hardware and then rendering it impossible to use with overly complicated layers of software May 20 10:17:10 I mean, nobody forces you to use remoteproc-pru or rpmsg May 20 10:18:24 I've got a nice python library that lets you directly inspect and manipulate pru cores, load code onto them (both pasm and clpru output supported), map shared memory, and setup and receive interrupts: https://github.com/mvduin/py-uio May 20 10:19:28 I wasn't thinking of the pru only May 20 10:19:41 anyone remember all those competing dsp frameworks? May 20 10:20:11 when I used a DSP of theirs I didn't use any framework May 20 10:20:22 so no, I don't :) May 20 10:20:44 I mean the arm-side things to access the dsp in the old omap chips May 20 10:20:55 dsplink, dspbridge, and whatnot May 20 10:21:03 Thanks a lot for your reply guys! May 20 10:21:07 ah, haven't used those either May 20 10:21:12 me neither May 20 10:21:16 it was too much work May 20 10:21:19 I've asked the question because of this thread: https://e2e.ti.com/support/processors/f/791/t/543704?dst-parameter-for-pru-rpmsg-send- May 20 10:21:47 And just now I've read it once more and find that I might get it wrong. May 20 10:22:23 Is the dst and src always static between RPMsg communication? May 20 10:22:39 I'd really like to learn something about this topic, but I just don't know where to start. May 20 10:22:50 lemme read the thread May 20 10:26:52 I mean, this just seems to be talking about how port numbers are allocated during setup May 20 10:27:55 Indeed. I guess I've got it wrong. I'll try it out later today. May 20 10:28:36 I don't really know anything about this part of rpmsg so I can't comment on it, I only know what the actual protocol looks like between arm and pru May 20 10:28:59 I'm not familiar with channel management or routing on the linux side May 20 10:29:15 Ok, where can I find the communication protocol between PRU and ARM? May 20 10:30:23 After several days researching, I just doesn't feel that I've touched the core of this topic. May 20 10:30:32 I just examined the source code... I'm not sure if it's clearly documented somewhere, generally you don't need to know if you just use the library functions. I personally dug into it because I wanted to add support for rpmsg to my py-uio library (which I still haven't finished since I don't really care that much about rpmsg, and even less so once I saw how terribly inefficient it is) May 20 10:30:54 =$ May 20 10:31:15 Sounds like a lot of work to do. May 20 10:31:48 nah not really, I've just lacked time and motivatoin May 20 10:32:57 It sounds like I can find something useful from py-uio project. May 20 10:33:10 I'll look into it. Thanks a lot for the information. May 20 10:34:52 just keep in mind that although I support loading binaries produced by clpru (and include 1 simple example), py-uio does not yet support interpreting the "resource table", and most examples are written in pru assembly (assembled using pasm) rather than C (compiled with clpru) May 20 10:36:51 Actually I'm already considering switch to UIO. May 20 10:36:58 (in part because support for clpru was only added later, and in part because I think using C to program PRU is a bit silly and throws away much of its benefits) May 20 10:37:25 well then py-uio is definitely worth checking out :) May 20 10:37:45 I still want to make a better C/C++ library for using uio-pruss too, but just haven't gotten around to it May 20 10:37:52 the old libprussdrv is kinda ew May 20 10:37:54 imho May 20 10:38:10 Ah, it has already been years after the last time I've worked with ASM. May 20 10:38:22 PRU assembly is quite clean and simple May 20 10:38:40 most things except x86 are May 20 10:38:48 PRU was designed to be programmed in assembly, its instruction set is actually quite poorly matched to being targeted by a C compiler May 20 10:39:09 Haha, "most things except x86 are", nice. May 20 10:39:37 yeah PRU is a clean 32-bit RISC architecture, but much simpler than most of those May 20 10:39:57 Ok, I think I need to change my approach to this topic completely. May 20 10:40:07 That's good information. May 20 14:45:05 m May 20 23:13:10 The bot lives! May 20 23:13:24 And... May 20 23:13:52 I almost got this beetle the size of TX on the webcam attached to the BBGW. Wait, just wait. May 20 23:23:52 A bot? May 20 23:24:25 YEs. One in the same! May 20 23:25:28 GenTooMan: How is the complicated theory coming along w/ the grease? May 20 23:35:16 I started a LoRa cape for the BBB? I need to redo the calculation based on medium loading and the board I'm considering redoing the routing for ground and power on the drivers. May 20 23:37:26 Oh. May 20 23:37:58 I am trying to understand systemd still. My file ran at boot, a .sh file, and now it does not. So, I am reading more. May 20 23:44:50 Bots for Bugs. Would this be a neat corner story or what? May 20 23:48:25 GenTooMan: See, the people that sold me this Bot ExoSkeleton did not take into account running four motors while the thing spun on axis-x. May 20 23:48:48 So, when it spins, it creates a jerky motion. May 20 23:48:53 Mechanical! May 20 23:49:28 The bot is at its full capacity, i.e. .sh file and all. Now, time for action. May 20 23:51:23 The only issue I see, outside of mechanical, is the source I programmed into the bot w/ the BBGW. The site reloads every time I use the "GRIPPER" but only that motor makes it reload for some reason. May 21 00:01:26 And! I need to set up the password protect and a sign in screen for getting into the bot interface. May 21 00:07:54 GenTooMan: One more note...I am making a superbot w/ linear actuator motors w/ aluminum extrusions that move in and out! May 21 02:46:40 What's goin on? May 21 02:47:55 sqlite3 May 21 02:48:14 making the ole dbs for no reason whatsoever. May 21 02:48:38 sqlite3 makes a db for exactly one reason: because you asked it to May 21 02:49:12 Right oh! I guess so. I am just learning it again b/c cherrypy uses it. This all goes along w/ a book. May 21 02:49:27 p. 167! May 21 02:49:28 lots of things use sqlite3 May 21 02:49:33 Like what? May 21 02:49:52 As you can tell, I am unaware. May 21 02:51:10 https://www.sqlite.org/mostdeployed.html https://www.sqlite.org/famous.html May 21 02:52:58 Okay. I will go and look. May 21 02:54:16 Dang! May 21 02:54:29 trillion...Over the course of time. May 21 02:54:59 I still catch typos in the docs. May 21 02:55:06 Ha. May 21 02:55:20 Evening May 21 02:56:17 Hello...sqlite3. May 21 02:56:30 A little catch up in case you missed it. May 21 02:57:20 KenUnix: What was that last email of a html file? I am refusing to open it for now. Maybe one day... May 21 02:57:51 OK If that floats your boat May 21 02:57:57 Hey. May 21 02:58:21 Serious. What was that last email w/ the html file? May 21 02:58:44 It's the finished Beaglebone everything and where to get it and builders and reference material May 21 02:58:59 Oh. You completed that already? May 21 02:59:03 Neat. May 21 02:59:39 I have that github page open still but I have not gotten to it recently. May 21 02:59:43 Tightened it up and added a reference section. Alll items shown can be downloaded **** ENDING LOGGING AT Thu May 21 02:59:57 2020