The Raspberry Pi 4 was once sold at sky-high prices, becoming a financial product, while domestic “similar products” have sprung up like mushrooms after rain, with many domestic Pi alternatives emerging.

It can be said that these domestic Pis currently have obvious gaps compared to the Raspberry Pi in terms of hardware design, resource richness, community support, and stability, although the gap is gradually narrowing.

So, is the gap between domestic Pis and Raspberry Pis large? Today, we will buy three domestic Pis—ART-Pi, Bear Pi, and BIGTREETECH Pi—to evaluate the actual performance of domestic Pis.

Image Source丨ProjectZarya

Raspberry Pi 3B Alternative BIGTREETECH PI Development Board

Unboxing Review

Original Post Address:http://www.eeworld.com.cn/aSybHiD

In the past two years, the price of Raspberry Pi has been difficult to describe. I have a 3B+ used in a smart home control system, but I love to tinker with new things… and there are no new projects for reimbursement… so I have been looking for domestic boards to replace it.

First, let’s briefly compare the parameters of BIGTREETECH PI and Raspberry Pi 3B. The chip is the familiar Allwinner H616, 64-bit 4 cores and A53, with a frequency slightly higher than that of Raspberry Pi’s BCM2837. The H616 chip has been widely used in various fields, from TV boxes and game consoles to development boards, and the development resources are already very comprehensive.

40 GPIOs, Bluetooth, wireless, 4 USB 2.0 ports, 100M Ethernet, microHDMI, and a 3.5mm headphone jack are basically the same as Raspberry Pi. The BIGTREETECH adds CAN, infrared receiving functions, and supports 4K 60Hz output. Overall, the performance has surpassed my Raspberry Pi 3B+.

After unboxing, the following items are included: a cute little duck, a thank-you card, the main board, signal cables, flat cables, and a heatsink.

Testing the Performance of Domestic Raspberry Pi Alternatives

The main board looks really good, with a black body and classic red and white color scheme, and green accents on the GPIO. Personally, I prefer this style.

The front features the H616 chip, with two Kingston 4Gb RAMs, and the infrared interface is located on the left side of the GPIO. The back has a memory card slot and a wireless module, and the included antenna is plugged in here; if you use a network cable or are close to the router, you can omit it.

The documentation provided is comprehensive, even including models for the case that can be printed directly on a 3D printer.

Briefly discussing the software aspect,https://github.com/bigtreetech/CB1/releases Download the dedicated image file from here, burn it to the memory card, then open the boot partition’s system.cfg file with a card reader and enter the WiFi and password. After powering on, you can find the device starting with BTT in the router. Record the device’s IP address, and you can connect remotely using SSH tools.

Note that there is a red jumper cap next to the board type; if you are powering with 12V, you need to remove it; if using type power, you do not need to touch it.

I am using Moba, which is a replacement for Xshell. It is compact and fast, with all the necessary functions, the only downside being that it does not support Chinese.

Graphics Card Performance Test

Original Post Address:http://www.eeworld.com.cn/aWL8iXT

This article uses a classic testing program for graphics card testing.

Glxgears

Running at over 90 frames is not a problem.

GL Mark 2

Board Audio Device Output Test

Original Post Address:http://www.eeworld.com.cn/ayf9SiP

Check Audio Devices

Execute command: biqu@BTT-CB1:~$ aplay -l

Detected the audio device of the H616 board

Play Music

Play the audio file in the board’s system

Execute command:biqu@BTT-CB1:/usr/share/sounds/alsa$ aplay -D hw:2,0 audio.wav

Control Audio Volume

Use alsamixer tool to control the audio device

Using command:biqu@BTT-CB1:/usr/share/sounds/alsa$ alsamixer

Select H616 Audio Device

H616 Audio Device Control Interface

Use left and right keys to select audio parameter options, up and down keys to adjust parameter size.

USB Camera Test

Original Post Address:http://www.eeworld.com.cn/au10S40

After connecting the USB camera to the development board, execute the command: lsmod to check the kernel-loaded USB camera hardware device, install fswebcam, execute photo capture, and generate the image:

Copy to the computer and open the image:

Install motion software, modify etc/default/motion configuration, execute startup command, and enter the development board’s IP:8081 in the browser address bar to view the camera data in real-time. This software has some delay and is often laggy.

CAN Transceiver Test

Original Post Address:http://www.eeworld.com.cn/aejrnzT

The communication results between the development board and the CAN card debugging assistant:

