RikiBlog

自制FPGA渲染器：软件算法模拟

Tue, 01 Apr 2025 00:00:00 GMT

本文档介绍了我自制的FPGA渲染器项目的背景、目标

自制FPGA渲染器：项目说明

Tue, 01 Apr 2025 00:00:00 GMT

最近看到很有意思一个项目，裸眼3D显示器。具体的实现原理就是在液晶屏幕前面加一个光栅，通过不同角度看到不同的画面实现3D效果。 <iframe width="100%" height="468" src="//player.bilibili.com/player.html?bvid=BV1DEQoYmEEp&p=1" scrolling="no" border="0" frameborder="no" framespacing="0" allowfullscreen="true"> </iframe>

这让我想到很有意思的一个问题：即使有三维的显示器，也没有三维的画面内容，往往只能显示一些固定的三维图像，久看很难不看腻，但我们想看的电影、电视剧等内容都是二维的。那能不能通过某种方式，把二维的画面内容转换成三维的呢？这样就可以在享受任何数字内容的身临其境的体验，而且还要保证这个过程还是实时的，可以即插即用。

这个项目主要涉及到两部分，一部分是立体信息的获取，另一部分是图像的渲染。因为本身缺少一个维度的信息，所以只能通过一些深度学习的方法来估计立体信息。通过这个立体信息，就可以生成多视点的图像，然后通过光栅进行融合显示。

立体信息的获取

图像的渲染

这个项目的原理并不复杂，但是实现起来工程量还是挺大的。首先是光栅的设计和加工，然后是多视点图像的生成，最后是图像的融合显示。考虑到光栅的加工难度，很难再单独设计光学硬件。这样一来，实现效果主要聚焦于两大问题，一个是多视点图像的生成，另一个是这些图形的融合。

自制FPGA渲染器：系统架构

Tue, 01 Apr 2025 00:00:00 GMT

FPGA系统架构设计

对比维度	状态机流水线（固定功能）	指令式设计（可编程）
架构思路	每个渲染步骤做成状态机/流水线模块，数据按流程走	定义指令集，硬件执行指令驱动渲染
灵活性	低（功能固定，难扩展）	高（算法可通过程序/微码修改）
性能	高（专用硬件加速，时钟周期可预测）	中（需要调度，性能受指令开销影响）
资源利用	紧凑（LUT/DSP/BRAM 利用高效）	占用较大（需指令解码器、寄存器文件、控制器）
开发难度	中（需要模块化设计，但不涉及 ISA）	高（需要设计 ISA、指令调度、编译/汇编工具链）

考虑到要在ZYNQ7020实现，资源有限，小bram+DDR3指令式速度不敢想象，同时其实也不需要太复杂的渲染功能，所以我选择了状态机流水线的设计思路。

内存存取设计

在内存设计方面存在不少难点，根本的原因在于片上的bram比较小，而把数据存在DDR中，每次读取又需要十几个周期的延迟，会造成渲染帧率的降低。具体而言，渲染器需要存取以下几类数据：

Z-buffer

对于图形的消隐，考虑到效率现代最常用的算法是Zbuffer算法，也就是开辟一个屏幕空间大小的buffer，深度浅的覆盖深度深的，最终完成深度测试。对于非常紧张的bram,很难开一个全局的缓冲区，为此需要把画面分成一个一个的tile，如64x64，对于每一个tile单独进行渲染。

纹理

在纹理映射步骤中，对于纹理的访问是一个随机读取，而随机读取对于DDR又是非常不友好的，所以最好的方式是依次顺序读取，把小三角形(实际操作可能是矩形)纹理读进bram。对于每一个tile而言，也不能把所有纹理全部加载进来，而只能把正在渲染的三角形面加载进来。在渲染过程中，再配合流水线加载，可以把ddr造成的延迟消除掉。

顶点数据

纯计算方案

每次算出的所有顶点数据全部顺序交给下一步tile的纹理映射器，会有大量浪费，因为每个tile只会用到一部分顶点数据，其他的顶点数据白算了。

纯不计算方案

顶点数据算出来就分配给不同的tile。

顶点数据的访问也是一个随机读取，很搞笑的是，我认为数据量最少的顶点数据居然也放不进bram，也只能设计ddr存取流程。

在这里有一个很有意思的权衡，顶点数据如果是顺序存储的，那么可以顺序读取，但是渲染器需要按照三角形的顶点索引来访问顶点数据，这样就会变成随机读取。如果把顶点数据按照三角形的顶点索引顺序存储，那么就可以顺序读取了，但是这样会造成顶点数据的冗余存储。

