BeagleBoard/GSoC/Ideas-2023

=Welcome!= BeagleBoard.org has been accepted to be a mentoring organization in the Google Summer of Code for nine previous years! Below, we're collecting project ideas for the GSoC-2023!

The BeagleBoard.org community is loaded with experts on building open source embedded systems.

An embedded system is build of computers dedicated a specific collections of functions and connected to automate things in the physical world.

We don't want to just make more things, we want to enabled individuals to make the things that dominate their lives, rather than leaving it up to someone else. Google Summer of a Code with BeagleBoard.org is a great way to learn skills highly in demand while making a difference in the world.

=Contents=

=Introduction=

What is Google Summer of Code?
Spend your summer break writing code and learning about open source development while earning money! Accepted students work with a mentor and become a part of the open source community. Many become lifetime open source developers! The 2022 student application window will be open from March 20th to April 4th 2023! But don't wait for then to engage! Come to our Slack chat and forum to share ideas today.

Google Summer of Code is open to individuals age 18 and older in most countries who are new or beginner contributors to open source coding projects.

Read more on the GSoC site rules page and the FAQ.

BeagleBoard.org Background
BeagleBoard.org is a volunteer organization that seeks to advance the state of open-source software on open-source hardware platforms capable of running high-level languages and operating systems (primarily Linux) in embedded environments. Born from taking mobile phone processors and putting them on low-cost boards to build affordable desktop computers, BeagleBoard.org has evolved to focus on the needs of the "maker" community with greater focus on the I/O needed for controlling motors and reading sensors to build things like robots, 3d printers, flying drones, in-car computer systems and much more. Past BeagleBoard.org GSoC projects included creating an interpreter for tiny CPUs, adding SPI and sensor support to Python, an HTML and git based tutorial sharing environment, porting autopilot software to Linux, an open source 100MHz 14-channel logic analyzer, using Android tablets as Linux displays, putting ADC support in Linux under the IIO framework, using Android phones as a network boot source, Running Arduino code on Linux, Robot Operating System support within the Yocto Project build system, Minix I2C support, an RPC framework for heterogeneous processor communication, a transparent USB packet sniffer, ARM optimizations for XBMC, ARM optimizations for FFTs, make-shift pulse-width-modulation and RPC optimizations for OpenCV. BeagleBoard.org has benefited from sponsorship from Texas Instruments, Circuitco, Digi-Key, element14 and others, but avoids any dependence on that sponsorship for sustaining the effort. The project has evolved over the past few years with over 1,000,000 boards in circulation with developers worldwide and strong roots in the Linaro, Yocto Project, Angstrom Distribution, Debian and Linux communities---and support for running most major Linux distributions including Ubuntu, Android, Fedora, ArchLinux, Gentoo, Buildroot and many more.

BeagleBoard was inspiration for Raspberry Pi and PocketBeagle is available for about $25 through over 30 distributors world-wide (and is even available at Micro Center in the USA), but is more than a throw-away computer. It is an instance of true open hardware, exposing users to the broader world of electronics, demystifying computers and fostering an environment of clones that have changed the industry for good.

Students will be expected to demonstrate an understanding of cross-compiling before being accepted, but support for demonstration is available through the IRC channel that typically has approximately 150 online chatters logged on at any time, most with sufficient experience to explain the process.

' Every accepted student will be sent a PocketBeagle, TechLab or GamePup, and either a BeagleBone AI, BeagleBone Black Wireless, BeagleBone Black, BeagleBone Blue, SeeedStudio BeagleBone Green, SeeedStudio BeagleBone Green Wireless, BeagleBoard-X15, BeagleBone AI, BeagleConnect Freedom (in beta), or one of several platforms in development before the first week of coding for testing their project. '

Additional hardware will be provided depending on need and value.

For more information, check out https://beagleboard.org and https://beagleboard.org/brief.

Students looking for ideas
Student proposals can encompass projects inspired from the following list of ideas or can include personal project ideas. Previous Google Summer of Code projects show that the key to success is being passionate about your project, so propose something that is extremely interesting to you, even if it is not on this list. We will be glad to help students develop ideas into projects via Slack or Discourse. There are many potential project ideas and we will match students to projects based on their interests and help scope the proposals to something that can be completed in the Summer of Code timeframe.

There are more than a thousand existing projects listed at http://beagleboard.org/p. If you are interested in any of the projects listed on the BeagleBoard.org projects page, contact the project members to see if there are any aspects of their projects that can be enhanced to create a GSoC project. There are also several ideas on the ECE497 class project idea list. You can also check out last year's idea page. Note, however, we are looking for projects that provide a service to the developer community and aren't simply "look what cool thing I made or you can make". The projects should provide a useful software component for other people to utilize.

Mentors wondering where to help
Please start by registering your ideas for student projects below by following the template provided with the existing ideas. Furthermore, scroll down to the bottom and give everyone a bit of information about your expertise and availability by adding yourself to the table. Jason will make final approvals for mentor assignments based on if we first get accepted as a mentoring organization and best matching mentor skill sets with student project ideas deemed valuable to the community.

You will also need be invited by an administrator to register on the GSoC site and request to be a mentor for BeagleBoard.org.

General requirements
All projects have the following basic requirements:
 * 1) Students must create accounts on Github, eLinux, Slack and Discourse prior to creating their application.
 * 2) All newly generated materials must be released under an open source license.
 * 3) Individual students shall retain copyright on their works.
 * 4) Students will demonstrate their ability to cross-compile and utilize version control software by creating a "Hello World" application and generating a pull request to https://github.com/jadonk/gsoc-application/tree/master/ExampleEntryJasonKridner.  For assistance, please visit http://bbb.io/gsocchat or utilize the beagleboard-gsoc Discourse.  The "Hello World" application must print your name and the date out in an ARM Linux environment.  Freely available emulators may be used to test your application or you can ask anyone on the chat or mailing list to help you test.
 * 5) All projects will produce reusable software components and will not be "what–I-built-over-my-summer-vacation" projects. Including a hardware component is welcome, but the project *deliverable* will be software that may be utilized by a wide audience of the BeagleBoard.org community.
 * 6) Students will demonstrate their ability to collaborate by creating an eLinux wiki page for their proposal and utilizing Slack to collect quotes regarding the usefulness of their proposal to the BeagleBoard.org community. The wiki timestamp will help mentors recognize the provenance of ideas from prospective students. Use of Google Docs for proposal development is discouraged due to insufficient revision control and extensive use of computing resources having numerous documents open simultaneously.
 * 7) Source code generated during the project must be released on Github (to be cloned to github.com/beagleboard or merged with appropriate upstream project upon successful completion).
 * 8) To help you to break your project down into manageable chunks and also to help the project's mentors to better support your efforts, weekly project status reports should be e-mailed to the the  beagleboard-gsoc Discourse. Each status report should outline:
 * 9) what was accomplished that week,
 * 10) any issues that prevented that week's goals from being completed and
 * 11) your goals for the next week.
 * 12) Students will provide two recorded audio/video presentations uploaded to Youtube or Vimeo (screencasts are appropriate), one near the beginning of the project summarizing their project goals and another in the wrap-up phase to summarize their accomplishments.  Examples can be found on http://beagleboard.org/gsoc. There is no requirement to show your faces or use English.

