CN101179790A - 一种移动终端处理器之间的串口通信方法 - Google Patents
一种移动终端处理器之间的串口通信方法 Download PDFInfo
- Publication number
- CN101179790A CN101179790A CNA2007101130888A CN200710113088A CN101179790A CN 101179790 A CN101179790 A CN 101179790A CN A2007101130888 A CNA2007101130888 A CN A2007101130888A CN 200710113088 A CN200710113088 A CN 200710113088A CN 101179790 A CN101179790 A CN 101179790A
- Authority
- CN
- China
- Prior art keywords
- packet
- processor
- value
- data
- mobile terminal
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Landscapes
- Communication Control (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
本发明公开了一种移动终端处理器之间的串口通信方法,第一处理器发送由二进制数据组成的数据包,包含指令、校验值以及与该数据包唯一对应的句柄值;第二处理器接收第一处理器发送的数据包,对接收到的数据包进行校验;如果校验值一致,则第二处理器向第一处理器返回一个应答包,所述应答包中包含所接收到数据包的句柄值,如果校验值不一致,则放弃接收该数据包直接搜索下一个数据包;如果第一处理器在规定时间内没有收到应答包,则重新发送所述的数据包,重新发送的数据包内有一个重发包的标识值,本发明支持全双工通信方式,大大提高了处理器之间通信效率和可靠性。
Description
技术领域
本发明属于移动终端技术领域,具体的说是涉及到移动终端中两个处理器之间进行串口通信的方法。
背景技术
在当前的移动终端产品中经常集成有两个以上的处理器,处理器之间通常使用串口连接以进行信息交互来实现某些功能。交互使用的通信协议通常有两种,一种为AT命令,另一种为串口复用协议如GSM 07.10等。串口通信并非完全可靠,因为通信受到干扰、接收端休眠或接收缓冲器溢出等原因,传输的数据时有丢失。
为了保证数据可靠传输,目前串口通信常用的技术方式是发送端发送完AT命令后通常会等待接收端发回确认信息。只有在收到确认信息后发送端才会发送下一条AT命令。而接收方需要对收到的数据进行解析后才能发回确认信息,这就造成了传输效率低下。
串口通信常用的技术方式除了传输效率低下的缺点,还有另一个缺点就是接收方确认信息容易发生整体错乱,因为所有AT命令的确认信息都一样。如果第一次发送的AT命令没有收到确认,发送端会重发该命令。发送端重发AT命令后收到的第一条确认信息很可能是针对第一次发送的,然后发送端发送下一条AT命令收到的确认信息很可能是对应上一条重发的AT命令。这就造成了确认信息的整体错乱。而且重发时,接收端有可能收到两条重复的AT命令,对其进行判断和处理程序也很复杂。
保证AT命令可靠传输的另一种方法是打开回显,所有发送的数据会全部通过串口返回,发送端据此判断该次发送是否成功。这种打开回显的方法无疑使通信量倍增,且增加了软件实现的复杂度。
AT命令为字符串,使用固定的开始与结束符,因此需要处理转义字符。其最大问题是处理速度慢。最长的AT命令长度超过1K字节,解析时间很长。用户与移动终端设备进行人机交互时,如果等待操作完成的时间过长,将会降低用户的满意度。而且因为需要对字符串进行解析,解析出错的机率较高,增加了系统的风险。
在实现数据业务功能时,AT命令并不适合。这时就需要使用串口复用协议如GSM 07.10,在同一个串口上实现多种应用。此时数据将组帧发送,每个应用对应一个通道,AT命令与网络数据可同时传输。但GSM 07.10协议需要考虑到各种应用,其实现比较复杂,会造成系统额外的负担。
GSM 07.10只适合比较稳定的串口通信。其数据帧头包含数据长度,但其校验数据在数据帧的最后。如果数据长度信息发生错误,则接收端需要将错误长度的数据全部接收后才有可能发现错误,这中间可能包括很多个数据帧了。这种情况可能造成大量数据丢失,系统很长时间恢复不过来。虽然这种情况不经常碰到,但如果串口受到干扰系统长期运行不可避免会出现数据丢失的严重问题。
基于此,该发明需要解决的问题就是针对上述串口通信的缺点,提出一种稳定可靠并且传输效率高的两个处理器之间串口通信的方法。
发明内容
本发明的目的在于提供一种移动终端处理器之间的新的串口通信方法,使用二进制数据传输代替了字符串的AT命令,同时支持串口复用,支持全双工式异步收发。
为了实现本发明的目的,本发明采用以下技术方案予以实现:
一种移动终端处理器之间的串口通信方法,包括以下步骤:
第一处理器发送由二进制数据组成的数据包,包含指令、校验值以及与该数据包唯一对应的句柄值;
第二处理器接收第一处理器发送的数据包后进行校验;
如果校验值一致,则第二处理器向第一处理器返回一个应答包,所述应答包中包含所接收到数据包的句柄值,如果校验值不一致,则放弃接收该数据包直接搜索下一个数据包;
如果第一处理器在规定时间内没有收到应答包,则重新发送所述的数据包,重新发送的数据包内有一个重发包的标识值。
在本发明的技术方案中,还具有以下技术特征:所述的数据包和应答包还包含优先级值,所述应答包的优先级值为最高值,所述的应答包只有10个字节。
在本发明的技术方案中,还具有以下技术特征:数据包中数据区段为字节型二进制数据,可以是AT命令、数据结构或者上层应用传来的数据。所述的数据包的头部有整个数据包的信息长度值,结尾处有校验值和结束字节,数据包的最大长度为512字节。所述的校验值是对数据包长度的低8位值和高8位值的和取反。
在本发明的技术方案中,还具有以下技术特征:第一处理器和第二处理器均有三种先进先出队列,分别为发送队列、已发送队列和接收队列,其中发送队列用于缓存上层应用送来的数据包和响应收到该数据包的应答包,已发送队列用于存放发送后的数据包,接收队列用于存放接收到的数据包。
每一项优先级有一个发送队列和一个接收队列,各项优先级内的队列项采用动态方式分配内存。
已发送队列只有一个,用于发送失败后把该数据包重新放回原优先级对应的发送队列中等待发送。
与现有的串口通信技术相比,本发明的优点和积极效果是应用二进制数据代替字符串来标识指令加快了指令的解析和处理速度,极大的提高了处理器之间通信的速度与可靠性。
附图说明
图1是本发明的流程图;
图2是本发明的数据传输过程示意图;
图3是本发明的数据包结构图。
具体实施方式
下面结合附图和实施例对本发明作进一步详细的描述。
如图1和图2所示,手机中两个处理器之间通过串口通信,采用二进制数据代替通常使用的字符串,通信方式可以是全双工方式,即两端可以同时开始数据包的发送与确认,不必等待第一个数据包确认后再发送第二个数据包,应用二进制数据以及全双工的通信方式提高了串口通信传输效率,其通信流程如下:
步骤101:第一处理器发送数据包,该数据包中包含指令、校验值以及与该数据包唯一对应的句柄值。
数据包中有与此一一对应的一个句柄值,不同的数据包句柄值不同。数据包中还可以包括优先级的数值,根据数据包的紧急程度分配一个优先级数值,处理器的发送队列中,优先级高的数据包优先发送。优先级可以分为很多级别,在实施例具体应用时,4级优先级区分为优选方式,其中1级为最高级,4级为最低级。
步骤102:第二处理器接收第一处理器发送的数据包,并对接收到的数据包进行校验。
校验的方法有多种,实施例中具体选择的校验方法是对第二处理器对接收到的数据包长度的低8位值和高8位值的和取反,然后与数据包内的校验值进行比较。
步骤103:判断校验值是否一致。
第二处理器计算出的校验值与数据包内的校验值进行比较,如果两个值是一致的,则说明第二处理器成功接收到了第一处理器发送的数据包。如果两个值不一致,则说明第二处理器没有成功接收到数据包,就丢弃该数据包,返回到102步骤,即第二处理器继续搜索,准备接收第一处理器发送的数据包。
步骤104:判断结果为是,则返回应答包。
第二处理器为了将成功接收数据包的信息通知给第一处理器,需要及时向第一处理器返回一个应答包,应答包中包含与所接收到数据包唯一对应的句柄值,从而与接收到的数据包对应起来,并可以用于区别每一个不同的应答包。返回应答包这一步骤是必须的,用于确定接收端是否接收到正确的数据包,以确保通信的可靠性。
应答包的发送必须要及时,因此应答包的优先级设置为最高,而且每一个应答包只有10字节,传输时间很短。
步骤105:判断第一处理器是否在规定时间内收到句柄值一致的应答包。
第一处理器内置有一个定时器,在规定的时间内判断第一处理器是否接收到应答包,而且继续判断应答包是否与发送数据包的句柄值一致。
步骤106:判断结果为是。
如果第一处理器接收到正确的应答包,说明数据包的成功发送已经得到确认,就把该数据包从已发送队列中删除,同时释放内存。
步骤107:判断结果为否。
如果第一处理器没有接收到正确的应答包,则重新发送数据包,并且数据包中带有重发包的标识。
该步骤为数据包的重发机制,当发送方在规定时间内收不到应答就会重发该数据包以保证处理器之间通信的可靠性。
由于第一处理器所发送的每一个数据包不同,其字节大小不同,因此所占用的传输时间不一,如图2所示,两个处理器一方为发送端,另一方为接收端,发送端连续发送数据(1)、数据(2)、数据(3)等若干个数据包,而接收端成功收到数据后,一一返回对应的应答包,即应答(1)、应答(2)、应答(3)等,数据包与应答包用斜线来表示传输所用时间,斜线斜度越大表示传输时间越长。数据包和应答包后括号中的值为包的Handle值即句柄值,两端处理器分别对数据包排号,每一个数据包都有一个返回的应答包,且应答包Handle值与其对应的数据包的Handle值相同,应答包只有10个字节,便于接收到数据包后及时确认。
两端处理器各有三种先进先出队列:发送队列、已发送队列和接收队列。为了提高发送效率,每一个优先级级别都有一个发送队列和一个接收队列,应用每一个优先级一个队列的方式,减少了寻找最高优先级且最早到达数据包的搜索时间。4种优先级则有4个发送队列和4个接收队列,其中已发送队列只有一个。所有队列项全部采用动态方式分配内存。
发送队列用于缓存上层应用送来的数据包和因为收到数据包要回的应答包,队列中每一项除了数据包数据外还要包括优先级、已发送次数信息。所有的应答包均存在最高优先级的发送队列中。串口发送数据时按优先级从高到低查找各发送队列。找到未空队列的第一个包,发送结束后如果该包不是应答包就将该包放入已发送队列。
上层应用调用发送API函数后只是将相关数据包放入发送队列中,并不意味着相关数据包会被立即发送。一个包在发送过程中是不能被打断的,如果当前有另一个包正在发送,则必须等当前包发送完,才会发送新的包。
已发送队列用于发送失败时重发,其中各数据包按发送时间排序。有定时器定时查询该队列,如果已发送的数据包在规定时间内没有收到应答,就会将该数据包重新放回发送队列,仍使用原优先级等待发送,但将包的最后一个字节改为重发包的标识。如果数据包超时且已发送过限定次数,就会向上层应用发回出错提示。
为了及时应答,所有应答包为同一优先级都为最高优先级,故收到的应答包与已发送的数据包应该是同一顺序。第一处理器收到应答包后会查询已发送队列的第一项,如果Handle值相符,说明发送成功,会将此项从已发送队列中删除,内存同时释放。如果Handle值不符,则说明已发送队列中第一项数据包接收端没有收到或是返回的应答包丢失,无论何种情况,系统会立刻将该数据包转入发送队列进行重发。然后继续查找已发送队列新的第一项的Handle值,如果不符,继续将该项转入发送队列重发,直到找到匹配的Handle值后将该项删除、释放。至此应答包的处理结束。
第二处理器接收到数据包后,如果该包最后一个字节不是重发包的标识,则会将该包的Handle值与校验值保存在一个数据结构中。数据结构只保存最近150个包的信息。如果收到的数据包最后一个字节为重发包的标识,说明该包为重发包,则需要在上述数据结构中查找,如果发现Handle值与校验值均匹配,则说明此包为重复包,直接丢弃既可。如果在数据结构中没有找到匹配的值,则仍然需要将该数据包的Handle值与校验值保存在上述数据结构中。
第二处理器接收到的所有数据包,即使是重复包,都需要及时返回应答包,即把应答包放入最高优先级的队列。所有非重复包根据优先级不同放入不同接收队列。第二处理器收到数据包不意味着指令会被立刻执行,第二处理器会根据情况按优先级从高到低依次处理。
每一个数据包的结构格式如图3所示。首先,以二进制数据代替字符串来标识指令大大的加快了指令的解析和处理速度。其次,每次都要传输一个完整的数据包,其头部有整个数据包的长度信息,结尾处有校验数据和结束符,很好的保证了信息的可靠性。在该数据包中,并不是以结束符来判断数据包是否结束,数据包中可以直接包含任何二进制数据,不再需要将数据转换为字符,这也加快了处理速度。
数据包的第1字节用于标识包的开始,每一个数据包的第1字节都是相司的,实施例中取值为0xAA,当数据包出现错误时可以借此快速的找到下一个数据包的开始。
数据包的第2、3字节为包的长度,其中第2字节(Length LSB)为长度的低8位,第3字节(Length MSB)为长度的高8位。这里的长度是指含包头、指令、句柄、数据、校验值、结束符的一个完整数据包的长度,单位为字节。如果不包含任何数据,数据包的最小尺寸为10字节。数据包的最大尺寸理论上可以到64K字节,但一次传输64K字节时间太长且容易出错,并不现实。一个数据包在传输过程中是不能中断的,如果低优先级数据包过大、传输时间过长就会影响到下一个高优先级数据包传输的实时性。考虑到即使是高优先级的指令,几十毫秒的延迟也是可以接受的,因此包的最大长度定为512字节。
校验值Checklen用于校验数据包的长度信息是否出错,计算方法为对第2字节与第3字节的和取反。如果发现出错,则立刻放弃该包的接收直接向下搜索下一个包的开始。校验值的应用减少了系统占用,且避免了因一个错误的包长度导致串口一直在等待接收结束,中间有可能会错过很多数据包的这种情况的发生。
句柄值Handle为数据包的一个字节,不同的数据包有不同的Handle值,只有重发的数据包会使用相同的Handle值,该字节可以用于出错重发和过滤收到的重复包。第一处理器发送完数据包后如果在规定时间内没有等到应答就会重发该数据包。而第二处理器有可能只收到了重发的数据包,也有可能收到了两个重复的数据包,这就有可能造成系统错误。解决的方式是第二处理器记录最近收到的150个数据包的Handle句柄值与Checksum校验值。可以据此两个值判断接收到的数据包是否为已经接收过的重复包,如果是已经接收的数据包,则将收到的重复包抛弃掉。而应答包的Handle值与其对应的数据包的Handle值相同。对于重复的包也需要返回应答。
Priority值是标明该数据包的优先级,对于每一个数据包,可以根据需要分为多级的优先级,通常4级已足够,高优先级的数据包会被发送端优先发送并被接收端优先处理。
Module模块值表明数据包所含指令的所属模块属性,如呼叫、短消息还是数据业务等,便于通信指令的管理、扩展。如果该值为0xFF,则表明此包为应答包,用于应答收到的数据包。
Command为具体的指令,如发起呼叫、接听呼叫等,不同的模块(Module)可以有相同的Command值。如果Module值为0xFF,即此数据包为应答包,则Command的值无意义。此结构支持的指令最多可以有254*255个。
Data为字节型二进制数据,数据内容不受任何限制。串口收到数据后会根据包头中的长度信息来判断包何时结束,而不是根据结束符来进行判断。如果不需要,此数据段也可以完全被省略掉。
Data中保存的可以直接为AT命令、数据结构,或是上层应用传来的数据包。如果为数据结构则省掉了AT命令的解析过程。但需要注意两端处理器数据存储方式可能会不同。如一方为Big Endiean,另一方为Little Endiean。串口传输的数据格式可根据需要而定,但尽量使用Big Endian格式进行数据传送。因此在发送完整的数据结构时某一个处理器端在发送前与接收后可能需要进行Big Endiean与little Endiean之间的数据格式转换。同时需要注意两端处理器同一种结构占用字节数可能不同,尤其需要注意枚举变量的长度。
字节Checksum用于纠错,是包中除Checksum和结束符外所有字节值相加所得到的。接收方收到指令后将据此字节判断在传输过程中是否有数据错误发生。
结束符0x7E/0xE7有两个作用,一是用于纠错,二是用于判断该数据包是否为重发包。其中0x7E为始发包,0xE7为重发包。第二处理器收到重发包后将触发重复包过滤流程,避免了对每一个数据包都进行过滤,从而减少了系统消耗。
该数据包的数据格式中0xAA字节、Length LSB、Length MSB、Checksum和结束符均由串口驱动层添加、控制。接收时所处理的数据由Handle字节开始,因为Data区数据包含各种数据结构,需要4字节对齐,因此Handle至Command字节必须占用4个字节。Data区4字节对齐后可以方便的将其强制转化为各种数据结构,否则就会出现问题。
在实际使用时,应用115.2kbps串口,两端处理器均为ARM7的系统中进行实测。采用本发明的技术方案可以在1秒内送达200个10字节的数据包。而如果使用AT命令,则1秒内只能发送不到10条最小指令。如果数据包与AT命令数据量加大,则差距慢慢减小。但无疑本发明适合应用在移动终端两个处理器之间进行通信传输,能够大大的加快传输速度,进而加快整个系统的响应速度,并且其查错机制也大幅增加了传输的可靠性。
Claims (10)
1.一种移动终端处理器之间的串口通信方法,其特征在于包括以下步骤:
第一处理器发送由二进制数据组成的数据包,包含指令、校验值以及与该数据包唯一对应的句柄值;
第二处理器接收第一处理器发送的数据包,对接收到的数据包进行校验;
如果校验值一致,则第二处理器向第一处理器返回一个应答包,所述应答包中包含所接收到数据包的句柄值,如果校验值不一致,则放弃接收该数据包直接搜索下一个数据包;
如果第一处理器在规定时间内没有收到应答包,则重新发送所述的数据包,重新发送的数据包内有一个重发包的标识值。
2.根据权利要求1所述的移动终端处理器之间的串口通信方法,其特征在于所述的数据包和应答包还包含优先级值。
3.根据权利要求1和2所述的移动终端处理器之间的串口通信方法,其特征在于所述应答包的优先级值为最高值。
4.根据权利要求3所述的移动终端处理器之间的串口通信方法,其特征在于所述的应答包只有10个字节。
5.根据权利要求1所述的移动终端处理器之间的串口通信方法,其特征在于数据包中数据区段为字节型二进制数据,可以是AT命令、数据结构或者上层应用传来的数据。
6.根据权利要求1所述的移动终端处理器之间的串口通信方法,其特征在于所述的数据包的头部有整个数据包的信息长度值,结尾处有校验值和结束字节,数据包的最大长度为512字节。
7.根据权利要求1和6所述的移动终端处理器之间的串口通信方法,其特征在于所述的校验值是对数据包长度的低8位值和高8位值的和取反。
8.根据权利要求1所述的移动终端处理器之间的串口通信方法,其特征在于第一处理器和第二处理器均有三种先进先出队列,分别为发送队列、已发送队列和接收队列,其中发送队列用于缓存上层应用送来的数据包和响应收到该数据包的应答包,已发送队列用于存放发送后的数据包,接收队列用于存放接收到的数据包。
9.根据权利要求8所述的移动终端处理器之间的串口通信方法,其特征在于每一项优先级有一个发送队列和一个接收队列,各项优先级内的队列项采用动态方式分配内存。
10.根据权利要求8和9所述的移动终端处理器之间的串口通信方法,其特征在于已发送队列只有一个,用于发送失败后把该数据包重新放回原优先级对应的发送队列中等待发送。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2007101130888A CN101179790B (zh) | 2007-11-03 | 2007-11-03 | 一种移动终端处理器之间的串口通信方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2007101130888A CN101179790B (zh) | 2007-11-03 | 2007-11-03 | 一种移动终端处理器之间的串口通信方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101179790A true CN101179790A (zh) | 2008-05-14 |
CN101179790B CN101179790B (zh) | 2011-02-02 |
Family
ID=39405839
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2007101130888A Expired - Fee Related CN101179790B (zh) | 2007-11-03 | 2007-11-03 | 一种移动终端处理器之间的串口通信方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101179790B (zh) |
Cited By (19)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101945155A (zh) * | 2010-09-03 | 2011-01-12 | 展讯通信(上海)有限公司 | 实时抓取终端调试信息的方法及终端设备 |
CN101764730B (zh) * | 2009-12-18 | 2011-12-21 | 航天东方红卫星有限公司 | 一种can总线数据传输方法 |
CN102438012A (zh) * | 2011-11-15 | 2012-05-02 | 航天科工深圳(集团)有限公司 | 一种协议通讯方法和系统 |
CN102591739A (zh) * | 2012-01-06 | 2012-07-18 | 深圳市沛城电子科技有限公司 | 串口同步通讯数据对齐的方法及装置 |
CN102739340A (zh) * | 2011-04-08 | 2012-10-17 | 深圳富泰宏精密工业有限公司 | At命令主动上报响应处理系统及方法 |
CN102946376A (zh) * | 2011-11-29 | 2013-02-27 | Ut斯达康通讯有限公司 | 一种异步通讯的实现方法 |
CN103793343A (zh) * | 2012-10-29 | 2014-05-14 | 上海斐讯数据通信技术有限公司 | 一种串口传输数据的实现方法及系统 |
CN104102169A (zh) * | 2014-06-16 | 2014-10-15 | 福建睿能科技股份有限公司 | 纺织、机控设备及控制系统、控制及驱动装置、通讯方法 |
CN105812932A (zh) * | 2014-12-29 | 2016-07-27 | Tcl集团股份有限公司 | 一种模块电视的通信数据防丢失方法及系统 |
CN105975424A (zh) * | 2016-04-28 | 2016-09-28 | 北京信息科技大学 | 一种主从串行通讯协议 |
CN107844455A (zh) * | 2017-11-14 | 2018-03-27 | 江苏佳讯纳通能源技术有限公司 | 一种基于双cpu的数据传输方法 |
CN108879958A (zh) * | 2018-07-23 | 2018-11-23 | 阳光电源股份有限公司 | 一种分布式电源系统及其通信串扰抑制方法 |
CN109591033A (zh) * | 2018-09-28 | 2019-04-09 | 广州智伴人工智能科技有限公司 | 一种非接触式人机交互系统 |
CN109660429A (zh) * | 2018-12-26 | 2019-04-19 | 芯翼信息科技(上海)有限公司 | 信息校验方法及信息校验系统 |
CN111835658A (zh) * | 2020-06-23 | 2020-10-27 | 武汉菲奥达物联科技有限公司 | 一种基于lpwan的数据优先响应方法及装置 |
CN112565295A (zh) * | 2020-12-24 | 2021-03-26 | 中国电子科技集团公司第二十研究所 | 一种基于顺序编码的指令应答优化方法 |
CN113132065A (zh) * | 2019-12-30 | 2021-07-16 | 西安诺瓦星云科技股份有限公司 | 数据通信方法、装置及系统、存储介质和视频处理设备 |
CN114760364A (zh) * | 2022-04-02 | 2022-07-15 | 沈阳飞机设计研究所扬州协同创新研究院有限公司 | 一种时间触发的串口设备通信的管理方法 |
CN114760010A (zh) * | 2022-04-02 | 2022-07-15 | 沈阳飞机设计研究所扬州协同创新研究院有限公司 | 一种可靠的串口数据传输方法 |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR100566266B1 (ko) * | 2004-01-20 | 2006-03-29 | 삼성전자주식회사 | 휴대용 단말기와 pc간의 데이터 통신방법 |
US20080092007A1 (en) * | 2004-09-06 | 2008-04-17 | Silicon Gap Pty Ltd | Data Communication Device And Method |
CN1819506A (zh) * | 2006-03-16 | 2006-08-16 | 江苏沙钢集团有限公司 | 串行接口无线通信数据的处理方法 |
-
2007
- 2007-11-03 CN CN2007101130888A patent/CN101179790B/zh not_active Expired - Fee Related
Cited By (28)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101764730B (zh) * | 2009-12-18 | 2011-12-21 | 航天东方红卫星有限公司 | 一种can总线数据传输方法 |
CN101945155B (zh) * | 2010-09-03 | 2013-03-27 | 展讯通信(上海)有限公司 | 实时抓取终端调试信息的方法及终端设备 |
CN101945155A (zh) * | 2010-09-03 | 2011-01-12 | 展讯通信(上海)有限公司 | 实时抓取终端调试信息的方法及终端设备 |
CN102739340A (zh) * | 2011-04-08 | 2012-10-17 | 深圳富泰宏精密工业有限公司 | At命令主动上报响应处理系统及方法 |
CN102739340B (zh) * | 2011-04-08 | 2016-03-16 | 深圳富泰宏精密工业有限公司 | At命令主动上报响应处理系统及方法 |
CN102438012A (zh) * | 2011-11-15 | 2012-05-02 | 航天科工深圳(集团)有限公司 | 一种协议通讯方法和系统 |
CN102946376A (zh) * | 2011-11-29 | 2013-02-27 | Ut斯达康通讯有限公司 | 一种异步通讯的实现方法 |
CN102946376B (zh) * | 2011-11-29 | 2015-04-29 | Ut斯达康通讯有限公司 | 一种异步通讯的实现方法 |
CN102591739A (zh) * | 2012-01-06 | 2012-07-18 | 深圳市沛城电子科技有限公司 | 串口同步通讯数据对齐的方法及装置 |
CN103793343B (zh) * | 2012-10-29 | 2016-12-21 | 上海斐讯数据通信技术有限公司 | 一种串口传输数据的实现方法及系统 |
CN103793343A (zh) * | 2012-10-29 | 2014-05-14 | 上海斐讯数据通信技术有限公司 | 一种串口传输数据的实现方法及系统 |
CN104102169A (zh) * | 2014-06-16 | 2014-10-15 | 福建睿能科技股份有限公司 | 纺织、机控设备及控制系统、控制及驱动装置、通讯方法 |
CN105812932A (zh) * | 2014-12-29 | 2016-07-27 | Tcl集团股份有限公司 | 一种模块电视的通信数据防丢失方法及系统 |
CN105812932B (zh) * | 2014-12-29 | 2018-10-26 | Tcl集团股份有限公司 | 一种模块电视的通信数据防丢失方法及系统 |
CN105975424A (zh) * | 2016-04-28 | 2016-09-28 | 北京信息科技大学 | 一种主从串行通讯协议 |
CN105975424B (zh) * | 2016-04-28 | 2018-06-26 | 北京信息科技大学 | 一种主从串行通讯协议 |
CN107844455A (zh) * | 2017-11-14 | 2018-03-27 | 江苏佳讯纳通能源技术有限公司 | 一种基于双cpu的数据传输方法 |
CN107844455B (zh) * | 2017-11-14 | 2020-07-07 | 江苏佳讯纳通能源技术有限公司 | 一种基于双cpu的数据传输方法 |
CN108879958A (zh) * | 2018-07-23 | 2018-11-23 | 阳光电源股份有限公司 | 一种分布式电源系统及其通信串扰抑制方法 |
CN108879958B (zh) * | 2018-07-23 | 2021-12-10 | 阳光电源股份有限公司 | 一种分布式电源系统及其通信串扰抑制方法 |
CN109591033A (zh) * | 2018-09-28 | 2019-04-09 | 广州智伴人工智能科技有限公司 | 一种非接触式人机交互系统 |
CN109660429A (zh) * | 2018-12-26 | 2019-04-19 | 芯翼信息科技(上海)有限公司 | 信息校验方法及信息校验系统 |
CN113132065A (zh) * | 2019-12-30 | 2021-07-16 | 西安诺瓦星云科技股份有限公司 | 数据通信方法、装置及系统、存储介质和视频处理设备 |
CN111835658A (zh) * | 2020-06-23 | 2020-10-27 | 武汉菲奥达物联科技有限公司 | 一种基于lpwan的数据优先响应方法及装置 |
CN111835658B (zh) * | 2020-06-23 | 2022-06-10 | 武汉菲奥达物联科技有限公司 | 一种基于lpwan的数据优先响应方法及装置 |
CN112565295A (zh) * | 2020-12-24 | 2021-03-26 | 中国电子科技集团公司第二十研究所 | 一种基于顺序编码的指令应答优化方法 |
CN114760364A (zh) * | 2022-04-02 | 2022-07-15 | 沈阳飞机设计研究所扬州协同创新研究院有限公司 | 一种时间触发的串口设备通信的管理方法 |
CN114760010A (zh) * | 2022-04-02 | 2022-07-15 | 沈阳飞机设计研究所扬州协同创新研究院有限公司 | 一种可靠的串口数据传输方法 |
Also Published As
Publication number | Publication date |
---|---|
CN101179790B (zh) | 2011-02-02 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101179790B (zh) | 一种移动终端处理器之间的串口通信方法 | |
CN100421417C (zh) | Tcp卸载的系统和方法 | |
US7756990B2 (en) | Configurable protocol engine | |
CN101047714B (zh) | 一种处理网络数据的方法及系统 | |
US8605578B1 (en) | System and method for handling of destination host side congestion | |
CN100454813C (zh) | 一种计算机和移动终端之间数据文件传输的方法 | |
WO2009021417A1 (fr) | Procédé, système et dispositif de transmission et de réception de données de réseau | |
US20050135395A1 (en) | Method and system for pre-pending layer 2 (L2) frame descriptors | |
CN109547162B (zh) | 基于两套单向边界的数据通信方法 | |
CN103348620A (zh) | 用于利用低信号能量的改进的稳健头部压缩的方法 | |
US20060069788A1 (en) | Interface method, system, and program product for facilitating layering of a data communications protocol over an active message layer protocol | |
CN104205735A (zh) | 用于分布式信息技术体系结构的通信传输协议 | |
CN102946376A (zh) | 一种异步通讯的实现方法 | |
WO2004040819A2 (en) | An apparatus and method for receive transport protocol termination | |
CN101106550A (zh) | 大尺寸消息的发送方法、接收方法及传输系统 | |
US4551834A (en) | Method and system for communicating over an open communication network | |
CN103944880B (zh) | 一种ZigBee数据传输的方法 | |
CN105940658B (zh) | 一种用户数据的传输方法、装置及终端 | |
CN103178930A (zh) | 物理层链路汇聚传输方法及装置 | |
CN102315918B (zh) | 一种tcp连接与sctp连接互通的方法及装置 | |
CN101534297B (zh) | 一种实现流控制传输协议的动态流创建方法 | |
CN106302426A (zh) | 一种基于fpga的带重发机制的udp协议栈实现方法 | |
CN101631074A (zh) | 一种多链路报文发送方法、装置和网络设备 | |
JP2001069174A (ja) | 伝送制御方法 | |
CN101145968A (zh) | 网管系统和传输设备间数据发送及接收方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
CF01 | Termination of patent right due to non-payment of annual fee | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20110202 Termination date: 20191103 |