同时，怎么把三角形分配到各个tile上也是一个问题，可以把三角形的包围盒和tile进行相交测试，分配到相交的tile上，但是怎么存？可以为每个tile维护一个桶，把相交的三角形放进去，这样在渲染tile时就是顺序读取了，但是在写的时候又是随机写入。你可能说很简单，每个tile维护一个小的bram桶就行了，但是bram桶开多大呢？如果开得太小，如果所有面都到一个tile，可能会溢出；如果满就写一次，满就写一次，又成了随机读取。如果开得太大，又浪费bram资源。统一缓冲区，再分配，倒是一个选择...

也可以把三角形顺序存储，然后每个tile维护一个索引列表，存储相交的三角形的索引，这样在渲染tile时就是随机读取了。

不管怎么样，总有一个随机读取。

折中方案

也许可以浪费一点计算资源，来做一些重复计算，同时减少内存访问？比如说，把顶点分成几个大片（注意是按照乘以MVP矩阵之前的大片，是为了可预测顺序），把每个大片放到ddr中，渲染时再从bram中读取大片数据，ddr顺序读大片。

我愿称之为双tile方案

电动牙刷BLE指令设计

Tue, 01 Apr 2025 00:00:00 GMT

大端在前，每条指令均为20字节，未使用的字节填充为0

0x01 设置牙刷命令

该命令用于设置牙刷的工作参数，包括使能状态、振动频率、振动幅度、扫动频率、扫动幅度等。其余字节补零。

字节位置	1	2	3	4	5	6~20
内容	使能	振动频率	振动幅度	扫动频率	扫动幅度	0 填充

0x02 刷牙状态服务

该命令用于上报电池电量、刷牙进度和固件版本号。

字节位置	1	2-3	4-7	8~20
内容	电池电量	刷牙进度（大端）	版本号（大端）	0 填充

0x03 RFID 标签数据

该命令用于上报刷头标签信息，包括唯一ID、生产日期、刷头类型、寿命及使用次数。

字节位置	1-8	9-10	11	12	13	14-15	16-17	18~20
内容	标签唯一ID	年份（大端）	月	日	刷头类型	寿命（大端）	使用次数（大端）	0 填充

0x04 同步历史数据服务 - 包1

历史数据同步包1用于传输时间戳、刷牙时长及刷头ID。

字节位置	1	2-5	6-7	8-15	16~20
内容	包头	时间戳（大端）	时长（大端）	刷头ID（大端）	0 填充

0x04 同步历史数据服务 - 包2

历史数据同步包2用于传输刷牙位置等刷牙数据。

字节位置	1	2-19	20
内容	包头	刷牙数据	空

0x07 刷牙状态数据

刷牙状态数据用于传输刷牙状态信息及剩余时间。

字节位置	1-18	19	20
内容	状态数据	剩余时间	空

0x08 刷牙模式设置

刷牙模式设置共5个包，每个包包含分片索引、刷头ID和部分模式数据（每包截取20字节）。

字节位置	1	2-9	10-20
内容	分片索引	刷头ID（大端）	模式数据部分

0x09 UTC 时间同步

用于同步 UTC 时间，4 字节时间戳 + 填充。

字节位置	1-4	5-20
内容	UTC 时间（大端）	0 填充

0x0A 图片传输服务 - 信息包

该命令用于传输图片的基本信息，包括图片尺寸、总包数及图片格式等。

字节位置	1	2-3	4-5	6-7	8	9-16	17	18-19	20
内容	包头	图片宽度（大端）	图片高度（大端）	总包数（大端）	图片格式	标签唯一ID（8字节）	位置	保留	保留

包头：0x00 表示信息包
图片宽度、高度：2字节大端
总包数：2字节大端
图片格式：1字节（如 0x01=RGB565）
其余字节补零或保留

0x0A 图片传输服务 - 数据包

该命令用于分包传输图片数据，每包最多携带18字节图片数据。

字节位置	1	2-19	20
内容	包序号	图片数据	填充

包序号：1字节，表示当前数据包的序号（从1开始递增）

若超出则从1循坏开始(packetnumber)%255 + 1
图片数据：最多18字节，若不足18字节则后续字节补0
填充：1字节，若图片数据已满18字节则为0，否则用于补齐20字节长度

每个数据包的格式为：命令字节（0x0A）+ 包序号 + 图片数据（18字节）+ 填充（不足时补0），共20字节。

0x0B 同步RFID名称附加信息

该命令用于上报刷头标签信息及名称

字节位置	1-8	9	10 ~20
内容	标签唯一ID	位置数据1、2、3	字符串

字节大端序小端序的问题

Tue, 01 Apr 2025 00:00:00 GMT

实验现象

同步图片是这个

实际上屏幕显示