How to write a successful proposal
BeagleBoard.org has received a large number of GSoC student proposals over the years that we have participated in the program. Some of these proposals are quite good, but many are poor proposals that would not be accepted by any organization participating in GSoC. Unsuccessful proposals often do/have the following:
 * 1) Try to pass off previous school projects as something to do for GSoC. The work has already done, and the project often has very little to do with BeagleBoard.org hardware.
 * 2) Roughly a half page of "proposal" that is submitted shortly before the submission deadline. These proposals are usually little more than a name, contact information, and a statement of "I will work hard."
 * 3) A generic proposal that was sent to every other GSoC org that has very few details on deliverables or schedule.
 * 4) A project idea that was never talked about to the BeagleBoard.org mentors in Slack or in the Discourse. The proposal was submitted without ever "meeting" the Beagle community.

In order to be successful, a proposal has to be relevant to BeagleBoard.org, a proposal topic that the mentors recognize (either from being proposed on this page or from the topic being discussed on our Discourse, Slack or on Libera.Chat IRC), and sufficiently detailed that the mentors know exactly what you'll be creating and when it will be done. Successful proposals are also almost always shown to mentors via Slack or IRC well before the submission deadline so that the mentors can comment on it and offer suggestions that improve the proposal.

Start your proposal early, speak with the mentors often, and dedicate an appropriate amount of time to both thinking about the deliverables for your project and how you can describe those deliverables in writing.

=Ideas= Throughout all of these ideas, contributions specifically contributing to the Linux kernel will be given extra attention. The ability for the BeagleBoard.org community to leverage software created out of GSoC is greatly expanded when those contributions land in the upstream Linux kernel where they are shared across many platforms and maintained by the broadest possible support community. In each application area, consideration how a kernel module submitted upstream could be a central component should be considered. In lieu of contributing to the Linux kernel, finding an upstream project, like ArduPilot, RTEMS, DonkeyCar, MachineKit, FPP, etc., where there is already an active community, is strongly desired. More weight is given the more broad the impact of the coding project is. We've seen bug fixing projects to be very productive as well.

Feel free to look at previous ideas and migrate some here.

Linux kernel improvements
These project ideas focus on improvements to the Linux kernel and tightly-coupled boot/userspace projects that power the basic infrastructure on which Beagles run. Our desire is to work upstream, pushing changes that enable all Linux users on any platform, but to integrate and test on a Beagle open hardware design.

USB configfs in device tree
To speed up the boot process by configuring USB statically in the device tree instead of it being conventionally done through a script at boot time. Goal: USB configfs in device tree such that they can be configured statically in device tree ahead of boot and speed the boot process. Hardware Skills: USB Software Skills: C, Linux kernel, USB configfs Possible Mentors: rcn-ee Expected Size of Project: 350 hrs Rating: Medium Upstream Repository: https://github.com/beagleboard/linux/tree/4.19 kernel.org References: https://events.static.linuxfound.org/sites/events/files/slides/USB%20Gadget%20Configfs%20API_0.pdf

BeagleBone Cape add-on board compatibility layer
Goal: Update the compatibility layer for BeagleBone Black and AI to support more kernel versions. Hardware Skills: UART, I2C, SPI, ADC, GPIO and PWM Software Skills: C, Linux kernel Possible Mentors: Deepak Khatri, jkridner Expected Size of Project: 350 hrs Rating: Medium Upstream Repository: various References:
 * Beagleboard:BeagleBone cape interface spec
 * Device tree how-to blog post
 * GSoC 2020 project page
 * lorforlinux's GSoC project documentation website

Xenomai vs Preempt-RT
In the growing market of embedded Linux audio devices, engineers more and more face the question "how fast is fast enough?". There is need to provide a framework for testing responsiveness (and consequently minimum latency) for a given platform and evaluate whether it meets the requirements for the application at hand. In 2010, the paper "How fast is fast enough?" by Brown and Martin compared average and worst-case performance of Preempt-rt Linux vs Xenomai on an old BeagleBoard. In this project you will develop code for a test setup that allows to reproduce these tests on more modern SoCs in order to obtain an indirect measure of how much Preempt-rt has improved over the past few years, what is today the gap with Xenomai and reflect on how this impacts specific applications. Goal: Produce a testing suite that allows to evaluate interrupt latency and CPU performance on Xenomai vs Preempt-rt Hardware Skills: none Software Skills: C, Linux kernel, Xenomai Possible Mentors: giuliomoro Expected Size of Project: 350 hrs Rating: Medium Upstream Repository: https://xenomai.org

Xenomai kernel for most recent BB boards
Xenomai is a co-kernel for Linux that allows selected threads on the board to bypass the Linux kernel and deliver hard real-time performance. This is used worldwide in such diverse sectors as manufacturing processes, drones and audio (e.g.: the Bela project on Beagleaboard boards). The Xenomai core is currently maintained by Siemens and interactions happen through the official mailing list. Board-specific support is only offered on a small set of SoCs, but it's mostly down to the maintainers of individual boards. Kernels for the Beagleboard family are regularly patched and released by `rcn-ee`, who also occasionally releases Xenomai versions. While 4.9, 4.14 and 4.19 (and newer versions) have been working fine on AM335x devices (e.g.: BeagleBone Black, PocketBeagle), these do not run properly on other devices (e.g.: AM572x-based ones such as Beaglebone-AI). The scope of this project is to offer support for Xenomai kernels across the Beagleboard family and implement a workflow that makes maintenance easier. Goal: Fix Xenomai support for newer BB boards, make future maintenance easier. Hardware Skills: none Software Skills: C, Linux kernel, Xenomai Possible Mentors: giuliomoro Expected Size of Project: 350 hrs Rating: Medium Upstream Repository: https://evlproject.org/overview/ https://xenomai.org References:
 * paper "How fast is fast enough?"

