0xAA55 发表于 2024-4-19 17:41:26

【嵌入式】芯片之间的通讯方式


# 芯片通讯协议概述

## 1. UART/USART 方式(TX/RX)(T 是 Transmitter,R 是 Receiver)

!(/data/attachment/forum/202404/25/145900cqkdzdwkk1wmdnfr.png)
- UART 方式不受传输距离的影响, **可以长距离传输** ,但是要求传输的双方 **写死传输速率值** 。
- 一般按 115200 Hz 波特率传输,相当于 10KB/s 的速度。但传输波特率也可以 ***瞎几把改*** ,改的数值越大,传输速率越高,对芯片的要求就越高。不能超过芯片的 UART 外设的最大传输频率。
- 「TX」指的是发送线,「RX」指的是接收线。举例:芯片 A 的 TX 接芯片 B 的 RX,芯片 A 的 RX 接芯片 B 的 TX。
- UART 方式没有明确定义如何设计总线,因此基本上都是一对一传输。 **每个设备占用一个 UART 外设和两个 PIN** 。但是如果你想要只收不发或者只发不收,那就只需要一根线。
- 因为 UART 的TX/RX 之间其实是互不干扰的,所以可以认为它是 **全双工** 的工作模式。
- UART 最适合使用DMA + Periph 通讯方式(后文有描述通讯方式)。因此不会占用 CPU 的时间。
- UART 没有抗干扰设计。传输时需要做好容错机制。

## 2. SPI 方式(MOSI/MISO)(M 是 Master,S 是 Slave)

!(/data/attachment/forum/202404/25/145836w99gkljz955999kj.png)
- SPI 因为自带时钟信号,所以传输过程中发送和读取的部分由 Master 的时钟线负责驱动,而无需传输双方互相写死。通常情况下 SPI 的传输速率比 UART 高很多,就比如 STM32F1 之间的传输就可以达到 1MB/s 以上。
- SPI 是 **全双工** 的工作方式。它每进行一次传输,双方都会发送出一个字节,然后接收一个字节。
- SPI 有 16bit 模式,此时则是每次传输一个 uint16_t,并读到一个 uint16_t。
- SPI 方式对传输距离十分敏感, **不可以长距离传输** (因为会导致发送线和接收线的时钟错位)。SPI 自带时钟信号,因此不需要「Slave 方」约定传输速率。
- 传输距离越远,「Slave 方」发送过来的数据就越迟。因此不得不降低传输频率来通信。
- 理想传输距离: **5cm 以内。**
- SPI 方式可以设计为总线传输方式,使用 CS 线来区分传输目标。 **可以设计为每个设备占用一个 CS PIN,所有设备共用一个 SPI 外设。**
!(/data/attachment/forum/202404/25/145836af8mmob88ldi5bmm.png)

## 3. I²C 方式(SDA/SCL)(也可写作 IIC。读作「I方C」)

!(/data/attachment/forum/202404/25/145836bcq8bb8lued9j3ju.png)
- 天生擅长总线方式传输,因为每次传输都必须先传输目标设备的「设备地址值」,比如 0x29。传输后,传输方需要等待对方反馈一个 ACK 信号。如果成功接收 ACK 信号,则发送方就能与接收方进行通讯,而总线上的其余设备则不会受到任何影响。
- 因此可以多个设备同时连接一个 I²C 总线,然后 CPU 作为 Master 对其它设备进行「点名通讯」。
- 因为传输时要等待一个 ACK 信号,所以需要等待。这就导致传输效率十分低下。
- 有的 Master 会在发送了某个传输目标地址后无视该地址的 Slave 返回的 ACK 信号(假设所有 Slave 都不发出 ACK 信号),然后广播它的数据,每隔一段时间进行一次这样的传输。这里面,VGA 视频传输协议里的「显示器设备信息信号线」就是这样的行为。
- **传输距离比 SPI 短,传输速度比 UART 慢,只能半双工传输** ,而且很多芯片的 I²C Periph 有 BUG,无法正常传输, **需要使用 PIO 方式传输** (因此通讯过程中会完全占用 CPU,后文会描述什么是 PIO),速度难以达到 1KB/s,属于是 **比较垃圾** 的传输协议了。然而却很通用,因为它节省芯片的 PIN 数的使用。

## 4. CAN 方式(Car Area Net,车内网)