SPI Transceiver Test

Original Post Address:http://www.eeworld.com.cn/aaTmLCS

Execute command: $ sudo ./spidev_test -v -D /dev/spidev1.1

Do not short the PH7 and PH8 on the board, as it will not receive self-transmitted data. After shorting, the self-transmitted and received data are consistent, indicating SPI communication is normal.

Testing Game Play

Original Post Address:http://www.eeworld.com.cn/a0irrfT

Original Post Address:http://www.eeworld.com.cn/a48Oav1

Although this development board is specifically designed for 3D printing, due to its complete Debian operating system, it has strong performance, allowing for many fun activities. While waiting for printing, playing games is also a good option. Installing an NES emulator allows you to play various NES games like Tank Battle, Contra, and Adventure Island, which were popular games in childhood. Playing such small games on a development board is very useful for leisure. Later, we will try some 3D games to showcase the board’s performance.

Tank Battle

Adventure Island

Previously, we played NES games, which felt a bit unsatisfactory. The development board’s performance is indeed overkill for NES, so this time we will try playing TORCS—an autonomous driving training game—to highlight the board’s performance.

Only two frames are displayed, which seems to consume significant performance. It’s unclear if this is due to not utilizing the GPU.

Connecting to Smart Hub via MQTT

Original Post Address:http://www.eeworld.com.cn/aO4mLmH

Sensors act as the eyes of smart homes, collecting various data from the environment and executing preset automation programs based on the situation. Controllers act as the hands of smart homes, and automation tasks must be implemented through controllers. The original project used temperature, humidity, light, combustible gas, human presence, and facial recognition sensors, as well as actuators like servos and access control.

Each sensor is located in different rooms, so to connect to the hub, wireless methods must be used. Currently, the mainstream options are Bluetooth, WiFi, and ZigBee. Bluetooth has a short transmission distance and requires a microcontroller to control the Bluetooth module, while ZigBee is relatively expensive… equipping each sensor with a ZigBee module results in a staggering cost for a whole house with around 20-30 sensors. WiFi is more friendly, with abundant resources, many models, long transmission distance, and no need for an additional gateway, and most importantly, it is cost-effective! The esp01s module: 8mb flash, 2 GPIO, powered by 3V at 71mA. It can be said to be a microcontroller with WiFi functionality, and the personal small batch procurement unit price is only about 5 RMB!

Direct connection is not possible; it must go through the MQTT server we previously set up. You can understand it this way: the MQTT server is the data center for transmission, and all sensors, the subsequent controllers, and the Hass smart hub must connect to it.

During the transmission process, the data is not encrypted and is sent in broadcast form within the local area network. Each data packet has a topic, and all devices in the network will receive this data packet. However, if the topic does not match the subscribed topic, the device will discard it directly; only when it matches will it read the data further.

Therefore, we need to assign a unique topic to each sensor (each one, not each type) for publishing, and Hass needs to subscribe to all sensor topics; each actuator must subscribe to a unique topic to receive instructions from Hass.

Although each sensor is different, the general idea is the same. For sensors: configure esp-01s with WiFi, MQTT address, publish topic, read sensor data, and send it periodically. For actuators: configure WiFi, MQTT address, pre-select subscribed topic, construct data packet structure, write unpacking function, and write action function. The esp-01s flash is too small, making OTA difficult, so it is essential to test the program well; otherwise, it will need to be disassembled for reprogramming, which is cumbersome.

One thing to note: GPIO0 cannot be pulled down during normal boot operation; otherwise, it will enter programming mode. Some sensors require two GPIO ports, so care must be taken during connection. If unavoidable, there is another way: power the esp-01s first, then power the sensors after a delay of three seconds to avoid entering programming mode; the specific implementation will not be detailed here.

After programming is completed, power on, and open the web page of the EMQX server to see a new connection appearing. The connected sensors can be seen here, and names must be defined for easy management.

Next, display the sensor information on the Hass panel. Add various sensors to the dashboard.

Edge Detection and Video Streaming (zmj)

Original Post Address:http://www.eeworld.com.cn/a1OCWPC

**The BIGTREETECH PI development board’s USB camera (UVC) can easily achieve edge detection functionality based on OpenCV.

UVC, in simple terms, refers to USB cameras, officially known as USB Video Class, is a protocol standard defined for USB video capture devices.

The video stream from the USB camera is mainly completed by calling the OpenCV library in Python for edge detection on each frame of the image, with parameter adjustments made through sliders in real-time to achieve better results. Pressing the ESC key exits the test program (it must be said that Python is indeed powerful).

