背景

• 主控: D1H
• 板卡: 两块哪吒开发板(以下简称为主机, 从机)
• 操作系统: Tina Linux 2.0

问题

验证D1H芯片SPI主从机通信.

硬件接线

	主机SPI	从机SPI
19	SPI1_MOSI	SPI1_MOSI	19
21	SPI1_MISO	SPI1_MISO	21
23	SPI1_SCK	SPI1_SCK	23
24	SPI1_CE	SPI1_CE	24

SPI概述

SPI接口是一种高速的, 全双工, 同步的通信总线.
适配D1H芯片的Tina Linux的BSP-SDK(以下简称SDK)中已包含相关驱动文件: spi-sunxi.c.
它提供的了仅内核态下主从机的简易通信验证实验, 这或许是考虑到SPI通信速率比较高的特性.
验证操作

SPI主机配置

menuconfig

在SDK执行完环境变量加载后, 执行:

/mnt/tina-d1-h$ make kernel_menuconfig

●开启Device Drivers->SPI support
●进入SPI support, 按图示开启:

设备树

修改: ./device/config/chips/d1-h/configs/nezha/board.dts

需要根据手册和原理图确认好针脚功能:

SPI从机配置

menuconfig

(同SPI主机配置一致)

设备树

仅spi_slave_mode设为0, 其余项同SPI主机配置一致. spi_slave_mode = <0>;

SPI主机收发信息

按上述配置, 重新编译SDK, 打包, 烧录, 启动设备会出现:

root@TinaLinux# ls -l /dev/spidev1.0
crw-------    1 root     root      153,   0 Jan  1 08:00 /dev/spidev1.0

然后将可执行的SPI测试程序(./lichee/linux-5.4/tools/spi/spidev_test)挪到设备上(adb push等)并赋予可执行权限:

# 主机以10MHz发送(即MOSI)发送16进制数据: 0x01 0x02 0x03 0x04
./spidev_test -v -D /dev/spidev1.0 -s 10000000 -p "\x01\x02\x03\x04" 
# 主机以10MHz发送(即MOSI)发送ASCII字符串数据: "allwinner"
./spidev_test -v -D /dev/spidev1.0 -s 10000000 -p  "allwinner"
spi mode: 0x0
bits per word: 8
max speed: 10000000 Hz (10000 KHz)
TX | 61 6C 6C 77 69 6E 6E 65 72 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __  |allwinner|

注意SPI是同步通信接口, 所以在发送的同时也会接收同样长度字节的数据.
下文将用到SPI主从通信的一种常见做法: 主机先发指令头, 然后再发指令体以获取从机应答.

SPI从机收发信息

spi-sunxi.c中对SPI从机模(SLAVE_MODE)采取了简单的收发验证处理, 具体是创建一个内核线程执行int sunxi_spi_slave_task(void *data), 该函数又被设备中断所控制(当收到SPI数据时).

• SPI从机接收到数据的主要流程:
  sunxi_spi_slave_task() -> sunxi_spi_slave_handle_head(), 然后:
  若指令头是写操作(0x01), 则执行:sunxi_spi_slave_cpu_rx_config(), 该函数仅是输出写入内容.
  若指令投是读操作(0x03), 则执行:sunxi_spi_slave_cpu_tx_config(), 该函数仅是将收到的指令体的值+0x80, 然后发送(MISO)给主机.

• 对于从机, spi-sunxi.c能验证SPI通信, 但没有可供用户层直接使用的方法.

用户层可验证的SPI从机收发方案

功能设计

从机安排一块32byte的内存缓存空间(简称"缓存空间")供主机通过指令进行读操作和写操作, 且从机能在用户层对该内存空间访问.

主要改动

• spi.c:
  • 增加static struct class_attribute ye_spi_buf_attrs[], 以创建/sys/class/spi_slave目录下的spi_buf文件, 并提供实现了读/写缓存空间的方法.
• spi-sunxi.c:
  • 使用ye_spi_slave_set_txdata()方法替换sunxi_spi_slave_set_txdata(), 以实现读操作.
  • 修改sunxi_spi_slave_cpu_rx_config()方法, 以实现写操作.