RTOS/microkernel improvements
These project ideas focus on growing open source for microcontrollers with a specific focus on better understanding of computer systems and co-processing in a heterogeneous, asymmetrical multiprocessor system where Linux is the typical kernel used on the system coordination portion of the system.

RTEMS on RISC-V
Goal: Add RISC-V-based PolarFire SoC support to RTEMS RTOS Hardware Skills: RISC-V Software Skills: C, RTOS Possible Mentors: Joel Sherrill, jkridner Expected Size of Project: 350 hrs Rating: Medium Upstream Repository: https://git.rtems.org References:
 * issue on RTEMS tracker

Zephyr on R5/M4F (K3)
Goal: Add J721E/AM62 R5/M4F support to Zephyr RTOS Hardware Skills: R5/M4F Software Skills: C, RTOS Possible Mentors: NishanthMenon Expected Size of Project: 350 hrs Rating: Medium Upstream Repository: https://github.com/zephyrproject-rtos/zephyr References:
 * J721E TRM
 * AM62 TRM

Deep Learning
BeagleBoard-X15, BeagleBone-AI and an upcoming TDA4VM-based Beaglebone all have accelerators for running deep learning tasks using TIDL (1, 2). We'd love projects that enable people to do more deep learning application and end-nodes and leverage cloud-based training more easily. Goal here is to create tools that make learning about and applying AI and deep learning easier. Contributions to projects like ArduPilot and DonkeyCar (DIY Robocars and BlueDonkey) to introduce autonomous navigation to mobile robots are good possible candidates.

For some background, be sure to check out https://e2e.ti.com/blogs_/b/process/posts/simplify-embedded-edge-ai-development

YOLO models on the X15/AI
Port the YOLO model(s) to the X15/AI so the accelerator blocks can be leveraged. Currently, running a frame through YOLOv2-tiny takes anywhere from 35 sec to 15 second depending on the how the code is run on the ARM.35 second being a pure brute force compilation for ARM; 15 second utilizing NEON and tweaked algorithms. The goal is to get things down to 1 second or less using the onboard accelerators. Note, there are over 6 different variants of YOLO (YOLOv1, YOLOv2, YOLOv2 and each one has a full size and a tiny version). The main interest is in getting either the YOLOv2 or YOLOv3 versions running. Please discuss with potential mentors on the desired approach as there are many approaches. Just to name a few: Porting the YOLO model into TIDL; OpenCL directly; OpenCL integration with the acceleration library; Integrating TIDL support with an acceleration library. Goal: Run YOLOv2 or YOLOv3 with the onboard hardware acceleration. Hardware Skills: None Software Skills: C, C++, Linux kernel, Understanding of NNs and Convolution. Possible Mentors: Hunyue Yau (ds2) Expected Size of Project: 350 hrs Rating: Medium Upstream Repository: Numerous References: https://pjreddie.com/darknet/yolo/

OpenGLES acceleration for DL
Current acceleration on the X15/AI focuses on using the EVE and DSP hardware blocks. The SoC on those boards also feature an OpenGLES enabled GPU. The goal with this is to utilize shaders to perform computations. A possible frame work to utilize this on is the Darknet CNN framework. Goal: Accelerate as many layers types as possible using OpenGLES. Hardware Skills: None Software Skills: C, C++, Linux kernel, OpenGLES, Understanding of NNs and Convolution. Possible Mentors: Hunyue Yau (ds2) Expected Size of Project: 350 hrs Rating: Medium Upstream Repository: Numerous References: https://pjreddie.com/darknet/

BeagleConnect - Hundreds of remote sensors over networks, including 6lowpan
See https://github.com/beagleboard/beagleconnect. The BeagleConnect Freedom board runs the Zephyr RTOS has mikroBUS ports along with BLE and Sub-GHz radios on it. The code to enable a Linux gateway for the Sub-GHz radio is in the repository.

Rewrite GBridge
Greybus was created to enable modular mobile phones. We are reusing it to drastically simplify developing embedded systems. Fundamental to using Greybus for IoT (embedded systems) is a tool called GBridge. GBridge is a combination of a kernel module called gb-netlink and a userspace application called gbridge that enables routing of Greybus traffic across various transports, including IP. It was initially written as a proof of concept and has not been developed into a stable, production tool. It needs to be rewritten with better error handling and, potentially, to be part of the Linux kernel itself. Further, additional hooks, probably through debugfs, should be provided to report on network status, including signal strength. This might further require patches to the wpanusb and bcfserial drivers to expose additional debug information.

Complexity: 350 hours Goal: GBridge should be submitted upstream, stable and provide debug visibility Hardware Skills: Familiarity with wireless communication Software Skills: C, Rust (optional) Possible Mentors: jkridner, vaishnav Rating: Medium Upstream Repository: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git References:
 * https://github.com/jadonk/gbridge
 * https://github.com/beagleboard/beagleconnect
 * https://github.com/jadonk/wpanusb_bc
 * https://github.com/jadonk/bcfserial

Zephyr SDK
Beagle will be using Visual Studio Code as an IDE moving forward. We want to simplify development targeting Zephyr by hosting a quality set of development tools targeting BeagleConnect Freedom.

Complexity: 175 hours Goal: Visual Studio Code environment hosted by Beagles ready to develop on Zephyr for BeagleConnect Freedom Hardware Skills: flashing MCU boards Software Skills: C, RTOS Possible Mentors: jkridner, rcn-ee Rating: Medium Upstream Repository: https://github.com/beagleboard/image-builder References:
 * https://github.com/beagleboard/beagleconnect
 * https://github.com/jadonk/beagleconnect/blob/docker-arm-zephyrsdk/sw/zephyrproject/Dockerfile
 * https://github.com/rcn-ee/repos/tree/master/bbb.io-vsx-examples
 * https://github.com/rcn-ee/repos/tree/master/bb-code-server
 * https://github.com/beagleboard/Latest-Images