- 可 **高频长距离抗干扰全双工** 传输。
- CAN 总线可以像 I²C 总线那样挂载多个 Slave 设备,并对每个设备单独通信。
- 通讯方式较为复杂,高端芯片使用。

## 5. 红外线(遥控器)方式

- 此种方式的开发比较自由。使用红外 LED 发出红外光,而因为 LED 具有光电效应,红外 LED 也可以接收到红外光并转换为电能(类似于光伏板受到光照后会发电一样)。自定一套协议,使红外 LED 按照这样的协议去发出光线,而接收端则通过某些手段过滤掉环境光,按照自定的协议去接收红外光的信号,就可以完成一次通信。
- 此种方式容易被环境光影响。通常像空调、电视机、电视机顶盒等通常不会移动位置的家电会使用此种方式进行通信。

## 6. 并口通讯

- 并口通讯使用多根数据线传输数据,传输的时候,每个时钟周期,每根线传输一个 bit。
- **现代 PC 计算机的 CPU 和 DDR 内存条之间的传输协议就是一种有时钟信号的并口传输协议** 。
- 并口通讯现在极少在单片机 MCU 上使用。一般都在 FPGA 上使用。单片机一般不会提供并口传输的外设,但也有例外,比如 ESP8266 提供 SDIO 用于和 SD/TF 卡进行通讯。SD/TF 卡既可以进入 SPI 传输模式进行 SPI 传输,也可以进入 SDIO 传输模式, **同时使用四根信号线进行并口传输** 。
- 并口通讯 **要求每一根信号线的长度都必须一致,每根线的阻抗值也要一致** 。并口传输对于信号线长度和阻抗的容错性非常低,所有的信号线里,如果有一根稍微长了几毫米,或者阻抗稍微低了几毫欧姆,都会导致传输的频率受到影响。
- **这也是现代 PC 计算机在尝试让 CPU 和 RAM 超频工作时超频失败的原因之一** 。
- 古早时期、Windows 98/XP 的年代,PC 内部的硬盘、软驱和光驱使用的 IDE 总线就是一种典型的并口协议。最终,PC 内部的硬盘、光驱的传输协议被高频串口通讯协议比如 SATA 或者其它传输协议比如 NVMe 取代。

# 芯片通讯方式概述

芯片之间的通讯按三种方式来区分:

## 1. PIO 方式

- 通过 CPU 按 Bit 一个一个写 GPIO 来实现传输。
- 不同的芯片使用不同的方式写 GPIO,不过大多数芯片厂给的方案都是靠直接写 GPIO 外设地址上的寄存器来实现写 GPIO。
    - 每一款 CPU 都有它独有的 GPIO 外设地址和数量。
- 按照直接读写寄存器的方式来读写 GPIO 是效率最高的 PIO 方式,然而还是无法达到 **正常通讯** (此处指:使用 DMA + 针对特定传输协议专用的外设 Periph)的速度。
    - 因此是 **兼容性最好但是最慢、最卡、最低效的方式** 。示波器上可以看到 **绝大多数的时间都是在等待** 。
    - 如果 PIO 的代码是使用 `WiringPi` 书写的,那么它就可以兼容 Arduino、Raspberri Pi、Armbian 等开发环境或者操作系统。而与此相应的问题就是使用 `WiringPi` 传输速度会变慢好几倍。
- 无法实现UART 传输,除非使用的 UART 波特率极低(比如 9600)。
- 无法实现 SPI Slave,除非波特率极低。
- 无法实现 I²C Slave,除非波特率极低。
- **最符合 _外行人_ 对「芯片之间的通讯方式」的理解。**

## 2. Periph 外设通讯方式