改动详情请查看: d1h_spi_driver.diff

使用方法

写操作: 操作:0x01(写) 地址:0x00 0x00 0x00 指令体长度:0x09
./spidev_test -v -D /dev/spidev1.0 -s 10000000 -p "\x01\x00\x00\x00\x09" && \
./spidev_test -v -D /dev/spidev1.0 -s 10000000 -p  "allwinner"

读操作: 操作:0x03(读) 地址:0x00 0x00 0x00 指令体长度:0x09
./spidev_test -v -D /dev/spidev1.0 -s 10000000 -p "\x03\x00\x00\x00\x09" && \
./spidev_test -v -D /dev/spidev1.0 -s 10000000 -p  "\x00\x00\x00\x00\x00\x00\x00\x00\x00"

从机读取缓存空间:
cat /sys/class/spi_slave/spi_buf

从机写入缓存空间:
echo "Hello world" > /sys/class/spi_slave/spi_buf

【XR806官方开发板入门】openHarmony编译与烧录

非常感谢AW陈老板赠与XR806开发板~~~
期望未来线下面基活动不会太晚.

首先画重点:
【严重警告】不要用全志客户服务平台Freertos v1.2版本编出来的固件烧到XR806开源鸿蒙开发板
由于我鸽子特性, 所以前一段时间我卡在了openharmony(简称OH)开发路线上, 所以避开了官方RTOS这坑.

OH开发路线我断断续续地摸索了2天

• 一是文档教程分散且有多个版本(见 参考文献);
• 二是估计OH官方库跟XR806的适配出现了一些分歧, 两者没有合并在一起.

平台

原生Ubuntu 20.04

资源

先建个文件夹, 边下载边往下看

mkdir xradio && cd ~/xradio

gn

需要下载gn-linux-x86-1717.tar.gz工具. 链接忘了
放到

~/gn目录下, 并加入环境变量

工具链

Linux: gcc-arm-none-eabi-10-2020-q4-major

下载解压, 加不加到PATH不要紧. 因为OH依靠ninja工具构建. 只要将工具链路径(gcc-arm-none-eabi-10-2020-q4-major/arm-none-eabi/bin)加入

特定库

devboard_device_allwinner_xr806

git@gitee.com:moldy-potato-chips/devboard_device_allwinner_xr806.git

devboard_vendor_allwinner_xr806

git@gitee.com:moldy-potato-chips/devboard_vendor_allwinner_xr806.git

以上两个库是早期从OH库特定分支fork下来的. 个人认为可能是最新的OH官方库与xr806适配方式存在一些分歧, 所以导致官方教程的里repo sync时无法同步到特定目录(库).

下载完之后xradio目录应该为:

xradio
├── devboard_device_allwinner_xr806
├── devboard_vendor_allwinner_xr806
└── gcc-arm-none-eabi-10-2020-q4-major

OH

先来看看官方教程, 然而并不能正常repo sync(21/03/06之前)

mkdir openharmony
cd openharmony
repo init -u ssh://git@gitee.com/openharmony-sig/manifest.git -b OpenHarmony_1.0.1_release --no-repo-verify -m devboard_xr806.xml
repo sync -c
repo forall -c 'git lfs pull'   #下载部分大容量二进制文件

问题出现在

-m devboard_xr806.xml

所以直接取得OpenHarmony_1.0.1_release分支OH仓即可:

repo init -u https://gitee.com/openharmony/manifest.git -b OpenHarmony_1.0.1_release --no-repo-verify
repo sync -c
repo forall -c 'git lfs pull'

注意xr806仅适配特定分支的OH系统.

整合目录★★★

以下操作是为了弥补该分支OH仓的一些差异.
估计是OH官方仓作了一些修改没法向前兼容XR806的适配.

# 若~/openharmony/device/xradio目录已存在, 则可备份一下.
# 复制device库
cp -rfa ~/xradio/devboard_device_allwinner_xr806 ~/openharmony/device/xradio