Upstream wpanusb and bcfserial
These are the drivers that are used to enable Linux to use a BeagleConnect Freedom as a SubGHz IEEE802.15.4 radio (gateway). They need to be part of upstream Linux to simplify on-going support. There are several gaps that are known before they are acceptable upstream

Some notes from Stefan Schmidt:


 * 1) The wpanusb linux driver is missing quite a few driver ops (listen before talk, set frame retries). I added rough sketches but these are non functional due to 2.
 * 2) The zephyr firmware side needs to implement these ops as well and hook it up to the zephyr radio_api
 * 3) A way to read the permanent extended address from the device to use in Linux is needed
 * 4) The generic aspect of the firmware driver combo is missing completely. Band, supported channel, power levels, etc is all hard-coded in the linux driver and not queried from the device firmware. Its not even giving the page on which a channel is being set when changing it.
 * 5) More driver ops are coming in right now as there is heavy work towards support management frames as well as active and passive scanning on the Linux stack. Which means these would need proper handling on the firmware side as well.

Complexity: 175 hours Goal: Submit upstream patches for these drivers and respond to feedback Hardware Skills: Familiarity with wireless communication Software Skills: C, Linux Possible Mentors: jkridner, vaishnav Rating: Medium Upstream Repository: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git References:
 * https://www.kernel.org/doc/html/latest/process/submitting-patches.html
 * https://github.com/beagleboard/beagleconnect
 * https://github.com/jadonk/wpanusb_bc
 * https://github.com/jadonk/bcfserial

BeagleConnect(Greybus) host on WIO Terminal
Complexity: 350 hours Goal: Enable remote access to mikroBUS(GPIO, I2C, SPI, PWM, ADC drivers) via UART/BLE. Hardware Skills: Basic wiring Software Skills: C, RTOS Possible Mentors: jkridner, vaishnav Rating: Medium Upstream Repository: https://github.com/zephyrproject-rtos/zephyr/pull/40811 References:
 * https://github.com/zephyrproject-rtos/zephyr
 * https://github.com/beagleboard/beagleconnect
 * https://beagleboard.org/p/ansonhe1997/how-to-use-wio-terminal-as-a-usb-hmi-for-beagleboard-sbc-78e6b9
 * https://elinux.org/BeagleBoard/GSoC/2021_Proposal/MicroPython_with_GreyBus_for_BeagleConnect_Freedom

Greybus for Zephyr Updates
Complexity: 350 hours Goal: Support all the relevant peripherals(SPI, UART, PWM, ADC, GPIO IRQ) on BeagleConnect Freedom on Greybus for Zephyr, this requires adding platform specific changes to enable the protocols and interface to the existing NuttX sources, once the protocols are tested over greybus-for-zephyr, the mikrobus kernel driver needs to be updated to be able to support mikrobus add-on boards on these buses. An ideal end goal for the project would be to test one mikrobus add-on board of each category over greybus with the corresponding device driver in kernel. Hardware Skills: Basic wiring Software Skills: C, Linux Kernel, RTOS Possible Mentors: Vaishnav, jkridner Rating: Medium Upstream Repository: https://github.com/jadonk/greybus-for-zephyr References: https://github.com/RobertCNelson/bb-kernel/tree/am33x-v5.17/patches/drivers/mikrobus, https://github.com/jadonk/beagleconnect

Micropython for BeagleConnect Freedom
Goal: Enable Micropython for BeagleConnect Freedom along with basic GPIO, I2C, SPI, PWM, ADC drivers. Hardware Skills: Basic wiring Software Skills: C, RTOS Possible Mentors: jkridner, Vaishnav Expected Size of Project: 350 hrs Rating: Medium Upstream Repository: https://github.com/micropython/micropython/tree/master/ports/zephyr References: https://github.com/zephyrproject-rtos/zephyr, https://github.com/jadonk/beagleconnect

Automation and Industrial I/O
BeagleBone gets used a lot in automation tasks, be they in industrial, building, home or otherwise. Software that helps enable individual hobbyists, but can bridge into professional automation tasks, is strongly desired.


 * MikroElectronika click board manifests for the Greybus simulator, instead of device tree overlays
 * learning tools like BlockyTalky3 and Makecode, but with a focus on making automation easy
 * open source PLC software

librobotcontrol support for BeagleBone AI and Robotics Cape
Goal: Complete implementation of librobotcontrol on BeagleBone AI. Hardware Skills: Basic wiring Software Skills: C, Linux Possible Mentors: jkridner, lorforlinux Expected Size of Project: 350 hrs Rating: Medium Upstream Repository: https://github.com/jadonk/librobotcontrol/tree/bbai References:http://www.strawsondesign.com/docs/librobotcontrol/index.html

Makecode Arcade for PocketBeagle GamePup
Makecode is a framework for creating special-purpose programming experiences for beginners, especially focused on computer science education. Makecode has a blockly based programming environment served on the browser along with an in-browser board simulator. MakeCode Arcade is a similar environment to MakeCode, but the environment has code blocks that are oriented towards building games. The goal of this project is to support the Makecode Arcade target for the Beaglebone boards and demonstration of example games on the Pocketbeagle Gamepup Cape. Complexity: 350 hours Goal: Makecode target for Beaglebone boards with Breadboard simulator functionality making use of a UF2 daemon running in Beaglebone Hardware Skills: Basic breadboard prototyping skills Software Skills: Linux,Javascript,PXT Possible Mentors: Andrew Henderson, Vaishnav Rating: Medium Upstream Repository: TBD References: https://github.com/microsoft/pxt-arcade, https://github.com/microsoft/uf2-linux , https://beagleboard.org/capes