Code Function Description:

a. Import necessary libraries: cv2, numpy, video, and sys.

b. Create two sliders: cv.namedWindow(‘edge’) to display the edge detection results window, cv.createTrackbar(‘thrs1’, ‘edge’, 2000, 5000, nothing) and cv.createTrackbar(‘thrs2’, ‘edge’, 4000, 5000, nothing) to set edge detection parameters.

c. Create a video capture object: cap = video.create_capture(fn), where fn is the specified video file name.

d. In an infinite loop, read frame data from the video capture object: while True:.

e. Convert the read frame data to grayscale: gray = cv.cvtColor(img, cv.COLOR_BGR2GRAY).

f. Perform edge detection on the grayscale image: edge = cv.Canny(gray, thrs1, thrs2, apertureSize=5).

g. Merge the original image and edge detection results: vis = img.copy(), then set the non-zero pixel parts of the result image to green: vis = np.uint8(vis/2.), and finally display the result image: cv.imshow(‘edge’, vis).

h. Listen for the window’s close event: ch = cv.waitKey(5), and if the ESC key is pressed, exit the loop: if ch == 27:.

i. Finally, print the program’s documentation string: print(__doc__), and close all windows: cv.destroyAllWindows().

Testing effect:

Bear Pi Foldable Development Board BearPi-HM Micro

Unboxing Review

Original Post Address:http://www.eeworld.com.cn/aDanfL8

Original Post Address:http://www.eeworld.com.cn/a44mXP0

I have previously used Bear Pi products and found that both the quality and technical support, as well as the completeness of the documentation, are very rich. The BearPi-HM Nano development board I am trying this time is no exception. The most special feature is the folding design that allows the 4.3-inch LED capacitive screen to be installed back-to-back with the main control board, effectively protecting the FPC soft ribbon cable, which is very thoughtful and creative. I recall that I previously broke the FPC line of a liquid crystal screen due to various reasons, and this design is indeed considerate for users.

Looking at the main control board, most of the main components are on the front, as shown in the figure below. The main control chip used is STM32MP157, and it retains the E53 interface, which can connect with boards that comply with the E53 interface specification. Power supply and downloading are completed through the USB TYPE C port at the lower left corner. Overall, the functionality is quite complete.

This board’s second highlight is using the HarmonyOS OpenHarmony, which is an open-source project with basic operating system capabilities, equivalent to Android’s AOSP.

The type-c interface is highly praised not only because it uses a type-c port but also because it supports cables with type-c on both ends. I have used several development boards with type-c interfaces, and some of them only have the interface but are not perfect in supporting type-c.

After powering the board with a type-c cable, the screen lights up. The 4.3-inch screen has a resolution of 800X480, which is already quite high. It comes with several applications, including weather, alarm clock, calculator, and the once-popular 2048.

The weather defaults to Hangzhou, but since it is not connected to the internet, the data has no practical significance, and the time cannot be set. There is also a built-in lock screen feature with several seasonal landscape wallpapers, which looks pleasant.

In the settings, you can find specific information, such as system version OpenHarmony 3.0, hardware version, software version, device serial number, etc.

In addition, the official accompanying introductory video tutorial and document tutorial are very detailed. The main references for getting started are the BearPi-HM Micro ten-minute tutorial and Bilibili video, which are written in great detail.

To work well with this development board, you need to set up the development environment according to the tutorial, which requires multiple tools, including:

1. VMWare and Ubuntu operating system; OpenHarmony uses a Linux kernel, and it is recommended to use a virtual machine with Ubuntu 18.04.

2. STM32CubeProgrammer (version 2.4.0 and above); since the main control is from the STM32MP1 series chip, it is natural to recommend the manufacturer’s software for downloading programs.

3. SSH connection tools, serial connection tools; development can be done through SSH connection to the Ubuntu environment, and serial printing can be used for running logs. It is recommended to use MobaXterm or XShell tools.

4. RaiDrive tool; a small tool that maps the virtual machine to a Windows drive. Portable version.

5. JRE, CH340 drivers, etc.

Serial Interaction Output

Original Post Address:http://www.eeworld.com.cn/aiHGSKG

After a few days of practice, I have gained more understanding of OpenHarmony, such as how to compile a simple program into the system.