# 复制vender库
cp -rfa ~/xradio/devboard_vendor_allwinner_xr806 ~/openharmony/vendor/xradio

配置工具链

cd ~/openharmony

修改:
device/board/allwinner/xradio
device/xradio/xr806/liteos_m/config.gni +37

# Compiler prefix.
board_toolchain_prefix = "~/xradio/gcc-arm-none-eabi-10-2020-q4-major/bin/arm-none-eabi-"

修改:

device/xradio/xr806/xr_skylark/gcc.mk

CC_DIR := ~/xradio/gcc-arm-none-eabi-10-2020-q4-major/bin

编译注意事项

hb工具选择兼容XR806的版本

hb是构件OHOS的python工具. 它位于openharmony/build/lite/hb.

hb最新版本不兼容编译XR806 SDK, 所以必须使用b765e35分支的hb工具, 即对应OH仓OpenHarmony_1.0.1_release分支的版本.

git reset --hard b765e35
# 在openharmony目录下执行安装才会替换hb
python3 -m pip install --user build/lite

编译SDK

编译前要包含一下要编译的程序, 比如

~/openharmony/device/xradio/xr806/ohosdemo/hello_demo

需要修改一些Build.gn...
详细见官方教程和OH仓吧...
还有一些生成文件需要注意:

openharmony/device/xradio/xr806/liteos_m/SDKconfig.gni

编译

hb set 然后按一下回车出现:

!imga

选择wifi_skylark@xradio选项.
然后

hb build -f -c gcc

见success即可.

烧录

记得按官方教程打上 配置里的勾勾.

参考文献

[1] XR806使用安装包方式搭建编译环境

[2] 系统下载与编译

首先配置wpa_supplicant的配置文件:/etc/wifi/ake.conf

ctrl_interface=/var/run/wpa_supplicant
update_config=1
network={
        ssid="(SSID)"
        psk="(PWD)"
}

然后

# 主要连接操作
 wpa_supplicant -Dnl80211 -iwlan0 -c/etc/wifi/ake.conf -B
# 通过DHCP服务获得IP地址等信息
udhcpc -i wlan0 -B

# 搜索WIFI
wpa_cli -iwlan0 scan
wpa_cli -iwlan0 scan_result

# 检查WiFi连接状态
wpa_cli -iwlan0 status

WiFi已连接的应答

想开机配置网络和WiFi, 可以修改/etc/init.d/wpa_supplicant文件第48行左右:

if [ x$brlan=="xbr-lan" ]; then
    echo "change the default ip address 192.168.1.1"
    ifconfig br-lan 192.168.100.1
    # 加你所想操作的指令
fi

某天刷文章认识到了一位比肩Linus Torvalds的神人---QEMU, FFMPEG等神器作者法国程序猿Fabrice Bellard, 敬仰之余, 发现他手下有个OpenGL的开源子集实现tinyGL. 粗看代码感觉不算复杂

恰好手头上有个哪吒D1-H又没有GPU, 就把tinyGL移植了一下, 把牛当马使, 顺便摸摸D1-H性能的天花板.

先上效果图

默认分辨率大概47帧左右. (其实如果不搬RGB到fb可以上百帧)

打满官方MIPI屏分辨率(800x1280), 大概19帧左右.

运行该程序, D1-H终于有点发烧的感觉了, 也不算烫手.(估计还得再压个tinaplayer硬解4k)

修改要点

• 乱七八糟地魔改了一下Makefile, 里面的路径大家自己跟自家用的SDK对一下. ;
• 顺手牵羊几份SDK里的fbviewer的源码,

交叉编译

1. 先make src目录下的源码, 得到库
2. 再make RawDemos目录下可执行程序

github有个大伙优化的原始tinyGL原始版: https://github.com/C-Chads/tinygl

我魔改移植到D1的tinyGL: https://gitee.com/YJHmath/tinygl-d1

想拿程序去玩的:
Raw_demos.zip

坑点

1. 填-march=native或者-march=rv64imafdc会导致编译出来的程序无法运行, 解决方法: 不填, 让编译器默认.

2. 因为用了lp64d/libm.a, 所以指定了-mabi=lp64d, 但也不清楚生没生效