问题原因

像素数据
0000 0001 0002 0003 0004 0005 0006 0007 0008

生成的指令数据
0A02000000010002000300040005000600070008

在设备端使用代码

memcpy(&buf, data+2, 18);

由于设备端使用的是小端序，所以需要将数据转换为大端序。因此需要将数据转换为大端序，正确的指令数据应该是：

uint16_t pixel = (data[2+i] << 8) | data[3+i];
buf[offest+i] = pixel&0xFF;
buf[offest+i+1] = (pixel>>8)&0xFF;

常见情况

:::note 在LVGL中也有类似的设置项即为像素的swap选项一定记得注意统一😂 :::

处理器架构	默认字节序	说明
ARM（Cortex-M）	小端序	Cortex-M（如 STM32、NRF52）等低功耗微控制器常用小端序。<br>ARM Cortex-A 也通常默认小端，但可以配置成大端。
MIPS	可配置，但多数是小端序	某些嵌入式设备或老旧网络设备可能使用大端。
PowerPC	多为大端序	早期嵌入式和网络设备中常见。现在较少使用。
RISC-V	小端序	默认小端序，也支持大端（但很少用）。
x86（Intel）	小端序	工业控制或嵌入式PC中常见。

CH340x自动下载电路调试心得

Tue, 01 Apr 2025 00:00:00 GMT

问题1 识别问题

大多串口插件比较离谱的筛选规定只能识别ttyS..和ttyUSB..(ttyCH341USB0:那我走？) 导致默认不显示，自己去open比较麻烦于是修改驱动，将设备名称命名为ttySCH341USBxx

问题2 自动复位电路调试记录

:::tip 问题的本质 CH340X的DTR#虽然有两种模式，分别是默认为低和高，但Linux驱动会自己设置默认值😂 :::

有RST#和DTR#引脚(注意这里的#号，代表相反的意思)

默认初始状态或者close以后的状态是全0,即DTR，RST都是低电平，DTR#和RST#都是高电平

RST#倒是正好，因为单片机的复位逻辑也是RST#

但DTR#为高就比较麻烦，也就是BOOT引脚为高（和单片机BOOT逻辑正好相反，单片机在下载模式），导致单片机无法正常启动，此时手动按复位键也没有用

ps：也有的单片机BOOT逻辑是BOOT#，这个要看清楚，如果是这样的就不用修改

遂修改一下驱动（开源yyds）

static void ch341_port_shutdown(struct tty_port *port)
{
	struct ch341 *ch341 = container_of(port, struct ch341, port);
	struct urb *urb;
	struct ch341_wb *wb;
	int i;

#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3, 16, 0))
	usb_autopm_get_interface_no_resume(ch341->data);
	ch341->data->needs_remote_wakeup = 0;
	ch341->ctrlout = CH341_CTO_D;//add
    ch341_set_control(ch341, ch341->ctrlout);//add
	usb_autopm_put_interface(ch341->data);
    //******existing code
    //对于内核版本较小的修改也是类似的
}

经过测试一切正常，单片机可以正常启动

另外附一段软件复位

#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/ioctl.h>
#include <stdlib.h>

int main() {
    const char *serial_port = "/dev/ttySCH341USB0";  // 修改为你的串口设备
    int fd = open(serial_port, O_RDWR | O_NOCTTY);
    if (fd < 0) {
        perror("open");
        return EXIT_FAILURE;
    }

    int status;

    // 获取当前控制线状态
    if (ioctl(fd, TIOCMGET, &status) == -1) {
        perror("TIOCMGET");
        close(fd);
        return EXIT_FAILURE;
    }

    // 拉高 DTR
    status |= TIOCM_DTR;

    // 拉高 RTS（RTS# = 低电平，置0）
    status |= TIOCM_RTS;

    if (ioctl(fd, TIOCMSET, &status) == -1) {
        perror("TIOCMSET (DTR low, RTS low)");
        close(fd);
        return EXIT_FAILURE;
    }

    printf("DTR# 已拉低，RTS# 已拉低（复位开始）\n");

    // 延时100ms（可根据需要修改）
    usleep(100000);  // 100,000微秒 = 100ms
    //拉低RST
    status &= ~TIOCM_RTS;

    if (ioctl(fd, TIOCMSET, &status) == -1) {
        perror("TIOCMSET (RTS high)");
        close(fd);
        return EXIT_FAILURE;
    }

    printf("RTS# 已拉高（复位完成）\n");

    // 保持状态（可根据需要修改延时或退出前清理）
    sleep(1);

    close(fd);
    return EXIT_SUCCESS;
}

gcc set_dtr_rts_reset.c -o set_dtr_rts_reset