[Win32] Win32 RS232讀寫

win32api所提供的serial port读写方式有分两种
同步方式: 读够了指定的字元才会返回(执行绪不会先返回去做其他工作)
非同步方式: ReadFile/WriteFile函式被呼叫之后,执行绪会先返回,win32api自动帮你新增一个执行绪在背景做IO工作,你必须去检查OVERLAPPED结构的hEvent物件是否已被触发,才知道 背景IO工作是否已经结束

标准做法是先用WaitForSingleObject去检查hEvent物件,如果触发了,才使用GetOverlappedResult去检查执行的结果(IO工作结束后有很多种结果,读取到的字元可能介于0~N个你指定的字 元,可能是顺利读完之后返回或是因为timeout被迫先返回而实际读取字元=0或是


win32做IO的方式(serial port/档案读写/和其他IO都适用)会受到timeout的影响,否则同步方式很容易会锁死,如果是在XP系统,逾时机制的预设值应该都是 0,也就是不使用timeout机制
你在开启通讯埠使用CreateFile函式的时候并没有指定要用overlapped非同步方式去执行,我也没看到你有去设定timeout值,所以你的IO执行绪是以同步方式在跑,overlapped结构 和设定等等动作是白做的,因为ReadFile根本不会去使用

因此你的程式应该是会锁死住,一直等到ReadFile读够了256个bytes才会返回...,我建议你要把一些事情做好,比较容易debug

1. 开启通讯埠之后,把UART晶片的缓冲区一律清除掉,否则程式上一次执行所传送的资料仍然会在缓冲区里面等着被读取(至系统记忆体内),事实上一般白牌的 UART晶片的接收缓冲区大约是16到256个bytes,很容易就被塞暴,因此windows事实上在背后帮你提早接收了这些资料,并自行保管,等到你去读取serial port的时候,它 就直接把资料给你(系统记忆体的复制动作),所以你会发现写入serial port返回的时间跟baudrate以及字数有相关,但是读取serial port却是""瞬间""完成,即使你 的baudrate很低...我把这个称之为windows所提供的""软体缓冲区"",实测结果是这个软体缓冲区可以放超过1MB以上的资料(虽然被灌暴的时候,win32API函式 有检查overrun的事件和机制,也可以警告你,但是资料仍然被存放入软体缓冲区里面,一个byte都没少也不会被丢掉),所以开启/关闭通讯埠的动作要确实,该清空 /reset的动作都要做,不然改过的新程式码去读取软体缓冲区里面的旧资料,改对了还是可能产生错误结果

2. 因为win32api提供了timeout返回的机制,所以你可以没事就去读取看看,大不了就是没资料可读而已,这种方式特别适合资料固定在流动,但是资料量不定的情况(而且最新资料 可以取代旧资料),另一种方式是先检查接收缓冲区之后,知道了有无字元和实际数量,然后才去做读取动作,这种方式如果出了问题比较好debug