First, a source program that implements functionality is needed, such as helloworld.c. A BUILD.gn file is also required. .gn files are a type of compilation build file, similar to CMake. Compared to CMake, when the project size becomes unimaginably large, the compilation speed and the division of project modules become crucial, and gn effectively addresses these two issues. The OpenHarmony documentation introduces the relevant .gn coding specifications.

The basic structure of BUILD.gn is as follows:

import("//build/lite/config/component/lite_component.gni")

executable("generated_library_name") {    output_name = "executable_file_name"    sources = [ "source_file" ]    include_dirs = []    defines = []    cflags_c = []    ldflags = []}

lite_component("lite_component_name") {    features = [        ":library_file",    ]}

Import the gni component, compile the source code into a library file, and then package the library file into a lite component, while defining the output executable file name.

Burn the compiled file into BearPi-HM Micro, and after burning is complete, open the serial assistant. Through the serial assistant, most Linux operating commands can be used.

Run the compiled program and check the serial output, successfully printing the content of the source file.

The entire process reveals that interactions with components are relatively frequent. OpenHarmony follows a layered design, with layers from bottom to top being: kernel layer, system service layer, framework layer, and application layer. System functionality unfolds step by step from “system > subsystem > component.” In multi-device deployment scenarios, it supports trimming unnecessary components based on actual needs. A subsystem is a logical concept composed of corresponding components.

Components are further subdivisions of subsystems, reusable software units that include source code, configuration files, resource files, and compilation scripts; capable of independent construction and integration in binary form, with independent verification capabilities.

Using HDF Driver Framework to Implement LED Blinking

Original Post Address:http://www.eeworld.com.cn/abLibDG

The HDF (Hardware Driver Foundation) driver framework provides driver developers with capabilities for driver loading, driver service management, and driver messaging mechanisms. It aims to build a unified driver architecture platform, providing driver developers with a more precise and efficient development environment, striving for once development and multi-system deployment.

Driver development based on the HDF framework mainly consists of two parts: driver implementation and driver configuration. Driver implementation includes driver business code and driver entry registration, both of which are provided with templates in the development documentation, such as driver business code.

During actual programming, you can directly extend on this template, such as the demo provided by BearPi-HM Micro.

Driver registration involves instantiating the driver entry, which must be a global variable of type HdfDriverEntry (defined in hdf_device_desc.h), and the moduleName must match the device_info.hcs. The HDF framework collects the starting addresses of all loaded drivers’ HdfDriverEntry objects, forming an address space similar to an array, facilitating upper-level calls.

As for driver configuration, the HDF framework uses .HCS files, which stands for HDF Configuration Source. It is the configuration description source for the HDF driver framework, primarily in Key-Value format. It achieves the decoupling of configuration code and driver code, making it easier for developers to manage configurations. HC-GEN (HDF Configuration Generator) is a tool for converting HCS configuration files into a format readable by software: in low-performance environments, it converts to configuration tree source code or configuration tree macro definitions, allowing drivers to directly call C code or macro APIs to obtain configurations. In high-performance environments, it converts to HCB (HDF Configuration Binary) files, allowing drivers to use the configuration parsing interfaces provided by the HDF framework to obtain configurations. HCS files compiled by HC-GEN generate HCB files, and the HCS Parser module in the HDF driver framework reconstructs the configuration tree from the HCB file, allowing the HDF driver module to obtain configuration content through the configuration reading interfaces provided by the HCS Parser.

Like driver implementation, driver configuration also consists of two parts: the driver device description defined by the HDF framework and the driver’s private configuration information. The driver device description defined by the HDF framework is located at:~\bearpi\project\bearpi-hm_micro_small\device\st\bearpi_hm_micro\liteos_a\hdf_config\device_info\device_info.hcs.The driver’s private configuration information is the configuration information added by the user, such as here:~\bearpi\project\bearpi-hm_micro_small\device\st\bearpi_hm_micro\liteos_a\hdf_config\led\led_config.hcs

Finally, this configuration file needs to be added to the board-level configuration entry filehdf.hcs

device\st\bearpi_hm_micro\liteos_a\hdf_config\hdf.hcs

Regarding GPIO operations, the GPIO driver has already provided relevant interfaces.

Then comes the business code for LED blinking, which is the code that receives driver program instructions, sending instructions from user space to kernel space.

