R5F100FE的UART

前几天在调试100FE的时候，碰到一件怪的事情，当UART0和UART1配置为9600时候都正常，

当UART0配置为115200时候，UART0不正常。由此我想到肯定当配置UART1的时候，把

UART0的寄存器给改变了。首先想到的是驱动里面，UART1的某个寄存器忘记修改名字了

（复制UART0的驱动，经常忘记），但是看了一遍，并没有。于是我怀疑是不是波特率计

算有问题，于是把其它UART全部关闭，只保留UART0，然后配置为115200，结果正常。这个

时候，想不通了，于是看手册。首先看到这个：

UART0和UART1用的同一个单元，继续往下看：

通道可以选择时钟，再往下看：

好了，看看驱动里面怎么初始化的：

看见没有，选的时钟，都是一样的，可是我把UART1的时钟修改，还是不行，继续看底层驱动：

根据前面得寄存器说明，可知，这里把其它时钟的分频比也修改了，因此修改为：

这次在调试，没有问题。开始驱动写成那个样子，是我没有理解他的时钟那章说明，才导致后来的错误。

不过总算是解决了。。。。。。。。。。

2017.12.25

        今天在调试程序，一直习惯了用工具去DEBUG，但是感觉非常的不方便，尤其是在联合调试的情况下，

如果是远程技术支持，现场debug，几乎不可能。于是做了一个log机制。思路很简单，就是为UART1单独

开辟了一个PIPE，然后用hook函数勾出交互的UART0的收和发数据，放进PIPE中，main里面判断PIPE非空

就打印。

        调试当中发现UART1会出现答应log不完整情况，这个时候必须重启设备，否则UART1不接任何指令，

设备貌似“死了”。分析思路如下：

一、首先我想到的是，UART1的发送中断丢失，导致UART1的资源信号量“死锁”，因为我是根据UART1

串口发送完成自动清除信号量。因此我在底层驱动加了一个超时清除信号量的机制。发现问题还是没有解决。

二、这个时候，我把LOG打印功能关闭，发现问题“消失”。

三、于是我查看LOG的打印逻辑，发现里面有一个出队频繁关闭-打开总中断的过程，于是我想，会不会是

这里的问题？于是把这里的逻辑修改掉，发现问题解决。

       由此，我得出结论，在串口中断发送期间，如果频繁的操作总中断位，可能会把UART口干死，这种情

况只是基于我上面的分析过程而出的结论，不一定准确。如果有幸，您也遇到了同样的问题，并且找到了原

因及解决方案，不妨给我留言，谢谢。

2018.02.11

今天又看了下代码逻辑，通过下面的宏，屏蔽掉入队函数的atom属性：

//queue_service入队函数是否加锁

#define     QUEUE_SERVICE_ENQUEUE_IS_ADD_LOCK       0

而入队函数是在UART的中断里面调用的，难道是因为我在总中断里面频繁

操作总中断位的问题？