- Periph **(译作「外设」)** 是 CPU 上集成的芯片电路, **是 CPU 与外部设备之间通信的桥梁** 。
- 以 **MMIO** 的方式设计的外设在 CPU 上体现为「特定内存地址」上的「状态机寄存器」。CPU 在读写这些「内存地址」的时候,就会触发对应外设的行为。
- 比如 STM32 上,在某个地址 `0x4001xxxxx` 上,是 SPI 外设。在 STM32 官方库的头文件里,有个「结构体」,也就是按 C 语言写的一个 `struct`,它有若干 `uint32_t` 类型的成员变量,其中一个叫「DR」。这个 `uint32_t DR` 它所在的「内存地址」,就是 SPI 外设的数据寄存器 Data Register 映射到 `0x4001xxxxx` 的地址。
    - **你只要给 DR 赋值,SPI 就开始了全自动的通讯** ,输出一个 `uint8_t` 或者 `uint16_t`(取决于 SPI 是 8bit 模式还是 16bit 模式)
    - 通讯后,DR 里面有对方设备传输过来的数据,因此你需要再读取这个 DR 的值,这样就能使 DR 为「空」的状态。此时,你就可以继续你的第二轮的传输了,以此类推,不断传输数据。
      - STM32 允许你在不读取 DR 的情况下强行怼 DR 进行持续的数据输出,但是别的芯片就不一定了。
    - 这种方式的传输比 PIO 效率高很多,但仍然不是最理想的。 **示波器上看到的,是断断续续的传输** ,也就是 CPU 需要先花时间准备数据,然后一旦数据准备好了,写入 DR 了,那么 SPI 外设就立刻以最快速度发送 + 读取数据,然后等待 CPU 过来读取。CPU 读取前还必须先轮询 DR 判断它是不是「空」状态,这样下来,每传输一个字节或者一个 ***字*** (即 `uint16_t`),都需要一个间隔时间。
    - 外设如果支持中断,那么外设可以做到 DR 有数据待读取时发出中断信号,让你的 CPU 立刻马上读取 DR。能稍微加快通讯的速度。
- 除了 STM32 以外,其它的芯片也有它们的外设,以及配套的外设通讯库软件,比如 Arduino,ESP32,Raspberri Pi 等。每一种芯片的外设数量、外设地址、外设寄存器布局、外设行为都不一样,此处无兼容性可言。
- `WiringPi` 提供了最基础的外设库,可以跨一部分平台来使用外设的功能。比如 SPI、UART 外设的控制。但是达不到最理想的效果, **因为没有 DMA 的支持** ,并且 `WiringPi` 作者自己在十年前就声明不再更新 `WiringPi` 了。
- 除了 MMIO 方式以外,还有 **端口通信** 的方式,即:使用类似 `in`/`out` 的指令,指定端口,然后读写外设的寄存器,触发外设的具体行为。
- x86 机器在早些年间就是典型的以端口通讯为主的机器,对应 C 语言开发环境有 `inp()`、`outp()` 函数用于控制外设。
- 同理,每个外设都有它自己的地址。不过这种方式的外设使用的地址可以和内存的地址区分开,不同于 MMIO 可以通过直接怼「内存地址」来写外设寄存器。
- 在 x86 物理机器上,MMIO 比端口通讯快;但是在 QEMU、bochs 等 PC 模拟器里, MMIO 远慢于端口通讯。

## 3. DMA + Periph 通讯方式

- DMA(Direct Memory Access)是外设的一种,它可以在无需 CPU 监督的情况下从某个「内存地址」读或者写特定数量的数据到另一个「内存地址」,并且读写指针既可以配置成每次读写都前进,也可以配置成每次读写都不动, **期间 CPU 能够依然继续运行** 。借助 DMA,我们可以实现内存到内存的数据拷贝、内存到外设的数据拷贝、外设到内存的数据拷贝甚至外设到外设的数据拷贝。
- 不同的芯片有不同的 DMA 外设数量、不同的通道数量、支持的不同的外设类型和数量、外设地址和寄存器布局等。即使是相同厂商的 CPU,对应的 DMA 和外设的工作方式也是不一样的。 **此处无兼容性可言,必须以厂商提供的 PDF 为准** 。
- 在联合使用 DMA 和外设的过程中,我们需要指定外设的工作模式为「配合 DMA 工作」的模式,然后指定 DMA 的读或者写的「内存地址」,再指定 DMA 的触发条件。当 DMA 触发后,它就会不断和外设一起联合工作,实现数据的批量读取和写入, **示波器上看到的就是连续不断的数据读取和输出** 。
- 假设我们要借助 DMA 实现 SPI 的自动读取,我们需要先设置 DMA 写入的「内存地址」,然后指定 DMA 的读取地址为 SPI 的 DR 寄存器,再启动 DMA,数据就开始传输了。

## 4. DMA + Periph + 中断的通讯方式