Blynk support for BeagleBone Boards
Blynk is a hardware-agnostic IoT platform with white-label mobile apps, private clouds, device management, data analytics, and machine learning. There are no good examples of Blynk with BeagleBone boards and there is no option for it in their mobile App right now. This project will change that and provide good visibility for BeagleBone boards with well-documented examples and How-To guides. Goal: Blynk support for BeagleBone Boards (Black, AI, Blue, and Pocket) with well-documented examples Hardware Skills: Basic breadboard prototyping skills Software Skills: Linux and Javascript Possible Mentors: Deepak Khatri, Vedant Paranjape Expected Size of Project: 350 hrs Rating: Medium Upstream Repository: TBD References: TBD

Low latency and soft peripherals using co-processors
The programmable real-time units are one of the coolest features of BeagleBone. Of course, the architecture of using a main processor running a high-level operating system and co-processors running without an operating system is a general architecture. Projects that help create tools and learning around this architecture can be rather successful around BeagleBone. See https://beagleboard.org/pru.


 * low-latency audio (bela.io) (see more projects below)
 * LED lighting (Falcon Player, PocketScroller, etc.)

Another approach is to add support for Verilog (or VHDL) to synthesis PRU code for the soft peripherals. This can be based on the open source verilog toolchains.

Add features to simpPRU
simpPRU is a procedural programming language. It is a statically typed language. Variables and functions must be assigned data types during compilation. It is type safe, and data types of variables are decided during compilation. It has been a project that is being worked on from two years now, this is the third year and there are certain features that could augment it further.

Additionally, this needs to be benchmarked against vanilla PRU-C code to see the performance comparison between the two. Ring Test: https://pub.pages.cba.mit.edu/ring/ is a good benchmarking test to measure the latency between actions and the call from the processor. There are many more benchmarks that can be run on PRU to compare performance of simpPRU against vanilla PRU C code. The findings can be published as a paper, just like this one: https://ieeexplore.ieee.org/document/8056744

Goals: Hardware Skills: Minimal Software Skills: C, Linux, Compilers Possible Mentors: Vedant Paranjape, Abhishek, Archisman Expected Size of Project: 350 hrs Rating: Medium Upstream Repository: https://github.com/VedantParanjape/simpPRU/ References: https://github.com/VedantParanjape/simpPRU/wiki#things-to-be-implemented-in-future, https://github.com/VedantParanjape/simpPRU/wiki#known-issues, https://github.com/VedantParanjape/simpPRU/issues/5
 * Improve the features of simpPRU, namely:
 * add test.py to GitHub actions
 * indicator for PRU on/off state in simppru-console - Issue issue #24
 * quality of life improvements, such as improving error handling. Suggestions for more features by students are welcome.
 * add support for calling C code directly into simpPRU
 * BONUS: support for using PWM using eCAP module: analog_write and analog_read functions
 * Benchmark the effects of adding various compiler flags (-O2, -O3) to gcc-pru during compilation of the generated C code
 * Document the benchmark results as a research paper, and also help the mentors to write a paper regarding simpPRU and other PRU benchmarks.
 * If time permits, start porting the code at https://github.com/beagleboard/librobotcontrol that performs balancing on a 2-wheel robot using a lag-lead controller and moving the control loop over to the PRUs using simpPRU

Using dma-buf for PRU data transfers
Today, to make data transfers to and from the PRU (if using remoteproc, rpmsg dirvers), 1 PRU is utilized to make the transfers, which could instead be used to perform other real time tasks. This project is intended to solve this problem using dma-buf, to relieve the PRU, CPU of data transfer tasks.

Goal: Provide a way for users to use dma-buf for PRU data transfers. Dma-buf is to be based on OpenAMP, and ION allocator. Additional stretch goals for the project are to add this functionality to PRUSS-Bindings to make it a complete API to operate the PRUs; and possibly integrating with SimpPRU. Complexity: 350 hours Hardware Skills: Minimal Software Skills: C, basics of kernel modules Possible Mentors: Pratim Ugale, giuliomoro Rating: Easy Upstream Repository: TBA (New Repo), Repositories for integrating with PRUSS-Bindings, SimpPRU:- https://github.com/pratimugale/PRUSS-Bindings, https://github.com/VedantParanjape/simpPRU References: https://static.linaro.org/connect/bkk19/presentations/bkk19-207.pdf, Previous PRU-DMA project for reference (currently in unstable state):- https://github.com/maciejjo/beaglebone-pru-dma

Port am335x_pru_package to remoteproc
The am335x_pru_package is a community supported set of tools and examples on using the PRU. It includes an assembler and a C library for managing the PRU over UIO. The BeagleBoard community mostly desires to migrate PRU development to remoteproc to give the Linux kernel greater knowledge of the cores.

Goal: Move all examples to remoteproc, including adding elf support to pasm, adding an option to build using clpru and updating the C library to use the remoteproc interface for basic PRU control and using mmap for a limited set of communications functions. Hardware Skills: N/A Software Skills: C, assembly, Linux kernel Possible Mentors: Kumar Abhishek, Zubeen Tolani, Andrew Henderson, giuliomoro Expected Size of Project: 350 hrs Rating: Medium Upstream Repository: https://github.com/beagleboard/am335x_pru_package References: v5 examples TI Training Labs

Create a PRU based soft-peripheral example
The PRU is a hard realtime co-processor with dedicated realtime pins. Previous GSoC have created an assortment of examples and foundation pieces. However, most of them have custom interfaces. This project is to tie things together to implement at least one example of using the PRU with a standard interface. For example, this can be a SPI master interface that can be bound with another peripheral via DT.

Goal: Create at least one non trivial example that includes both the PRU firmware and the kernel driver interface. Utilization of remoteproc (other means of loading the firmware will be considered provided it is appropriately justified) to load the firmware and control the PRU. A device driver should expose the functionality using standard kernel APIs. The example should NOT be a trivial one (i.e. GPIO controller, simple input events, plain on-off LEDs) unless proper justification is provided. Simple non trivial possible examples include SPI master, I2C master (potential HW issues), or UART. This project includes creating the relevant PRU firmware. Hardware Skills: Some understanding of I/O is needed esp if the I2C master is choosen. Software Skills: C, assembly, Linux kernel Possible Mentors: Kumar Abhishek, Zubeen Tolani, giuliomoro, Andrew Henderson Expected Size of Project: 350 hrs Rating: Medium Upstream Repository: N/A References: BeagleLogic & BeagleScope from previous years.

