Diary of Portable WIFI Frustration (1)---Neon Light

introduction

By flashing the Debain system on the Qualcomm 410 chip's portable WIFI, we already have a mini ARM64 single-board computer with 4G function. Now we can carry out secondary development based on this platform.

The advantage of portable WIFI is its low price and similar performance to Raspberry Pi zero2 and Raspberry Pi 3b.

The hardware configuration is as follows:

msm8916 master Cortex-A53 * 4 on 0.9GHZ
512MB memory + 4GB storage emcp
WCN3620 & WCN3680b
pm8916 PMIC
USB interface

The io definition of the peripheral is as follows:

model	red led	green led	blue led	button
ufi001b/c	gpio22	gpio21	gpio20	gpio37

1. Neon lights

I mainly want to learn how Linux controls underlying hardware devices by lighting up LED lights.

1.1 Lighting

There are three LED lights on the portable WIFI. The author of Openstick sets the default blue to indicate the wifi connection status, and red to indicate whether the system is still running normally.

You can modify the led throughecho <behavior> > /sys/class/led/<name>/trigger Behavior.
The available behaviors are:

root@openstick:/sys/class/leds/green:internet# cat trigger 
[none] usb-gadget usb-host rfkill-any rfkill-none kbd-scrolllock kbd-numlock kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock timer heartbeat cpu cpu0 cpu1 cpu2 cpu3 default-on panic mmc0 bluetooth-power hci0-power rfkill0 phy0rx phy0tx phy0assoc phy0radio rfkill1

You can see that the trigger attribute of the green:internet device is [none], and the trigger event is none, which means turning off the light.

Set green led to constant state

root@openstick:/sys/class/leds/green:internet# echo default-on > trigger

The behavior of green led is defined as the active state of USB device mode
```
root@openstick:/sys/class/leds/green:internet# echo usb-gadget > trigger
```

After writing this string, the LED behavior takes effect immediately and will fail after restarting. After the configuration is completed, the green LED will flash every time there is data transmission on the USB interface.

1.2 Command analysis

 root@openstick:/sys/class/leds/green:internet# echo usb-gadget > trigger

/sys: sysfs is a virtual file system that can view and control device drivers and hardware information in Linux systems. Through sysfs, you can obtain information about drivers loaded in the system, including file systems, input devices, serial ports, Ethernet, etc. We can control the underlying hardware by reading and writing virtual device files in the /sys directory.
class- A section in the sysfs directory that contains all the classes used to implement the device model in the driver.
leds- The name of the device class used to control and access the system's LED groups.
green:internet- The name of the device indicating the specific LED you want to use.
trigger - Device property, representing LED trigger. Allows you to change the LED working mode (such as constant light, flashing, etc.). Some common trigger values include none (steady on), timer (flashing), heartbeat (heartbeat and other rhythms), different LED devices support different triggers. You can use the cat command to read this file to see which triggers the LED device supports. LEDs have many other commonly used properties, such as
- brightness- LED brightness, value is an integer between 0-255.
- max_brightness - Maximum brightness value of the LED. You can use the cat command to read this file to obtain the maximum brightness value of the LED.
- delay_on and delay_off - LED-specific properties used to set the blinking effect. delay_on represents the length of time the LED is on, delay_off represents the length of time the LED is off.
>-Redirection symbol, which writes the output of the previous command (standard output stream stdout) to the file specified after it. That is, write usb-gadget characters to the trigger device file.

In summary, the method of controlling underlying devices through the sysfs virtual file system is as follows:

#  写数据到设备
$/sys/class/设备组/设备名称# echo 属性值 > 属性名称
#  从设备读数据
$/sys/class/设备组/设备名称# cat  属性名称

1.3 Hardware control method

In addition tosysfs, we can also control the underlying hardware in the following ways:

Control Registers - Direct access to the registers that control hardware devices through the use of appropriate drivers and a low-level programming language such as C or assembly language. This requires understanding the register address of the hardware device and the specific functions and usage of the register.
I/O Ports - Access and control the I/O ports of hardware devices by using appropriate drivers and a low-level programming language (such as C or assembly language). This requires knowing the address of the I/O port of the hardware device and the specific input and output methods.
Device files - Some devices can be treated as files and provide an interface similar to file operations for control. For example, access the serial device through the/dev/ttyS0 device file. This requires understanding how to access device files and how to use the device specifically.

These methods all requireknowledge of the specific implementation details of the hardware device and therefore require a high level of skill to control the hardware. If you want to control hardware more simply, consider using a general-purpose high-level hardware control framework or library. These frameworks and libraries generally hide the implementation details of underlying hardware control and provide easy-to-use and cross-platform high-level interfaces so that you can use simpler way to control the hardware.

Some popular high-level hardware control frameworks or libraries include:

WiringPi (for Raspberry Pi)
RPi.GPIO (Raspberry Pi Python library)
Adafruit-GPIO (generic Python GPIO library)
libusb (general USB device control library)
PyUSB (generic Python USB library)

