**** BEGIN LOGGING AT Fri Mar 27 02:59:57 2020 Mar 27 04:34:28 Alright, so is my approach to the problem wrong? Please help me out with figuring a plan Mar 27 07:07:43 vedant16: Completeness of the project is very important this time. My suggestion would be to Make it feature complete in 6 weeks and use the next 6 weeks to integrate it *fully* in the Beagle ecosystem. Tie all loose ends. Reuse as much as you can, so. Mar 27 07:08:46 Abhishek_: You mean make PRUSpeak complete? like work on it? or feature complete the interpreter thing Mar 27 07:09:22 Abhishek_: So, i would like to reuse PRUSpeak firmware and build on top of that Mar 27 07:10:00 rather than the QBasic type syntax, I will implement a python like language on top of PRUSpeaks? what say/ Mar 27 07:10:50 * rather than the QBasic type syntax, I will implement a python like language on top of PRUSpeaks? what say? Mar 27 07:12:30 vedant16: Whatever feature set you choose to use, my suggestion would be to choose something that you can reasonably finish by mid term. Keep in mind your level of experience and your familiarity with the programming languages that you are going to use. Mar 27 07:17:15 Cool, I'll keep that in mind Mar 27 07:17:47 I mean, am i on a right track? Mar 27 07:17:57 * I mean, am i on a right track/approach? Mar 27 08:15:45 Look at https://github.com/mvduin/py-uio for a UIO based approach instead of remoteproc which you can try out Mar 27 08:17:44 Or if going with remoteproc use pratimugale’s code Mar 27 09:41:34 I think there's a misunderstanding. I am discussing about REPL on PRU and not the problem idea port pru_package to remoteproc Mar 27 11:59:36 @jkridner:matrix.org: @abhishek_:matrix.org if PRUspeak works what is the need for a REPL? Mar 27 12:30:31 PRUSpeak is on a very old version of the Linux kernel IIRC Mar 27 12:31:40 vedant16: No, I am saying, ultimately you will end up using either UIO or remoteproc to talk to the PRUs even if you make a REPL Mar 27 12:34:28 Is there any other way to talk to the PRU? Mar 27 12:35:09 Those are the only two available ways to access the PRU on Linux. Mar 27 12:35:21 UIO is a userspace-side Linux kernel driver, while remoteproc is a kernel moduke Mar 27 12:35:23 *module Mar 27 12:37:00 Yes, true Mar 27 12:39:57 I am not able to clearly define the goals for a REPL on PRU, if you might please list out expected goals for such a project. Mar 27 13:41:46 Define the opcodes Mar 27 13:41:55 and their syntax Mar 27 13:42:05 For opcodes, think of possible use cases Mar 27 15:10:58 What about the actual high level code? Mar 27 17:01:31 Hi, I am looking for a mentor around my area, anybody here from New Delhi, India? I want someone who can guide me through GSoC during when my mentor is busy.\ Mar 27 17:40:24 lorforlinux: are you attending an engineering school? Mar 27 19:13:25 https://elinux.org/BeagleBoard/GSoC/2020Proposal/VedantParanjape2 Did a bit off this. Mar 27 19:13:38 Please check it. Mar 27 19:41:01 jkridner: Current ways to set pins, accessing registers, delay is somewhat cubersome and a bit non-intuituve for a beginner, if one could write a wrapper to clean the methods. Could this be done? Mar 27 19:42:18 certainly could be done. Mar 27 19:42:27 ...if you want to do it. Mar 27 19:42:55 Should i add that as a goal instead of writing that remoteproc driver thing Mar 27 19:43:30 If it is useful for the community and help me get qualified for gsoc, i will love to do it. Mar 27 19:43:51 have you checked out config-pin ? Mar 27 19:44:32 have you checked out my write_init_pins.sh script as part of cloud9-examples? Mar 27 19:44:34 Yes, its a utility which configures pin muxes right? Mar 27 19:44:51 Yes, I had a look Mar 27 19:46:00 Won't a arduino like development interface for PRU be cool? does anything like that exit Mar 27 19:46:12 * Won't a arduino like development interface for PRU be cool? does anything like that exist **** ENDING LOGGING AT Sat Mar 28 02:59:59 2020