- 在芯片间通讯的过程中,如果对方芯片发送了数据过来,这边的外设接收到了数据(暂存于 DR 寄存器), **那么这些数据需要有合适的地方存储** 。如果不借助中断的方式来工作的话,你需要设计你的 CPU 不断轮询外设,判断它是否正在暂存数据,然后读出来放到内存上的指定位置里。但是如果你配置外设的中断,使其一旦拿到数据就触发中断的话,那就无需轮询外设了,CPU 可以去干别的工作,等到中断触发的时候,再来读取数据并对数据进行处理。
- 不同的 CPU 有不同的中断控制器,中断通道,以及不同的外设和中断号/中断通道之间的联接关系。 **此处无兼容性可言** 。
- 对于批量中转数据的情况,比如实现一个 USB Virtual COM Port,将 USB 协议转换为 UART 协议,可以借助 DMA + 中断实现「FIFO 缓冲区」,即「先进先出缓冲区」「环形缓冲区」。设置一个缓冲区,让 DMA 在接到数据后往缓冲区里存储,但是在 **经过缓冲区的一半位置** 的时候,触发一个中断。此时,你的中断处理程序得到机会执行,你的前半个缓冲区存储的是已经完成读取的数据。你可以让你的中断处理程序就在这个时候设置 DMA 再把这部分数据 **走别的通道发出去给别的设备** 。以此类推,DMA 走到缓冲区末尾后,同样发出中断信号并自动回到缓冲区头部,你就又可以再次把读取到的新数据转发给别的设备了。示波器上可以看到你的设备毫无间断地以最高的带宽大量传输数据。

# 芯片之间通讯的限制

## 1. Pin/GPIO 有限

这是绝大多数芯片的问题。为了解决这个问题,不少芯片不惜付出传输速率低的代价,使用了最省针脚的 I²C 总线来通信。
除此以外,也有一些芯片专门用于扩展 GPIO 的数量。使用特定的协议比如 SPI 和这样的芯片通讯,然后该芯片的特定 GPIO 口按照指定的值拉高或者拉低。牺牲时间换取 Pin/GPIO 的数量。

## 2. RAM 有限

通讯过程中,需要使用缓冲区(Buffer/Cache)来暂存数据进行处理。嵌入式开发环境下 RAM 基本都是按 KB 算的。当通信的过程中传输的数据超出了缓冲区后,就会造成数据丢失。有必要的时候需要设计合理的拥塞机制,压缩或者合并数据,以减少传输的数据量和所需的 RAM。

## 3. 传输距离有限
最受传输距离影响的传输协议是 I²C 和 SPI,其次是 UART 和 USB。传输距离较远的是 CAN 和 Ethernet。其中,I²C 和 SPI 的传输速率与传输距离有着较强的关联,传输距离越远,传输频率越低。

## 4. 外设资源有限

不同的芯片有不同的外设资源,有的芯片有多个 UART、SPI、I²C、ADC、DAC 外设,有的则没有那么多。在芯片选型时,需要注意你的芯片需要连接多少个传感器,并且和每个传感器之间使用什么样的传输协议,再看看外设是否足够,如果不够,那是要重新选型的。

## 5. 速率瓶颈:传输的双方必须按最慢的那个的速度来

芯片在和传感器进行通信时,如果传感器的传输频率很低,那么芯片则需要等待较长的时间才能完成一次采样传输。总体上会影响到传感器采样的频率,如果短时间内需要传感器快速大量采样,但是使用的传输协议却不能满足条件的话,就会导致采样频率不足。

## 6. 工作方式:是否能做到异步通讯

用好中断和 DMA,以及外设,避免使用 PIO 和轮询方式。
可以使用 FreeRTOS 等专为嵌入式设计的操作系统,通过多任务的方式,确保你的 CPU 能同时处理多项不同的任务,以免漏数据。

# 芯片与 PC 之间的通信

## 1. USB 方式

USB 方式是比较常见的上位机和下位机之间通讯的方式。USB 本身具有一丢丢抗干扰性(有,但不多),因此实际使用上(尤其是工控领域,一个上位机控制一百多个下位机的时候)还是 CAN 或者 Ethernet(局域网) 更优于 USB。
USB 的工作模式永远都是 USB Host 不断轮询连接它的 USB 设备,然后被轮询到的 USB 设备上报它的数据内容。USB 下位机永远工作在被动的被轮询后上报数据的模式,不存在主动性。

### USB 虚拟串口设备方式(USB Virtual COM Port)

