我一直在做单片机开发，不知道Linux是怎么一种调试方式。
以前我也是用比较Low的办法，去调试程序的BUG，比如借助数码管，屏、UART，甚至是LED灯，因为有些产品并没有把UART的接口引出来。
这些办法，其实对于复杂点的产品，调试效率是极低的，特别是指针异常的情况。
我对在线仿真调试的渴望和认知，是几年前，我在做车载产品，用到了升迈的GM81xx方案，领导让我把在线仿真调试搭建起来。
忘记当时是用哪个开发工具了，反正不是Keil。
资料贼少，也没支持，搞了我几个星期，都有点想发火了，然后跟领导说不搞在线仿真行不行，我直接写程序还更快一点。
领导说不行，也没说原因，我也没鸟他，边写程序边研究，现在还有当时的程序版本记录。
当时我非常不理解他，为什么非要死磕在线仿真功能，又不是刚需，没有这功能也能写程序开发产品啊，是不是看我不爽，故意给我找茬？
直到后面，我接触到一些复杂的项目，碰到了一些棘手的BUG，才理解他的用意，理解在线仿真调试的重要性。
比如说我们无际项目特训营的项目3和6的菜单系统。
在菜单系统跑起来之前，先初始化好，把各种子菜单通过链表的方式关联起来。
当我们要切换菜单的时候，就不用记住要跳转到哪个菜单了，直接把系统菜单的指针，指向当前菜单的子/父级菜单地址即可。
这种方式，哪怕是几十上百个子菜单，管理起来也不会乱，更方便，灵活。
但用链表这种方式，调试阶段出现BUG的时候比较头痛，因为涉及结构体、指针比较多，如果没有STlink在线仿真看指针地址的话，一个BUG可能要搞一天，如果直接用在线仿真调试看地址，可能几分钟就搞定了。
所以，一旦享受过在线硬件仿真调试的，很难再接受用UART去调试，除非硬件上不支持。
USART用的也多，如果是用于调试目的，一般会配置为UART模式。
所以USART和UART对于调试来说，可以理解成是一样的。
我觉得有必要先了解下，这几种协议的区别：
| 特性/协议 | UART (通用异步收发器) | USART (通用同步/异步收发器) | IIC (Inter-Integrated Circuit) | SPI (Serial Peripheral Interface) |
| 同步性 | 异步通信 | 支持同步和异步通信 | 同步通信 | 同步通信 |
| 连接线数 | 2线（Tx和Rx） | 2或3线（Tx、Rx和可选的RTS/CTS） | 2线（SDA和SCL） | 4线（MOSI、MISO、SCLK和SS） |
| 波特率 | 可变，由软件设置 | 可变，由软件设置 | 可变，由软件设置 | 可变，由软件设置 |
| 通信速度 | 慢到中等 | 可变，支持高速通信 | 慢到中等 | 高速通信 |
| 错误检测 | 奇偶校验 | 可配置奇偶校验或无校验 | 无内置错误检测，可使用CRC | 无内置错误检测 |
| 硬件复杂性 | 简单 | 较复杂，有额外的硬件支持 | 简单 | 较复杂 |
| 多主设备支持 | 不支持 | 支持 | 支持 | 不支持 |
| 应用场景 | 串口通信、调试接口 | 微控制器间通信、RS-232/RS-485接口 | 低速设备通信，如传感器、EEPROM | 高速设备通信，如SD卡、LCD显示屏 |
IIC和SPI不用于调试，我个人的心得是，调试需要通过电脑串口去看数据才方便，电脑有串口，但是没有IIC和SPI接口(或许有IIC，SPI的串口转接器，但多此一举，还不如直接用UART)。
还有一点就是距离的问题，串口加个485，距离能做得很远，方便调试那种距离比较远的设备。