Using these frameworks or libraries, you can control the hardware with higher-level code (usually Python or other easy-to-use scripting languages) and do not need to go into the implementation details of hardware control because these libraries already Hide them in the background. It should be noted that the advantage of using these libraries is simplicity and ease of use, but they may bring someperformance and customizability limitations. If you are an expert in advanced hardware control or require specific functionality, you may need to gain a deeper understanding of the underlying hardware controls and then implement the control logic yourself.

1.4 Low-level implementation: device tree and driver

In order to understand how the operating system controls the LED from the bottom level, we first need to understand the driver and device tree (Device Tree) 2 concepts:

Driver: It is actually a module of the kernel used to control and manage hardware devices. When a hardware device is plugged into the computer, the kernel loads the corresponding driver based on its hardware information. The driver can access the registers of the hardware device to control the operation of the device, such as reading and writing device status, sending and receiving data, controlling the power of the device, etc. Others also establish a bridge between the operating system and the hardware so that applications can interact with hardware devices. Drivers allow applications to access hardware devices. The driver establishes a hardware abstraction layer that provides some unified user interface or API to the application. , allows users to access the features or operations of certain hardware devices.
Device tree: In kernel 3.0 and later versions, the device tree method is used to implement the deviceDriverConnection withdevices. When the kernel starts, it will search the device tree file for nodes that match the hardware devices in the current system, and then the kernel will load the corresponding driver to control the device. This process can be achieved through Device Tree Binding. The driver needs to know the detailed information of the hardware device it controls, including the device's registers, interrupt routing, timing and other information. This information can be defined in the device tree file. Therefore, when writing a driver, you need to write the corresponding device tree binding, and write the corresponding driver according to the binding specifications.

Device tree files are usually binary files or source code files provided by the system vendor, and during development, they are also written or modified according to specific needs. Through the device tree file, the kernel can identify the hardware and load the corresponding device driver.

Simply put, the device tree file describes the hardware devices and their attributes in a system, and the driver implements these Control and operation of hardware devices. Their role is summarized below.

Driver: Provides a series of operating system calls and interfaces so thatapplications can interact with hardware devices to facilitate applications development.
Device tree: The device tree expresses the hardware structure in the form of text description, has nothing to do with the platform, and facilitates hardware transplantation and maintenance. It can provide a consistent interface for different hardware platforms and simplify the development of drivers.

Because there is no Linux source code in the root file system of the portable WIFI, if you want to see the source code of the device tree and driver, you probably need to unpack the boot.img image. It was too complicated and I didn’t delve into it any further.

1.5 Neon lights

Do something interesting. The portable WIFI has three LED lights, red, green and blue. Although the brightness of the lights cannot be controlled, you should still be able to combine yellow (red + green), magenta (red + blue), cyan (green + blue). ), mix (green + blue + red) 4 colors. Let's write a shell script to make the LED alternate between these colors.

for i in $(seq 1 20)
do
  echo none > /sys/class/leds/green:internet/trigger
  echo none > /sys/class/leds/blue:wifi/trigger
  echo none > /sys/class/leds/red:os/trigger

  echo 1 > /sys/class/leds/green:internet/brightness
  sleep 0.25
  echo 0 > /sys/class/leds/green:internet/brightness

  echo 1 > /sys/class/leds/blue:wifi/brightness
  sleep 0.25
  echo 0 > /sys/class/leds/blue:wifi/brightness

  echo 1 > /sys/class/leds/red:os/brightness
  sleep 0.25
  
  echo 1 > /sys/class/leds/green:internet/brightness
  sleep 0.25
  echo 0 > /sys/class/leds/red:os/brightness
  

  echo 1 > /sys/class/leds/blue:wifi/brightness
  sleep 0.25
  echo 0 > /sys/class/leds/green:internet/brightness

  echo 1 > /sys/class/leds/red:os/brightness
  sleep 0.25
  
  echo 1 > /sys/class/leds/green:internet/brightness
  sleep 0.25
  echo 0 > /sys/class/leds/green:internet/brightness
  echo 0 > /sys/class/leds/red:os/brightness
  echo 0 > /sys/class/leds/blue:wifi/brightness  
done

echo none > /sys/class/leds/green:internet/trigger
echo none > /sys/class/leds/blue:wifi/trigger
echo none > /sys/class/leds/red:os/trigger

echo 0 > /sys/class/leds/green:internet/brightness
echo 0 > /sys/class/leds/blue:wifi/brightness
echo 0 > /sys/class/leds/red:os/brightness

In this shell script, we use for to run 20 times in a loop, with an interval of 0.25 seconds each time. The final script will run for 35 seconds. Finally, we turn off the blinking mode of all lights again and use echo 0 to control all lights to go off. This ensures that no lights will flash in the final state of the script. The sequence of light flashing is: Green – Blue – Red – Yellow – Cyan – Magenta – Mixed .