- 1 Welcome!
- 2 Ideas
- 2.1 Linux kernel support for embedded devices and interfaces
- 2.2 Improving the BeagleBone low-latency multi-channel audio system
- 2.3 Heterogeneous co-processor support in open source operating systems and libraries
- 2.4 Process Sensor Data in Real-Time
- 2.5 Sample PRU code interfacing with other kernel interfaces
- 2.6 Linux userspace support of embedded devices and interfaces in high-level languages
- 2.7 Improving initial experience for novice developers
- 2.8 SPI Flash Emulator via PRU
- 2.9 PRU Framebuffer
- 3 Previous ideas
- 4 Mentors
BeagleBoard.org hopes to be accepted as a mentoring organization in the Google Summer of Code for 2016! Below, we've collected project ideas for the GSoC-2016.
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 500,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 is available for about $50 through over 30 distributors world-wide (and is even available at Micro Center and Radio Shack 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 BeagleBone Black 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 http://beagleboard.org and http://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 the BeagleBoard GSoC IRC or the BeagleBoard-GSoC mailing list. 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 500 existing projects listed at http://beagleboard.org/project. 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.
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 to register on Melange and request to be a mentor for BeagleBoard.org.
All projects have the following basic requirements:
- Once accepted, the project must be registered on http://beagleboard.org/project.
- All newly generated materials must be released under an open source license.
- Individual students shall retain copyright on their works.
- Source code generated during the project must be released on github.com (to be cloned to github.com/beagleboard on successful completion).
- The registration on http://beagleboard.org/project must include an RSS feed with project announcements and updates at every milestone. Sources for the RSS feed should be blogger.com, wordpress.com, or some other established blog-hosting service with known reliability.
- 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 project's mentors and the organization administrator (Jason Kridner). Each status report should outline:
- what was accomplished that week,
- any issues that prevented that week's goals from being completed and
- your goals for the next week.
- 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.
- 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://beagleboard.org/chat or utilize the beagleboard-gsoc Google Group. 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.
- 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.
Linux kernel support for embedded devices and interfaces
Improving the state of the Linux kernel, especially with regards to embedded devices and interfaces. Includes improved ARM/OMAP/Sitara platform support, simplifying the development of add-on hardware for embedded systems and exchanging hardware connectivity information with userspace.
Improving the BeagleBone low-latency multi-channel audio system
Based on existing hardware from http://www.creative-technologies.de/linux-based-low-latency-multichannel-audio-system-2/
- Extend driver architecture to Beagle Board X15 (more computational power for more DSP capabilities), including performance test at CPU load conditions, add DSP library to make use of X15's DSPs
- Create USB Audio Class 1 and/or 2 http://www.linux-usb.org/gadget/ Gadget Kernel Module, and optimizing throughput latency to allow cape to be used as independent PC soundcard
- Further optimize available driver for BBG for latency, with focus on ASOC driver
- Make a real-time audio processor box on beaglebone. Needs HD audio cape, could use PRUs for real-time sound processing (ie, guitar input) and second midi source using alsa or hardware cape. Also like to have pitch/envelope-following synth for analog instrument/mic input.
Heterogeneous co-processor support in open source operating systems and libraries
Enabling usage of DSPs, PRUs, FPGAs, Cortex-Ms, Arduinos, MSP430 launchpads and other attached processing platforms.
Process Sensor Data in Real-Time
- Need a sonic anemometer for open source weather station (use PRUs to calculate sonic velocity and wind components). Needs ultrasonic ping sensors and mounting framework.
- Port/implement MAV (drone) optical flow/stereo image processing to PRUs, use BBIO Ardupilot platform.
Sample PRU code interfacing with other kernel interfaces
Write sample code to demostrate how data to and from the PRU can be exposed via standard user interfaces. Possible samples include:
- Expose the PRU as a I2C/UART/SPI etc. The would act as a bitbang I2C master interface that other I2C drivers can leverage.
- Expose data from the PRU as an IIO, input, and/or character device.
The goal is to show the 2 pieces (kernel + PRU firmware) needed to use the PRU as a "normal" HW. Most likely this will have to use the remote proc interface.
Linux userspace support of embedded devices and interfaces in high-level languages
For PyBBIO this could include support for the latest 4.1 Linux kernel (see 4.1 milestone here), addressing open issues, adding new features and device drivers, etc..
Improving initial experience for novice developers
Improving the methods for communicating how to build projects, improving the out-of-box experience for novices and consolidating support for simplified home manufacturing (CNC, 3D printers, laser cutters, pick-and-place machines, etc.), drones/bots (ROS, IMU, video streaming, etc.) or other common tasks.
SPI Flash Emulator via PRU
Often in embedded devices, SPI NOR flash is being used more and more as the main non-volatile memory due to cost and technical abilities, but developing software and firmware for embedded devices which use SPI NOR flash as their main non-volatile memory often results in very slow code-compile-test sequences. This is due to SPI NOR flash's very slow erase and write times even when using a fast programmer like a Dediprog SF100 or Tin Can Tools SPI Hook. Typically, developers will purchase a SPI NOR flash emulator in order to speed development, as programming the emulator's memory can take 1% of the time it takes to program an actual SPI flash part which greatly improves the code-compile-test sequence throughput. However, typical emulators like this often cost upwards of $1000 or more. Creating a lower cost SPI NOR flash emulator which uses the PRU to handle the physical SPI slave interface and Linux's USB gadget capabilities to load the data from a PC host would result in a much lower cost but high performance SPI NOR flash emulator.
Initial development likely could be done using breadboard circuits without needing any special cape hardware. Development and testing could use a single BBB to act as both the emulator and the target, such as having the emulator portion expose a 64 Mb (8 MB) emulated SPI flash and then have the normal AM335x SPI host port access it as a block device or through spidev. Longer term, special cape hardware could be designed to support level shifting but initial development should not require any special PCB.
Like was done before on AM18xx (http://hackaday.com/2012/06/26/offloading-vga-generation-onto-a-coprocessor/) but bring the capability to AM335x. There is value in having a PRU video output system as some newer TI SoC have many PRU but no video output (such as AM5716) and sometimes the way pinouts work for a given design, the normal video output pins on a SoC may not be usable but a PRU may be able to reach usable pins.
|Name||IRC nickname||Melange name||Native language||Other languages||Timezone||Software help||Hardware help||Focus projects|
|Hunyue Yau||ds2||hygsoc||English||-||US Pacific||Android, C, Linux, scripting, Kernel||schematics, wiring, EE details||Kernel/HW|
|Anuj Deshpande||anujdeshpande||anujdeshpande||English||-||UTC+530||C, Python, Golang||Schematics||Arduino, Android|
|Andrew Bradford||bradfa||bradfa||English||-||US Eastern||C, Linux, U-Boot||KiCad, some RF||DSP/PRU/M4 communication from Linux, wifi, USB gadget|
|Alex Hiam||alexanderhiam||alexanderhiam||English||-||US Eastern||Python, C, programming...||schematics, design, debugging, prototyping||PRU, X15 stuff?, device drivers?|
|Vladimir Pantelic||av500||vp7||German||English||CET||C, Android, embedded programming||schematics, design, debugging, prototyping||kernel, Android, dsp|
|Robert Manzke||-||-||German||English||CET||C, kernel, audio interfacing||schematics, design, debugging, prototyping||kernel, audio, dsp|
|Steve Arnold||nerdboy||sarnold||English||-||PST8PDT||Python, kernel/bootloader, OS, sensor interfaces||design, debugging, prototyping||kernel, sensors/data acquisition/processing|
|Matt Porter||mdp||mdp||English||C :)||US Eastern||U-Boot, kernel, drivers, upstream, AVB, networking/ipcs||Schematic review, part selection, debugging||kernel, upstreaming, AVB, automotive|
|Name||IRC nickname||Melange name||Native language||Other languages||Timezone||Software help||Hardware help||Focus projects|