BeagleBoard/GSoC/2019 Projects

From eLinux.org
Jump to: navigation, search


Links

Weekly reports

All weekly reports will be sent to the mailing list (as that is our primary support venue outside of live chat) on a single thread (to avoid e-mail thrash).

They must be sent on Monday to allow for mentors to respond ahead of Wednesdays IRC meeting where all blockers will be discussed live.

They must include the following sections:

  • Accomplishments
  • Resolutions to blockers
  • On-going blockers
  • Plans for the next week


Projects

Project Student Mentors Videos Reports Code Documentation
Clickboard Support Under Greybus Vaishnav M.A. (vaishnav98_) Jason Kridner (jkridner), Ravi Kumar Prasad (ravikp7) intro final weekly gbsim manifesto proposal wiki blog more
PRU User Space API Pratim Ugale (pratimugale) Kumar Abhishek, Patryk Mężydło, ZeekHuge intro final weekly code proposal blog more
Xen on BeagleBoard-X15 Denis Obrezkov (embden) Julien Grall, Iain Hunter, Hunyue Yau, Stefano Stabellini intro final weekly GitHub repo proposal more
Reference Design For A GPIO-based Parallel Bi-Directional Bus Pranav Kumar (pranav_kumar) Andrew Henderson, Hunyue Yau, Kumar Abhishek intro weekly code proposal more

Greybus

Click boards are a flagship hardware product line of MikroElektronika with over 600 add-on boards ranging from wireless connectivity clicks to Human Machine Interface clicks for interfacing with peripheral sensors or transceivers. Most of the Click boards use the common protocols like SPI,I2C or UART to communicate with the Beaglebone and thus the support for them now is accomplished via device tree overlays via the bb.org-overlays repository. This requires /boot/uEnv.txt to be modified to load the drivers at boot, requiring at least one reboot to enable the support in a potentially error-prone way.

The Greybus Simulator is a tool which simulates an AP Bridge, SVC, and an arbitrary set of modules plugged into Greybus. Greybus already provides most of the interfaces used on click boards and utilizes manifest files to enumerate hardware at run-time. This project aims to enable Click Board Support via Greybus Simulator by writing suitable Manifests according to the Click board Specifications and by simply copying the manifest to a hotplug-directory a click board can be loaded, which would make the interfacing a lot easier.

Milestones

  1. Working gbsim and OLEDC Click
  2. Working 9DOF Click, documentation for I2C manifests
  3. Working Weather Click, video demonstration of all functionality
  4. Documentation for SPI manifests, working OLEDB and microSD Clicks
  5. Update milestones based on community feedback, working ETH and ETH Wiz Clicks
  6. Working RTC6 Click
  7. Working Temp/Humidity (not tested on Hardware) and Waveform Generator Clicks
  8. Makecode Integration
  9. New video demonstration of all functionality, update milestones based on community feedback
  10. Working GNSS4, GNSS5 and Ultrasonic2 Clicks
  11. Working insclick/rmclick utilities, on-line documentation for supported Clicks, video demonstration of utilities, OS image integration
  12. Examples to get started with supported clicks
  13. Documentation and final video demonstration

PRU API

This project aims to provide an API for different programming languages to load firmware, start/stop and communicate with the BeagleBone PRUs (Programmable Realtime Units) from user space using the RemoteProc, RPMsg drivers. Example firmware and user space software are provided to demonstrate the use of the project.
Project Homepage: https://github.com/pratimugale/PRUSS-Bindings/wiki

Milestones

  • Provided mem_read(), mem_write() functions that perform read/write 1-byte integer values to the PRU SRAM/DRAM0/DRAM1 using /dev/mem. These are helpful for debugging purposes as demonstrated in example6.
  • Provided sendMsg_raw() and sendMsg_string() functions to send data to the PRU through RPMsg device file in raw form as well as string format. Sending data in raw form makes it easier for the data to be reconstructed on the PRU side.
  • Created various firmware examples to demonstrate the use of the API:
    • example1: A simple GPIO toggling/blinky example.
    • example2: RPMsg Communication - Demonstrate writing of RPMsg firmware by sending messages back and forth.
    • example3: A PWM generator maximum frequency of upto 1MHz.
    • example4: Generating a single channel analog waveform on P9_31 GPIO using PWM at its root.
    • example5: 4-channel PWM written in assembly based on the example given in PRU Cookbook.
    • example6: A debugging program to read/write to PRU SRAM/DRAM using /dev/mem; and to demonstrate the showRegs() function which displays all the current values of the PRU Control Registers and PRU General Purpose Registers(only if the PRU is not running).
    • example7: A library to accurately control stepper motors which are driven by the PRU using PRU0 to PRU1 interrupts and RPMsg.
    • example8: To demonstrate how to link together multiple .asm files and call them from the C-program. Control is passed back to the C-program by using R3.w2
    • example9: Expanding Waveform Generation to 2, 4, and 8-channels. As the number of channels increase, the maximum frequency of the waveform is decreased.
  • Documented the process of using RPMsg according to the latest kernel, using SWIG for generating language bindings for pruss.cpp, and about using the PRU memory.
  • Implemented a pruss_api loadable kernel module that creates character device files of the form pruss_api_pruN specific for using with this project (derived from rpmsg_pru): https://github.com/pratimugale/PRUSS-Bindings/blob/master/drivers/pruss_api.c
  • Created a Debian package for easy installation of the software using dpkg. The download link is in the releases page.
  • Resolved and removed small bugs previously present in the project. For example:
    • pruss.cpp had buffer length of 1kB when the function showRegs() required more data to be transferred through /tmp/prussd.sock
    • load_firmware() function that loads firmware into the PRUs went inside an unwanted 'if' block if firmware path didn't begin with /lib/firmware.
  • Made a solution in user-space for a kernel oops issue mentioned in the mailing list: https://groups.google.com/d/msg/beagleboard-gsoc/711XmP7jFMc/sE0PvoScAwAJ

Xen

The idea behind the project is to make Xen hypervisor available and easy to use on beagleboard-x15. This implementation will allow users to experiment on embedded virtualization and in related fields like automotive, critical systems prototyping and processor's resources sharing. It might also provide very interesting possibilities for heterogeneous resources' utilization. The most interesting outcome is the availability of open-source virtualization on top of the open-source hardware.


PRU Bus

The idea behind this project is to create a hardware/software design incorporated with shift registers to allow BB.org hardware to communicate with hardware via a parallel, bidirectional bus.To create a software design that incorporates both a kernel driver to communicate with the parallel bus and a user space application/library using ioctl() calls to communicate with this kernel driver.

It will benefits to those people who want multiple inputs or output capability in their projects or those who want to interface different memory device with the beaglebone.org hardware. it also opens new capability by open an entire world of a new project that can get incorporated with the help of pocket beagle for ex. making a scientific calculator with the help of it, etc.