PRU-based USB stack
It should be possible to write a USB stack for PRU. The PRU-controlled USB interface should be able to work either as device or a host. The goal would be to minimize the latency for USB peripherals, specifically audio, HID and MIDI devices used for musical instruments, to integrate into the Bela.io software environment.

Possible Mentors: Jason Kridner, giuliomoro

GPIO Benchmarking
Goal: Read about the ring oscillator. Benchmark GPIOs using the below four approaches Answer and document questions like If possible come up with a use case for fast GPIO with or without PRU. Complexity: 175 hours Hardware Skills: Minimal Software Skills: Linux, C, kernel modules Possible Mentors: Jason Kridner, Shreyas Atre Rating: Easy Upstream Repository: TBD References: https://pub.pages.cba.mit.edu/ring/ https://gitlab.cba.mit.edu/pub/ring https://github.com/ehayon/BeagleBone-GPIO https://github.com/ehayon/BeagleBone-GPIO
 * mmap - userspace
 * character driver (libgpiod) - userspace
 * sysfs - userspace
 * kernel driver
 * How fast can we access pins into {memory, Filesys}?
 * How fast can we output a signal?

bb-config improvements
`bb-config` aka `beaglecfg` aka `beagle-config` is a terminal UI to make the configuration of beaglebone devices easier and more visually. Since bullseye is the default Debian of beaglebone boards we should take advantage of the changes brought into it and improve the functionalities.

Goal: Complexity: 175 hours Hardware Skills: Minimal Software Skills: Linux, C, C++, kernel modules Possible Mentors: Jason Kridner, Shreyas Atre Rating: Medium Upstream Repository: https://github.com/SAtacker/beagle-config References: bb-config NM Dbus spec Dbus CXX NM DBus examples
 * Support for network-manager using dbus API. Talking directly to dbus saves a step and may expose a richer interface than the command line.
 * Adding a graph section for ADC/DAC using FTXUI graph
 * Solve the following Issues (Highest priority to the lowest):
 * 1) Update to the latest FTXUI Version
 * 2) Bullseye (generic-sys-mods) regenerate_ssh_host_keys
 * 3) Add support for setting custom pinmux
 * 4) Add support for Overlay File System enable/disable
 * 5) Optional (depending upon the time and priorities) eMMC stats regression
 * 6) Improve the GitHub CI/CD

remoteproc tty
Goal: Write a new driver to model mailbox and other IPC schemes with a tty/virt terminal interface emulation - allowing for logs and debug messages to be accessible via standard interfaces. Initial implementation can be loopback, but could involve standardization to help implementation across heterogeneous processors. Complexity: 350 hours Hardware Skills: Minimal(understand IPC) Software Skills: Linux, C, C++, kernel modules Possible Mentors: NishanthMenon Rating: Medium Upstream Repository: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/ References: remoteproc tty

Security and Privacy
The BeagleBoard.org community cares a lot about understanding how information is managed. Projects that open up technology for more personal control and help secure data from external manipulation are generally well accepted. Consider how you can make contributions to existing projects in this area.


 * penetration testing (The Deck, Kali)
 * security appliance (Pangolin, ZeroTier Edge device)
 * self-hosted services (Freedombone)
 * car hacking (Macchina)

Example idea, a portable/plugable security appliance for use anywhere:


 * hardware: beaglebone with ethernet or beaglebone wireless, pocketbone + USB ethernet/wifi
 * OS: openwrt
 * configuration UI: bonescript/other
 * PRU accelerators...
 * privacy and safety tools...

Porting multi-channel sound card drivers to recent kernels
Goal: Porting sound card drivers to recent kernels.

As part of this project you will develop and/or update kernel audio drivers for some soundcards currently available for the BeagleBoard series of SBCs. The objective is to have support for the latest TI kernel (> 5.10) and for some of the most recent TI SoC, such as the Sitara AM6xxx series that is on the SK-AM62 board and the TDA4VM that is on the BeagleBone AI-64.


 * 1) The Bela and BelaMini capes feature a TLV320AIC3104 codec (stereo I/O) controlled via I2C and connected to the McASP clock and data lines. This could be used in older kernels and architectures (e.g.: up to 4.14 on Sitara AM3358) with the simple-audio-card driver and a relevant device tree fragment. It has to be tested whether it still works on more recent kernels and SoCs.
 * 2) A multi-channel version (BelaMiniMultichannelExpander) combines 1x TLV320AIC3104 and 3xTLV320AIC3106 to achieve 8in/8out; this is supported via a Bela-specific library but there is no kernel support for it yet.
 * 3) The Bela cape Rev C adds an ES9080Q 8-channel DAC which is also connected to the McASP; this is supported via a user-space Bela-specific library, but there is no kernel support for it yet.
 * 4) The CTAG capes have an AD1938 codec (4in / 8out) which is controlled via SPI, has an on-board crystal oscillator and are connected to the McASP data and clock lines. This has its own device driver which has been fixed up a few times over time (most recently here, AFAIK) but its features are limited and needs to be tidied up and tested on newer kernels.

Background / References: https://github.com/BelaPlatform/Bela, https://learn.bela.io/products/ Software Skills: C, Linux, Kernel Possible Mentors: rma, henrix, giuliomoro Expected Size of Project: 350 hrs Rating: Medium Upstream Repository: where available, listed above

IP Media Streaming
Goal: Building on a Beagle GSoC project of 2017 and 2020, the idea is to extend / add audio network streaming capabilities using the AVB and / or the Ravenna / AES67 standards.

Background / References: https://niklaswan.github.io/GSoC-Overview https://elinux.org/BeagleBoard/GSoC/BeagleBoneAVB Software Skills: C/C++, Linux, Kernel Possible Mentors: rma, henrix Expected Size of Project: 350 hrs Rating: Medium Upstream Repository: TBD

Bela audio driver for common audio APIs
Bela uses its own custom audio API which bypasses ALSA altogether. When adding support for Supercollider and Csound, we had to add a new audio driver to these pieces of software to call into Bela’s C API. In order to make the process of adding Bela support to more programming languages in the future easier, we could think of simply adding Bela support to some common audio backend libraries, so that a single effort can be reused across several pieces of software that use that same library. Examples of such libraries are: portaudio, rtaudio and jack and there may be more. In this project you’ll write a Bela driver for one or more of these libraries and build at least one application that uses the library (e.g.: ChucK, which uses RtAudio or Pure Data, which uses portaudio). You will need a good knowledge of C and build systems. Upon successful completion, the project will make it easier to add more applications and programming languages to Bela.

