Difference between revisions of "BeagleBoard/GSoC/2022 Proposal/GreybusforZephyrUpdates"
(→Timeline) |
(→Timeline) |
||
Line 87: | Line 87: | ||
*Documentation for PWM | *Documentation for PWM | ||
*Test PWM on the add-on board mentioned above | *Test PWM on the add-on board mentioned above | ||
+ | *Pull Request for PWM driver and feedback from mentors | ||
+ | |- | ||
+ | | July 4th || Milestone #4 || | ||
*Start Device driver code for ADC | *Start Device driver code for ADC | ||
*Interface ADC driver to existing NuttX sources | *Interface ADC driver to existing NuttX sources | ||
|- | |- | ||
− | | July | + | | July 11th || Milestone #5 || |
*Documentation for ADC | *Documentation for ADC | ||
*Test ADC code on the add-on board mentioned above | *Test ADC code on the add-on board mentioned above | ||
+ | *Pull Request for ADC driver and feedback from mentors | ||
+ | |- | ||
+ | | July 18th || Milestone #6 || | ||
*Start Device driver code for UART | *Start Device driver code for UART | ||
*Interface UART driver to existing NuttX sources | *Interface UART driver to existing NuttX sources | ||
|- | |- | ||
− | | July | + | | July 25th || Milestone #7 || |
*Documentation for UART | *Documentation for UART | ||
*Test UART code on the add-on board mentioned above | *Test UART code on the add-on board mentioned above | ||
+ | *Pull Request for UART driver and feedback from mentors | ||
+ | *Phase 1 Evaluation Deadline | ||
+ | |- | ||
+ | | August 1st || Milestone #8 || | ||
*Start Device driver code for GPIO IRQ | *Start Device driver code for GPIO IRQ | ||
*Interface GPIO IRQ driver to existing NuttX sources | *Interface GPIO IRQ driver to existing NuttX sources | ||
|- | |- | ||
− | | | + | | August 8th || Milestone #9 || |
*Documentation for GPIO IRQ | *Documentation for GPIO IRQ | ||
*Test GPIO IRQ code on the add-on board mentioned above | *Test GPIO IRQ code on the add-on board mentioned above | ||
− | * | + | *Pull Request for GPIO IRQ driver and feedback from mentors |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
|- | |- | ||
| August 15th || Milestone #10 || | | August 15th || Milestone #10 || |
Revision as of 07:12, 11 April 2022
Contents
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.
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 interface 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.
Software Requirements
The majority of this project involves writing device drivers, and interfacing it with the Zephyr RTOS. 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
- PWM
- ADC
- GPIO
- 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 |
|
||
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.
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.
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?