我在用Spcomm接收10K的数据时，收到的数据中间部分总是不全，而且有部分顺序颠倒，但用Spcomm发送时，用串口调试器则可以收到全部数据。不知为什么？
procedure TForm1.Comm1ReceiveData(Sender: TObject; Buffer: Pointer;
BufferLength: Word);
var
str :string;
i:integer;
begin
str := '';
fillchar(p,Bufferlength,#0);
move(Buffer^,p,BufferLength);
for I := 1 to BufferLength do // Iterate
begin
str :=str + chr(p[i]);
end; // for
Memo1.Lines.Add(str);
end;
procedure TForm1.Comm1ReceiveData(Sender: TObject; Buffer: Pointer;
BufferLength: Word);
var
str :string;
i:integer;
begin
str := '';
fillchar(p,Bufferlength,#0);
move(Buffer^,p,BufferLength);
for I := 1 to BufferLength do // Iterate
begin
str :=str + chr(p[i]);
end; // for
Memo1.Lines.Add(str);
end;
串口通讯误码分析及波特率自适应技术(非典)为讨论方便，只论证1位起始位+8位数据+1位停止位的误码问题
现设：发送方每位传输时间为TCK
接收方每位传输时间为RCK
起始位L(低电平)，停止位H(高电平)
空闲状态为X(高电平)，收据位DX(D0..D7)
通讯数据流为XXXXXLDDDDDDDDHXXXXXLDDDDDDDDHXXXX...
采样一般采用串口通讯公认的“中部三中取二”算法
当收发双方采用事先约定固定波特率串口通讯时，由于双方系统
时钟差异和线路传输时延，将会出现以下3种问题：
1. TCK=RCK时(可以稍有偏差)
发送数据流为XXXXXLDDDDDDDDHXXXXXLDDDDDDDDHXXXX...
接收数据流为XXXXXLDDDDDDDDHXXXXXLDDDDDDDDHXXXX...
故在这种情况下不会出现误码现象。
(别拍砖！这连腹中胎儿都“知道”，不敢“卖弄是非”)
2. TCK<RCK时(发快收慢)
由于串口采用“中部三中取二”算法，故只讨论RCK<=1.5TCK。
A)RCK=1.5TCK(“草图”)
发送数据流为XXXXXLD0D1D2D3D4D5D6D7HX0X1X2X3X4X5X6...
接收数据流为XXXXXLDDDDDDDDDDDDDDDD5DDD6DDDD7HXXXX...
故接收到的数据为111D4..D0，既高3位恒为'1'的“怪事”
B)RCK=1.25TCK(“草图”)
发送数据流为XXXXXLD0D1D2D3D4D5D6D7HX0X1...
接收数据流为XXXXXLDDDDDDDDDDDDDDD6D7HXX...
故接收到的数据为1xD4..D0，既最高位恒为'1'，
次高位不定的“怪事”
所以，可“总结”为最高位恒为'1'，加快接收速率“才是真”
3. TCK>RCK时(发慢收快)
这种现象总会出现“群魔乱舞”的乱码，只有“天知道”。
解决的唯一方法是加快发送速率或降低接收速率。
所谓的“波特率自适应技术”，就是双方为防止以上问题的出现。
发送方特意在发送数据串前，先发送1个字节的“波特率校准码”
一般为大写字母U，即55H(数据流为方波信号)。
当然也有用AAH(数据流也为方波信号)的串口通讯“奇才”。该技术的“精华”为“在线测试方波信号的半周期”。
这样，等到10个RCK后接收数据前，就可“从容地”计算出波特率，
从而达到“波特率自动校准”的目的即波特率自适应技术。
软件实现的方法很多，“遍地都是”。
我按照getit911(Windows转Linux中) 的说法，将缓冲加大，的确解决了问题，但是还是存在误码的情况，增加了些回车符。不知什么原因？