此种方式比较易于设计,通常情况下芯片厂给的 Demo 里面都会有源码。 **PC 端无需安装驱动** 即可使用(需要 Windows Vista 以上)。缺点是 **分配到的串口端口号比较随机(会根据设备的 VendorId 之类的信息固定)** ,一般要求用户自己猜或者调试端口号。
因为是 **虚拟串口设备** ,所以不会受到串口设备的波特率影响,可以按照 USB 1.1 的速率甚至 USB 2.0 的速率来通讯。
虚拟串口设备 **本来的用途** 是帮 PC 把一个 USB 口转换为一个 UART 通讯口,但是我们可以借助它本身能够和 PC 直接通讯的优势(芯片厂给的代码有封装好了的 API 去收发数据) **去做我们想做的事情** 比如上报传感器采样的数据等,而不是真正去制作一个 USB 转 UART(相同功能的设备有 CP2102、CH343 等,但是它们似乎需要 PC 装驱动)。

### USB 人体工学设备

此种方式需要你提供你的「HID_XXX_Report_Descriptor」(HID 设备上报内容描述符),用来描述你上报的数据的具体格式。你的 USB 外设在每次被 USB Host 轮询到的时候按照你的描述符所描述的 ***格式*** 来上报数据到 USB Host,操作系统自带的 USB HID 驱动因此就能判断你上报的数据的具体内容是什么,然后在 GUI 上体现出来。比如你上报的数据里面,哪些字节表示哪些个按键按下等,是需要你自己来定义的。相同的 HID 设备,比如键盘,虽然都是键盘但是它的 HID 设备上报内容描述符不同,那么它上报的数据的内容就不同,但是表达的含义却是一样的:我哪个键按下了,哪个键弹起了。
使用此种方式你可以把你的设备假装成 **鼠标、键盘或者手柄** 等设备来和 PC 通讯,但是总的来讲不太方便——你需要在 PC 上开发软件,其同样需要按照读取鼠标、键盘或者手柄等方式来获取你的设备上报的数据。
这种方式有个优点是它兼容 Windows XP。在现在这个年代,这似乎没啥卵用。

### USB 大容量存储器设备

此种方式,操作系统的 USB 驱动会把你的设备识别为 U 盘(或者 SD 卡、移动硬盘等类似的东西),然后会像读取 U 盘那样去读取分区表、文件系统扇区等。操作系统和它的驱动 **假定你的设备不会擅自改变读出的数据** ,否则视为设备的存储功能损坏。
当你的嵌入式设备需要使用 SD 卡等存储器来存储你的信息,但是同时也想像读卡器那样接电脑就能读出其中的信息的时候,你就可以设计你的设备为这种形式。 **不能在 PC 端访问存储器时改变存储器的内容** ,但是你可以读。

### USB 复合设备

作为一个 USB 复合设备,你可以 **同时具有上述的几种 USB 通讯接口** (USB 虚拟串口设备、USB 人体工学设备、USB 存储器),然后每一种接口你都可以上报你的数据。USB 复合设备是目前很常见的 USB 设备形式,比如一些高级的 USB 键盘,它可以同时提供键盘和鼠标的接口,而键盘这部分负责普通键盘的功能,鼠标这部分则以轨迹球的形式允许用户手搓键盘上的轨迹球来操作鼠标。或者一些高级的鼠标除了左键、右键、中间滚轮以外,还可以提供各种各样的鼠标键,而这些鼠标键可以通过 USB 复合设备的键盘接口来实现。而且 USB 复合设备还可以包含 USB 虚拟串口的接口,用来提供升级固件等功能。

### USB 集线器(USB Hub)

如果要以 USB Hub 的方式用作芯片与 PC 之间的通讯手段来进行复杂通讯的话,似乎没什么卵用。完全可以通过 USB 复合设备的形式与主机进行通讯。与 USB 复合设备不同的地方之一是 **USB Hub 可以假装自己上面接的 USB 设备被热插拔了** ,从而上报相关信息给 USB Host 使 PC 端上对应的 USB 设备处于被移除的状态。

### 其它 USB 设备(自定协议 USB 设备)

十分不推荐开发这样的设备。虽然事实上,上文列出的设备无法涵盖所有的 USB 设备类型,并且解决这样的问题的办法就是自己发明一套设备,自己开发下位机的上报信息的行为,自己开发对应的上位机的 USB 驱动,但是在 Windows 下开发 USB 驱动 ***需要购买微软的数字签名*** ,给自己开发的 .sys 驱动加上数字签名才能发布、安装。强制安装的结果是 Windows 蓝屏(错误代码 103)。 ***需要不少的费用*** 。