Goal: Improve the portability of Bela code across audio APIs/ Hardware Skills: Minimal Software Skills: C / make Possible Mentors: giuliomoro Expected Size of Project: 350 hrs Rating: Medium Upstream Repository: https://github.com/BelaPlatform/Bela, https://github.com/thestk/rtaudio, https://github.com/PortAudio/portaudio

Live patching of Pure Data on embedded devices
Pure Data (Pd) is a visual data-flow language for audio applications and it is one of the several languages supported by Bela. Pd ships as a cross-platform software with a C backend and a Tcl/Tk GUI (replaced by HTML5 in the PurrData project). When running Pd on Bela, the user can leverage the analog and digital I/Os of the board to integrate audio processing with the physical connectivity capabilities of the board. Bela provides access to a browser-based IDE for programming the board but, since a desktop environment is not available, the current workflow for using Pure Data on Bela consists in editing the patch on the host computer and then copying it over to Bela where it gets executed.

One of the limitations of this two-step workflow is that the immediateness of the live-patching behaviour of Pd is lost. In this project, the student will leverage the fact that Pd communicates with its GUI via a socket to run the GUI on the host computer while running the audio backend on Bela. This requires a number of adaptations to Pd, including:
 * managing the GUI startup process to allow GUI and audio backend to be started separately and connect to each other
 * allowing access to paths on the remote device
 * loading patches through the GUI instead of from the backend
 * delegating some of the functionalities currently handled in the backend to the GUI

Knowledge of C is required as part of the work will take place in the audio backend, however there will be need to operate on the GUI side as well. A good starting point for the project would be last year's GSoC project which managed to run PurrData entirely in the browser. At the end of a successful project we should be able to submit a pull request in the upstream Pure Data or Purr Data repositories. The benefits of this contribution will not be exclusive to Bela, but can benefit the Pd community at large, making it easier to use Pure Data on embedded devices.

Goal: Allow live patching of Pd on embedded devices. Hardware Skills: Minimal Software Skills: Javascript/HTML, possibly using Svelte as a framework Possible Mentors: giuliomoro Expected Size of Project: 350 hrs Rating: Medium Upstream Repository: http://github.com/pure-data/pure-data/, https://git.purrdata.net/jwilkes/purr-data/, https://gist.github.com/hugonxc/75e0bb838b1953cfa52fa87045bf5b98#file-gsoc2020_hugocarvalho_purrdata-md

Other Bela applications
Bela is a platform for ultra-low latency audio and sensor applications based on the BeagleBoard family of boards. It uses PRU and Xenomai at its core. https://bela.io

Browser-based workbench
Bela features a browser-based oscilloscope for visualising audio and sensor signals. This project would extend the oscilloscope into a more full-featured laboratory workbench.

The oscilloscope itself could be extended in several ways, for example: On top of that, other workbench tools could be added, including:
 * More options for scaling the plot in each axis
 * Adjustable cursors for reading off measurements in time or amplitude
 * Automatic detection of amplitude or frequency from the plot
 * More options for triggering
 * XY mode
 * Updated visual appearance
 * Waveform generator
 * Multimeter (RMS amplitude, frequency, DC offset, etc.)
 * Browser-based simulation of common analog and digital inputs (buttons, potentiometers etc.) and outputs (e.g. LEDs) This project would be built primarily in JavaScript, with some secondary work in C++ to connect to the Bela core code. We are open to the inclusion of existing open-source libraries to build any of these components.

Goal: Improve the features of the Bela oscilloscope and turn it into a full-fledged workbench for audio-rate signals. Hardware Skills: Minimal Software Skills: Javascript, HTML, frontend Possible Mentors: giuliomoro Expected Size of Project: 350 hrs Rating: Medium Upstream Repository: https://github.com/BelaPlatform/Bela/

Browser-based IDE
Bela’s browser-based IDE is served by a node.js server running home-grown modules and a HTML5 frontend based around jquery, ace.js and scss. The codebase started out in 2015 for internal development purposes, it has since been made public and has gone through two major redesigns during its 6-year lifetime. It allows the user to browse projects and examples, edit files and build and run projects. Over time, the frontend/backend relationship has evolved to support a number of Bela-specific features.The software landscape has changed radically since 2015 and there are now several great web-based IDEs out there. The scope of this project is to evaluate how a Bela-like workflow and appearance could be implemented on top of a more modern and better supported browser-based IDE, such as Cloud9 (or - better - something with a more liberal license). You will start by verifying that the requirements for frontend-backend communication logic can be met on the new platform. Then you will write a proof of concept skin for the new platform that mimics, where possible, the existing Bela one. You will need knowledge of web technologies, both for frontend and backend.

Goal: Improve the core foundation and maintainability of the Bela IDE. Hardware Skills: Minimal Software Skills: Javascript / HTML / frontend Possible Mentors: giuliomoro Expected Size of Project: 350 hrs Rating: Medium Upstream Repository: https://github.com/BelaPlatform/bela-image-builder, https://github.com/beagleboard/image-builder

