Student: Harshil Bhatt
Mentors: Vaishnav Achath, Jason Kridner, Tim Orling
This project is currently just a proposal.
- The PR for "Hello World" task #163
School: Manipal Institute of Technology
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
Greybus is an application layer for UniPro, initially designed to be used by modular phones to control modules. 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. Since Greybus is an application, it can be used over other protocols and buses such as TCP/IP, Bluetooth, GB Sim or UART with the help of GBridge (Greybus Bridge).
Greybus has two types of classes. The Device Class defines a group of protocols that provide device abstraction for functionality. Greybus Bridged PHY protocol is a set of designated protocols that allows modules to expose functionality to the Greybus system. Greybus Bridged PHY class drivers are used to emulate "traditional" busses by tunnelling them over Greybus. These include serial, SPI, I2C, USB and others. This class provides a bus where all bridged PHY devices connect. It provides a framework for the drivers to plug into.
There is a dedicated Zephyr module for Greybus, although still in pre-release. Currently, the following I/O protocols are supported by greybus-for-zephyr
The support for other peripherals (PWM, UART, and GPIO IRQ) exists in NuttX sources. ADC is currently not supported by Greybus specifications, and would require workarounds .
The Linux kernel's IIO subsystem  contains drivers for many sensors, most of which are interface using either I2C or SPI. Several boards mentioned below do not have kernel drivers. For these boards, kernel drivers will have to be written and merged upstream.
The aim of this project is to support all relevant peripherals (UART, PWM, 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. Drivers for these peripherals exist in the NuttX sources and need to be modified for Zephyr RTOS. The GPIO drivers require minor modifications to fix current issues such as excessive IRQ events sent by the greybus subsystem. 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. A vital addition would be adding samples as well as improving documentation of the existing peripherals for each peripheral.
Mikrobus drivers will be updated to automatically probe device drivers for the new peripherals added. Greybus will also be updated with support for gb-log, which can be used for logging data from remote nodes and gb-loopback, which can be used for greybus transaction throughput testing.
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.
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.
A Linux machine is required by the client in order to connect and control a Zephyr device via Greybus. The Greybus kernel modules also need to added to the current Linux kernel. 
- Beagleconnect freedom
- MikroElectronica boards for all relevant peripherals (any one board for each peripheral is required to successfully complete this project)
- General hardware requirements (LEDs, Resistors, Capacitors, Push-buttons)
|May 20th - June 12th||Community Bonding|
|June 13th||Milestone #1||
|June 20th||Milestone #2||
|June 27th||Milestone #3||
|July 4th||Milestone #4||
|July 11th||Milestone #5||
|July 18th||Milestone #6||
|July 25th||Milestone #7||
|August 1st||Milestone #8||
|August 8th||Milestone #9||
|August 15th||Milestone #10||
|August 22nd||Milestone #11||
|August 29th||Milestone #12||
|Sep. 5th||Milestone #13||
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.
There is a lot of documentation on Greybus, and some drivers have been merged into the Linux kernel which should provide a good reference. Greybus has an extensive spec sheet which will be really helpful. NuttX also contains the original implementation of Greybus which has been partially ported to Zephyr. This will provide a reference for porting other features such as gb-log or gb-loopback. Along with this, Beagle and Zephyr have an active community that can be looked to for help.
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.
Is there anything else we should have asked you?