BeagleBoard/GSoC/2022 Proposal/bb-config improvements & GPIO Benchmarking

From eLinux.org
< BeagleBoard‎ | GSoC
Revision as of 18:35, 6 April 2022 by Jiande (talk | contribs) (Proposal Template)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


Proposal Template

About Student: Seak Jian De
Mentors: Jason Kridner, Shreyas Atre
Code: NatworkManger DBus
Wiki: https://elinux.org/BeagleBoard/GSoC/2022_Proposal/bb-config_improvements_%26_GPIO_Benchmarking
GSoC: bb-config improvements GPIO Benchmarking

Status

This project is currently just a proposal.

Proposal

Completed all the requirements listed on the ideas page. the code for the cross-compilation task can be found here submitted through the pull request #158.

About you

IRC: Jian De
Github: https://github.com/Fred-JD
School: Universiti Teknologi Malaysia
Country: Malaysia
Primary language: English, Mandarin, Malay
Typical work hours: 4PM - 11PM UTC +8
Previous GSoC participation: First year apply gsoc.

About your project

Project name: bb-config improvements & GPIO Benchmarking

Description

Bb-Config Improvement
Beagle-config is a terminal UI to make the configuration of beaglebone devices easier and more visually.

  • Update to the latest FTXUI Version
  • Adding a graph section for ADC/DAC using FTXUI graph
  • NetworkManager
  • Filesystem over NFS(Network File System)
  • Enable/disable "stuff" that takes up the boot up time issue#45
  • Scan Overlays and give a selection box issue#46
  • Add support for setting custom pinmux issue#42

GPIO Benchmarking
Benchmark GPIOs using the below four approaches

  • Memory-mapped
  • sysfs file system access
  • Character device
  • LKM
  • PRUs

Method of Implementation

Bb-Config Improvement

Update to the latest FTXUI Version
Update GIT_TAG in CMakeList.txt

   FetchContent_Declare(ftxui
       GIT_REPOSITORY https://github.com/ArthurSonzogni/FTXUI
       GIT_TAG v3.0.0
   )

Check is there any braking changes

ADC/DAC graph

   #define ADC_PATH "/sys/bus/iio/devices/iio:device0/in_voltage"

constexpr it instead of macro (a minor suggestion although I will be reviewing your code in a pull request)
https://arthursonzogni.github.io/FTXUI/index.html#autotoc_md89

Network Manager
We will implement a NetworkManager using dbus-lib API from gnome.

Implementation:

  • Display Active Network Details
  • Display Saved Network
  • Display Available WiFi AccessPoints
  • Saved a WiFi Network with PSK security
  • Forget Saved Network
  • Enable/Disable WiFi connection
  • Enable/Disable Ethernet connection
  • Config Network detail (Ethernet/WiFi)

Further Enhacement:

  • Enable WiFi hotspot
  • VPN
  • Bluetooth Setting

Here has code for NetworkManager using DBus
https://github.com/Fred-JD/NM-DBUS