RISC-V Based PRU on FPGA
A programmable real-time unit (PRU) is a fast (200-MHz, 32-bit) processor with single-cycle I/O access to a number of the pins and full access to the internal memory and peripherals on the AM3358 processor on BeagleBones (BeagleBone, BeagleBone Black, BeagleBone Green, etc.). They are designed to provide software-defined peripherals as part of the Programmable Real-time Unit Industrial Control SubSystem (PRU-ICSS) and are capable of implementing things like 25 pulse-width modulators, 4 soft UARTs, stepper motor drivers, and much more. Having these controllers integrated is really handy to avoid throwing in another device to control or interface to a new peripheral. The real power comes when you need high bandwidth between the main CPU and these controllers, such as in LEDscape (https://trmm.net/Category:LEDscape/#LEDscape). It would be great to have a RISC-V based PRU running on FPGA which will be interfaced with BBB. Features of PRU like multiple PWM, Soft UARTs, ultra-low latency IO control can be bit-banged on the RV core. Existing cores like Vex, Neorv, serv can be explored for this application.

Goal: RISC-V Based PRU on FPGA Hardware Skills: Verilog, Verification, FPGA Software Skills: RISC-V ISA, assembly Possible Mentors: Michael Welling, Omkar Bhilare, Kumar Abhishek Expected Size of Project: 175 hrs Rating: Medium

Beaglewire Updates
Beaglewire is an FPGA cape for the Beaglebone black that was developed to support a project for the 2017 season of GSoC. This first year of Beaglewire support was very intensive and there some issues were left to be resolved. The most notable known issue is with the SDRAM interface working sporadically. A student interested in Verilog, kernel coding and hardware would be an ideal candidate. Each of the subsystems (SPI, PWM, UART, SDRAM, etc) can be tested, corrected if necessary and improved if desired. Furthermore, it may be interesting to implement nMigen support for flexible python based gateware support as a stretch goal.

Goal: Improve the Gateware/Firmware support for the Beaglewire cape Hardware Skills: Schematics, Verilog Software Skills: Kernel coding Possible Mentors: Michael Welling Expected Size of Project: 350 hrs Rating: Medium Upstream Repository: https://github.com/mwelling/BeagleWire, https://github.com/mwelling/beagle-wire

Port FPP to BeagleBone AI/AM5729
Falcon Player (FPP) is a distribution for Raspberry Pi's and BeagleBone Blacks that is used to run synchronized light show, primarily for holiday lighting like Christmas and Halloween shows. It's also used as a "firmware" for various capes used to connect wx281x Pixels and LED Panels to Raspberry Pi and BeagleBone's.  On the BeagleBone's, it uses the PRU's to handle the tight ws281x timing which allows it to drive up to 48 strings of pixels. This project would involve porting FPP to run on a BeagleBone AI. There would be several steps to this project including getting basic FPP to install/run on the AI, getting the code to recognize the AI and differentiate that to the users, updating the GPIO code to allow the user to configure GPIO for events, updating the I2C handling to be able to recognize devices on the i2c bus, creating a new device tree to reserve memory for data transfers, and porting the PRU code to the run on the AM5729 PRU's.

Goal: Get FPP fully up and running on a BeagleBone AI Hardware Skills: Minimal Software Skills: C++, PHP, PRU assembly Possible Mentors: Daniel Kulp Expected Size of Project: 350 hrs Rating: Medium Upstream Repository: https://github.com/FalconChristmas/fpp

Support K3 Platform on buildroot
Goal: Support a minimal bootable system(headless containerized) for K3 platforms in upstream buildroot. Complexity: 350 hours Hardware Skills: Minimal Software Skills: C, Linux Kernel, make/build Possible Mentors: NishanthMenon Rating: Medium Upstream Repository: https://git.busybox.net/buildroot/ References: buildroot homepage

Enhance OpenOCD support for VSCode
Goal: Enhance OpenOCD support for VSCode / Eclipe Theia to include register, peripheral views Complexity: 350 hours Hardware Skills: Minimal Software Skills: C, Linux Kernel, node.js, make/build Possible Mentors: NishanthMenon Rating: Medium Upstream Repository: https://github.com/Marus/cortex-debug/ References: https://github.com/Marus/cortex-debug/blob/master/debug_attributes.md https://github.com/Marus/cortex-debug/wiki https://github.com/dhoove/tixml2svd

Self hosted debug of Microcontroller with openOCD
Goal: Currently microcontroller development/debug involves physical jtag interface. Enhance OpenOCD support for debugss to do selfhosted debug on the same SoC. Example: Debugging R5 or M4F from A72/A53 Complexity: 350 hours Hardware Skills: Minimal Software Skills: C, Linux Kernel, debuggers, debug subsystem, make/build Possible Mentors: NishanthMenon Rating: Medium Upstream Repository: https://openocd.org/pages/repos.html References: https://openocd.org/doc-release/html/About.html#What-is-OpenOCD_003f

Support BeagleBoard Flashing with balenaEtcher in Windows
Today balenaEtcher (https://www.balena.io/etcher/) can be used to flash USB drives and SD cards, as well as some eMMC’s for some SBC’s directly. This is possible today for BeagleBone devices in Linux and MacOS, but needs someone with Windows Driver Framework experience to get it over the line for Windows users. We would expect the process to be something like the following:


 * Adjust the u-boot configuration and fix this issue: https://github.com/ravikp7/node-beagle-boot/issues/14
 * Associate the right winusb drivers with the device using this module: https://github.com/balena-io-modules/winusb-driver-generator
 * For reference, the source code for the plugin can be found here: https://github.com/balena-io-modules/node-beaglebone-usbboot and the u-boot image can be found in the `blobs` directory

Goal: Allow Windows users running balenaEtcher to flash BeagleBoard hardware Hardware Skills: Minimal Software Skills: Windows Driver Framework, U-boot, Typescript, C, C++ Possible Mentors: Zane Hitchcox and Joseph Kogut Expected Size of Project: 350 hrs (less if very experienced with Windows Drivers) Rating: Medium Upstream Repository: https://github.com/balena-io/etcher References: https://github.com/balena-io/etcher/issues/3477

=Mentors=

Guide to prospective mentors
Prospective mentors, sudents will look here to make contact with you, so be sure to provide up-to-date information. Please feel free to add yourself here and we will monitor and police this list. Acceptance as an official mentor with the ability to rate proposals and grade students will come via the Google system. We will only approve official mentors who have a prove track record with Beagle, but welcome all community members to provide guidance to both mentors and students to best service the community as a whole. Don't be shy and don't be offended when we edit.

Be sure to use the the template below for providing your project ideas. Remember these are supposed to be for software projects that service the Beagle and general open source embedded systems community, not theses, how-to guides or what I did over my summer vacation ideas.

Contact and background on mentors
Previous mentors

Idea template
Please place your idea in a suitable section.

Summarizing project name
Long summary of the project.

Goal: (concise statement that describes completion and expected outcomes) Hardware Skills: Software Skills: Possible Mentors: (Slack nicknames of possible mentors for prospective students to contact) Expected size of project: (175 or 350 hour) Rating: (easy, medium or hard) Upstream Repository: (git repository and/or link to upstreaming process) References:
 * (url)
 * (url)