Difference between revisions of "BeagleBoard/GSoC/2016 Projects"

From eLinux.org
Jump to: navigation, search
Line 37: Line 37:
* Code: https://github.com/pmezydlo/SPI_slave_driver_implementation
* Code: https://github.com/pmezydlo/SPI_slave_driver_implementation
* Wiki: https://github.com/pmezydlo/SPI_slave_driver_implementation/wiki
* Wiki: https://github.com/pmezydlo/SPI_slave_driver_implementation/wiki
* Blog: http://www.elinux.org/Pmezydlo
* GSoC site: https://summerofcode.withgoogle.com/projects/#5652864013697024
* GSoC site: https://summerofcode.withgoogle.com/dashboard/project/5652864013697024/overview/

Revision as of 01:15, 7 May 2016


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

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

SPI slave driver implementation. This task is to create a driver which controls 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 the applications based on SPI much more easily. The first implementation of my protocol driver is going to be a flash emulator. This application will provide the BeagleBone community with valuable experience. We encounter the non-volatile nor-flash memory in embedded systems more and more frequently. Unfortunately, it is not a good memory considering its time parameters. Writing and erasing it takes quite a long time even the use of high-speed programmer. My task will be to develop a Nor-flash emulator, which would shorten the time required to test the prototypes and it is a good example of the use of SPI Slave in many projects.

Project: 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.