参考

MCU 上纯软件实现 OpenGL

官方例程lv_example_meter_3.c的钟表里指针采用的是贴图方式, 所以解决思路有两个:

1. 针对屏幕分辨率, 优化贴图文件(img_hand.c)的样式
2. 将贴图指针换成普通线段(粗细可调), 只要比的刻度粗一丁点或者把刻度覆盖掉就舒服多了.

贴出第二种方法变动:(基于lv_port_linux_frame_buffer.git)

--- a/examples/widgets/meter/lv_example_meter_3.c
+++ b/examples/widgets/meter/lv_example_meter_3.c
@@ -32,8 +32,9 @@ void lv_example_meter_3(void)
     LV_IMG_DECLARE(img_hand)

     /*Add a the hands from images*/
-    lv_meter_indicator_t * indic_min = lv_meter_add_needle_img(meter, scale_min, &img_hand, 5, 5);
-    lv_meter_indicator_t * indic_hour = lv_meter_add_needle_img(meter, scale_min, &img_hand, 5, 5);
+    lv_meter_indicator_t * indic_min = lv_meter_add_needle_line(meter, scale_min, 5, lv_color_black(), 5);
+    lv_meter_indicator_t * indic_hour = lv_meter_add_needle_line(meter, scale_min, 3, lv_color_black(), 5);

效果:

结帖撒花✿✿ヽ(°▽°)ノ✿

前端时间带实习生的过程中顺带学习了一下F103调OV2640传感器获取图片，顺带把图像通过以太网抛出。MCU采用状态机写法(整理后开源)，通过TCP/UDP传输在PC上解包不要太顺利了.（这里要感谢实习生wyr填好的路）

接下来，主要想把上位机解包程序移植到哪吒开发板上，目标平台：Tina.

开源项目

哪吒开发板实现TCP/UDP图传:
https://gitee.com/YJHmath/image-transmission-d1-tina

图传协议:
https://docs.qq.com/doc/DVkRZUXhSa3prbXZp

预期需求：

• JPEG图片输出到HDMI, 或者MIPI.
• 整合NCNN, 直观看识别效果.
• 或许会支持更通用(复杂)的PES协议.

阶段性成果汇报

2021年9月30日

HDMI调通

• 感谢 @anruliu 指出了sdk中显示编码图像文件的工具fbviewer.
• 感谢 @anruliu 在D1设置hdmi分辨率中9楼指出Tina Linux启动时默认选择MIPI作为显示输出, 并给出了开机默认选择HDMI输出的方案.

开发过程

一开始着重快速地把协议移植, 所以我会使用cmake工具在win下qtcreator编写, 在Ubuntu20.10交叉编译.
开发语言自然是C++和C混着搭. 因为C++有着丰富的轮子,
程序采用了:

• 陈硕大佬的muduo网络库(C++)的Buffer类作为接收缓冲区.
• UNP例程库(C)来做一个简单的UDP Server, 就喜欢它足够简单纯粹.

这两个库在哪吒上的编译过程可以参考:
muduo网络库在哪吒上编译
《Unix网络编程》例程库在哪吒上编译

技术受限

一开始我想把接收到的图片一气呵成地输出到HDMI时, 但发现若将fbviewer目录(tina-d1-open/out/d1-nezha/compile_dir/target/fbviewer)下除main.o外的.o文件链接成静态库(.a), 再编译出来的程序无法正常运行:

root@TinaLinux:/mnt/nfs/tina# ./fbtest
./fbtest: line 1: ELF


�
8@@
                                : not found
./fbtest: line 3: syntax error: EOF in backquote substitution

这是一道坎, 望各位大佬指教.

寻求解决

既然验证了链接到静态库存在问题. 那能想到解决思路有3种:

