Difference between revisions of "BeagleBoard/GSoC/Ideas-2016"

From eLinux.org
Jump to: navigation, search
m (Add my details to mentor table)
(Mentors)
(418 intermediate revisions by 58 users not shown)
Line 2: Line 2:
 
[[Category: OMAP]]
 
[[Category: OMAP]]
 
[[Category: BeagleBoard]]
 
[[Category: BeagleBoard]]
 
+
[[Category: GSoC]]
=Welcome!=
 
BeagleBoard.org has been accepted as a mentoring organization in the [[BeagleBoard/GSoC|Google Summer of Code]] for 2010!! Students will be applying startign March 29 and we still need several more mentors to register before then.
 
 
 
'''Background'''<br>
 
For a quick view of how the BeagleBoard relates to the open source development community, take a listen to [http://www.youtube.com/watch?v=m9xVbntl-DY Mans and Koen's interview with the Linux Outlaws]. The BeagleBoard is a popular [http://en.wikipedia.org/wiki/Open-source_hardware open-source hardware] project utilizing the first broadly available ARM Cortex-A8 processor. Over 10,000 people are experimenting with the BeagleBoard today to bring their ideas for the future of everywhere-computing to life and you can be one of them.
 
 
 
Because the BeagleBoard:
 
* utilizes a complex SoC with 3 primary processing cores,
 
** one for general-purpose activities such as running Linux and applications (ARM Cortex-A8),
 
** one for running real-time signal processing algorithms (C64x+ VLIW fixed-point DSP), and
 
** one for rendering 3D graphics (Imagination SGX), and
 
* is specifically designed for low-power (typically running under 2W at full processing load), and
 
* has a very small foot-print that includes standard peripheral expansion like USB,
 
there are many opportunities to explore challenges in computer science in areas of
 
* optimal execution of applications/algorithms on additional instruction set architectures like ARM or C6000,
 
* splitting tasks appropriately between processing cores to minimize task execution time and power consumption, and
 
* integrating computation into new form-factors.
 
 
 
'''Students and mentors'''<br>
 
Student proposals can create projects from the following ideas or propose their own project based on their own ideas.  From reading about previous Google Summer of Code projects, the key to success is being passionate about your project, so propose something that is extremely interesting to you, even if it not on the list. We will be glad to help students develop ideas into projects on [http://webchat.freenode.net/?channels=beagle the BeagleBoard IRC] or [http://groups.google.com/beagleboard the BeagleBoard mailing list]. There are many more ideas of what can be done and we will match projects to students interest and help scope the proposal to something that can be completed in the Summer of Code time-frame.
 
 
 
There are more than 100 exiting projects list at http://beagleboard.org/project. If you are interested in one of those projects, talk with the project members to see if there are any aspects of their projects with which they can help you contribute. There are also several ideas on the [[ECE597_Project_Ideas|ECE597 class project idea list]].
 
  
 
__TOC__
 
__TOC__
  
=General requirements=
+
=Welcome!=
All projects have the following basic requirements:
+
BeagleBoard.org has been accepted as a mentoring organization in the [[BeagleBoard/GSoC|Google Summer of Code]] for 2016! Below, we've collected project ideas for the GSoC-2016.
* The project must be registered on http://beagleboard.org/project.
 
* All newly generated materials must be released under an [http://www.opensource.org/licenses open source license].
 
* Individual students shall retain copyright on their works.
 
* Source code generated during the project must be released on gitorious.org, github.com, repo.or.cz, sourceforge, code.google.com, gforge.ti.com, or omapzoom.org.
 
* 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 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.
 
  
=Fundamental infrastructure projects=
+
==What is Google Summer of Code?==
These projects fundamentally improve support of existing open source projects for ARM-based devices in general and the BeagleBoard in specific, bringing the broad body of high-level open source applications into smaller, lower-cost, lower-power systems that can go anywhere.
+
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 2016 student application window is March 14th to 25th.
  
==JTAG debugging==
+
Google Summer of Code is open to post-secondary students, age 18 and older in most countries.
Implement, configure and document a complete open source based JTAG debugging development chain for ARM Cortex A8 in OMAP3 used on Beagle Board. This includes final port of open source JTAG software [[BeagleBoardOpenOCD|OpenOCD]] for OMAP3 on Beagle, and then configure and document all software (and hardware) components involved. This could look like:
 
  
''ARM Cortex A8 <-> OMAP3 <-> BeagleBoard <-> Flyswatter (*)'' <-> OpenOCD <-> GDB <-> Eclipse (CDT)
+
Read more on [https://summerofcode.withgoogle.com/organizations/4817552005922816/ the GSoC site BeagleBoard.org landing page] and [https://developers.google.com/open-source/gsoc/faq the FAQ].
  
(*) Note: [[BeagleBoardJTAG#TinCanTools_Flyswatter|Flyswatter]] is used as example JTAG dongle here. All OpenOCD JTAG dongles able to deal with 1.8V and configure EMUx pins correctly can be used.
+
==BeagleBoard.org Background==
 +
BeagleBoard.org is a volunteer organization that seeks to advance the state of open-source software on [http://en.wikipedia.org/wiki/Open-source_hardware 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 [[BeagleBoard/GSoC/2014_Projects#Project:_BotSpeak_PRU_Firmware|creating an interpreter for tiny CPUs]], [[BeagleBoard/GSoC/2014_Projects#Project:_PyBBIO|adding SPI and sensor support to Python]], [[BeagleBoard/GSoC/2014_Projects#Project:_Bone101|an HTML and git based tutorial sharing environment]], [[BeagleBoard/GSoC/2014_Projects#Project:_BeaglePilot|porting autopilot software to Linux]], [[BeagleBoard/GSoC/2014_Projects#Project:_BeagleLogic|an open source 100MHz 14-channel logic analyzer]], [[BeagleBoard/GSoC/2014_Projects#Project:_Android_Remote_Display|using Android tablets as Linux displays]], [[BeagleBoard/GSoC/2013_Projects#Linux_ADC_IIO_Support|putting ADC support in Linux under the IIO framework]], [[BeagleBoard/GSoC/2013_Projects#Android-based_Boot|using Android phones as a network boot source]], [[BeagleBoard/GSoC/2013_Projects#Userspace_Arduino|Running Arduino code on Linux]], [[BeagleBoard/GSoC/2013_Projects#Robot_Operating_System|Robot Operating System support within the Yocto Project build system]], [[BeagleBoard/GSoC/2013_Projects#Minix_I2C|Minix I2C support]], [[BeagleBoard/GSoC/2010_Projects/C6Run|an RPC framework for heterogeneous processor communication]], [[BeagleBoard/GSoC/2010_Projects/USBSniffer|a transparent USB packet sniffer]], [[BeagleBoard/GSoC/2010_Projects/XBMC|ARM optimizations for XBMC]], [[BeagleBoard/GSoC/2010_Projects/FFTW|ARM optimizations for FFTs]], [[BeagleBoard/GSoC/2010_Projects/Pulse_Width_Modulation|make-shift pulse-width-modulation]] and [[BeagleBoard/GSoC/2010_Projects/OpenCV|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.
  
''Goal:'' Able to single step kernel code using OpenOCD, GDB, and Eclipse<br>
+
BeagleBoard was inspiration for Raspberry Pi[http://www.linuxuser.co.uk/features/raspberry-pi-interview-eban-upton-reveals-all] 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.
''Existing project:'' [http://beagleboard.org/project/OpenOCD+OMAP3+JTAG+support/ OpenOCD]<br>
 
''Hardware skills:'' Able to monitor logic-level digital signals<br>
 
''Software skills:'' C, ARMv7 assembly<br>
 
''Possible mentors:'' Dirk Behme, Ceriand <br>
 
  
'''NOTE: [http://www.tincantools.com TinCanTools] will donate [[Flyswatter]] boards for this project
+
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.
'''
 
  
==Linux kernel improvements==
+
'''''<span style="color:red">Every accepted student will be sent a BeagleBone Black, SeeedStudio BeagleBone Green or BeagleBoard-X15 before the first week of coding for testing their project.</span>'''''
Several improvements are desired in the Linux kernel to make it more useful for embedded/device applications.
 
 
''Goal:'' Improve the capabilities of the Linux kernel, especially for embedded devices including ARM Cortex-A8 and OMAP3-based devices.<br>
 
''Existing project:'' [http://beagleboard.org/project/linux linux-omap]<br>
 
''Software skills:'' C, ARMv7 assembly (desired), Linux kernel driver development<br>
 
''Possible mentors:'' Kevin Hilman, Tony Lindgren, Khasim Syed Mohammed, Russell King<br>
 
  
===More detailed kernel improvement ideas===
+
Additional hardware will be provided depending on need and value.
'''Power Management'''<br>
 
Good power management is crucial to embedded systems.  There are many areas that need continued development:
 
* [http://elinux.org/OMAP_Power_Management#Run-time_PM runtime PM framework for OMAP]
 
* full off-mode support in drivers (SoC is powered off during suspend and idle)
 
* optimize board-specific inactive power (requires board/hardware/PMIC experience)
 
* power measurement and analysis tools
 
  
''Existing project:'' [[OMAP_Power_Management|OMAP Power Management]]<br>
+
For more information, check out http://beagleboard.org and http://beagleboard.org/brief.
''Software skills:'' C, Linux kernel driver development<br>
 
''Mentor:'' Kevin Hilman (english, français)<br>
 
  
'''MUSB enhancements'''<br>
+
==Students looking for ideas==
The MUSB block on the Beagle has a lot of potential but the driver is currently rather buggy. This project will be to fix the driver so the MUSB implementation as paired with the PHY used on the Beagle board can work reliably as a USB OTG device. This means it should be able to at least reliably go back and forth between host and device mode without a reboot by just changing from a A to a B cable AND be able to force host or device mode in software. See the Nokia N8x0 devices for a sample behavior of how software can force this. An initial estimate is code needs to be implemented to force the PHY into host or device mode as requested by SysFS.
+
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 [http://webchat.freenode.net/?channels=beagle-gsoc the BeagleBoard GSoC IRC] or [http://groups.google.com/group/beagleboard-gsoc 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.
  
''Possible mentors:'' Felipe Balbi, Kevin Hilman, Swami, Hunyue Yau<br>
+
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_Project_Ideas|ECE497 class project idea list]]. You can also check out [[BeagleBoard/GSoC/Ideas-2015|last year's idea page]].
  
'''USB device audio support'''<br>
+
==Mentors wondering where to help==
The Linux USB gadget infrastructure doesn't have audio device class support (but Linux does have [http://www.linux-usb.org/USB-guide/x319.html USB host audio] support.  There is some work on a [http://docs.blackfin.uclinux.org/doku.php?id=gadget_midi gadget MIDI audio driver].  Some work has been done over at [http://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_item_id=4212 Blackfin], but is reported as not working very well. Getting USB isochronous endpoint, gadget audio driver connected to audio on BeagleBoard would be beneficial to all OMAP3 isochronous USB needs, better isochronous gadget support in Linux (there are no standard gadgets test for isochronous endpoints), and a prove out a real gadget driver that requires isochronous endpoints.  Anyone wanting to learn about communication protocols, a well designed layered communication implementation, and a chance to work at the driver level will enjoy this project.
+
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.
  
''Possible mentors:'' Swami
+
You will also need be invited by an administrator to register on [https://summerofcode.withgoogle.com/organizations/4817552005922816/ the GSoC site] and request to be a mentor for BeagleBoard.org.
  
'''SYS/Link support in the mainline kernel'''<br>
+
==General requirements==
''Possible mentors:'' Mugdha Kamoolkar<br>
+
All projects have the following basic requirements:
 
+
# Once accepted, the project must be registered on http://beagleboard.org/project.
==Improve bootloader support==
+
# All newly generated materials must be released under an [http://www.opensource.org/licenses open source license].
There are many bootloaders available for the BeagleBoard and other ARM embedded devices, but all can be given improvements for ease-of-use for new usersPlaces where many bootloaders fall down is in reliance on a limited set of user inputs (such as only the serial port) or not connecting to every boot device (such as a USB flash drive). They also might rely on commands that are difficult to understand or not familiar to the user.
+
# 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 GroupThe "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.
  
''Goal:'' Create a bootloader, or a set of bootloaders, that:
+
==Idea template==
* is open source without requiring giving away rights over the operating system or applications,
+
Description
* can be built using open source tools,
+
<br>
* can be loaded from NAND, SD, USB, or serial port directly by the ROM code and executed,
 
* provides a user interface to Windows and Linux PCs over both the USB OTG and serial ports,
 
* provides a user interface to the user via keyboard, mouse, and monitor,
 
* loads quickly from the ROM and can load an operating system quickly, and
 
* can load operating systems from and format new SD cards and USB flash drives with bootable copies of itself.<br>
 
''Existing projects:'' [http://beagleboard.org/project/tianocore Tianocore], [http://beagleboard.org/project/U-Boot+%28V1%29/ U-boot], [http://beagleboard.org/project/OMAP+U-Boot+Utils/ u-boot utilities], [http://beagleboard.org/project/x-loader X-load bootloader-loader], [http://beagleboard.org/project/U-Boot+V2/ Barebox], [[APEX]], and [http://code.google.com/p/0xlab-bootloader/ Qi]<br>
 
''Additional references:'' [http://beagleboard.org/project/puppybits/ PuppyBits]<br>
 
''Hardware skills:'' Configure hardware at boot<br>
 
''Software skills:'' C, ARMv7 assembly<br>
 
 
 
===More detailed bootloader improvement ideas===
 
'''U-boot'''<br>
 
This is the bootloader shipped with the BeagleBoard today. We like it, but we don't love it. Because the development is moving to GPLv3, many commercial developers are likely to be frightened away from it at some point. Still, it would be nice to improve some of its fundamental short-comings on the BeagleBoard, such as:
 
* Add support for the USB host port (to connect a hub, keyboard, and mouse).
 
* Add USB Ethernet adapter support.
 
* Add USB OTG port (to connect to a PC to download code). This works on a branch, but isn't in good shape for getting accepted upstream.
 
* Add DVI-D display.
 
* Add USB mass-storage class host support (for flash drives).
 
* Add a boot configuration header to eliminate the need for x-loader.
 
 
 
''Possible mentors:'' Jason Kridner, Khasim Syed Mohammed, Steve Sakoman, Dirk Behme<br>
 
 
 
'''TianoCore'''<br>
 
It is unlikely that any has more standards momentum and flexibility than the TianoCore implementation of the UEFI boot specification. EFI bootloaders are further interesting in their ability to run EFI byte code (EBC) applications. There is already basic support of the BeagleBoard in TianoCore, but the functionality is a bit limited and the build instructions currently rely on non-free tools. At least the following improvements are required:
 
* Add support for the USB host port (to connect a hub, keyboard, and mouse).
 
* Add USB Ethernet adapter support.
 
* Add USB OTG port (to connect to a PC to download code).
 
* Add DVI-D display.
 
* Add USB mass-storage class host support for flash drives.
 
* Add USB device serial adapter emulation.
 
* Build with GCC.
 
* Performance optimizations.
 
 
 
All of the desired functionality is already demonstrated in Linux, one of the other boot-loaders, or in one of the additional references above.
 
 
 
'''Barebox'''<br>
 
It has already been shown that the Barebox bootloader can be scaled very reasonably down to something that can fit into the on-chip memory of the OMAP3, without using the DRAM.  Maintaining this sort of scalability can be critical to providing the fastest possible boot times.
 
 
 
''Possible mentors:'' Nishanth Menon<br>
 
 
 
'''boot.kernel.org'''<br>
 
There is a new network-based way to boot Linux hosted on kernel.org called [http://boot.kernel.org/ boot.kernel.org].  How about adding support there for the BeagleBoard (or BeagleBoard-xM, since it includes an Ethernet adapter).
 
 
 
==x86 instruction emulation==
 
Development or tuning the an emulator like qemu to emulate the x86 instruction set at a reasonable speed to run legacy x86 apps developed for another non Linux OS. Possibilities include Windows 9x, 2000, etc. An alternative approach to use qemu to emulate an x86 Linux system and run Wine up top of that. Yet another approach might be to add an emulation engine inside wine. The goals is to be able to run x86 applications. The OS is optional. Task could possibly be split between the ARM and DSP.
 
  
 
''Goal:'' <br>
 
''Goal:'' <br>
''Hardware skills:'' n/a<br>
+
''Hardware Skills:'' <br>
''Software skills:'' C, x86 assembly, ARMv7 assembly<br>
+
''Software Skills:'' <br>
''Possible mentors:'' _TBD_<br>
+
''Possible Mentors:''<br>
''Complexity:'' High<br>
+
''Upstream Repository:'' <br>
 
+
''References:'' <br>
==Minix3 support==
 
Porting Minix3 (www.minix3.org) to beagleboard. Minix3 is a highly reliable operating system. Currently it only runs on x86 hardware, but some work has been done to get it running on ARM.
 
 
 
''Goal:'' Getting Minix3 to run on BeagleBoard; adding drivers for the BeagleBoard peripherals<br>
 
''Hardware skills:'' n/a<br>
 
''Software skills:'' C, x86 assembly, ARMv7 assembly<br>
 
''Possible mentors:'' Frans Meulenbroeks, _TBD_<br>
 
''Complexity:'' High<br>
 
 
 
=Projects for heterogeneous multicore processing=
 
==Vala bindings for Codec Engine algorithms==
 
''Goal:'' _TBD_<br>
 
''Existing project:'' [http://beagleboard.org/project/disptec dispTEC]<br>
 
''Software skills:'' C, Vala, _TBD_<br>
 
''Possible mentors:'' Maria Rodriguez, Cristina Murillo, Todd Fischer, Diego Dompe, _TBD_<br>
 
 
 
==Erlang for ARM and C6000 in heterogeneous compute environments==
 
[http://en.wikipedia.org/wiki/Erlang_%28programming_language%29 Erlang] is a concurrent programming language that can theoretically be used to spread tasks across the processing cores on a BeagleBoard or across BeagleBoards on a network.  There is a project advancing on putting Erlang on the BeagleBoard and I'm sure there will be some additional tasks that could be suitable for GSoC students.
 
 
 
''Goal:'' Distribute tasks across multiple BeagleBoards and between the ARM and DSP processors on a BeagleBoard using Erlang.<br>
 
''Software skills:'' Erlang, _TBD_<br>
 
''Possible mentors:'' Marcus Taylor, _TBD_<br>
 
 
 
==Compile POSIX applications on a slave DSP==
 
To do algorithm prototyping, sometimes it is desired to not initially bother with the details of the optimized interprocessor communications.  Instead, it is desired to take a simple stand-alone application and proceed with optimizations before dividing it up between the processors.  To do the optimizations for the DSP, you need a environment that provides simple compile, run, and profile development flow, without looking at IPC.
 
 
 
A stretch goal would be to expose some display/audio capabilities that work in real-time.
 
 
 
''Goal:'' Build a C64x+ POSIX library that utilizes resources on the ARM over DSP/Link and compile with a simple script that looks like 'gcc'.<br>
 
''Existing project:'' [https://gforge.ti.com/gf/project/dspeasy/ DSPEasy]<br>
 
''Software skills:'' C, JavaScript, shell scripting<br>
 
''Mentors:'' Jason Kridner, Daniel Allred<br>
 
 
 
==Add DSP support to GNU radio==
 
''Goal:'' GNU Radio is a popular Software Defined Radio package for PC based computers. GNU Radio also runs on the Beagleboard and can make use of the floating point unit on the ARM. However, the DSP on the Beagleboard has tremendous potential for increasing GNU Radio's capability on small hardware. The project difficulty is based on the level of effort desired by the student, it should be fairly easy to create a standalone GNU Radio block that talks to the DSP via dsplink, or very complex to modify the GNU Radio block scheduler to launch block on the DSP directly.<br>
 
''Existing project:'' [http://gnuradio.org GNURadio]<br>
 
''Software skills:'' C++<br>
 
''Mentors:'' Philip Balister<br>
 
 
 
=Multimedia and user experience projects=
 
==Speech recognition==
 
TI has released [https://gforge.ti.com/gf/project/tiesr/ source for a speech recognition library] that runs on the ARM processor of the OMAP3 on the BeagleBoard.  Currently, it is under a TI license, so it might not qualify as-is for inclusion in GSoC, but that can be explored.  There may be other libraries that can be utilized for this project.  Using speech recognition library, several tasks could be performed:
 
* Voice recognition integrated into Ubiquity: Integrate Mozilla Firefox, Mozilla Ubiquity, and voice recognition on the BeagleBoard with a microphone.  Use of a Wiimote could provide additional interactive capabilities.
 
 
 
''Existing project:'' http://beagleboard.org/project/tiesr<br>
 
''Possible mentors:'' Lorin Netsch, Sourabh Ravindran<br>
 
 
 
==Android running as a windowed application==
 
Modify Android to work within an embedded system as a windowed application.  This has been done under an emulation environment today on PCs, but that might not be fast enough for embedded systems.  This should provide minimal overhead and look as close to running only Android as possible to the Android application and core tasks.
 
 
 
''Goal:'' Execute Android .apk-distributed applications within a more full-featured GNU/Linux distribution as a windowed application.<br>
 
''Software skills:'' Java, C, shell scripting<br>
 
''Possible mentors:'' Jason Kridner, Katie Roberts-Hoffman, _TBD_<br>
 
 
 
==XBMC Media Center to Beagle Board==
 
XBMC is an open-source, cross platform media center that would allow you to display high definition video on your TV that is streamed from your local network or the internet.  XBMC on Beagle Board would would be a very low cost, low power platform that would allow the media center to literally be embedded ''in'' the TV.  XBMC could run on an Ubuntu distribution of Linux and would requiring the development of OpenGL ES complaint DirectFBGL drivers.
 
 
 
Some work has already been done to get this going by ''TheUni'' on the IRC channel.  He's also made blog postings about his work.
 
 
 
=Hardware + software projects=
 
These are "Make"-style projects that advance general knowledge for creating and improving end products for consumers.
 
 
 
Multiple prototype hardware systems should be made to complete these projects. The process should be documented and be something that the mentor reproduces and that anyone else can reproduce at a reasonable expense with only some minimal hardware skills (soldering, using a volt meter, etc.).
 
 
 
==Intelligent thermostat that utilizes weather forecasts==
 
* Improve the thermostatic control of a domestic heating system by more intelligent control based on the analysis of forecast weather.
 
* Enable remote control of the system through IP Internet access.
 
* Enable local control through touch screen.
 
 
 
''Possible mentor:'' Todd Fischer
 
 
 
==Adding Sense to Beagle==
 
Sensory aware applications are becoming more mainstream with the release of the Apple iPhone.  This project would combine both HW and SW to add sensory awareness to beagle.  First, additional modules such as GPS, 3-axis accelerometers, Gyroscopes, Temperature Sensors, Humidity Sensors, Pressure Sensors, etc, would be added to beagle to compliment the microphone input in order to allow sensing of the real world environment.  Then SW APIs would need to be layered on top to allow easy access to the sensory data for use by applications. 
 
 
 
The Freespace module is already working with the BeagleBoard as are many other sensors.  This project should seek to summarize how to connect as many sensors as possible on one place on the eLinux wiki.
 
 
 
''Possible mentor:'' Mark Yoder
 
 
 
=Community infrastructure projects=
 
==Updating BeagleBoard.org UI/backend==
 
The BeagleBoard.org website is currently written in JavaScript using Helma and makes use of several Java components through JavaScript.  One advantage of this is you can actually run an instance of the BeagleBoard.org web server on the BeagleBoard with a full clone of the website.
 
* Improve OpenID support
 
* Create Ubiquity scripts to simplify page editing
 
* Add tags to project entries and improve the views
 
* Import RSS feed items into pages for ranking/tagging
 
* Add microblogging support integrated with the IRC channel
 
** See http://code.google.com/p/beagleboard/issues/detail?id=46
 
** Enable users to store http://beagleboard.org/user user profiles
 
** Have the chat show Twitter and Identica update
 
* Translate BeagleBoard.org into other languages
 
** http://code.google.com/p/beagleboard/issues/detail?id=4
 
* Update the site for the BeagleBoard-xM launch occurring in June
 
 
 
''Software skills:'' JavaScript, XML, HTML/CSS<br>
 
''Mentor:'' Jason Kridner<br>
 
 
 
=To be classified=
 
=== BeaglePOD ===
 
'''Easy'''
 
MP3 player based on Beagle Board. This could involve porting Rockbox (www.rockbox.org) - an open source firmware for mp3 players to Beagle Board. Additional effort would involve creating Rockbox plugins to port the audio decoders and encoders to the DSP side. MTP device class support need to be added on USB as well.
 
 
 
=== BeagleChat ===
 
'''Easy'''
 
Video Chat Client on Beagle Board. Porting Ekiga (www.ekiga.org) - an open source VoIP and video conferencing application for GNOME. The client should be able to talk to ekiga software running on PC as well as another beagle board. Optimizations would involve porting audio and video codecs on Ekiga to DSP plus supporting video streaming over USB for webcam support.
 
 
 
===Fast Linux boot===
 
Beagle variant of "from 0 to 60 in 5 seconds" make a beagle that starts in < 5 seconds
 
 
 
Modify Beagle boot loader and OS to boot in < 5 seconds. While for desktop systems boot time might not be critical, for an embedded system like Beagle Board it often is. For an embedded system there often are external requirements which need fast boot to react properly to external events. For example external sensor signals, user input or even wake up signals in extremely deep sleep which needs re-start of operating system.
 
 
 
For Linux OS, there are already several resources how to reduce boot time available, e.g. [[Boot_Time|boot time]] and [[Suspend_To_Disk_For_ARM|suspend to disk for ARM]] articles.
 
 
 
Review, select, and apply some of the known technologies for BeagleBoard.
 
 
 
Ideally, should come up to a GUI prompt, such as with Android, Angstrom, or Ubuntu.
 
 
 
Need to examine http://code.google.com/p/swiftbeagle/ as a starting point.  Improvements include getting into a more functional environment.
 
  
=== Ogg Theora integration into Firefox and performance improvements ===
+
=Ideas=
'''Medium'''
+
==Linux kernel support for embedded devices and interfaces==
Codec Engine (C64x+) implementation of Ogg Theora
+
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.
  
There was a Neuros GSoC project to port Ogg Theora to the C64x+ last year, but it was never finished.  See the [http://wiki.neurostechnology.com/index.php/Summer_of_Code_2008/Ogg_Theora_Codec Neuros project page] to understand the status.
+
==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/
  
=Raw ideas that need to be fleshed out=
+
* 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
Some additional ideas can be found on the [[BeagleBoard/contest|BeagleBoard contest page]] and the [http://beagleboard.org/project BeagleBoard project page].
+
* 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.
  
* RTEMS BSP for Beagle board: '''Medium''' [http://www.rtems.org RTEMS] is a free real-time operating system.  This project would require developing an RTEMS Board Support Package for the Beagle board. The Beagle board has come up multiple times in our community as a excellent device for students, hobbyists, and a starting point for customized boards. I am the maintainer of RTEMS and would be willing to co-mentor this with someone from the Beagle board community. --[[User:JoelSherrill|JoelSherrill]] 23:12, 18 March 2010 (UTC)
+
==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.
  
* VNC client on Beagle board: '''Done/Easy'''  Enable Virtual Network Computing on Beagle board to allow remote access to desktops. TightVNC (http://www.tightvnc.com/index.html) derived from VNC can be ported to a Embedded Linux distribution.
+
==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 or stereo image processing to PRUs, use "Blue" or Black (via BBIO cape) as Ardupilot platform.
  
* Ubuntu Mobile on Beagle MID: '''Done/Easy'''  Porting Ubuntu mobile version on Beagle board (http://elinux.org/BeagleBoardUbuntu) and enable support for standard applications used in standard internet tablets/MIDs - media player, browser.
+
==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.
  
* NEON Support for FFTW: '''Medium'''  [http://www.fftw.org| FFTW] is a library for calculating the [http://mathworld.wolfram.com/FastFourierTransform.html| Fast Fourier Transform]. The current implementation of FFTW contains SIMD optimizations for several instructions sets. It should be possible to add optimizations for the NEON SIMD co-processor in the Beagle Board. FFTW is widely used in the open source community and this project would make FFTW far more useful on processors with NEON instructions. The mentor is particularly interested in improving GNU Radio on the OMAP3 and improving FFTW performance would be very useful.
+
==Linux userspace support of embedded devices and interfaces in high-level languages==
 +
Improving the Bonescript JavaScript library, the PyBBIO Python library, Userspace Arduino, web-based interface libraries, examples or alternatives in other languages.
  
* Audio-based translator: '''Medium'''  Utilizing voice recognition on the BeagleBoard with a microphone, submit text to Google Translator, then perform text-to-speech.
+
For PyBBIO this could include support for the latest 4.1 Linux kernel (see [https://github.com/graycatlabs/PyBBIO/milestones/4.1%20kernel%20support 4.1 milestone here]), addressing [https://github.com/graycatlabs/PyBBIO/issues open issues], adding new features and device drivers, etc..
  
* Spectrum analyzer using the DSP: '''Medium'''  Write a program that uses the DSP to take an alsa input and to all the math and a GUI on the arm that display the realtime spectrum. The DSP side needs to use xdais so other DSP programs can run at the same time.
+
==BeagleSat Platform Integration==
 +
* Goal: Integrate BeagleSat "satellite" platform into existing ArduPilot framework, including previous GSoC BeagleSat magnetometer application; BeagleBone blue has most of the required hardware, and black is already a supported hardware platform for ardupilot (via BBMini or Proto capes), however, ArduPilot does not have a satellite vehicle platform (should probably be derived from ArduCopter).
 +
* Hardware Skills: soldering/prototyping, serial/debug, sensors
 +
* Software Skills: high-level language skills (Python, C, etc), some knowledge of micro-controller compilers and targets, kernel config/programming (some)
 +
* Possible Mentors: Steve Arnold, Alexander Hiam
 +
* Upstream Repository: [https://github.com/nvisnjic/BeagleSat BeagleSat] , [https://github.com/BeaglePilot/ardupilot BeaglePilot] , [https://github.com/mirkix/BBBMINI BBMini]
 +
* References: [http://www.strawsondesign.com/#!board-features BeagleBone Blue board features] , [http://dev.ardupilot.com/wiki/building-for-beaglebone-black-on-linux/ Building (ardupilot) for BeagleBone Black on Linux] , [http://dev.ardupilot.com/wiki/mavlink-commands/ MAVLink Commands]
  
* Android integrated into embedded distributions: '''Medium'''  Utilize Open Embedded to build Android including Android kernel patches and integration of accelerated multimedia.  Add the 'repo' tool to Open Embedded to pull the Android open source code, apply kernel patches, and patch Android to utilize OpenGLES and GStreamer with the GStreamer-TI plugins. Android file system would co-exist with Angstrom file system.
+
==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.
  
* Cairo support for OpenVG: '''Medium'''  Cairo has an experimental openvg backend (found at http://lists.cairographics.org/archives/cairo/2008-January/012833.html). And there is some work that shows noticeable performance improvements on top level applications like webkit (http://www.atoker.com/blog/2008/01/28/accelerating-webkit-with-openvg/).
+
==SPI Flash Emulator (possibly 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 McSPI interface on AM335x or 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.
  
* Port MPlayer or GStreamer with DSP codec support: '''Medium'''  GStreamer is a multimedia package that handles streaming and file playback for a variety of multimedia files. The port was done for DaVinci, it would be cool to have a simiilar port done for Beagleboardhttp://focus.ti.com/dsp/docs/dspsplash.tsp?contentId=3100.  There's a lot of work done in the GStreamer arena: [[BeagleBoard/gst-openmax]] and there's also the [http://github.com/felipec/gst-dsp gst-dsp]. These projects are targeted for the [[BeagleBoard/DSP_Howto|bridgedriver]].
+
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 spidevLonger term, special cape hardware could be designed to support level shifting but initial development should not require any special PCB.
  
* Ogg Vorbis audio xDM encode and decode codecs: '''Medium'''
+
Since the McSPI interface on AM335x can only operate at up to 16 MHz in slave mode (even in OPP100, it's slower in OPP50), it will first need to be evaluated if using a PRU is the best course of action or if just using the McSPI interface would be a better choice.
  
* Implement NTFS and/or Mac OSX file systems: '''Medium'''  Read/write for SD cards and such
+
* Goal: Create a generic SPI slave framework in Linux with McSPI as the first hardware layer and a SPI flash emulator as the first protocol driver.<br />
 +
* Hardware Skills: General breadboarding with jumper wires.<br />
 +
* Software Skills: Linux kernel C programming.<br />
 +
* Possible Mentors: Andrew Bradford<br />
 +
* Upstream Repository:kernel.org<br />
 +
* References:
  
* Develop a ‘simple’ DSP loader Linux application that will allow user to load DSP image from ARM side: '''Medium'''
+
==PRU Framebuffer==
 +
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.
  
* Porting open-source codec to DSP (MadPlay, VLC, some of the mplayer codecs …: '''Medium'''
+
* Goal: PRU firmware which can drive a TTL LCD panel at a single or multiple standard resolutions along with Linux framebuffer driver enablement and communications to the PRU for both sending/receiving messages and sending of image data.<br />
 +
* Hardware Skills: Ability to jumper wire BBB to an off the shelf TTL LCD panel breakout.<br />
 +
* Software Skills: Linux kernel driver work.<br />
 +
* Possible Mentors: Andrew Bradford<br />
 +
* Upstream Repository: kernel.org<br />
 +
* References: http://hackaday.com/2012/06/26/offloading-vga-generation-onto-a-coprocessor/
  
* USB sniffer: '''Hard''' Come up with a USB sniffer solution. Idea is that the device to be sniffed is connected to the USB host port of the beagle and the beagle itself to the original host. The beagle will pass-trhu all usb data while logging that data. This could be a great help diagnosing USB problems or reengineering USB communication to a device (by logging the behaviour of a device when connected to a PC (software solutions for that exist too (usbsnoop), but a hardware solution could also support replay etc.
+
==Open-AVB support for BeagleBone==
 +
Ethernet AVB is being designed into most next generation automotive audio systems and is starting to be adopted for professional audio environments such as studios. However, most Ethernet AVB stacks are available only as commercial products from competing vendors. The AVNu Alliance, the standards organization for Ethernet AVB, does sponsor the FOSS Open-AVB project (https://github.com/AVnu/Open-AVB). Open-AVB currently only has proof-of-concept support for x86 and the I210 Ethernet NIC. AM335x and AM57xx have the necessary silicon support to support Ethernet AVB.
  
* Touchscreen and LCD open hardware design: '''Hard''' BeagleBoard rev C has a new connector for attaching an LCD. The Touchscreen and LCD open hardware design project would consist of a schematic, PCB layout, and bill of materials that can be purchased easily over the Internet. On online PCB fab could make the PCBs cheaply.  Only a soldering iron should be needed to populate the PCB. Once built, the user could connect the PCB to their BeagleBoard had have an LCD with touchscreen support. This project is targeted toward those interested in hardware and shouldn't require any complex software if a well supported touch screen controller chip is selected.
+
* Goal: Development can target two BeagleBones, supporting each in Open-AVB as both talker and listener. The effort will involve abstracting some of the x86 specific code in Open-AVB for ARMv7, enabling Open-AVB framing over CPSW Ethernet, and handling audio sourcing/sinking on each BeagleBone. The end goal is to use gstreamer to pass audio and/or video from a BeagleBone acting as a talker to a BeagleBone acting as a listener while complying with the AVB standards.
 +
* Hardware Skills: Basic skills in setting up Beaglebones and network cabling.
 +
* Software Skills: Ability to work in kernel and userspace in C. This will require work both in the AM335x Ethernet driver and the userspace Open-AVB project.
 +
* Possible Mentors: Matt Porter
 +
* Upstream Repository: https://git.kernel.org/cgit/ and https://github.com/AVnu/Open-AVB
 +
* References: https://en.wikipedia.org/wiki/Audio_Video_Bridging
  
* OpenCV DSP acceleration: '''Hard''' Research and implement hardware acceleration for OpenCV using the DSP on beagleboard. The DSP side needs to use xdais so other DSP programs can run at the same time.
+
==StratchX extension for BoneScript==
 +
[http://scratchx.org ScratchX] is a graphical programming tool for new programmers. [http://beagleboard.org/bonescript BoneScript] provides the ability to directly communicate with the I/O functions of a BeagleBone directly from within the browser. For examples see my presentation on [http://beagleboard.org/project/javascript-tricks/ JavaScript tricks]. ScratchX provides a fairly simple [http://scratchx.org/#faq-scratch-extensions extension mechanism] for which it would be easy to add BoneScript support.
  
* Power Aware Computing APIs: '''Hard'''  Power consumption is a major problem in mobile devices. While there are many HW level power management features in processors such as the OMAP35x, SW lacks the ability to manipulate and control those features. Research those power features and implement kernel APIs to allow applications to manage their power more efficiently.
+
==BeagleBone Blue APIs==
 +
* Goal: To create easy-to-use APIs for the hardware on the [http://beagleboard.org/blue BeagleBone Blue]. This should consist of developing/improving kernel drivers for the on-board sensors, developing a kernel driver for the PRU servo driver, etc., then reimplementing the [http://www.strawsondesign.com/#!manual-dc-motors Strawson APIs] to use these kernel drivers. If time allows, APIs could also be implemented in Bonescript and/or PyBBIO.
 +
* Hardware Skills: Some soldering, prototyping (hooking up and testing motors, etc.)
 +
* Software Skills: C, Linux kernel drivers, possibly PRU C or assembly, Device Tree
 +
* Possible Mentors: Alex Hiam, Deepak Karki
 +
* Upstream Repository: [https://github.com/beagleboard/linux beagleboard/Linux]
 +
* References: [https://github.com/StrawsonDesign/Robotics_Cape_Installer Strawson software]
  
* OpenGL DSP acceleration: '''Hard''' Research and implement OpenGL ES using the DSP on beagleboard.  The DSP side needs to use xdais so other DSP programs can run at the same time. Can take a look at Vincent OpenGL ES open source implementation and add DSP to it
+
==BBB-based Serial Terminal Server==
 +
Often in embedded development it is valuable to have a serial terminal server which can retain a serial port connection along with buffered past I/O separate from a typical host PC, either for longer term logging of serial port data or to enable remote management of a device via serial port.  Commercial units which have this capability are very expensive. The BeagleBones have 4 highly capable UARTs exposed besides UART0 through the cape connectors and a simple cape hardware could easily enable a BeagleBone to physically have all the interfaces needed to be a serial terminal server.  The cape hardware does not need to be created for this project to go forward, so long as other devices which connected to the BeagleBone terminal server used 3.3 V UARTs themselves.
  
* Smart Energy Monitoring Console: '''Hard''' The ZigBee Smart Energy profile is a wireless standard for utility companies and consumers to securely monitor and manage home energy consumption by communicating directly with smart appliances that report their power usageBy interfacing the Beagle Board to an MCU and RF transceiver monitoring the energy consumption of a home and it's appliances, the Beagle Board could act as a dedicated terminal to track ''and control'' energy usage of power hungry devices.
+
This project would begin with a survey of existing software which could be adapted to provide a terminal server experience (for example something as simple as using GNU screen with some adaptations over an SSH connection to the BeagleBone) and then proceed to create software changes needed to enable such operation in an easy to use and deploy way.  This resulting (or found) software would likely end up being generic for Linux based serial terminal serversThe end result of this project should likely be an easy to deploy SD card image to enable someone to setup a low cost serial terminal server based on a BeagleBone in only a few minutes.
  
* Wiigle Board (low cost video game platform): '''Hard''' Develop an open source platform for video game development by generating the drivers to standard interfaces such as wireless accelerometers or game controllers.  Off the self microcontrollers can be leverages to handle the I/O and RF interfaces, and the Beagle Board would handle all processing and displayBy generating a clean, open standard, the community could port existing games or use this as their preferred platform for video game development. The concept could be extended by porting known console emulators (NES, Genesis, SNES, etc) to run classic games on a unified, low cost platform.
+
A reach goal would be to enable the cape hardware and also to potentially provide DC relays which could switch 5-12 V at 2-3 A such that development boards could be powered on and off through the same software interface as is used for the serial communicationsSince hardware is not the focus of GSoC, actual development of such hardware should not be the focus of the project itself.
  
* Real-time audio room analyzer/equalizer: '''Hard''' Implement a real-time audio room analyzer/equalizer.  Using techniques such as PN sequence “noise” correlation, analyze the acoustic characteristics of a room and adjust the multiband filter responses for the high fidelity music output, all in real-time.  If the room acoustics change, even with something as transient as a person walking into the room, the filters adjust in real time to maintain the same frequency response for the specified region of the room.
+
==USB support for HelenOS on BeagleBoard XM and BeagleBone computers==
  
* Adjustable sweet spot for a high-end sound system: '''Hard''' Create an adjustable sweet spot for a high-end sound system. Use a sensor (thermal, webcam, whatever) to determine the placement of humans in the audience of a home theater or small concert hall.  Using appropriate timing delays in all pass filters and perhaps adjusting the frequency response, provide an optimized “sweet spot” for a 5.1, 6.1, or 7.1 sound system.  The program will be able to “move, ”  “grow,” or “shrink” the sweet spot area to provide the best acoustic experience for the greatest number of audience members, or as determined by some other user selectable criteria.
+
Implement HelenOS drivers for the USB host/OTG controllers as found on the BeagleBoard XM and BeagleBone single-board computers that will be part of the HelenOS DDF (Device Driver Framework) and USB stack.
  
* Inexpensive teleprompter that adapts to the speaker: '''Hard''' Design a small inexpensive teleprompter that adapts to the speaker. Using an image sensor and appropriate algorithms to determine the speaker’s location and direction of gaze, use a picoprojector to project the teleprompter output on a variety of predetermined surfaces. The surfaces could be special glass as with current teleprompters or simply a convenient wall of the room!  As the speaker moves their head or even moves around the stage or room, the teleprompter provides the projected output where needed.
+
HelenOS is a portable microkernel-based multiserver operating system designed and implemented from scratch. It decomposes key operating system functionality such as file systems, networking, device drivers and graphical user interface into a collection of fine-grained user space components that interact with each other via message passing. A failure or crash of one component does not directly harm others. HelenOS is therefore flexible, modular, extensible, fault tolerant and easy to understand.
  
* Protect the ears of concert-goers: '''Hard''' Protect the ears of concert-goers. Design a wideband real-time beamformer that would direct less sound energy to the front rows of a concert hall or stadium and more to the back rows, to equalize the relative volume.  Since beamforming algorithms are frequency (wavelength) dependent, the BeagleBoard would need to analyze the music content and adjust the beamforming parameters as needed in real-time.
+
HelenOS features basic support for the popular BeagleBoard XM and BeagleBone single-board computers. HelenOS also has its own USB stack, but because BeagleBone uses a non-standard USB host controller and BeagleBoard XM comes with a (sometimes) flaky EHCI host controller, and a non-standard OTG USB controller, HelenOS cannot unfold its full potential on these platforms, where most of the peripherals are meant to be attached via USB (mouse, keyboard, network, etc.).
  
* GPS: '''Done/Easy''' GPS application that works with USB GPS receiver (e.g. http://www.amazon.com/USB-12-Channel-NMEA-0183-Receiver-UT-41/dp/B000G6TYC8) or http://www.electronics-lab.com/projects/robotics/003/index.html. Has been done already using a Bluetooth GPS.
+
* Goal: Implement HelenOS drivers for the BeagleBone USB OTG controller, BeagleBoard XM OTG controller and get the HelenOS EHCI driver running on BeagleBoard XM
 +
* Hardware Skills: basic comprehension of the various USB connectors, interfaces and host controllers, studying hardware documentation
 +
* Software Skills: driver development, USB stack development, C, non-POSIX
 +
* Possible Mentors: Jakub Jermář
 +
* Upstream Repository: https://code.launchpad.net/~jan.vesely/helenos/usb, bzr://bzr.helenos.org/mainline
 +
* References: [http://www.helenos.org HelenOS home page], [http://www.helenos.org/ticket/647 HelenOS tickets for this idea], [http://www.helenos.org/wiki/DeveloperDocs/Peripherals#USB HelenOS collection of documentation pointers on USB peripherals], [https://code.launchpad.net/~jan.vesely/helenos/usb HelenOS USB 2.0 branch], [http://helenos-usb.sourceforge.net/manual/ Description of the original HelenOS USB stack], [http://elinux.org/BeagleBoard_Community#USB USB on BeagleBoard], [http://beagleboard.org/beagleboard-xm BeagleBoard XM home], [http://beagleboard.org/bone BeagleBone home], [http://processors.wiki.ti.com/index.php/Usb-am335x-quick-start Usb-am335x-quick-start], [https://en.wikipedia.org/wiki/USB_On-The-Go Wikipedia article about USB OTG]
  
* Jogger’s Friend: '''Hard''' Gather heart-rate data and GPS position information.  Use it to analyse the value of exercise and to suggest different exercise patterns to optimise the benefit to each individual.
+
== FlightGear remote Cockpit on BBB ==
 
* HiFi Companion: '''Hard''' Develop analysis algorithms to characterise the acoustic properties of a room, then present suggestions to optimise those characteristics to get best results from audio systems
 
  
* Voice Scrambler: '''Hard''' Develop algorithms for real-time scrambling of voice conversations for transmission across unsedcured connections. Some project has been kicked off here on on [[BeagleBoard/Contest]]
+
[http://www.flightgear.org/ FlightGear] is a free and open source cross-platform flight simulator platform or game. It support multiple computer and devices, so that we could build our remote cockpit at home, a [http://www.flightgear.org/Projects/747-JW/ example like this].  
 
* Brain Mouse: '''Hard''' Interpret brain signals so that a PC cursor can be controlled by thoughts to point and click on the screen.
 
  
* Open Source PLC: '''Hard''' Imagine Beagle opening and closing curtains, rendering audio when someone enters a room, turning on a fan as the temperature rises in a trombe wall - but only if the room temperature is cool, or a million other control applications.  There are several automation standards, including [http://en.wikipedia.org/wiki/IEC_61131 [IEC 61131]] and [http://www.automationml.org [AutomationML]]. However, there is no open source software available that implements any of these standards (puffin/MatPLC seems to have fizzled)! Create an Open Source PLC project supporting a freely accessible standard.
+
However, this project will only build a small prototype panel for FlightGear. It will use a small touch screen to display basic instruments for Aircraft - Atitude Indictor, Airspeed, Altitude and Heading, and two virtrual control "handle" for landing gear and flaps. The BBB will proform as a remote control device, it will connect to main flightgear instance FDM via network, and it could also connect to control devices or joystick/pedals as a control center.
  
* One-laptop-per-child (http://laptop.org/en/ ) with Beagle: '''Hard'''
+
On the other hand, when the remote panel is built, it could be used for Quadcopter and ROV remote control in the future.
  
* Move Firefox to Cairo on OpenVG and minimize memory footprint
+
* Goal: Build a prototype panel for FlightGear
* Implement OpenVG with the C64x and DMAs
+
* Hardware Skills: interfaces and host controllers, studying hardware documentation
* more codecs on the dsp (e.g. mp3 encoder/decoder, mpeg2 decoder, codecs for IP telephony (with video), ...)
+
* Software Skills: UI design and programing (C++, Qt, Python any availiable will okay), XML parse and basic flight theory.
* port LXDE (see www.lxde.org)
+
* Possible Mentors: Tong Hui
* beagle as DLNA/upnp renderer, server, controller, or media player.
+
* Upstream Repository: [https://github.com/saul-rodriguez/PanelBoeing A Qt Project]
* good text to speech support, xDM-based algorithm
+
* References: [http://flightgear.sourceforge.net/getstart-en/getstart-en.html FlightGear Manual], [https://sites.google.com/site/raspberryflightgear/home FlightGear Panel on a Rpi], [http://garagelab.com/profiles/blogs/tutorial-flightgear-with-arduino Arduino control aircraft in FlightGear]
* Clean MythTV, Boxee, XBMC, or Miro builds
 
* facial recognition with depth analysis using pico projector and webcam
 
* Port face-recognition and/or fingerprint recognition user app running on top of Android OS thru USB webcam
 
* high-speed 3d scanning with pico projector and webcam
 
* implementing a single pixel camera with beagleboard, pico projector and webcam; accelerate processing using DSP
 
* USB class converters (MTP to mass-storage, audio to midi, ...) or invasive sniffer
 
* Wiimote + Pico Projector + 3D art tool
 
* Extend Android with extra sensory operations (GPIO/PWM controls, temperature sensors, barometers, etc.)
 
* DSP libraries for Android (both portable C and optimized implementations with C64x+ and/or NEON)
 
* OpenCL implementation that uses the DSP and/or NEON (could be used as framework for any dsp/neon acceleration)
 
* Gesture-controlled web browser
 
* Power monitoring (http://www.google.org/powermeter/smarterpower.html)
 
* Off-line Google App host on an SD card
 
* Commodore 64 emulator via S-Video and Bluetooth keyboard
 
* Printer and Scanner Drivers for Beagle
 
* JPEG2000 codec running on BeagleBoard
 
* Video extender – take in video via usb webcam, compress it using video encoder, stream it over ethernet (could be like a security camera).  Could/should be implemented using DLNA protocols (e.g. view on ps3 or tv's).
 
* DVD player – hook up USB dvdrom drive and playback video and audio
 
* Receive and/or transmit IR signals (like from a remote control. Since I don’t think Beagle has an IR receiver, you’d probably need something like http://www.usbuirt.com/ (there are many others out there, too FM: lirc already works, as do usb-ir dongles
 
* Recording/logging data coming from instrumentation (e.g. Fluke multi-meter) … even better, combine with some DSP algorithm to “crunch” the data.
 
* Telescope interface that let a telescope track items in the sky (important if you’re trying to photograph things). Something along these lines for Beagle might be neat.
 
** http://www.telescopes.com/telescope-accessories/general-accessories/meade15foot20usbcable.cfm
 
** http://www.instructables.com/id/Usb_PTZ_webcam_tracking_system/
 
* USB midi keyboard interfacing
 
* Beagle-based Linux Fileserver FM: what would this have above a setup with samba/nfs/etc (e.g. the openembedded nas-server-image) ?
 
* Beagle-based Skype phone (VOIP application that connects microphone & speaker to ethernet). Could use either USB or Audio headset/mic-speaker
 
* Solar cell powered beagle-board (hardware/software). For potential laptop/computer applications
 
* Incorporate accelerometer (SPI or I2C interface) to lay the foundation for neat motion detection apps (hardware/software)
 
* Youtube on Linux (Angstrom) on Beagleboard:
 
* ekiga Wi Fi Video Softphone: (existing open source video conferencing code )that works on Linux (Angstrom) on Beagleboard Ekiga is already compiled for the arm-7 on Angstrom (http://www.angstrom-distribution.org/repo/?pkgname=ekiga). So The project would be to optimize it for the Beagle (and probably some debugging as Ekiga on beagle apparently is not that stable).
 
  
* Cellular Wireless card plug into USB on Beagleboard: (http://www.wireless.att.com/cell-phone-service/cell-phone-details/?device=AT%26T+USBConnect+Quicksilver&q_sku=sku3020359
+
=Previous ideas=
* Windows CE 6.0R2 running on Beagleboard using armv7 (Cortex A8) instruction set
+
* [[BeagleBoard/GSoC/Ideas-2015]]
* 2D Graphics acceleration using Cortex A8 Neon Coprocessor on Beagleboard
+
* [[BeagleBoard/GSoC/Ideas-2014]]
* SWFDEC using Cortex A8 / Neon coprocessor for acceleration
+
* [[BeagleBoard/GSoC/Ideas-2013]]
 +
* [[BeagleBoard/GSoC/Ideas-2012]]
  
 
=Mentors=
 
=Mentors=
 
 
{| border="1"
 
{| border="1"
 
! Name
 
! Name
Line 397: Line 210:
 
| English
 
| English
 
| -
 
| -
| US Central
+
| US Eastern
| web development, C, shell/perl scripting
+
| JavaScript, C, u-boot
 
| wiring, timing diagrams, basic debug
 
| wiring, timing diagrams, basic debug
| infrastructure improvements
+
| BoneScript development
 
|-
 
|-
 
| Hunyue Yau
 
| Hunyue Yau
 
| ds2
 
| ds2
|
+
| English
|
+
| -
 
| US Pacific
 
| US Pacific
 +
| Android, C, Linux, scripting, Kernel
 +
| schematics, wiring, EE details
 +
| Kernel/HW
 
|-
 
|-
| Frans Meulenbroeks
+
| Anuj Deshpande
| eFfeM
+
| anujdeshpande
| Dutch
+
| English
| English, basic understanding of German
+
| -
| CET
+
| UTC+530
| C, User Interface, Linux, booting, performance improvement, networking technology
+
| C, Python, Golang
| no
+
| Schematics
 +
| Arduino, Android
 +
|
 
|-
 
|-
| Kevin Hilman
+
| Andrew Bradford
| khilman
+
| bradfa
 
| English
 
| English
| fluent in French
+
| -
| US Pacific
+
| US Eastern
 +
| C, Linux, U-Boot
 +
| KiCad, some RF
 +
| DSP/PRU/M4 communication from Linux, wifi, USB gadget
 
|-
 
|-
| Luis Gustavo Lira
+
| Alex Hiam
|
+
| alexhiam
| Spanish
+
| English
| fluent in English and French)
+
| -
 +
| US Eastern
 +
| Python, C, programming...
 +
| schematics, design, debugging, prototyping
 +
| PRU, high-level userspace stuffs, kernel (device drivers?) X15?
 
|-
 
|-
| Koen Kooi
+
| Vladimir Pantelic
| _koen_
+
| av500
| Dutch
+
| German
| Fluent in English
+
| English
 
| CET
 
| CET
| Buildsystem integration, distribution
+
| C, Android, embedded programming
| not really
+
| schematics, design, debugging, prototyping
|  
+
| kernel, Android, dsp
 
|-
 
|-
| Katie Roberts-Hoffman
+
| Robert Manzke
| katier
+
| rma
 +
| German
 +
| English
 +
| CET
 +
| C, kernel, audio interfacing
 +
| schematics, design, debugging, prototyping
 +
| kernel, audio, dsp
 
|-
 
|-
| Mans Rullgard
+
| Steve Arnold
| mru
+
| nerdboy
| English, Swedish
+
| English
| Some German
+
| -
| GMT
+
| PST8PDT
| C, Assembler
+
| Python, kernel/bootloader, OS, sensor interfaces
|
+
| design, debugging, prototyping
|
+
| kernel, sensors/data acquisition/processing
 
|-
 
|-
| Mike Zucchi
+
| Matt Porter
| notzed
+
| mdp
 
| English
 
| English
|
+
| C :)
| Australia/South
+
| US Eastern
| C, Assembly, Java, SIMD.  Applications, libraries, GUI, multi-threading.
+
| U-Boot, kernel, drivers, upstream, AVB, networking/ipcs
| not much
+
| Schematic review, part selection, debugging
|  
+
| kernel, upstreaming, AVB, automotive
 +
|-
 +
| Kumar Abhishek
 +
| Abhishek_
 +
| English, Hindi
 +
| -
 +
| IST,+0530
 +
| C, Kernel, PRU related, embedded
 +
| Yes
 +
| kernel, PRUs, X15
 
|-
 
|-
| Philip Balister
+
| Jakub Jermář
| Crofton
+
| jermar
 +
| Czech
 +
| English
 +
| CET
 +
| everything HelenOS, C, Kernel, embedded
 +
| basic
 +
| HelenOS USB drivers for BeagleBone and BeagleBoard XM
 
|-
 
|-
| Robert Nelson
+
| Deepak Karki
| rcn-ee
+
| karki_
 +
| English
 +
| Hindi, kannada
 +
| India (IST)
 +
| PyBBIO, PRU programming, basic kernel stuff.
 +
| yes
 +
| BeagleBone Blue APIs.
 
|-
 
|-
| Soren Steen Christensen
+
| Michael Welling
|
+
| m_w
 +
| English
 +
| -
 +
| US Central
 +
| C, Linux Kernel, U-Boot, BASH
 +
| KiCad, FPGA, Robotics
 +
| Kernel, Robotics, FPGA
 
|-
 
|-
| Mark Yoder
+
| Tong Hui
| yoder
+
| tonghuix
|
+
| Chinese
 +
| English
 +
| UTC+8
 +
| C, driver, Embedded Programming.
 +
| KiCAD, schematics, design, debugging, testing
 +
| Beaglebone Black, Flightgear
 
|-
 
|-
| Jeff Osier-Mixon
+
| Andrew Henderson
| jefro
+
| hendersa
| English (US)
+
| English
|  
+
| -
| US Pacific
+
| US Eastern
|  
+
| C/C++, ARM asm, Linux, Linux kernel, Android
|  
+
| Prototyping, Eagle PCB
| documentation
+
| BeagleBone Black, Android, Linux userspace multimedia
 
|-
 
|-
| Laine Walker-Avina
+
| Chris Simmonds
| Ceriand
+
| simmondscd
 
| English
 
| English
|  
+
| -
| US Pacific
+
| GMT
| C, Assembly, Buildroot
+
| Android, Linux, U-Boot, kernel, drivers, C, C++, Java
| USB protocol & logic analyzers, Various JTAG probes
+
| Schematics, basic wiring, debugging
| OpenOCD, bootloaders, Linux kernel
+
| Android, Hardware support, Real-time
 +
|-
 +
| Name
 +
| IRC nickname
 +
| Native language
 +
| Other languages
 +
| Timezone
 +
| Software help
 +
| Hardware help
 +
| Focus projects
 
|}
 
|}
 +
[[BeagleBoard/GSoC/Ideas-2015#Mentors|Previous mentors]]

Revision as of 09:32, 16 March 2016


Welcome!

BeagleBoard.org has been accepted as a mentoring organization in the Google Summer of Code for 2016! Below, we've collected project ideas for the GSoC-2016.

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 2016 student application window is March 14th to 25th.

Google Summer of Code is open to post-secondary students, age 18 and older in most countries.

Read more on the GSoC site BeagleBoard.org landing 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[1] 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, SeeedStudio BeagleBone Green or BeagleBoard-X15 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 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. Once accepted, the project must be registered on http://beagleboard.org/project.
  2. All newly generated materials must be released under an open source license.
  3. Individual students shall retain copyright on their works.
  4. Source code generated during the project must be released on github.com (to be cloned to github.com/beagleboard on successful completion).
  5. 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.
  6. 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:
    1. what was accomplished that week,
    2. any issues that prevented that week's goals from being completed and
    3. your goals for the next week.
  7. 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.
  8. 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.
  9. 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.

Idea template

Description

Goal:
Hardware Skills:
Software Skills:
Possible Mentors:
Upstream Repository:
References:

Ideas

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 or stereo image processing to PRUs, use "Blue" or Black (via BBIO cape) as 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

Improving the Bonescript JavaScript library, the PyBBIO Python library, Userspace Arduino, web-based interface libraries, examples or alternatives in other 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..

BeagleSat Platform Integration

  • Goal: Integrate BeagleSat "satellite" platform into existing ArduPilot framework, including previous GSoC BeagleSat magnetometer application; BeagleBone blue has most of the required hardware, and black is already a supported hardware platform for ardupilot (via BBMini or Proto capes), however, ArduPilot does not have a satellite vehicle platform (should probably be derived from ArduCopter).
  • Hardware Skills: soldering/prototyping, serial/debug, sensors
  • Software Skills: high-level language skills (Python, C, etc), some knowledge of micro-controller compilers and targets, kernel config/programming (some)
  • Possible Mentors: Steve Arnold, Alexander Hiam
  • Upstream Repository: BeagleSat , BeaglePilot , BBMini
  • References: BeagleBone Blue board features , Building (ardupilot) for BeagleBone Black on Linux , MAVLink Commands

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 (possibly 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 McSPI interface on AM335x or 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.

Since the McSPI interface on AM335x can only operate at up to 16 MHz in slave mode (even in OPP100, it's slower in OPP50), it will first need to be evaluated if using a PRU is the best course of action or if just using the McSPI interface would be a better choice.

  • Goal: Create a generic SPI slave framework in Linux with McSPI as the first hardware layer and a SPI flash emulator as the first protocol driver.
  • Hardware Skills: General breadboarding with jumper wires.
  • Software Skills: Linux kernel C programming.
  • Possible Mentors: Andrew Bradford
  • Upstream Repository:kernel.org
  • References:

PRU Framebuffer

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.

  • Goal: PRU firmware which can drive a TTL LCD panel at a single or multiple standard resolutions along with Linux framebuffer driver enablement and communications to the PRU for both sending/receiving messages and sending of image data.
  • Hardware Skills: Ability to jumper wire BBB to an off the shelf TTL LCD panel breakout.
  • Software Skills: Linux kernel driver work.
  • Possible Mentors: Andrew Bradford
  • Upstream Repository: kernel.org
  • References: http://hackaday.com/2012/06/26/offloading-vga-generation-onto-a-coprocessor/

Open-AVB support for BeagleBone

Ethernet AVB is being designed into most next generation automotive audio systems and is starting to be adopted for professional audio environments such as studios. However, most Ethernet AVB stacks are available only as commercial products from competing vendors. The AVNu Alliance, the standards organization for Ethernet AVB, does sponsor the FOSS Open-AVB project (https://github.com/AVnu/Open-AVB). Open-AVB currently only has proof-of-concept support for x86 and the I210 Ethernet NIC. AM335x and AM57xx have the necessary silicon support to support Ethernet AVB.

  • Goal: Development can target two BeagleBones, supporting each in Open-AVB as both talker and listener. The effort will involve abstracting some of the x86 specific code in Open-AVB for ARMv7, enabling Open-AVB framing over CPSW Ethernet, and handling audio sourcing/sinking on each BeagleBone. The end goal is to use gstreamer to pass audio and/or video from a BeagleBone acting as a talker to a BeagleBone acting as a listener while complying with the AVB standards.
  • Hardware Skills: Basic skills in setting up Beaglebones and network cabling.
  • Software Skills: Ability to work in kernel and userspace in C. This will require work both in the AM335x Ethernet driver and the userspace Open-AVB project.
  • Possible Mentors: Matt Porter
  • Upstream Repository: https://git.kernel.org/cgit/ and https://github.com/AVnu/Open-AVB
  • References: https://en.wikipedia.org/wiki/Audio_Video_Bridging

StratchX extension for BoneScript

ScratchX is a graphical programming tool for new programmers. BoneScript provides the ability to directly communicate with the I/O functions of a BeagleBone directly from within the browser. For examples see my presentation on JavaScript tricks. ScratchX provides a fairly simple extension mechanism for which it would be easy to add BoneScript support.

BeagleBone Blue APIs

  • Goal: To create easy-to-use APIs for the hardware on the BeagleBone Blue. This should consist of developing/improving kernel drivers for the on-board sensors, developing a kernel driver for the PRU servo driver, etc., then reimplementing the Strawson APIs to use these kernel drivers. If time allows, APIs could also be implemented in Bonescript and/or PyBBIO.
  • Hardware Skills: Some soldering, prototyping (hooking up and testing motors, etc.)
  • Software Skills: C, Linux kernel drivers, possibly PRU C or assembly, Device Tree
  • Possible Mentors: Alex Hiam, Deepak Karki
  • Upstream Repository: beagleboard/Linux
  • References: Strawson software

BBB-based Serial Terminal Server

Often in embedded development it is valuable to have a serial terminal server which can retain a serial port connection along with buffered past I/O separate from a typical host PC, either for longer term logging of serial port data or to enable remote management of a device via serial port. Commercial units which have this capability are very expensive. The BeagleBones have 4 highly capable UARTs exposed besides UART0 through the cape connectors and a simple cape hardware could easily enable a BeagleBone to physically have all the interfaces needed to be a serial terminal server. The cape hardware does not need to be created for this project to go forward, so long as other devices which connected to the BeagleBone terminal server used 3.3 V UARTs themselves.

This project would begin with a survey of existing software which could be adapted to provide a terminal server experience (for example something as simple as using GNU screen with some adaptations over an SSH connection to the BeagleBone) and then proceed to create software changes needed to enable such operation in an easy to use and deploy way. This resulting (or found) software would likely end up being generic for Linux based serial terminal servers. The end result of this project should likely be an easy to deploy SD card image to enable someone to setup a low cost serial terminal server based on a BeagleBone in only a few minutes.

A reach goal would be to enable the cape hardware and also to potentially provide DC relays which could switch 5-12 V at 2-3 A such that development boards could be powered on and off through the same software interface as is used for the serial communications. Since hardware is not the focus of GSoC, actual development of such hardware should not be the focus of the project itself.

USB support for HelenOS on BeagleBoard XM and BeagleBone computers

Implement HelenOS drivers for the USB host/OTG controllers as found on the BeagleBoard XM and BeagleBone single-board computers that will be part of the HelenOS DDF (Device Driver Framework) and USB stack.

HelenOS is a portable microkernel-based multiserver operating system designed and implemented from scratch. It decomposes key operating system functionality such as file systems, networking, device drivers and graphical user interface into a collection of fine-grained user space components that interact with each other via message passing. A failure or crash of one component does not directly harm others. HelenOS is therefore flexible, modular, extensible, fault tolerant and easy to understand.

HelenOS features basic support for the popular BeagleBoard XM and BeagleBone single-board computers. HelenOS also has its own USB stack, but because BeagleBone uses a non-standard USB host controller and BeagleBoard XM comes with a (sometimes) flaky EHCI host controller, and a non-standard OTG USB controller, HelenOS cannot unfold its full potential on these platforms, where most of the peripherals are meant to be attached via USB (mouse, keyboard, network, etc.).

FlightGear remote Cockpit on BBB

FlightGear is a free and open source cross-platform flight simulator platform or game. It support multiple computer and devices, so that we could build our remote cockpit at home, a example like this.

However, this project will only build a small prototype panel for FlightGear. It will use a small touch screen to display basic instruments for Aircraft - Atitude Indictor, Airspeed, Altitude and Heading, and two virtrual control "handle" for landing gear and flaps. The BBB will proform as a remote control device, it will connect to main flightgear instance FDM via network, and it could also connect to control devices or joystick/pedals as a control center.

On the other hand, when the remote panel is built, it could be used for Quadcopter and ROV remote control in the future.

Previous ideas

Mentors

Name IRC nickname Native language Other languages Timezone Software help Hardware help Focus projects
Jason Kridner jkridner English - US Eastern JavaScript, C, u-boot wiring, timing diagrams, basic debug BoneScript development
Hunyue Yau ds2 English - US Pacific Android, C, Linux, scripting, Kernel schematics, wiring, EE details Kernel/HW
Anuj Deshpande anujdeshpande English - UTC+530 C, Python, Golang Schematics Arduino, Android
Andrew Bradford bradfa English - US Eastern C, Linux, U-Boot KiCad, some RF DSP/PRU/M4 communication from Linux, wifi, USB gadget
Alex Hiam alexhiam English - US Eastern Python, C, programming... schematics, design, debugging, prototyping PRU, high-level userspace stuffs, kernel (device drivers?) X15?
Vladimir Pantelic av500 German English CET C, Android, embedded programming schematics, design, debugging, prototyping kernel, Android, dsp
Robert Manzke rma German English CET C, kernel, audio interfacing schematics, design, debugging, prototyping kernel, audio, dsp
Steve Arnold nerdboy English - PST8PDT Python, kernel/bootloader, OS, sensor interfaces design, debugging, prototyping kernel, sensors/data acquisition/processing
Matt Porter mdp English C :) US Eastern U-Boot, kernel, drivers, upstream, AVB, networking/ipcs Schematic review, part selection, debugging kernel, upstreaming, AVB, automotive
Kumar Abhishek Abhishek_ English, Hindi - IST,+0530 C, Kernel, PRU related, embedded Yes kernel, PRUs, X15
Jakub Jermář jermar Czech English CET everything HelenOS, C, Kernel, embedded basic HelenOS USB drivers for BeagleBone and BeagleBoard XM
Deepak Karki karki_ English Hindi, kannada India (IST) PyBBIO, PRU programming, basic kernel stuff. yes BeagleBone Blue APIs.
Michael Welling m_w English - US Central C, Linux Kernel, U-Boot, BASH KiCad, FPGA, Robotics Kernel, Robotics, FPGA
Tong Hui tonghuix Chinese English UTC+8 C, driver, Embedded Programming. KiCAD, schematics, design, debugging, testing Beaglebone Black, Flightgear
Andrew Henderson hendersa English - US Eastern C/C++, ARM asm, Linux, Linux kernel, Android Prototyping, Eagle PCB BeagleBone Black, Android, Linux userspace multimedia
Chris Simmonds simmondscd English - GMT Android, Linux, U-Boot, kernel, drivers, C, C++, Java Schematics, basic wiring, debugging Android, Hardware support, Real-time
Name IRC nickname Native language Other languages Timezone Software help Hardware help Focus projects

Previous mentors