int32_t LedDriverDispatch(struct HdfDeviceIoClient *client, int cmdCode, struct HdfSBuf *data, struct HdfSBuf *reply){    uint8_t contrl;    HDF_LOGE("Led driver dispatch");    if (client == NULL || client->device == NULL)    {        HDF_LOGE("Led driver device is NULL");        return HDF_ERR_INVALID_OBJECT;    }

    switch (cmdCode)    {    /* Receive LED_WRITE_READ command sent from user space */    case LED_WRITE_READ:        /* Read data from data and assign to contrl */        HdfSbufReadUint8(data,&contrl);                          switch (contrl)        {        /* Turn on light */        case LED_ON:                                                        GpioWrite(g_Stm32Mp1ILed.gpioNum, GPIO_VAL_LOW);            status = 1;            break;        /* Turn off light */        case LED_OFF:                                                       GpioWrite(g_Stm32Mp1ILed.gpioNum, GPIO_VAL_HIGH);            status = 0;            break;        /* Toggle status */        case LED_TOGGLE:            if(status == 0)            {                GpioWrite(g_Stm32Mp1ILed.gpioNum, GPIO_VAL_LOW);                status = 1;            }            else            {                GpioWrite(g_Stm32Mp1ILed.gpioNum, GPIO_VAL_HIGH);                status = 0;            }                                                    break;        default:            break;        }        /* Write the LED status value to reply, which can be brought to the user program */        if (!HdfSbufWriteInt32(reply, status))                        {            HDF_LOGE("replay is fail");            return HDF_FAILURE;        }        break;    default:        break;    }    return HDF_SUCCESS;}

Through the code, it can be felt that the driver invocation in OpenHarmony’s device development is different from that of microcontrollers. The driver invocation in microcontrollers often uses function calls, but OpenHarmony does not have such operations. Instead, the driver invocation uses the driver program to expose the server to the user space, allowing the program to send instructions to the driver program through Dispatch, carrying user space data to the driver program and reading data from the driver program. The above code sends instructions to the driver program through Dispatch to achieve the on/off of the LED light. Of course, the kernel space can also send data to user space.

As with the previous hello world, compilation files are also needed. For business code, the operations are the same as before: configure BUILD.gn, applications.json, config.json. For driver files, not only do you need your own BUILD.gn, but you also need to modify~\bearpi\project\bearpi-hm_micro_small\device\st\drivers\BUILD.gn

Finally, compile and burn it onto the board. As before, open the serial assistant, and use commands to operate the LED’s on/off status changes.

Trial Summary

Original Post Address:http://www.eeworld.com.cn/a0WXX1G

After two months of testing, it can be said that the BearPi-HM Micro is indeed a development board suitable for getting started with OpenHarmony. Before this, I had no exposure to OpenHarmony’s code, but through step-by-step practice, I have gained a lot of understanding and knowledge about OpenHarmony, which I previously thought was quite mysterious.

From setting up the environment to the first successful compilation of source code, it has been a fulfilling experience. Although I encountered various problems, it was through solving these problems that I got to know and understand various aspects of OpenHarmony. For learning OpenHarmony, the materials provided by BearPi can help you get started, but if you want to know more, such as why to do this and the principles behind it, the materials provided by BearPi are somewhat insufficient, and I would recommend referring to the official documentation.

The official documentation is very detailed, including introductions to some terms, and it can be said that the materials from BearPi tell you how to operate, while the official documentation explains why to do so. Combining the two provides a comprehensive understanding.

The advantages of BearPi-HM Micro are obvious, but there are also drawbacks, such as the openness of the documentation, especially for the underlying bootloader part. This part is quite important for those who want to understand and learn about the boot process of OpenHarmony on STM32. Although it is said to be open-source, it has been delayed. On the other hand, the completeness of the board’s hardware driver is also not comprehensive. As a direction for driver development (BearPi has southbound drivers and northbound applications), the onboard aspect should be the main starting point. Perhaps this is due to some functions still being perfected, and it seems that this part may be supplemented later; otherwise, lacking this part would make development incomplete.

Testing the Performance of Domestic Raspberry Pi Alternatives

Raspberry Pi 3B Alternative BIGTREETECH PI Development Board

Edge Detection and Video Streaming (zmj)

Bear Pi Foldable Development Board BearPi-HM Micro

Unboxing Review

How Early MCU Chips Were Encrypted?

Advancements in Embedded Vision Technology Driven by Image Sensors

How Image Sensors Drive the Development of Embedded Vision Technology

Advancements in Embedded Vision Technology Driven by Image Sensors

Understanding the Application of Ground Loop Detectors in Parking Systems

Leave a Comment Cancel reply

Menu