**** BEGIN LOGGING AT Thu Apr 16 02:59:57 2020
Apr 16 15:23:26 <pratimugale[m]> vedant16 Abhishek_ Would micropython be required ? I thought that was a different idea
Apr 16 15:24:02 * pratimugale[m] sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/xNYFlaSrCgyPFVOvIxAadTUI >
Apr 16 15:26:08 <pratimugale[m]> and the latter part of the timeline in integrating it in the Beagle ecosystem
Apr 16 15:33:56 * vedant16[m] sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/ZqqZRuMTGfWLRHoRxTBXHbrb >
Apr 16 16:14:41 <pratimugale[m]> vedant16: The PRUSpeak commands on the ARM are compiled into the bytecode and according to its encoding scheme, the PRU0 interprets the instructions which are run by PRU1 in realtime. So I think what he meant was to instead directly generate the PRU assembly which can be directly loaded and run on the PRUs; so that interpretation on the PRU0 is avoided. Is this it jkridner ?
Apr 16 20:44:11 <jkridner[m]> https://groups.google.com/forum/#!topic/beagleboard/Xv9H7wxDRAEdeepankarmaithani:
Apr 16 20:48:27 <jkridner[m]> pratimugale: I'm really not that happy with assembling (really not a compiler) into bytecode, though I keep falling back into that path too. I think assembling straight down to PRU code should be perfectly reasonable, even within the program space of a PRU. That said, maybe having an ARM-side doing the assembler/REPL is more optimal, but is isn't as nicely self-contained.
Apr 16 20:48:52 * jkridner[m] takes action to create a Bison grammar for Botspeak.
Apr 16 20:57:33 <ds2> compromise - assemble on the M3!
Apr 16 20:57:35 <ds2> ;)
Apr 16 20:59:15 <jkridner[m]> :-)
Apr 16 20:59:18 <vedant16[m]> > and the latter part of the timeline in integrating it in the Beagle ecosystem
Apr 16 20:59:18 <vedant16[m]> Actually we could run a minimal VM on PRU to actually emulate a kind of interpreter based language
Apr 16 21:01:01 <jkridner[m]> that's what I started to write at https://github.com/beagleboard/cloud9-examples/tree/v2020.01/PocketBeagle/pru/.work-in-progress, but I would never call it a VM....
Apr 16 21:01:23 <ds2> how about a Z80 emulator on 6502 using just page 6 as a pre GSoC quickie project?
Apr 16 21:01:31 <jkridner[m]> it was going to interpret commands and write 32-bit codewords into memory for run-time interpretation.
Apr 16 21:01:38 <vedant16[m]> > pratimugale: I'm really not that happy with assembling (really not a compiler) into bytecode, though I keep falling back into that path too. I think assembling straight down to PRU code should be perfectly reasonable, even within the program space of a PRU. That said, maybe having an ARM-side doing the assembler/REPL is more optimal, but is isn't as nicely self-contained.
Apr 16 21:01:38 <vedant16[m]> Considering the people who will use PRU, creating a REPL doesn't make sense.
Apr 16 21:02:34 <vedant16[m]> Ohhh, i had something similar in mind
Apr 16 21:02:48 <jkridner[m]> using /dev/rpmsg_pru30 has some challenges as a REPL, but could probably be opened using a terminal package.
Apr 16 21:03:07 <vedant16[m]> > how about a Z80 emulator on 6502 using just page 6 as a pre GSoC quickie project?
Apr 16 21:03:07 <vedant16[m]> What's z80 emulator?
Apr 16 21:03:20 <jkridner[m]> I think having a REPL for PRU does make sense for trying something with the PRU quickly before diving deeper. Sometimes, only a few lines of assembly are needed to solve a user's challenges.
Apr 16 21:03:23 <vedant16[m]> @jkridner:matrix.org: how about writing subroutines for PRU, like for I2C, SPI, etc?
Apr 16 21:04:20 <vedant16[m]> > I think having a REPL for PRU does make sense for trying something with the PRU quickly before diving deeper. Sometimes, only a few lines of assembly are needed to solve a user's challenges.
Apr 16 21:04:20 <vedant16[m]> But there's PRUSpeaks for that
Apr 16 21:04:36 <ds2> actually, since RT seems to be out of the window - why not just carve up the IRAM into 2 sections... section 1 - a list of branch to XYZ that is created from the original code and section 2 is the code sections that implement it? no real assembly
Apr 16 21:05:16 <vedant16[m]> Is there a PRU emulator? I don't have a Beaglebone rn, but would like to experiment, get my hands dirty
Apr 16 21:06:59 <ds2> what do you want to do?
Apr 16 21:07:24 <ds2> the PRU is simple enough you can almost work it out w/pencil and paper
Apr 16 21:07:46 <ds2> I pretty much did that for my NTSC video overlay on the PRU
Apr 16 21:13:19 <ds2> jkridner[m]: too late now but another potential GSoC project may be to setup a remote access BBB farm (say 5-10 boards), acessible over the internet with a display showing the IO's
Apr 16 21:13:50 <jkridner> yes, some orchestration would be cool.
Apr 16 21:13:55 <jkridner> checked out k3s?
Apr 16 21:14:05 <jkridner> and other kubernetes light stuff?
Apr 16 21:17:01 <ds2> nothing that fancy....just real boards
Apr 16 21:17:21 <ds2> with that cloud9 GUI I think.. or whatever you had on that demo that can show a shell
Apr 16 21:17:35 <ds2> just need to harden it so it can be wiped between users or backed up elsewhere
Apr 17 02:58:10 <pradan[m]> @freenode_ds2:matrix.org: TFLite was an amazing option for us, as it had some good pruning options. But sadly, most of the layers aren't supported right now. I tried it yesterday with YOLO v3-tiny.
**** ENDING LOGGING AT Fri Apr 17 02:59:57 2020