1. 把已经正常运行的图传程序从C++改成C语言, 直接链接到fbviewer相关的.o文件, 这样程序大概率能正常运行. 但相当于弃盔卸甲, 还要用C把缓存区再造一遍.
2. 把整个fbviewer里jpeg输出到HDMI的代码搬到图传程序里, 然后笃定地相信它会编译成功.
3. 不要忘了操作系统扮演协调资源的角色. 图传程序将接收到的图片储存到运行目录下, 然后再魔改一下fbviewer, 通过stat读取运行目录下对应图像文件的最后修改时间有无发生变化来决定是否要通过HDMI输出图像. 这样就不用再纠结高层代码和底层代码之间千丝万缕的关系.

对于下班的闲暇抽空写码的我, 毫不犹豫地选择了第3种.

#include <stdio.h>
#include <stdint.h>
#include <unistd.h>
#include <sys/stat.h>

int main()
{
    printf("Hello world\n");
    char* path = "pic.jpg";
    uint32_t ts = 0;
    struct stat tmp;
    stat(path, &tmp);
   
    uint8_t* image = (uint8_t*)malloc(1600 * 1200 * 3);
    int is_need_output = 0;
    while(1)
    {
        stat(path, &tmp);
        //printf("st_ctime:%d\n", tmp.st_ctime);
        if(ts != tmp.st_ctime)
        {
            
            ts = tmp.st_ctime;
            is_need_output = 1;
        }
        if(is_need_output)
        {
            fh_jpeg_load(path, image, NULL, 1600, 1200);
            fb_display(image, NULL, 1600, 1200, 0, 0, 160, 0);
            is_need_output = 0;
        }
        usleep(25 * 1000);
    }
    free(image);
    return 0;
}

既然程序需要频繁地读写, 那就直接放到挂载到RAM的目录吧!
于是乎:

下一步把ncnn的demo整合应该也不是什么难事.

效果如上.

在Tina SDK目录下 按官方文档加载环境:

source build/envsetup.sh
lunch d1_nezha-tina
make menuconfig

然后沿路径进入:
Base system->BusyBox->Network Utilities->telnetd
功能全开.(telnet工具可选, 除非你要telnet到别的设备)

如图:

工具和镜像:
spidev_test
tina_d1-h-nezha_uart0_spi_master_slave.zip

@sfgy125110 你用spidev_test就可以试，10M,5M,25M,50M

@sfgy125110 说明不支持该频率. SPI很少用这么速率的通信的, 毕竟用上了4个io

挖uboot, 哪个驱动不行调哪里

@sfgy125110 能, 但芯片分频器支持的分频数有限. 你可以试出哪个有效

@yd_d1s 如果你能贴出spi-sunxi.c, spi-slave-protocol.h的代码差异, 真相就只有一个了

git diff spi-sunxi_old.c spi-sunxi.c
git diff spi-slave-protocol_old.h spi-slave-protocol.h

@xiaorui 优秀优秀~记录学习

在docker(ubuntu:20.04)中编译时, facebuildercmd出现段错误;
换成了一台Ubuntu 22.04.2 LTS(Linux tao 5.15.0-58 x86_64 GNU/Linux)物理机编译成功;
原因待查

@noah-yi 晚点分享个xfel跑裸机hello world

工具和镜像:
spidev_test
tina_d1-h-nezha_uart0_spi_master_slave.zip

背景

• 主控: D1H
• 板卡: 两块哪吒开发板(以下简称为主机, 从机)
• 操作系统: Tina Linux 2.0

问题

验证D1H芯片SPI主从机通信.

硬件接线

	主机SPI	从机SPI
19	SPI1_MOSI	SPI1_MOSI	19
21	SPI1_MISO	SPI1_MISO	21
23	SPI1_SCK	SPI1_SCK	23
24	SPI1_CE	SPI1_CE	24

SPI概述

SPI接口是一种高速的, 全双工, 同步的通信总线.
适配D1H芯片的Tina Linux的BSP-SDK(以下简称SDK)中已包含相关驱动文件: spi-sunxi.c.
它提供的了仅内核态下主从机的简易通信验证实验, 这或许是考虑到SPI通信速率比较高的特性.
验证操作

SPI主机配置

menuconfig

在SDK执行完环境变量加载后, 执行:

/mnt/tina-d1-h$ make kernel_menuconfig

