硬件错误带来的问题处理方案

硬件错误

很多时候，就是硬件接口松了，现在的硬件都是挺耐用的，除了那些黑心商家的低温焊锡，廉价的元器件等。有的时候，是用户没安卓驱动，有的时候是用户没接上去，或者中途拔线等，都会导致来自硬件的bug。

在我们软件开发过程中，要分清楚有无系统。是嵌入式开发，还是app开发，还是小程序开发，其实小程序开发就是app的进一步封装来着，只要手机是可以正常使用设备的，小程序也是ok的。这种硬件错误一般都是因为热插拔的问题，也就是pcie和usb等接口设备。

MCU的硬件错误

比如，写了一个USART重定向printf，做一个日志功能。其实就会发现一件事，我们写代码是非常自由的，非常非常爽的。因为我们不论有没有接上去外设总线，我们都能发送，至于读取这个事情，一般都是中断触发。所以，在程序运行过程中，不论总线有没有被插拔，其实都是不影响，mcu的收发的，你说对，mcu只要收发就完事了，而协议考虑的就多了。所以，此时就要有协议回传，就要校验来保证通信是没问题的，不是说，你发送完毕，接收完毕就是OK的，中间线松了也是可以正常通信的。

有系统的MCU

比如rt-thread的smart版本就有一个设备注册和设备查询的操作，这里就封装了文件操作集，open write read那些东西，此时，读写是由返回值的，开发过程中，要注意返回值是真的有用的，是必须要的。对于这些返回状态，可以是一段时间没由回复就为异常，也可以是没有ack，没有片选等诸多方法来判断是否硬件异常。

linux系统

千万不要神话系统了，系统就是为了管理资源和分配任务。有很多总线驱动，这个其实就是上面rt-thread干的事情咯，然后通过vfs来统一接口，所以，应用层开发，就是每次调用文件io的时候，都必须判断返回值是否正常，异常的话，就打印出来，错误是会直接输出出来的，注意咯，标准错误是没有缓冲区的。

FILE *fp;
 
fp = fopen("file.txt", "r");
if( fp == NULL ) 
{
    fprintf(stderr, "Value of errno: %d\n", errno);
    fprintf(stderr, "Error opening file: %s\n", strerror(errno));
}

这样就可以一定程度上解决来自硬件的错误，所以，我们编写驱动的时候，真的要返回有用的返回值和错误提示，不然应用层真的要爆炸。常见还有就是open成功了，但是读写那些出问题了，比如拔线，此时就得判断，然后fclose文件。

系统开发解决方案

我们都上系统了，那么就肯定要上多线程和多进程的，可以在主线程进行人机交互，子线程进行通信和从机操作等，子线程发现硬件错误，就结束线程，返回给主线程或者修改标准位。此时，就可以在主线程中进行对应操作和反馈用户了，可以等待open成功，也可以结束进程。

代码检错机制

我一开始以为python的异常抛出也就是try，是一个不能乱用的东西，是一个类似于debug固件的东西，不能在release版本存在的东西，后面我才知道，因为python是一个高度抽象的东西，它做不到正常通过代码来识别硬件错误。所以，使用try这种错误机制是可以的哦，不要把它当成一个坏东西，就好比python的一个串口，突然拔了，直接就是write错误，而且非常难处理，此时try抛出是一个非常简单好用的方法哦，尤其是开发上位机的时候。

try可以使用，但是建议少用，这个终究是在逃避，而不是真正的解决问题，而且会增加代码量，如果可以还是避免比较好。嵌入式项目中，用这个try简直就是要命了。因为try会带来新的库，生成文件之后体积明显变大了，尤其是开启了异常处理和堆栈追踪的情况下。

注意了，c中的断言是宏，作用预处理阶段哦，所以，后续程序运行过程是没用的，虽然它可以检测和判断，还能查找文件是否存在。