BeagleBoard/GSoC/2021 Proposal/simpPRU Improvements

From eLinux.org
< BeagleBoard‎ | GSoC
Revision as of 22:15, 2 April 2021 by Archisman (talk | contribs)
Jump to: navigation, search


Proposal for Improvements to simpPRU

===== About =====
Student: Archisman Dey
Mentors: Abhisekh
Code: https://github.com/VedantParanjape/simpPRU
Wiki: https://elinux.org/index.php?title=BeagleBoard/GSoC/2021_Proposal/simpPRU_Improvements
GSoC: [N/A]

Status

This project is currently an unfinished draft proposal.

Proposal

I have completed all the requirements listed on the ideas page. The code for the cross-compilation task can be found here, submitted through the pull request #146

About you

IRC: archismandey (@archismandey:matrix.org)
GitHub: GitHub Account
School: Indian Institute of Technology Guwahati
Country: India
Primary language: English, Bengali, Hindi
Typical work hours: 10:30 AM - 8:30 PM US Indian Standard Time
Previous GSoC participation: This is the first time I am participating in GSoC.

About your project

Project name: Improvements to simpPRU

Description

This project aims to improve simpPRU, the simple python-like language developed during GSoC 2020 to make programming the PRU easier, by doing the following things:

Add suport for BeagleBone Blue
Currently, simpPRU supports the following boards: PocketBeagle, BeagleBone Black, BeagleBone Black Wireless and BeagleBone AI. This project will add support for the BeagleBone Blue (solving issue#4). Adding support for other boards in the BeagleBone family like the SeedStudio boards can also be done depending on availability. This will be done by adding the pin mappings for the BeagleBone Blue in include/pin_config.h, and setting the device model in src/pin_config.c.

Add unit tests
Currently, simpPRU lacks any testing apart from making sure the examples work. This project will add unit tests for every feature present in simpPRU.

For example, a test case for variable assignment, equality checking, and if statement would look like:

int a := 5;
if : a != 5 {
    error();
}
return 0;

Then we would build and run using the host C compiler and make sure that error() never gets called.

For the PRU specific functions, a stub function will have to be provided to satisfy the linker, for example:

void digital_write(pin_number, value) {
    printf("Digital Write called");
}

Running the unit tests would be automated into the build process.

Update the grammar so that control statements (break/continue) can only be called inside loops
Currently, they can be called inside any compound statement such as conditionals, which will throw an error while compiling the generated C code. After updating the grammar, this would be an error in the bison parser.

Update the grammar so that return statements can be called anywhere in the function
Currently they can be called only at the end of a function, which is less flexible.

Add a more flexible for loop
Currently the for loop in simpPRU can only handle loops of the form

for : var in range_1:range_2 {...}, where range_2 > range_1

This project will add support for more flexible for loops of the form

for : var in range_1:range_2:increment {...}, where range_1, range_2, and increment can be any integers.

Better error handling in the parser
simpPRU has some error handling in the bison parser, but it is not comprehensive. This project will add more comprehensive error handling.

Possible idea, to be added: Considering possiblities and approaches about sending denser information through rpmsg since currently simpPRU only supports sending one integer at a time, and Linux kernel will not be able to handle, for example, one integer every 100 microsecond. The solution is to store the integers in the PRU memory and send a list of int to the host through rpmsg every 10 ms (for example).

  • Bonus: Add support for calling C code from simpPRU: This can be done if time is left after the other tasks are completed. Approaches will have to discussed with mentors.

Timeline

(will make a more detailed timeline later)

Mar 29 Applications open, Students register with GSoC, work on proposal with mentors
Apr 13 Proposal complete, Submitted to https://summerofcode.withgoogle.com
May 17 Proposal accepted or rejected Go through course on parsers, lexers, compilers, documentation of flex and bison, build a compiler for a toy simpPRU like programming language, play around with simpPRU. Also go through best practices for unit testing.
Jun 07 Pre-work complete Coding Officially begins!
Jun 17 Milestone #1 Introductory YouTube video, setup the hardware received, add support for BeagleBone Blue, setup infrastructure for automated unit testing into the build process and finish writing unit tests for the PRU specific functions (input. output, delay, counters).
June 24 Milestone #2 Finish writing unit tests for the language features - variables, control statements, loops and functions. Fix any bug that are caught and fix them.
June 30 Milestone #3 Update the grammar so that control statements can only be called inside loops, write tests and documentation for this.
July 12 18:00 UTC Milestone #4 Mentors and students can begin submitting Phase 1 evaluations.
Add the more flexible for loop, write tests, documentation and examples for this.
July 16 18:00 UTC Phase 1 Evaluation deadline Add more error handling in the bison parser.
July 23 Milestone #5 TBD
July 30 Milestone #6 TBD
Aug 06 Milestone #7 TBD
August 10 Milestone #8 Completion YouTube video
TBD
August 16 - 26 18:00 UTC Final week Students submit their final work product and their final mentor evaluation
August 23 - 30 18:00 UTC End of sesssion Mentors submit final student evaluations

Experience and approach

I have some experience with building stuff using arduinos and other controllers before (github). I also have programming experience with C, C++, and Python. I got interested in how parsers and compilers work while trying to build a symbolic differentiator (github) as a personal project. I have learned the basics of how flex and bison work and looked at the repository for simpPRU and I understand how it works. So I think I am qualified to work on this project.

Contingency

BeagleBoard is a very active community and it is unlikely that none of the mentors would be willing to help. That said, everything I am going to be working on is an open source project with good documentation, so I will use all the resources available to help myself.

Benefit

  • quotes

Misc

Link to pull request: #146