BeagleBoard/GSoC/2016 Projects

< BeagleBoard‎ | GSoC
Revision as of 14:58, 23 March 2020 by Jkridner (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


Project: Template Project, please copy first and then edit

{{#ev:youtube|fL_XMieanSc||right|Video Title}} “Project Name”. add your project description here.

Project: Exposing the PRU as an I2C and SPI master Controller

{{#ev:youtube|fyaebfssmyE||right|GSOC-2016 Exposing the PRU as an I2C,SPI Master Controller}} Exposing the PRU as an I2C and SPI master Controller.Bitbanging an SPI or/an I2C device in Linux leads to a lot of problems. It consumes a lot of valuable CPU cycles. And since Linux is an non-preemptive OS(And not an RTOS), once we start bitbanging, other important tasks that require CPU time would suffer. Thus, there are a lot of software overheads in doing the same. To avoid this on the BBB, we could offload the task of bitbanging I2C and SPI to the PRU. The PRU is a separate core and hence not affected by the Linux Scheduler. Hence, the motivation for exposing the PRU as an I2C and SPI master controller comes from the fact that they would be no software overheads in doing it. We would gain extra serial interfaces without wasting valuable CPU cycles in bitabanging.

This project involves writing Device Tree Overlays,Device Drivers and PRU firmware code for Bitbanging I2C and SPI.

Project: SPI slave driver implementation

{{#ev:youtube|yBgMwMcvcKg||right|GSoC 2016 - SPI slave driver implementation}} SPI slave driver implementation. The task is to create a driver controlling SPI hardware controller in slave mode, and to ensure optimal performance through the use of DMA and interrupt. Creating an easy to implement realization of SPI slave would definitely help the BeagleBone community members to write applications based on SPI much more easily. The first implementation of my protocol driver is going to example of a bidirectional data exchange. This application will provide the BeagleBone community with valuable experience and will be a good example of SPI slave. Hardware limitations make it impossible to perform any realization of the device using SPI slave. Sending away data to the master during one transaction is not possible. One transaction is enough to receive data by slave device. To receive and send back data, two transactions are needed. The data received from master device in a single transaction is transferred to the user after completing the transaction. The user's reply to received data is sent in the next transaction.

Project: BeagleScope

{{#ev:youtube|tdanTRSmq4E||right|Introduction BeagleScope}} Many applications require mechanisms for high speed, real time and continuous data acquisition from a sensor that is essentially an ADC. Most hobbyists would want to use simple devices, rather than high end converters with differential serial interfaces to communicate as these high end devices can be expensive. The typical serial data communication protocols used for this are somewhat limited in terms of speed, while parallel data communication definitely has an advantage of higher speed data transfers.

This GSoC project aims to utilize the two PRUs present in the PRUSS2 subsystem and their low latency architecture to get a fast, generic, parallel analog converter interface, in the form of parallel bus, ready for various applications ( Oscilloscopes, Ultrasound scanners etc). The interface on the PRUs side would be generic in the sense that it would be highly customizable in terms of its clock (frequency and relative timing to the data), or sampling bit depth and there will also be support for writing data to a DAC . The project on completion will provide a ready to use firmware, user-space library, kernel driver, and the subsystem to manage all the transactions. This will further allow developers to build some cool applications like function generators, oscilloscopes, voltmeter etc.

On the right, is a small introductory video, that tells some basic things about the project. The video is basically a slide show, along with the description.

Project: Porting the CTAG face2|4 multichannel soundcard drivers to BeagleBoard-X15 (AM5728 SoC). Create library to make use of AM5728 DSPs (C66x).

{{#ev:youtube|_oYuRwqEvCc||right|Improving the BeagleBone low-latency multi-channel audio system}} The CTAG face2|4 is an open source audio system with 2 stereo inputs and 4 stereo outputs. The idea of the audio system is to create an open platform for DIY audio projects. Currently, the PCM soundcard can only be used with a BeagleBone Black/Green, which have not enough computing power for complex signal processing with Linux. Especially due to its two C66x DSPs the BeagleBoard-X15 seems to be a good alternative to improve the audio system and to create a more powerful platform.

The goal of the project is to port the soundcard drivers to the BeagleBoard-X15 and create an user-space library to make use of DSPs. Typical signal operations like FFT, convolution, etc. should be offloaded to the DSPs using the TI DSPLIB and OpenCL. As a strech goal a gstreamer plugin which uses the library should be created to simplify application development and to dynamically build complex audio pipelines.

Project: Sonic Anemometer

{{#ev:youtube|1EHpIu2IRQA||right|Sonic Anemometer}} The aim of this project is to create a sonic anemometer for small, inexpensive weather stations. Currently such stations are limited to cup anemometers which are heavily reliant on the precise movement of large mechanical sections. This limits their ability to respond to small amounts of wind, and they can be unreliable if they are not constructed well. A sonic anemometer solves these issues. Sonic waves can be used to determine even very low wind speeds, and without large moving components they are very reliable. Current sonic anemometers are relatively expensive, so they are not suitable for small, inexpensive stations.

Project: API support for Beaglebone Blue

{{#ev:youtube|oGlwUnbqkPg||right|API support for Beaglebone Blue}} The aim of the project is to create easy-to-use APIs for the hardware on the BB Blue. This would consist of developing/improving kernel drivers for the on-board devices and then re-implementing the Strawson APIs to use these kernel drivers. These APIs will then be used by real-time applications which can be run on BB Blue. In the later phase of the project, support for BB Blue will be added in Ardupilot and ROS will be ported to BB Blue using these APIs.

Project: Improving Bone101 Experience

{{#ev:youtube|AdhE9wmNZww||right|Improving Bone101 Experience}} This project is aimed to improve the experience of Bone101 to make the most use of it to be friendly to novice developers, allowing them to work with BBUI inside tutorials, write python code beside Javascript, and discover new experience of Bone101 in Cloud9 IDE. Providing Python support to tutorial languages will benefit a wide base of developers and newcomers, they can easily choose between JS and python to write new tutorials, and having the real experience of BB from a web page