Difference between revisions of "BeagleBoard/GSoC/2022 Proposal/GreybusforZephyrUpdates"

From eLinux.org
Jump to: navigation, search
(Timeline)
(Benefit)
Line 142: Line 142:
 
===Benefit===
 
===Benefit===
 
The major advantage of Greybus is that drivers can be maintained in Linux rather than microcontroller firmware. This gives us the ability to reuse existing Linux device drivers to access remote devices and reduces development time significantly. Since most application logic is kept out of the microcontroller firmware and in a better centralized location, updates can be better tested and deployed frequently.
 
The major advantage of Greybus is that drivers can be maintained in Linux rather than microcontroller firmware. This gives us the ability to reuse existing Linux device drivers to access remote devices and reduces development time significantly. Since most application logic is kept out of the microcontroller firmware and in a better centralized location, updates can be better tested and deployed frequently.
 +
 +
Improving the native-POSIX target provided by Zephyr and adding support for generating Greybus traffic and Greybus message handling will further reduce development time by reducing the need for architecture-specific hardware in the early phases of development.
  
 
==Misc==
 
==Misc==

Revision as of 09:30, 14 April 2022


Proposal

About Student: Harshil Bhatt
Mentors: Vaishnav Achath, Jason Kridner

Status

This project is currently just a proposal.

Proposal

  • The PR for "Hello World" task #163

About you

Github: harshilbhatt2001
School: Manipal Institute of Technology
Country: India
Primary language : English
Typical work hours: 2PM-1AM Indian Standard Time
Previous GSoC participation: This is my first time applying to participate for GSoC.

About your project

Project name: Greybus for Zephyr Updates

Description

Greybus is an application layer for UniPro. UniPro follows the classical OSI model, and UniPro communications happen over bidirectional connections between entities. The physical bus is attached to the connected device, which will be running Zephyr. A virtual bus, corresponding to the physical bus on the connected device, is created on the Linux side. The functionality of the physical bus and virtual bus appears the same to a user. Greybus is used to exchange bus-specific messages and data between the connected device and Linux.

Greybus Bridged PHY class drivers are used to emulate "traditional" busses by tunnelling them over Greybus. These include serial, SPI, I2C, USB and others. The Greybus Bridged PHY class provides a bus where all bridged PHY devices connect. It provides a framework for the Bridged PHY drivers to plug into.

There is a dedicated Zephyr module for Greybus, although still in pre-release. Currently, the following modules are supported by greybus-for-zephyr

  • GPIO
  • I2C
  • SPI

The aim of this project is to support all relevant peripherals (UART, PWM, ADC, GPIO IRQ) on BeagleConnect Freedom on Greybus for Zephyr. This involves adding platform-specific changes to enable these protocols and interfaces to existing NuttX sources. The device drivers will be merged into the kernel. These device drivers will be compatible with mikrobus add-on boards, and each peripheral will be tested over a mikrobus add-on board over Greybus using its corresponding driver in the kernel.

The Zephyr Project provides a native POSIX target that can run on the host OS without emulation. This eliminates the need for architecture-specific hardware in the early phases of development. This makes it a strong candidate for a host-side testbench. This target lacks several features which prevent it from being used in Greybus testing. A goal would be to generate Greybus traffic for testing along with fleshing out the native-posix target to be able to demonstrate Greybus message handling.

Software Requirements

The majority of this project involves porting existing device drivers from NuttX sources to work with Zephyr RTOS. This will enable using existing device drivers in the host kernel to interface with drivers on a remote microcontroller.

This is done in the C programming language and will be cross-compiled using the GCC compiler.

Hardware Requirements

  • Beagleconnect freedom
  • MikroElectronica boards for all relevant peripherals (any one board for each peripheral is required to successfully complete this project)
  • UART
  1. GPS Click
  2. Ultrasonic 2 Click
  3. H-Bridge 8 Click
  • PWM
  1. Buzz 2 Click
  2. Haptic 2 Click
  • ADC
  1. Three-Axis Accelerometer Board
  2. Force Click
  • GPIO
  1. Water detect Click
  2. Tilt 3 Click
  • General hardware requirements (LEDs, Resistors, Capacitors)

Timeline

Provide a development timeline with a milestone each of the 11 weeks and any pre-work. (A realistic timeline is critical to our selection process.)

Date Status Details
Presubmission
  • Setup zephyr environment and build a board for native POSIX execution (completed)
  • Blink an LED using Linux, Zephyr and Greybus via BLE
May 20th - June 12th Community Bonding
June 13th Milestone #1
  • Required hardware will be available to me, and I will start flashing Zephyr on Beagleconnect Freedom
  • Start going through the documentation and datasheet of the hardware available.
June 20th Milestone #2
  • Introduction Video
  • Interface PWM driver to existing NuttX sources
  • Documentation for PWM
June 27th Milestone #3
  • Test PWM on the add-on board mentioned above
  • Pull Request for PWM driver and feedback from mentors
July 4th Milestone #4
  • Interface UART driver to existing NuttX sources
  • Documentation for UART
July 11th Milestone #5
  • Test UART code on the add-on board mentioned above
  • Pull Request for UART driver and feedback from mentors
July 18th Milestone #6
  • Interface GPIO IRQ driver to existing NuttX sources
  • Documentation for GPIO IRQ
July 25th Milestone #7
  • Test GPIO IRQ code on the add-on board mentioned above
  • Pull Request for GPIO IRQ driver and feedback from mentors
  • Phase 1 Evaluation Deadline
August 1st Milestone #8
  • gb-log module for logging data from remote nodes
August 8th Milestone #9
August 15th Milestone #10
  • Explore support for ADC and possible workarounds.
August 22nd Milestone #11
August 29th Milestone #12
  • Submit final work product and final mentor evaluation
  • Complete YouTube video
Sep. 5th Milestone #13
  • Completion of GSoC

Experience and approach

  • I am a third-year undergrad having a good understanding of C, C++, ARM assembly and Python. Several of these languages have been used in my coursework too.
  • I was a firmware engineer intern at Sensegrass, and an Embedded System Engineer at Retisense. I have worked on Bluetooth Low Energy, where I improved throughput, interfaced various sensors over an I2C bus and optimized runtime memory with an innovative solution.
  • I have developed drivers for common peripherals (SPI, UART, I2C, ADC, GPIO IRQ, etc) using either bare-metal C or an underlying RTOS.
  • I am also developing a wireless body sensor network based on the Zephyr RTOS, where I have utilized the Nordic BLE stack along with LittleFS to propose a novel encryption scheme of collected sensor data.


Contingency

There is a lot of documentation on Greybus, and some drivers (GPIO) have been merged into the Linux kernel which should provide a good reference. Along with this, the Beagle and Zephyr have an active community that can be looked to for help.

Benefit

The major advantage of Greybus is that drivers can be maintained in Linux rather than microcontroller firmware. This gives us the ability to reuse existing Linux device drivers to access remote devices and reduces development time significantly. Since most application logic is kept out of the microcontroller firmware and in a better centralized location, updates can be better tested and deployed frequently.

Improving the native-POSIX target provided by Zephyr and adding support for generating Greybus traffic and Greybus message handling will further reduce development time by reducing the need for architecture-specific hardware in the early phases of development.

Misc

I have completed the requirements stated in the ideas page,the cross compilation task can be found here and the created the pull request can be found here

Suggestions

Is there anything else we should have asked you?