●开启Device Drivers->SPI support
●进入SPI support, 按图示开启:

设备树

修改: ./device/config/chips/d1-h/configs/nezha/board.dts

需要根据手册和原理图确认好针脚功能:

SPI从机配置

menuconfig

(同SPI主机配置一致)

设备树

仅spi_slave_mode设为0, 其余项同SPI主机配置一致. spi_slave_mode = <0>;

SPI主机收发信息

按上述配置, 重新编译SDK, 打包, 烧录, 启动设备会出现:

root@TinaLinux# ls -l /dev/spidev1.0
crw-------    1 root     root      153,   0 Jan  1 08:00 /dev/spidev1.0

然后将可执行的SPI测试程序(./lichee/linux-5.4/tools/spi/spidev_test)挪到设备上(adb push等)并赋予可执行权限:

# 主机以10MHz发送(即MOSI)发送16进制数据: 0x01 0x02 0x03 0x04
./spidev_test -v -D /dev/spidev1.0 -s 10000000 -p "\x01\x02\x03\x04" 
# 主机以10MHz发送(即MOSI)发送ASCII字符串数据: "allwinner"
./spidev_test -v -D /dev/spidev1.0 -s 10000000 -p  "allwinner"
spi mode: 0x0
bits per word: 8
max speed: 10000000 Hz (10000 KHz)
TX | 61 6C 6C 77 69 6E 6E 65 72 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __  |allwinner|

注意SPI是同步通信接口, 所以在发送的同时也会接收同样长度字节的数据.
下文将用到SPI主从通信的一种常见做法: 主机先发指令头, 然后再发指令体以获取从机应答.

SPI从机收发信息

spi-sunxi.c中对SPI从机模(SLAVE_MODE)采取了简单的收发验证处理, 具体是创建一个内核线程执行int sunxi_spi_slave_task(void *data), 该函数又被设备中断所控制(当收到SPI数据时).

• SPI从机接收到数据的主要流程:
  sunxi_spi_slave_task() -> sunxi_spi_slave_handle_head(), 然后:
  若指令头是写操作(0x01), 则执行:sunxi_spi_slave_cpu_rx_config(), 该函数仅是输出写入内容.
  若指令投是读操作(0x03), 则执行:sunxi_spi_slave_cpu_tx_config(), 该函数仅是将收到的指令体的值+0x80, 然后发送(MISO)给主机.

• 对于从机, spi-sunxi.c能验证SPI通信, 但没有可供用户层直接使用的方法.

用户层可验证的SPI从机收发方案

功能设计

从机安排一块32byte的内存缓存空间(简称"缓存空间")供主机通过指令进行读操作和写操作, 且从机能在用户层对该内存空间访问.

主要改动

• spi.c:
  • 增加static struct class_attribute ye_spi_buf_attrs[], 以创建/sys/class/spi_slave目录下的spi_buf文件, 并提供实现了读/写缓存空间的方法.
• spi-sunxi.c:
  • 使用ye_spi_slave_set_txdata()方法替换sunxi_spi_slave_set_txdata(), 以实现读操作.
  • 修改sunxi_spi_slave_cpu_rx_config()方法, 以实现写操作.

改动详情请查看: d1h_spi_driver.diff

使用方法

写操作: 操作:0x01(写) 地址:0x00 0x00 0x00 指令体长度:0x09
./spidev_test -v -D /dev/spidev1.0 -s 10000000 -p "\x01\x00\x00\x00\x09" && \
./spidev_test -v -D /dev/spidev1.0 -s 10000000 -p  "allwinner"

读操作: 操作:0x03(读) 地址:0x00 0x00 0x00 指令体长度:0x09
./spidev_test -v -D /dev/spidev1.0 -s 10000000 -p "\x03\x00\x00\x00\x09" && \
./spidev_test -v -D /dev/spidev1.0 -s 10000000 -p  "\x00\x00\x00\x00\x00\x00\x00\x00\x00"

从机读取缓存空间:
cat /sys/class/spi_slave/spi_buf

从机写入缓存空间:
echo "Hello world" > /sys/class/spi_slave/spi_buf