## 2. 串口方式

### 主板自带串口方式

不推荐这种方式。需要 ***上个世纪末的计算机的主板(或者猫)*** 才能有这样的串口设备(在当时被用于上网)。电平是 +12V -6V 的范围,现在的嵌入式设备一般都工作在 3.3v 到 0v 的范围(或者 5v 到 0v 的范围),因此需要一个电压转换器。

### 虚拟串口方式

**这是最流行的方式之一** 。上文我们提到过自己开发 USB 虚拟串口。作为对比,这里我们指的是使用既有的 USB 转 COM 芯片,比如 CP2102 或者 CH343。不少开发板比如 NodeMCU ESP8266-12F 就 **自带了 CP2102 芯片** 用于提供串口通信,而 nanoESP32-C6 开发板则 **提供了 CH343** 用于串口通讯。这两块板子都使用串口方式来下载、烧录程序,而且默认的波特率都是 115200 Hz。类似的还有某盖革计数器 GC-10 也提供了串口输出芯片,用于输出采集到的盖格计数值。

## 3. 声卡方式

PC 上开发设备用于采集麦克风的输入,而嵌入式设备则可以把输出信号的线的接头做成 3.5mm 耳机/麦克风接头。PC 上的设备以「录制麦克风」或者「录制线路输入」的方式接收来自声卡的数据。具有一定的可行性,但总的来讲是一种比较稀奇的通讯方式。
有基于声卡模拟信号输入的示波器软件,需要高刷屏和高采样率声卡,然后从声卡的线路输入接出表笔,使 PC 按示波器的逻辑工作。 **不推荐这样使用** ,因为容易把声卡烧坏,而且本身测量的波形也不准确。

# 总结

- 设计嵌入式程序时应当以 **芯片厂提供的 PDF 为标准** 进行开发。
- 嵌入式开发讲究的是 **充分利用外设资源** 进行数据的通讯或者处理,而不同的 CPU 之间的外设的设计截然不同,轻易不可通用。
- 尽量用好 **异步逻辑** ,通讯时减少 CPU 的参与度。
- 芯片与 PC 的通讯方式多种多样,根据合适的需求来选择合适的通讯协议。

YY菌 发表于 2024-4-26 09:53:51

第三个声卡方式,其实可以改成USB声卡或HDMI/DP声卡的方式,这样就是走的数字信号了嘛,而且还可以自定义成超高采样率的虚拟声卡。

AyalaRs 发表于 2024-4-20 21:53:12

这,章节不能重点突出一下么

tangptr@126.com 发表于 2024-4-21 00:57:23

本帖最后由 tangptr@126.com 于 2024-4-21 01:01 编辑

x86的I/O非常抽象。
MMIO对于真实硬件速度是远快于PIO的,但是对于虚拟机上的模拟硬件却远慢于PIO。
CPU能辅助解码PIO指令,能让虚拟机软件更快地传输数据。
但是CPU不会辅助解码MMIO指令,因为CPU也不知道在捕获到MMIO指令的时候到底是不是在I/O。
AMD-V提供的`Decode-Assist`功能至少会辅助把指令的机器码复制出来,不需要虚拟机软件自己去解析页表再拿指令的机器码。
最后虚拟机软件需要自己去解析并模拟指令实现MMIO。
[高桥巧(Takumi Takahashi)写的KVM的文档](https://takumi.tmfam.com/sphinx-linux-kvm/api/5.html)里说过这么一句:

> Note KVM_EXIT_IO is significantly faster than KVM_EXIT_MMIO.

“端口I/O远快于内存映射I/O。”

0xAA55 发表于 2024-4-25 15:03:40

AyalaRs 发表于 2024-4-20 21:53
这,章节不能重点突出一下么

丢格式了

0xAA55 发表于 2024-4-26 16:55:45

YY菌 发表于 2024-4-26 09:53
第三个声卡方式,其实可以改成USB声卡或HDMI/DP声卡的方式,这样就是走的数字信号了嘛,而且还可以自定义成 ...

这个思路可以,走数字信号就不容易受到信号串扰了,至于采样率的高低还得看你使用的 USB 协议的速度,此处作为瓶颈限制声卡式示波器的采样率(如果波形数据一定需要传输到 PC 上位机的话)。
页: [1]
查看完整版本: 【嵌入式】芯片之间的通讯方式