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

From eLinux.org
Jump to: navigation, search
Line 18: Line 18:
  
 
==Project: [[Exposing the PRU as an I2C and SPI master Controller]] ==
 
==Project: [[Exposing the PRU as an I2C and SPI master Controller]] ==
“Exposing the PRU as an I2C and SPI master Controller”. add your project description here.
+
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.
 +
 
 
* Student: Vaibhav Choudhary
 
* Student: Vaibhav Choudhary
 
* Mentors: Andrew Bradford, Matt Porter
 
* Mentors: Andrew Bradford, Matt Porter

Revision as of 11:21, 4 May 2016

Links

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.