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

From eLinux.org
< BeagleBoard‎ | GSoC
Revision as of 19:44, 3 April 2022 by Jiande (talk | contribs)
Jump to: navigation, search


Proposal Template

About Student: Seak Jian De
Mentors: Jason Kridner
Code:
Wiki:
GSoC:

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

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

Mar 29 Applications open, Students register with GSoC, work on proposal with mentors
Apr 13 Proposal complete, Submitted to https://summerofcode.withgoogle.com
May 17 Proposal accepted or rejected
Jun 07 Pre-work complete, Coding officially begins!
Jun 17 Milestone #1, Introductory YouTube video
June 24 Milestone #2
June 30 Milestone #3
July 12 18:00 UTC Milestone #4, Mentors and students can begin submitting Phase 1 evaluations
July 16 18:00 UTC Phase 1 Evaluation deadline
July 23 Milestone #5
July 30 Milestone #6
Aug 06 Milestone #7
August 10 Milestone #8, Completion YouTube video
August 16 - 26 18:00 UTC Final week: Students submit their final work product and their final mentor evaluation
August 23 - 30 18:00 UTC Mentors submit final student evaluations

Experience and approach

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

Contingency

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

Benefit

If successfully completed, what will its impact be on the BeagleBoard.org community? Include quotes from BeagleBoard.org community members who can be found on http://beagleboard.org/discuss and http://bbb.io/gsocchat.

Misc

Please complete the requirements listed on the ideas page. Provide link to pull request.

Suggestions

Is there anything else we should have asked you?

Retrieved from "https://elinux.org/index.php?title=BeagleBoard/GSoC/2022_Proposal/bb-config_improvements_%26_GPIO_Benchmarking&oldid=563666"