基于1553B总线的ARINC 661指令传输（二）--HT-6306板卡提供的API性能测试

来自www.hoopercao.com

 

昨天怀疑是自己程序问题，确实，我没有在发送完数据之后做任何的状态字检测。

按照1553B的要求，消息尽可能的短（最多一条64B），并在很小的时间段能响应BC的操作，这也是实时系统的特点。BC在发送完之后，会收到来自RT的一个状态字回复，这个状态字包含了BC刚刚发送的消息的接受情况，一旦BC收到这样的消息，则应该检验里面的状态字，并决定是否重新发送。

对于现有的板卡，说明书中也未提及到有关出错的问题，是否板卡自动检测状态字并自动重发不得而知。此板卡不但提供RT状态字，同样提供板卡和主机（PC）传输的状态字，有一套自己定义的状态字涵义表，通过此表可以知晓这则消息是否得到了RT的响应，结合RT状态字即可判断消息是否被RT接受等等。

于是，我加入了状态字检测的代码，包括检测自定义的板卡到主机的状态字以及RT返回的1553B标准状态字。

但是结果让我刚到很奇怪：

BC不断发送200个数据包，RT只收到一半不到（72个），但是只要BC发送消息出去，RT能够很快的响应，并将RT状态字也能立刻返回，而且从未出现错误，自定义状态字也是正确。这表明，作为RT的板卡已经接受到了BC发来的消息，并经过校验正确后返回一个正确的确认消息给BC，但是RT端的程序为何没有收到？看来只有一种可能了，那就是RT端代码不够简洁。

于是我将RT端的主机代码只保留RT_HaveMsg()和RT_ReadMsg()两个函数，对于接受到的数据也不做任何处理，但是仍然不能接受到所有的数据。应该是RT在检测消息和阅读消息时出了问题吧，但是这都是板卡提供的函数，以DLL形式存在，对方也不提供源代码，无法进行修改。

为了证实确实是函数库的效率，我再次打开板卡的说明书，阅读了板卡缓存区的定义，发现它是使用一个共用的数据缓冲区，板卡可以往里面写数据，主机通过此缓冲区读数据，同时，它使用了循环队列的方式往该缓冲区里写数据，也就是说存在一个头指针和尾指针，指针一旦超过缓冲区末端则立刻将其改为缓冲区首端，通过判断队首队尾指针来判断是否有消息。进一步查看地址，发现缓冲区大小为0x1000，即4KB，一条消息（实际上是板卡自己定义的一个所谓的“信息标识”数据结构，里面包含一个指向真正数据的指针）占用32B，所以一共可以存放128条消息。

这样就不难解释为何我发送200条，显示成功，而RT程序只收到72条消息了：循环队列一共可存放128条，我一下子发了200条，缓冲区必定溢出，这样RT板卡虽然接受到了数据，但是RT主机上的程序却只收到（200 mod 128=72）个消息了。

至此，我终于得知了丢失数据包的原因，原来版卡的传输速度还是很好的，而且稳定性也很强，内容出错的概率基本为0。可是这不代表RT端的主机程序能全部读取到这些数据，由于读取缓冲区使用的是板卡提供的函数RT_ReadMsg()，估计是这个函数效率太低了，可是这是无法改变的现实。。。

 

经过这一系列的事件，也让我对我国国防企业技术服务的印象大打折扣。。