**** BEGIN LOGGING AT Mon May 11 02:59:57 2020
May 11 14:52:54 <vedant16[m]> Hey, just a reminder today's meet at 9.30 PM IST
May 11 14:53:53 <vedant16[m]> For REPL for PRU project idea
May 11 14:55:41 <vedant16[m]> <vedant16[m] "Hey, just a reminder today's mee"> @abhishek_:matrix.org: @pratimugale:matrix.org @hendersa
May 11 15:28:51 <lorforlinux[m]> @jkridner:matrix.org: hey, we should also decide a schedule for my cape compatability project. Let's discuss it :)
May 11 16:07:13 <hendersa> vedant16[m]: I'm here. Just got out of a meeting for work.
May 11 16:12:56 <hendersa> vedant16[m]? Are you here?
May 11 16:14:18 <vedant16[m]> Hey hendersa I'm here
May 11 16:15:11 <hendersa> Abhishek[m]_, pratimugale[m]: Are you two around?
May 11 16:15:18 <Abhishek[m]_> Yes
May 11 16:15:21 <Abhishek[m]_> I’m here
May 11 16:15:38 <hendersa> Well, let's help vedant16[m] out, then.
May 11 16:16:16 <vedant16[m]> So, I went through docs of PRU, and the clpru compiler
May 11 16:16:25 <hendersa> vedant16[m]: I guess the big question is whether you think you have a plan for moving forward. Or, if not, do you have some questions that we can answer for you.
May 11 16:16:38 <vedant16[m]> I solved issue #44 this week
May 11 16:16:45 <pratimugale[m]> Im here
May 11 16:17:20 <vedant16[m]> <hendersa "vedant16: I guess the big questi"> I do have a plan ahead.
May 11 16:19:19 <vedant16[m]> I have one question, if i do implement a REPL on PRU, should i load script into the PRU, or send commands one by one?
May 11 16:20:09 <hendersa> Personally, I'd keep things simple and send commands one-by-one.
May 11 16:20:39 <Abhishek[m]_> I think putting entire REPL on PRU will be heavyweight so have the REPL run on ARM but smartly move things to the PRU
May 11 16:20:55 <vedant16[m]> <hendersa "Personally, I'd keep things simp"> But then will be able to run programs that could say generate a 1Khz signal? Can RPMSG send commands that fast?
May 11 16:21:16 <vedant16[m]> <Abhishek[m]_ "I think putting entire REPL on P"> like a paging thing you mean?
May 11 16:22:09 <hendersa> It's time to think about what you'd like to accomplish. Are you looking at essentially adding a bytecode engine to the PRU?
May 11 16:22:14 <Abhishek[m]_> Execution happens on the PRU but interactivity takes place on ARM
May 11 16:22:29 <hendersa> with a buffer of bytecode instructions that the PRU interprets?
May 11 16:22:31 <Abhishek[m]_> hendersa- that’s the idea yes
May 11 16:22:47 <vedant16[m]> <Abhishek[m]_ "Execution happens on the PRU but"> Yes, but rather a minimal one
May 11 16:23:12 <vedant16[m]> <Abhishek[m]_ "Execution happens on the PRU but"> so one core could handle the paging requests
May 11 16:23:37 <vedant16[m]> <hendersa "with a buffer of bytecode instru"> Correct.
May 11 16:23:54 <hendersa> In that case, perhaps specifying a format for the instructions and a max program size would be a good place to start.
May 11 16:24:11 <Abhishek[m]_> vedant16: I sometimes think of a JIT-compilation approach as well for this application - so sequence of instructions gets compiled to PRU machine code and then loaded and executed adhoc
May 11 16:25:32 <Abhishek[m]_> It’s okay to begin with a bytecode based approach for simplicity but JIT is something worth thinking about as well acc to me
May 11 16:25:40 <vedant16[m]> <hendersa "In that case, perhaps specifying"> I did propose a instruction format in my proposal.
May 11 16:26:02 <pratimugale[m]> A bytecode format for pruspeak exists
May 11 16:26:18 <vedant16[m]> <Abhishek[m]_ "vedant16: I sometimes think of a"> Yes, this seems doable
May 11 16:26:25 <vedant16[m]> https://elinux.org/BeagleBoard/GSoC/2020Proposal/VedantParanjape2
May 11 16:26:43 <vedant16[m]> <pratimugale[m] "A bytecode format for pruspeak e"> Should i use the same, since it gets almost all things done
May 11 16:27:48 <hendersa> vedant16[m]: I saw the instruction list in the proposal, but I didn't see control flow commands. No conditional branching, for example.
May 11 16:28:07 <hendersa> vedant16[m]: Hence why I figured you'd use a serial stream of commands one-by-one.
May 11 16:28:12 <vedant16[m]> Since less RAM is a issue, can i add a external ram chip, i mean is it possible?
May 11 16:29:17 <vedant16[m]> <hendersa "vedant16: I saw the instruction "> I kept it simple in the proposal. I will add instructions for branching too
May 11 16:29:20 <hendersa> Not really. The PRU RAM is on-chip and part of the PRU core.
May 11 16:29:20 <Abhishek[m]_> 8KB is not “less RAM” per se, you also have 12KB shared RAM and PRU can also access system memory but it’s non deterministic
May 11 16:29:45 <vedant16[m]> <Abhishek[m]_ "8KB is not “less RAM” per se, yo"> less RAM as in, not able to support port of micropython
May 11 16:30:35 <vedant16[m]> <hendersa "vedant16: Hence why I figured yo"> Is branching possible with this? I presume not.
May 11 16:30:39 <vedant16[m]> Unless, host handles branching for me?
May 11 16:30:59 <hendersa> The host would handle the branching in a serial stream of commands.
May 11 16:31:41 <hendersa> If it is a JIT/bytecode engine where a bytecode program is passed to PRU memory, then labels for branching and whatnot need to be managed on the PRU.
May 11 16:32:12 <vedant16[m]> <hendersa "The host would handle the branch"> Okay, I guess this should be a starting point for me, once i build a proof of concept, I can think of adding branching
May 11 16:32:53 <Abhishek[m]_> vedant16: Do take a look at WebAssembly and associated projects for code generation
May 11 16:32:57 <hendersa> I see that you have the am335x PRU package with prussdrv in your repos. Are you going to use that as a starting point to talk to the PRU and load the firmware?
May 11 16:34:17 <hendersa> Actually, have you gone through the process of building PRU firmware and verified that it is running on the PRU?
May 11 16:35:05 <hendersa> If there are any troubles that you are having with the more "hands-on" parts of working with the PRU, the mentors should help you with that part first.
May 11 16:35:18 <Abhishek[m]_> Have to drop off at the moment, will check the logs later. vedant16: If you have any questions for me, leave them here and I will review and reply as soon as I can
May 11 16:36:14 <vedant16[m]> <hendersa "I see that you have the am335x P"> I have that since i was fixing issue in it. I am going to use remoteproc jkridner suggested to use rproc
May 11 16:36:17 <vedant16[m]> <Abhishek[m]_ "Have to drop off at the moment, "> Ok cool !
May 11 16:36:41 <vedant16[m]> <hendersa "Actually, have you gone through "> I am yet to receive the hardware, but i am able to build firmwares, I compiled all the example codes.
May 11 16:37:16 <vedant16[m]> hendersa: I would like to know what should be my approach, if I want to implement a interpreter like language
May 11 16:38:27 <vedant16[m]> Abhishek:pratimugale  paging thing seems interesting, but will the data transfer be fast enough to not create a bottleneck?
May 11 16:39:09 <hendersa> Well, I'd like you to consider the pros and cons of that approach. You'll have to limit the number of registers available to the coder, since you'll need some registers to maintain your bytecode engine.
May 11 16:40:22 <hendersa> You'll need to compile the text file of PRU code into the bytecode, so you'll need to parse it all before transforming it.
May 11 16:41:03 <hendersa> Once you have the bytecode itself, you can send it serially or as a buffer of bytecode commands.
May 11 16:41:25 <vedant16[m]> Yes, correct.
May 11 16:41:48 <hendersa> Either way, it will take a number of commands to achieve the execution of a single bytecode instruction.
May 11 16:42:09 <hendersa> So, that will impose limits on the execution speed of the program.
May 11 16:42:18 <vedant16[m]> <hendersa "Once you have the bytecode itsel"> Like just put a while loop on PRU, and check using if which bytecode i have received, and what needs to be done
May 11 16:42:54 <vedant16[m]> It means, I cannot use this to implement, UART, Ethernet examples using this?
May 11 16:43:27 <hendersa> Correct. But, think about how many conditional compare/branches will be required to decode the bytecode. It may take 10-15 PRU opcodes just to execute one bytecode operation.
May 11 16:43:56 <hendersa> I think that you could still perform UART operations, basic GPIO toggling, etc. at a decent rate.
May 11 16:44:12 <vedant16[m]> <hendersa "Correct. But, think about how ma"> So, how could i simplify this?
May 11 16:44:41 <vedant16[m]> <hendersa "I think that you could still per"> So, good enough to get beginner onboard with PRU.
May 11 16:45:19 <vedant16[m]> <vedant16[m] "So, how could i simplify this?"> Or, as abhishek said, should i follow the paging approach?
May 11 16:45:25 <hendersa> Well, you could compile the REPL firmware to binary code and then push it down to the PRU if you need the real-time stuff.
May 11 16:45:58 <hendersa> Or, you could focus on the bytecode approach and keep it simple.
May 11 16:46:26 <hendersa> Consider that the closest thing we have right now to this is Bonescript.
May 11 16:46:32 <vedant16[m]> <hendersa "Well, you could compile the REPL"> Sorry, I didnot understand this.
May 11 16:46:50 <vedant16[m]> <hendersa "Or, you could focus on the bytec"> But this will reduce things that a end user can do
May 11 16:48:08 <hendersa> Correct. You need to think about the balance between ease of use/implementation and what you want to accomplish.
May 11 16:48:48 <hendersa> If you're just looking at transforming REPL into PRU code, compiling it, and then pushing it down as straight PRU firmware, you could do that.
May 11 16:49:37 <vedant16[m]> <hendersa "Correct. You need to think about"> If this is meant to make it easy for begineers, bytecode approach will be feasible
May 11 16:50:08 <vedant16[m]> like a wrapper language over PRU C?
May 11 16:50:15 <vedant16[m]> <hendersa "If you're just looking at transf"> Ohh, so build a language on top of PRU.
May 11 16:50:54 <hendersa> Let the user program in your simplified language, and then you translate it into PRU instructions, compile it, and load it onto the PRU to execute.
May 11 16:51:36 <hendersa> You'd add a little prefix/postfix to the program that would halt the PRU if the kernel sent it an interrupt to tell it to stop, for example.
May 11 16:52:08 <hendersa> So, the end user gets a simple language to work with and the code runs natively on the PRU.
May 11 16:52:18 <vedant16[m]> <hendersa "You'd add a little prefix/postfi"> Yup
May 11 16:52:58 <vedant16[m]> <hendersa "So, the end user gets a simple l"> Should i convert from new lang --> asm
May 11 16:53:25 <vedant16[m]> or convert to C then using gcc to asm
May 11 16:53:41 <hendersa> At that point, it almost becomes a lexx/yacc project. It's basically a compiler that does the transform to PRU asm.
May 11 16:54:39 <vedant16[m]> I like this approach. I could do this.
May 11 16:54:53 <hendersa> You could turn it into C, but the commands are close enough to the final asm that you could do an assembly file, too.
May 11 16:55:38 <hendersa> We don't want you to fight through problems that already have a potential solution. You shouldn't have to fight through creating a parser and such.
May 11 16:55:40 <vedant16[m]> Assembly would be good, i'm more confident with assembly rather than PRU-C
May 11 16:56:48 <hendersa> So, think about this a little bit more. Consider the command set that you'd like to offer the coder, and think about what PRU opcodes should represent that.
May 11 16:56:50 <vedant16[m]> <hendersa "We don't want you to fight throu"> What should i use then?
May 11 16:57:54 <hendersa> Well, for starters, I think you should write a small PRU asm program to, say, toggle a GPIO. You can test it out once your hardware arrives.
May 11 16:58:20 <vedant16[m]> <hendersa "So, think about this a little bi"> I will think about this, and give a update on wednesday meeting.
May 11 16:58:26 <hendersa> But, you could also try putting together some code to emit PRU assembly that does the same thing.
May 11 16:58:49 <hendersa> Build it up piece-by-piece. Think about the big picture before diving into implementation details.
May 11 16:59:18 <hendersa> I have a meeting in two minutes, so I have to get going.
May 11 16:59:24 <vedant16[m]> <hendersa "But, you could also try putting "> I am doing a course, on coursera, I had made a assembler and a bytecode compiler for that course.
May 11 16:59:39 <vedant16[m]> <hendersa "Build it up piece-by-piece. Thin"> Yup
May 11 16:59:43 <hendersa> Good! That should be very applicable to this.
May 11 16:59:50 <vedant16[m]> <hendersa "I have a meeting in two minutes,"> Okay, Cool ! thanks for helping out.
May 11 16:59:59 <hendersa> Good luck, and let us (your mentors) know if you have any questions.
May 11 17:00:28 <vedant16[m]> <hendersa "Good! That should be very applic"> Its a 16bit cpu with 16K ram, and runs a OS.
May 11 17:00:40 <vedant16[m]> > <@freenode_hendersa:matrix.org> Good! That should be very applicable to this.
May 11 17:00:40 <vedant16[m]>  * Its runs on a 16bit cpu with 16K ram, and runs a OS.
May 11 17:02:27 <vedant16[m]> Abhishek: pratimugale I liked the idea that build a language on top of PRU asm and compile it into asm, I will research about this, and its pros and cons.
May 11 17:08:51 <vedant16[m]> Abhishek_: : Regarding the paging approach, will i still need a bytecode engine on the PRU?
May 11 17:50:27 <vedant16[m]> jkridner: Hey, what should be the purpose of the repl, should i assume it is only for begineers, according to this, I could select my approach to do it.
May 11 17:50:50 <vedant16[m]>  * jkridner: Hey, what should be the purpose of the repl, should i assume it is only to get begineers into PRU programming, according to this, I could select my approach to do it.
**** ENDING LOGGING AT Tue May 12 03:00:16 2020