EEPW论坛

感谢香蕉派，感谢源创，感谢二叔科技，感谢球猫，感谢王师傅，感谢表妹，感谢余璇，感谢EEPW，感谢CCTV，感谢小撸，感谢.............................

话说香蕉派到手之后一直各种忙，装了系统，测试一下后就一直没时间弄。

看二叔各种文章疯狂高产，顿觉自己不够努力啊。

什么装系统，VNC，TFT之类的二叔都写完了，再写就没重复创造轮子了，于是合计研究研究香蕉派的UART吧

来一张图，香蕉派引出了4组UART

UART0: 用于调试, 位置在J11需要从J12 借用GND 共地

UART2 和UART3: 从26pin 双排针上引出

UART7: 从J12 双排针引出

连接UART0与电脑，使用Putty登录，就可以登录香蕉派，对系统进行各种管理。

写了一个程序，打开UART0，也可以正常与PUTTY通信进行发送和接收。

可是在连接UART2，UART3, UART7的时候却遇到一些麻烦。

写了个程序与电脑交互，结果发现以下特征：
1）UART2：/dev/ttyS1，接收可用，发送无效

2）UART3：/dev/ttyS2，接收正常，发送正常

3) UART7：/dev/ttyS3，接收无效，发送正常

苦思不得其解。

怀疑是自己程序的问题，于是安装了minicom进行测试，

minicom -b 115200 -o -D /dev/ttyS1

发现问题依旧。

（这里我偷懒操作，回头细说）

到底是啥问题呢？我陷入到婶婶的思考中。。。尽管已经是凌晨2点了。

想来想去，尤其想不明白，为啥UART0和UART3正常？

因为，软件，连线，以及测试方法，明明都是相同或者相似的。

于是猜测，是不是硬件配置不同。

于是查看script.bin关于uart的部分：

[uart_para0]
uart_used = 1
uart_port = 0
uart_type = 2
uart_tx = port:PB22<2><1><default><default>
uart_rx = port:PB23<2><1><default><default>


[uart_para2]
uart_used = 1
uart_port = 2
uart_type = 4
uart_tx = port:PI18<3><1><default><default>
uart_rx = port:PI19<3><1><default><default>
uart_rts = port:PI16<3><1><default><default>
uart_cts = port:PI17<3><1><default><default>


[uart_para3]
uart_used = 1
uart_port = 3
uart_type = 2
uart_tx = port:PH00<4><1><default><default>
uart_rx = port:PH01<4><1><default><default>

[uart_para7]
uart_used = 1
uart_port = 7
uart_type = 2
uart_tx = port:PI20<3><1><default><default>
uart_rx = port:PI21<3><1><default><default>

可以UART7明明被配置成2线的啊。

看到这里已经困的睁不开眼，睡觉。

第二天被抓劳力一整天，回来看二叔发来好消息，说UART都是可以正常用的。

于是怀疑和二叔系统镜像不同，怀疑和二叔kernel版本不同，怀疑和二叔script.bin配置不同。

二叔发来配置文件，一比，略有差异，但是都和uart无关的。

意欲升级kernel，学习了半天，感觉很麻烦，还害怕把系统折腾坏重装。

于是重新学习二叔的文章，看看差异在哪里。

传送门：
【跟二叔玩bananapi】之四：你究竟有几个好串口，minicom篇

http://forum.eepw.com.cn/thread/265043/1

结果发现二叔与我操作的差异所在，二叔是打minicom命令，然后选择和配置串口
我则是直接进入minicom同时打开串口。

而最重要的是，二叔配置串口的时候，都关闭流控！！

于是关闭流控，重新测试，串口都如预料的方式工作。

不过，我始终想不明白，为何UART7配置成2线连接，怎么还默认打开流控呢？

不管如何，总算都好用了。

人说，拳不离手曲不离口，古之人诚不欺我！
些许年的安逸，果然业务生疏了。否则，早该想到的。

设置流控的代码

Setting Hardware Flow Control
Some versions of UNIX support hardware flow control using the CTS (Clear To Send) and RTS
(Request To Send) signal lines. If the CNEW_RTSCTS or CRTSCTS constants are defined on your
system then hardware flow control is probably supported. Do the following to enable hardware flow
control:
options.c_cflag |= CNEW_RTSCTS; /* Also called CRTSCTS */
Similarly, to disable hardware flow control:
options.c_cflag &= ~CNEW_RTSCTS;

感兴趣的朋友不妨试试看，我比较懒惰，就不试了。

再次对二叔表示诚挚的谢意！

二叔威武！！