Scan Overlays and give a selection box issue#46
dump /boot/dtbs/(uname -r)/*.dtbo
and give a seleciton box:
Virtual

[ ] - HDMI
[ ] - HDMI -audio
[ ] - WIFI

Overlays - generated

[ ] - ADC
[ ] - PRU
[ ] - I2C-bme260
[ ] - etc..

Add support for setting custom pinmux issue#42
Add a handy reference for BBB device which providing interactive pinout diagram.
Provide a list of selection to highlight GPIO, UART, SPI, I2C, PWM, MCASP, MMC, HDMI, ADC, Timer

  • pocketBeagle
  • BeagleBone Black / BeagleBone AI

Enable/disable "stuff" that takes up the boot up time issue#45
provide option for user to change run level program.
Depending on your default init level setting, the system will execute the programs from one of the following directories.

   Run level 0 – /etc/rc.d/rc0.d/ 
   Run level 1 – /etc/rc.d/rc1.d/ 
   Run level 2 – /etc/rc.d/rc2.d/ 
   Run level 3 – /etc/rc.d/rc3.d/ 
   Run level 4 – /etc/rc.d/rc4.d/ 
   Run level 5 – /etc/rc.d/rc5.d/ 
   Run level 6 – /etc/rc.d/rc6.d/ 

ref : https://www.thegeekstuff.com/2011/02/linux-boot-process
we can inspire from sysv-rc-conf UI

NFS(Network File System)
https://elinux.org/Mount_BeagleBoard_Root_Filesystem_over_NFS_via_USB
https://www.ofitselfso.com/Beagle/InstallingNFSOnABeagleboneBlack.php
Provide a user option to set NFS as client or server.

BB as server:
  • Provide a path folder to share by automatic setting up and return an IP address for the user to access in another device. Also will provide detailed guide to access in window/macos/linux
  • Provide easy interface for edit file sharing permission
  • Provide enable/disable for setup NFS on boot
BB as client:
  • Let user input ip address then automatically mount on BB
  • Provide enable/disable mount NFS on boot
Further Enhancement:
  • NFS through usb bridge
  • Cloud server eg. NextCloud

GPIO Benchmarking

We needed data to help ourselves and developers to decide which method accessing GPIOs suit them better. We compare the latency performance of different methods to access GPIOs: - memory-mapping, system call Interface for user space, character device, GPIOs in Linux Kernel (LKM) and PRUs.
We are measuring the timing for performing two tasks. The first task is to toggle a general purpose I/O output at fast as possible. The second task is to read a signal respond from input pin by causing the output pin value to toggle it.

Memory-mapped GPIO
Code in python
https://gist.github.com/wware/8150366
Code in C
https://github.com/chiragnagpal/beaglebone_mmap

sysfs
sysfs is a pseudo file system provided by the Linux kernel that exports information about various kernel subsystems, hardware devices, and associated device drivers from the kernel's device model to user space through virtual files.

chardev
Since Linux version 4.8 the GPIO sysfs interface is deprecated, and now we have a new API based on character devices (chardev)to access GPIO lines from user space.

Every GPIO controller (gpiochip) will have a character device in /dev and we can use file operations (open(), read(), write(), ioctl(), poll(), close()) to manage and interact with GPIO lines.

https://gist.github.com/pdp7/6fbcc75e48e1d765bbcc08d0e84ca084
https://embeddedbits.org/new-linux-kernel-gpio-user-space-interface/

PRUs
The Programmable Real-time Unit and Industrial Communications Subsystem (PRU-ICSS / PRU-ICSSG) is a small processor that is tightly integrated with an IO subsystem, offering low-latency control of IO pins
https://github.com/beagleboard/cloud9-examples/blob/v2020.01/PocketBeagle/pru/ring.pru0.c

LKM
Linux loadable kernel modules (LKMs) allow you to create binary code that can be loaded and unloaded from the kernel at runtime.

After read through the document by Derek Molloy about implementation LKM in GPIOs. I plan to do it in 3 part the 1st part is call linux/gpio with the handler function in LKM. Then the 2nd part improve the 1st part with adding KObject Interface. Then the 3rd part will adding kthread which is real time response in the kernel space.

http://derekmolloy.ie/html/kernel_docs/ExploringBeagleBone_LKMs.pdf

Linux GPIOs can easily access by <linux/gpio.h>

  static inline bool gpio_is_valid(int number)
  static inline int  gpio_request(unsigned gpio, const char *label
  static inline int  gpio_direction_input(unsigned gpio)
  static inline int  gpio_get_value(unsigned gpio)
  static inline int  gpio_direction_output(unsigned gpio, int value)
  static inline int  gpio_set_debounce(unsigned gpio, unsigned debounce)
  static inline int  gpio_sysfs_set_active_low(unsigned gpio, int value)
  static inline void gpio_free(unsigned gpio)
  static inline int  gpio_to_irq(unsigned gpio)


The LKM driver must register a handler function for the interrupt, which defines the actions that the interrupt should perfor. the handler function is called ebb_gpio_irq_handler()

   static irq_handler_t ebb_gpio_irq_handler(unsigned int irq, 
       void *dev_id, struct pt_regs *regs) {
       // the actions that the interrupt should perform
       ... }


   result = request_irq(irqNumber,         // the interrupt number
       (irq_handler_t) ebb_gpio_irq_handler,// pointer to the handler
       IRQF_TRIGGER_RISING,                 // interrupt on rising edge
       "ebb_gpio_handler",                  // used to identify the owner
       NULL);                 // *dev_id for shared interrupt lines, NULL


The ebb_gpio_irq_handler() function performs the majority of the timing. The clock time is stored, and the inter-press time is determined each time that the interrupt is handled.

Kobject Interface
Then next will look into the kobject interface. The infrastructure that enables sysfs to function is heavily based on the kobject interface.

   #define KOBJ_NAME_LEN   20
   struct kobject {
       char               *k_name;    // kobject name pointer (not NULL)
       char               name[KOBJ_NAME_LEN];  // short internal name
       struct kref        kref;       // the reference count
       struct list_head   entry;      // linked list to members of the kset
       struct kobject     *parent;    // the parent kobject
       struct kset        *kset;      // kobject can be a member of a set
       struct kobj_type   *ktype;     // kobj_type describes object type
       struct dentry      *dentry;    // the sysfs directory entry
   };


A single kobject is mapped to /sys/ebb/ on the file system.
There are five attributes associated with the kobject entry (ebb). These are diffTime, isDebounce, lastTime, ledOn, and numberPresses.

Kernel Threads
Introduce the use of kernel threads, kthreads, which can be started in response to an event that occurs in our LKM
kthreads are used to flash the LED at a user-defined interval.

The return of resources to the kthread scheduler is usually performed with a call to schedule()

   #include <linux/kthread.h>
   static struct task_struct *task;         // pointer to the thread task
   
   static int flash(void *arg) {
   while(!kthread_should_stop()){        // kthread_stop() call returns true
       set_current_state(TASK_RUNNING);   // prevent sleeps temporarily
       ...                                // state change instructions (flash)
       set_current_state(TASK_INTERRUPTIBLE);    // sleep but can be awoken
       msleep(...);                                // millisecond sleep 
   }
   }
   
   static int __init ebb_LED_init(void) {
   task = kthread_run(flash, NULL, "LED_flash_thread");   // start kthread
   ...
   }
   
   static void __exit ebb_LED_exit(void) {
   kthread_stop(task);                 // Stop the LED flashing kthread
   ...
   }

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.)

April 4 - 18:00 UTC Applications open, Students register with GSoC, work on proposal with mentors
April 19 - 18:00 UTC Proposal complete, Submitted to https://summerofcode.withgoogle.com
May 20 Proposal accepted or rejected
  • Go through FTUXI Documentation
  • Understand DBus NetworkManager
  • Satrt bb-config UI
  • Prepare code for benchmark
Jun 13 Pre-work complete, Coding officially begins!
Jun 20 Milestone #1, Introductory YouTube video
  • Setup beaglebone board
  • Update bb-congig latest FTUXI version
  • Improve breaking part after update
June 27 Milestone #2
  • Implement ADC/DAC graph
  • Implement Scan Overlays
July 4 Milestone #3
  • NetworkManager
July 11 Final Exam No Code
July 25 Final Exam No Code
July 29 18:00 UTC Phase 1 Evaluation deadline
Aug 01 Milestone #4
  • Custom Pinmux support
Aug 08 Milestone #5
  • Implement Enable/disable "stuff" that takes up the boot up time
Aug 15 Milestone #6
  • Implement NFS
Aug 22 Milestone #7
  • Finalize bb-config
  • Write documentation
Aug 29 Milestone #8

Prepare C code for benchmark

  • mmap
  • sysfs

Run Benchmark test

Sep 05 Milestone #9

Prepare C code for benchmark

  • chardev
  • pru

Run Benchmark test

Sep 12 Milestone #10

Prepare C code for benchmark

  • LKM

Run Benchmark test

Sep 19 Milestone #11
  • Report for GPIOs Benchmark findings
Sep 26 Completion YouTube video
Final week: Students submit their final work product and their final mentor evaluation
Nov 21 - 18:00 UTC Final date for all GSoC contributors to submit their final work product

Experience and approach

In 5-15 sentences, convince us you will be able to successfully complete your project in the timeline you have described.

  • In my first year of University I have passed the 3 month junior training program by ROBOCON UTM which include basic programming, basic electronics and basic Mechanisms.
* I have built a line following robot with dsPIC30f4011 microcontroller. Solder and design my own hardware with the PIC microcontroller. Understand about GPIO, PWM, UART, ADC/DAC. I have experience in C programming and know how circuit connection with breadboard. photo.
* I have build a custom PCB to control robotic pneumatic valve with Altium designer. photo
  • I have build a flutter mobile app which read and display sensor value from Bluetooth module with Maker Uno (similar with Arduino Uno). Then store the value on AWS with MQTT protocol.\
  • I have build Footfall Counter with openCV github
  • In order to successfully to complete the projects, I will start it early which start to work with the technology before official code period so I have extra time for debug and testing.

Contingency

What will you do if you get stuck on your project and your mentor isn’t around?

Benefit

  • Provide bb users more visual interactive way for header pin.
  • Provide easy UI for Enable/Disable "stuff" in boot.
  • Improve network config with DBus API
  • Gather data for developers to understand how fast gpio read and write in user space, kernel space and PRUs

Misc

Completed all the requirements listed on the ideas page. the code for the cross-compilation task can be found here submitted through the pull request #158.

Suggestions

Is there anything else we should have asked you?