【友善串口调试助手Serial Port Utility以ASCII形式发送字节数据显示0D的问题】

项目场景：

在做DS18B20温度检测时自己想通过UART串口接收上位机发出的指令来进行相应的操作，但是第一次上板未能成功，所以回过头来逐步排查问题

---

背景描述

自己考虑FPGA与DS18B20数据交互对DS18B20的控制可分为三类：复位、写操作与读操作，每种操作后面还需跟相应具体的指令，如SKIP ROM [CCh]、CONVERT T [44h]属于写操作一类；READ SCRATCHPAD [BEh]属于读操作。若通过串口控制则设置一个两字节的寄存器：

reg [15:0] rx_data_reg;

rx_data_reg[15:8]指示命令种类，rx_data_reg[7:0]指示命令种类下具体的指令。

在UART接收模块设置的数据位是8bit：

module uart_rx_byte (clk, rst_n, rxd, dout, rx_done);
 input clk, rst_n, rxd;
 output reg [7:0]dout;
 output reg rx_done;

dout为UART的rx端接收到的数据，由于需要的寄存器为2字节，所以还需一个移位寄存器：

always@(posedge clk or negedge rst_n)begin 
if(!rst_n)begin
        rx_data_reg <= 0;
    end 
else if(rx_data != rx_data_reg[7:0])begin
        rx_data_reg <= {rx_data_reg[7:0], dout};
    end     
else begin
        rx_data_reg <= rx_data_reg;
    end
end //always end

上述代码的含义为当串口接收到不一样的数据时，从rx_data_reg的右端“塞入”新的字节；

当在串口助手以ASCII形式发送字符“c”时，SignalTap显示如下：

由波形图可知当前FPGA接收到的数据最后1字节是0Dh，不是想要的字符“c”的ASCII码

---

原因分析：

 由于之前验证过UART接收模块的正确性，所以这里考虑应该是串口接收而非rx模块的问题，根据发送数据是字符“c”的ASCII码和接收到的0Dh值可联想到搜索0Dh所代表ASCII的值：

0D代表回车键，接着检查串口助手是否在字符后面多加了回车，发现也没有： 

此时检查寄存器rx_data_reg里的数据为630Dh，63为字符“c”的ASCII码值，说明数据发送成功，只是在末尾加入的回车的操作，此时检查串口助手的设置， 发现软件自动勾选了“当发送后自动添加换行（只在文本模式下有效）”，换行设置默认的是回车：

解决方案：

由以上分析可知，取消默认勾选即可解决ASCII码发送显示多余数据问题：

补充知识：

carriage return意为回车， line feed意为换行，回车只是只回到当前行的行首，换行只是只向下移动一行，组合起来才是我们熟悉的移动至下一行的行首；

在计算机还没有出现之前，有一种叫做电传打字机（Teletype Model 33）的玩意，每秒钟可以打10个字符。但是它有一个问题，就是打完一行换行的时候，要用去0.2秒，正好可以打两个字符。要是在这0.2秒里面，又有新的字符传过来，那么这个字符将丢失。于是，研制人员想了个办法解决这个问题，就是在每行后面加两个表示结束的字符。一个叫做"回车"，告诉打字机把打印头定位在左边界；另一个叫做"换行"，告诉打字机把纸向下移一行。

后来，计算机发明了，这两个概念也就被般到了计算机上。那时，存储器很贵，一些科学家认为在每行结尾加两个字符太浪费了，加一个就可以。于是，就出现了分歧。Unix系统里，每行结尾只有"<换行>"，即"\n"；Windows系统里面，每行结尾是"<回车><换行>"，即"\r\n"；Mac系统里，每行结尾是"<回车>"。一个直接后果是，Unix/Mac系统下的文件在Windows里打开的话，所有文字会变成一行；而Windows里的文件在Unix/Mac下打开的话，在每行的结尾可能会多出一个^M符号。