CN101150809A - 移动终端处理器串口唤醒与流控的方法 - Google Patents
移动终端处理器串口唤醒与流控的方法 Download PDFInfo
- Publication number
- CN101150809A CN101150809A CNA2007101130873A CN200710113087A CN101150809A CN 101150809 A CN101150809 A CN 101150809A CN A2007101130873 A CNA2007101130873 A CN A2007101130873A CN 200710113087 A CN200710113087 A CN 200710113087A CN 101150809 A CN101150809 A CN 101150809A
- Authority
- CN
- China
- Prior art keywords
- processor
- pulse
- pin
- level
- 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
- Power Sources (AREA)
Abstract
本发明公开一种移动终端处理器串口唤醒与流控的方法,包括以下步骤:第一处理器设置管脚为输出状态,改变与第二处理器之间连接线的电平高低;第二处理器接收到连接线的电平变化,产生中断,改变电平触发的类型;第一处理器设置管脚返回为输入状态,连接线也返回原来的电平形成一个脉冲;第二处理器产生中断,关闭控制管脚的中断,并退出休眠状态,查看接收缓冲区是否有空间且串口是否可用;如果接收缓冲区有空间且串口可用,则设置管脚为输出状态,改变连接线的电平;第一处理器响应电平变化,关闭控制管脚的中断,通过与第二处理器连接的数据线开始发送数据,在串口通信中使用两根控制线,实现了串口双向唤醒、双向唤醒确认、双向流控和死机监测。
Description
技术领域
本发明属于移动终端技术领域,具体地说是涉及到适用于电池供电终端设备内部处理器之间的串口通信方法。
背景技术
移动终端产品使用电池供电,对功耗要求很高。为了降低电量消耗,产品内部大多数芯片均可以进入休眠状态,此时芯片耗电量减少,但是芯片内大多数器件,包括串口均处于关闭状态。因此芯片休眠时不能进行串口数据的收发。进行数据传输时,发送端需要先唤醒接收端,然后再进行数据的发送。如果数据发送时接收端还没准备好,就会导致数据丢失。
目前发送端唤醒接收端的方法有两种,一种是通过串口本身电平变化唤醒接收端,即发送端在发送有用数据前,先发送几个字节的唤醒数据,唤醒数据会导致串口电平变化,从而唤醒接收端。但是有些芯片不支持串口唤醒,这时就只能采用另一种方法:应用GPIO即通用输入输出端口的电平变化导致中断唤醒。发送端与接收端通过一根互连线相连,连线两端均为GPIO端口,发送端设为输出,接收端设为输入。发送端发送时通过改变自身GPIO端口输出而控制连线电平变化,从而使接收端的GPIO端口检测到电平跳变产生硬件中断,此中断会唤醒接收端。如果是双向通信则需要两根连接线,两端各占用两个GPIO。
以上所述的这两种唤醒接收端的技术方式都很简单,但都存在一个缺点。即没有接收端反馈的唤醒确认信号,发送端发出唤醒动作后等待一段固定时间,然后就开始发送数据,而这时接收端可能处于不同的状态,导致接收端每次准备好接收所需要的时间长短不同。因此发送端等待的固定时间难以确定,如果等待的时间过短,这就有可能造成发送端发送时,接收端还没有准备好,造成数据丢失。如果等待的时间过长,要求发送端在发送前必须等待足够长的时间以保证接收端可以准备好,这样就降低了传输效率。
如果在以上所述的两种唤醒接收端的技术方式上增加唤醒确认信号的步骤,要求接收端返回唤醒确认信息,也存在一个问题,因为发送端发送数据时接收端可能正处于休眠状态,从接收端发现串口电平变化到真正开始接收数据需要一定时间,这就造成开头部分数据丢失。因此接收端无法判断接收到的具体数据是什么,也就不可能返回确认信息,这就需要发送端重发唤醒数据,从而导致效率下降。而GPIO电平唤醒方式可以使用另外一根互连线实现唤醒确认,但这样一来如果是双向通信就需要4根连接线来进行唤醒与唤醒确认。而移动终端追求微型化,其所用芯片的端口资源比较紧张,通常无法提供这么多的GPIO端口。
一般情况下,发送端与接收端都会有两个缓冲区(BUFFER)分别缓冲发送和接收的数据。当接收端收到数据后,数据存放在接收BUFFER中,只有在数据处理完后才能删除。如果有时接收到的数据需要较长的处理时间,而此时串口一直还在接收,就有可能造成接收缓冲区溢出,从而导致数据丢失。而且损坏的数据也要占用接收缓冲区的空间,等待处理器进行判断、删除,这就导致接收缓冲区的数据溢出情况进一步恶化。
对于数据溢出的解决方法有三种。方法一是降低串口的物理传输速率,但这会造成系统整体性能的下降,且仍然不能保证在所有情况下数据均能够得到及时的处理。方法二是采用硬件流控,需要在发送端与接收端之间增加四根专用连接线。硬件流控根据接收FIFO是否已满来控制是否发送,这就需要软件在接收BUFFER已满的信息时就停止取FIFO的操作,这种硬件流控的方法也增加了软件的复杂性,且硬件流控需要额外占用4个端口,在很多情况下是不可接受的。方法三是采用软件流控,发送端与接收端之间通过串口发送指令通知对方暂停或继续发送来避免数据的处理速度赶不上传输速度。这增加了软件实现的复杂度,流控指令本身也增加了系统的负担。且某些情况下流控指令可能丢失,从而导致流控失败。
基于此,本发明以一种巧妙可靠的方式来解决移动终端处理器之间串口唤醒和数据溢出问题。
发明内容
本发明的目的在于提供一种简单可靠的处理器之间串口唤醒和流控的方法,在串口通信中使用两根控制线,实现了串口双向唤醒、双向唤醒确认、双向流控和死机监测。
为了达到上述目的,本发明采用以下技术方案予以实现:
移动终端处理器串口唤醒与流控的方法,包括以下步骤:
第一处理器设置管脚为输出状态,改变与第二处理器之间连接线的电平高低;
第二处理器接收到连接线的电平变化,产生中断,改变电平触发的类型;
第一处理器设置管脚返回为输入状态,连接线也返回原来的电平形成一个脉冲;
第二处理器产生中断,关闭控制管脚的中断,并退出休眠状态,查看接收缓冲区是否有空间;
如果接收缓冲区有空间且串口可用,则设置管脚为输出状态,改变连接线的电平;
第一处理器响应电平变化,关闭控制管脚的中断,通过与第二处理器连接的数据线开始发送数据。
在本发明的技术方案中,还具有以下技术特征:第二处理器设置管脚返回输入状态,连接线也返回原来电平,形成一个脉冲,第二处理器形成的确认唤醒脉冲宽度比第一处理器形成的唤醒脉冲宽度大。
第一处理器和第二处理器之间的连接线上设置有上拉电阻,在处理器管脚为输入状态时,连接线保持为高电平,第一处理器形成的唤醒脉冲和第二处理器形成的确认唤醒脉冲均为一个高低高脉冲,脉冲宽度范围是1微秒至10毫秒。
在本发明的技术方案中,还具有以下技术特征:所述的两个处理器控制管脚均为GPIO通用输入输出端口。所述的两个处理器均采用电平触发中断,中断类型在高电平触发和低电平触发之间切换。
在本发明的技术方案中,还具有以下技术特征:第二处理器发送确认唤醒脉冲时设置串口休眠定时器。
在本发明的技术方案中,还具有以下技术特征:如果第一处理器在时限内没有接收到第二处理器发送的确认唤醒脉冲,则再次发送唤醒脉冲,第一处理器再次发送唤醒脉冲的前后瞬间判断一下连接线的电平状态。
与现有技术相比,本发明的优点和积极效果是:应用电平触发中断在两个处理器之间发送唤醒脉冲和确认唤醒脉冲的步骤,节省了把处理器从休眠状态唤醒的时间,最大程度上保证了串口传输的快速、稳定、可靠。
附图说明
图1是本发明处理器之间通信端口连接的示意图;
图2是本发明的流程图;
图3是本发明处理器之间唤醒和确认唤醒的汇报过程示意图;
图4是本发明处理器多次发送唤醒脉冲的示意图。
具体实施方式
下面结合附图和实施例对本发明作进一步的描述。
如图1所示,为实现双向通信,第一处理器1和第二处理器2之间用于通信的有4根连接线。其中两根单向数据线用于数据的收发,另外两根双向控制线用于唤醒、唤醒确认和流控。如果两个处理器之间只是单向通信,则只需要一根数据线与一根控制线。
控制线两端管脚均为GPIO管脚,处理器可以把管脚设置为输入或输出状态,并且管脚可以根据输入电平变化产生硬件中断。在每一条控制线上连接有上拉电阻,以保证控制线两端管脚在均设为输入时连接线会保持在高电平上。此上拉电阻可以是外接的,也可以是芯片内置的。上拉电阻阻值需要根据芯片特性而定,阻值应尽量大以减少耗电。
在第一处理器内部,有一个发送缓冲区11和接收缓冲区12,通过对应的寄存器13和寄存器14发送和接收数据,在第二处理器内部,有一个接收缓冲区21和发送缓冲区22,通过对应的寄存器23和寄存器24接收和发送数据。
如图2所示,两个处理器之间进行唤醒和确认唤醒以及流控过程的具体步骤如下:
201步骤:第一处理器设置管脚为输出状态,改变与第二处理器之间连接线的电平高低。
第一处理器为了发送唤醒信号,先把控制管脚由输入状态设置为输出状态,连接线置为低电平。
步骤202:第二处理器接收到连接线的电平变化,产生中断,改变电平触发的类型,管脚由低电平触发设置为高电平触发。
步骤203:第一处理器设置管脚返回为输入状态,连接线也返回原来的高电平,从而形成一个高低高脉冲作为唤醒信号。
步骤204:第二处理器产生中断,关闭控制管脚的中断,并退出休眠状态。
步骤205:第二处理器判断接收缓冲区是否有空间且串口是否可用。
判断结果为否,则说明第二处理器没有做好数据接收的准备,不能接收数据,继续进行步骤206:即第一处理器等待一定时间后,返回到201步骤,进行再一次的唤醒过程。再次唤醒过程可以重复多次。
判断结果为是,则说明第二处理器已经做好数据接收的准备,能够接收数据,进行步骤207:第二处理器设置管脚为输出状态,连接线为低电平。
步骤208:第一处理器响应电平变化,关闭控制管脚的中断,通过与第二处理器连接的数据线开始发送数据。
步骤209:第二处理器设置管脚返回输入状态,连接线也返回原来电平,形成一个高低高脉冲作为确认唤醒的信号。
因为使用边缘触发中断来检测GPIO管脚电平变化可靠性不高,本技术方案中使用的是电平触发中断。实现时,中断类型需要在高电平触发和低电平触发之间来回切换。控制线变为低电平后,GPIO管脚会收到低电平中断。此时中断类型需要更改为高电平触发,这样当控制线变回高电平时,就会产生高电平中断。收到高电平中断后管脚的中断类型会重新变为低电平触发,来检测下一个电平变化。
图3说明的是以第一处理器为发送端,第二处理器为接收端的一次完整的通信过程。图中A点处串口处于非工作状态,此时控制线两端管脚均设为输入。因为有上拉电阻的存在,因此控制线保持在高电平。此时第一处理器的控制管脚不响应中断,第二处理器的控制管脚设为响应低电平中断。
在图3中B点,当第一处理器准备向第二处理器发送数据时,发送端先将控制管脚设为输出低电平,从而导致控制线变为低电平。第二处理器发现其控制管脚变为低电平,产生低电平中断。在第二处理器的中断处理函数中不做其它操作,只是将控制管脚的中断类型改为高电平触发,等待控制线变回高电平。
在图3中C点,第一处理器将控制管脚重新设为输入,并设置管脚响应低电平中断。因为上拉电阻的关系,控制线会立刻变为高电平,从而形成一个高低高脉冲。电平的变化会导致第二处理器产生中断,第二处理器的中断处理函数中首先关闭控制管脚的中断。然后通知系统开始唤醒及准备接收工作。作为唤醒信号的高低高脉冲的宽度,即持续时间需要根据第二处理器的特性来确定。有些处理器可以检测到几微秒宽的脉冲,而有些处理器休眠时只能检测到几毫秒宽的脉冲,因此脉冲宽度设置范围是1微秒至10毫秒。第二处理器退出休眠状态后,首先查看接收缓冲区BUFFER剩余空间是否足够。如果剩余空间足够,而且串口已经准备好,就会将控制管脚从输入改为输出低电平,
在图3中D点,第一处理器此时响应低电平中断,因此会被触发。第一处理器被触发后,就可以知道第二处理器已经准备好接收数据了。则第一处理器关闭管脚中断响应,然后立刻开始发送数据。因此在D点串口已经可以开始发送数据了,不需要等到控制线回到高电平后再发送。
在图3中E点,第二处理器输出低电平足够长时间后,重新将管脚置为输入,且中断设为低电平触发。此时连线会立刻回到高电平,形成一个高低高脉冲。脉冲宽度必须足够宽以确认第一处理器可以如前所述触发低电平中断。至此,唤醒与唤醒确认过程结束。
如果在收到唤醒脉冲时,第二处理器已经处于可接收数据状态,会立即返回确认脉冲。但如果第二处理器此时忙于某种操作,如处于锁中断状态,或接收BUFFER剩余空间不够,会过一段时间当第二处理器满足接收条件后才返回确认脉冲。而第一处理器必须等到确认脉冲后才会开始发送数据,这就相当于放慢了串口传输速率,做到了自动限速。确认脉冲的存在极大的增强了通信的可靠性,防止数据流量大造成的数据丢失问题的发生。在第二处理器作为接收端,发送确认脉冲时会设置串口休眠定时器,当串口不再工作、相关任务完成,且定时器到时,第二处理器会重新进入休眠状态。为了降低电量消耗,收到唤醒脉冲后第二处理器设置的串口休眠定时器时间很短,如果需要串口长时间处于工作状态,则需要第一处理器作为发送端在指令中指定串口休眠定时器时间。
唤醒脉冲和确认脉冲同时有第二个功能,即确认接收端即第二处理器是否处于死机状态。在某些极端状态下,处理器可能会死机,不再响应任何操作。而如果接收端死机则不会回复确认脉冲,发送端即第一处理器可以很容易的通过确认脉冲的有无来检测接收端是否可正常工作。这通常用于主控端判断被控端是否异常,主控端会定期向被控端发送唤醒脉冲,如果收不到确认脉冲则说明被控端死机,主控端会据此进行处理,如控制被控端重启等操作,避免系统长时间处于异常状态。
如图4所示,因为各种原因,第一处理器发出的第一个唤醒脉冲在时限内可能得不到确认脉冲回复。此时第一处理器作为发送端会发送第二个唤醒脉冲。唤醒脉冲根据情况可以重发多次,比如唤醒脉冲最大重发次数为5次,如果最后一次发送的唤醒脉冲仍未得到确认,则说明接收端工作异常。
如果第一处理器发送多个唤醒脉冲,在某种情况下,第二处理器返回的确认脉冲也可能会有多个。因为发送端控制管脚在收到第一个确认脉冲后就不再响应中断,这样除第一个确认脉冲外其它确认脉冲并不会被发送端检测到。
接收端的第一个确认脉冲有可能和发起端第二个唤醒脉冲重合,从而造成发送端收不到确认。解决办法为确认脉冲要比唤醒脉冲宽。发送端在发送第二个唤醒脉冲前瞬间判断一下连线的当前状态,如果为低则说明已经收到了确认脉冲,只是中断还没有来的及处理,因此第二个唤醒脉冲将不再发送。发送端在第二个唤醒脉冲发送后立刻再判断一下连线状态,如果为低则说明正在接收确认脉冲,不需再等待确认就可以直接进行串口数据发送。
脉冲信号宽度如果是几微秒,可以采用死循环的方法来实现。移动终端处理器的主频经常是可变的,处理器主频不同时,相同等待时间死循环次数不同。因此需要根据当前处理器的主频来判断执行死循环的次数。而如果脉冲信号宽度为毫秒级,则只能使用定时器的方法实现。
本发明应用电平触发中断在两个处理器之间发送唤醒脉冲和确认唤醒脉冲的步骤,提高了串口传输的可靠性。
Claims (10)
1.移动终端处理器串口唤醒与流控的方法,其特征在于包括以下步骤:
第一处理器设置管脚为输出状态,改变与第二处理器之间连接线的电平高低;
第二处理器接收到连接线的电平变化,产生中断,改变电平触发的类型;
第一处理器设置管脚返回为输入状态,连接线也返回原来的电平形成一个脉冲;
第二处理器产生中断,关闭控制管脚的中断,并退出休眠状态,查看接收缓冲区是否有空间且串口是否可用;
如果接收缓冲区有空间且串口可用,则设置管脚为输出状态,改变连接线的电平;
第一处理器响应电平变化,关闭控制管脚的中断,通过与第二处理器连接的数据线开始发送数据。
2.根据权利要求1所述的移动终端处理器串口唤醒与流控的方法,其特征在于第二处理器设置管脚返回输入状态,连接线也返回原来电平,形成一个脉冲。
3.根据权利要求1或2所述的移动终端处理器串口唤醒与流控的方法,其特征在于第二处理器形成的确认唤醒脉冲宽度比第一处理器形成的唤醒脉冲宽度大。
4.根据权利要求1所述的移动终端处理器串口唤醒与流控的方法,其特征在于第一处理器和第二处理器之间的连接线上设置有上拉电阻,在处理器管脚为输入状态时,连接线保持为高电平。
5.根据权利要求1、2、3或者4所述的移动终端处理器串口唤醒与流控的方法,其特征在于第一处理器形成的唤醒脉冲和第二处理器形成的确认唤醒脉冲均为一个高低高脉冲,脉冲宽度范围是1微秒至10毫秒。
6.根据权利要求1、2、3或者4所述的移动终端处理器串口唤醒与流控的方法,其特征在于所述的两个处理器控制管脚均为GPIO通用输入输出端口。
7.根据权利要求1或者2所述的移动终端处理器串口唤醒与流控的方法,其特征在于所述的两个处理器均采用电平触发中断,中断类型在高电平触发和低电平触发之间切换。
8.根据权利要求1所述的移动终端处理器串口唤醒与流控的方法,其特征在于第二处理器发送确认唤醒脉冲时设置串口休眠定时器。
9.根据权利要求1所述的移动终端处理器串口唤醒与流控的方法,其特征在于如果第一处理器在时限内没有接收到第二处理器发送的确认唤醒脉冲,则再次发送唤醒脉冲。
10.根据权利要求3或者9所述的移动终端处理器串口唤醒与流控的方法,其特征在于第一处理器再次发送唤醒脉冲的前后瞬间判断一下连接线的电平状态。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2007101130873A CN101150809B (zh) | 2007-11-03 | 2007-11-03 | 移动终端处理器串口唤醒与流控的方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2007101130873A CN101150809B (zh) | 2007-11-03 | 2007-11-03 | 移动终端处理器串口唤醒与流控的方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101150809A true CN101150809A (zh) | 2008-03-26 |
CN101150809B CN101150809B (zh) | 2011-02-02 |
Family
ID=39251087
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2007101130873A Expired - Fee Related CN101150809B (zh) | 2007-11-03 | 2007-11-03 | 移动终端处理器串口唤醒与流控的方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101150809B (zh) |
Cited By (24)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101888435B (zh) * | 2009-06-16 | 2012-05-09 | 联想(北京)有限公司 | 便携终端的状态控制方法及便携终端 |
CN103092721A (zh) * | 2011-10-31 | 2013-05-08 | 联想(北京)有限公司 | 一种应用备份方法、电子设备及系统 |
CN101707674B (zh) * | 2009-11-04 | 2013-08-07 | 中兴通讯股份有限公司 | 支持cmmb功能的终端降功耗的方法及该终端 |
CN104597790A (zh) * | 2014-12-26 | 2015-05-06 | 北京兆易创新科技股份有限公司 | 一种串口控制器及基于其的微控制器系统的唤醒方法 |
CN105354116A (zh) * | 2015-10-23 | 2016-02-24 | 青岛海信移动通信技术股份有限公司 | 一种热插拔检测方法、装置、系统及移动终端 |
CN105634690A (zh) * | 2015-06-24 | 2016-06-01 | 东莞市芯谷电子科技有限公司 | 一种用于增强花样机串口通讯可靠性的方法 |
CN105704802A (zh) * | 2016-04-01 | 2016-06-22 | 努比亚技术有限公司 | 一种移动终端及其通信方法 |
CN106372012A (zh) * | 2016-08-25 | 2017-02-01 | 长沙丰灼通讯科技有限公司 | 一种不使用握手控制线的串口唤醒系统及串口通信方法 |
US9779106B2 (en) | 2011-08-15 | 2017-10-03 | Lenovo (Beijing) Co., Ltd. | Application management method and device |
WO2018000193A1 (zh) * | 2016-06-28 | 2018-01-04 | 北京小米移动软件有限公司 | 引脚控制方法及装置 |
CN107589824A (zh) * | 2017-09-21 | 2018-01-16 | 上海顺舟智能科技股份有限公司 | 一种降低仅支持io唤醒mcu功耗的方法 |
CN108988840A (zh) * | 2018-06-12 | 2018-12-11 | 北京车和家信息技术有限公司 | 单线双向唤醒电路及车辆 |
CN109765799A (zh) * | 2018-12-25 | 2019-05-17 | 哈尔滨工业大学 | 一种基于dsp的用于垂直起降飞行器制导控制的串口数据收发方法 |
CN110334046A (zh) * | 2019-07-11 | 2019-10-15 | 南方电网科学研究院有限责任公司 | 一种spi全双工的通信方法、装置及系统 |
CN110378155A (zh) * | 2019-06-25 | 2019-10-25 | 苏州浪潮智能科技有限公司 | 一种服务器串行口禁用保护电路、方法 |
CN110990066A (zh) * | 2019-11-26 | 2020-04-10 | 江苏嘉则信息技术有限公司 | 一种通信终端的睡眠唤醒方法 |
CN111244881A (zh) * | 2020-03-12 | 2020-06-05 | 甄十信息科技(上海)有限公司 | 电子设备自动掉电或卡死自重启的方法和装置 |
CN111338856A (zh) * | 2020-02-21 | 2020-06-26 | 深圳震有科技股份有限公司 | 一种串口硬件流控实现方法、智能终端及存储介质 |
CN113177016A (zh) * | 2021-05-25 | 2021-07-27 | 惠州Tcl移动通信有限公司 | 一种串口通讯方法、装置、终端设备及存储介质 |
CN113285856A (zh) * | 2021-07-22 | 2021-08-20 | 翱捷科技(深圳)有限公司 | 数据传输时延的处理方法及系统和数据传输方法及系统 |
CN113868185A (zh) * | 2020-06-30 | 2021-12-31 | Oppo广东移动通信有限公司 | 多芯片系统、电子设备及数据传输方法 |
CN114647448A (zh) * | 2020-12-17 | 2022-06-21 | 航天科工惯性技术有限公司 | 一种多单片机间唤醒通信的方法、装置、设备及存储介质 |
CN115312049A (zh) * | 2022-06-30 | 2022-11-08 | 青岛海尔科技有限公司 | 指令的响应方法、存储介质及电子装置 |
WO2023207187A1 (zh) * | 2022-04-24 | 2023-11-02 | 深圳市广和通无线股份有限公司 | 上位机唤醒方法、装置、系统、电子设备及存储介质 |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102096649B (zh) * | 2011-02-10 | 2014-12-10 | 中兴通讯股份有限公司 | 一种基于uart的睡眠唤醒方法及装置 |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1266569C (zh) * | 2003-12-16 | 2006-07-26 | 威盛电子股份有限公司 | 中断信号控制方法 |
CN100444670C (zh) * | 2005-06-03 | 2008-12-17 | 中兴通讯股份有限公司 | Gsm/phs双模手机及两模块间发送数据的方法 |
CN100388841C (zh) * | 2005-07-04 | 2008-05-14 | 中兴通讯股份有限公司 | 一种双模终端及其内部芯片间控制和通信的方法 |
CN101022630A (zh) * | 2007-04-02 | 2007-08-22 | 上海闻泰电子科技有限公司 | 一种双模手机通讯的控制方法 |
-
2007
- 2007-11-03 CN CN2007101130873A patent/CN101150809B/zh not_active Expired - Fee Related
Cited By (32)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101888435B (zh) * | 2009-06-16 | 2012-05-09 | 联想(北京)有限公司 | 便携终端的状态控制方法及便携终端 |
CN101707674B (zh) * | 2009-11-04 | 2013-08-07 | 中兴通讯股份有限公司 | 支持cmmb功能的终端降功耗的方法及该终端 |
US9779106B2 (en) | 2011-08-15 | 2017-10-03 | Lenovo (Beijing) Co., Ltd. | Application management method and device |
CN103092721B (zh) * | 2011-10-31 | 2017-04-19 | 联想(北京)有限公司 | 一种应用备份方法、电子设备及系统 |
CN103092721A (zh) * | 2011-10-31 | 2013-05-08 | 联想(北京)有限公司 | 一种应用备份方法、电子设备及系统 |
CN104597790A (zh) * | 2014-12-26 | 2015-05-06 | 北京兆易创新科技股份有限公司 | 一种串口控制器及基于其的微控制器系统的唤醒方法 |
CN104597790B (zh) * | 2014-12-26 | 2017-09-29 | 北京兆易创新科技股份有限公司 | 一种串口控制器及基于其的微控制器系统的唤醒方法 |
CN105634690A (zh) * | 2015-06-24 | 2016-06-01 | 东莞市芯谷电子科技有限公司 | 一种用于增强花样机串口通讯可靠性的方法 |
CN105354116A (zh) * | 2015-10-23 | 2016-02-24 | 青岛海信移动通信技术股份有限公司 | 一种热插拔检测方法、装置、系统及移动终端 |
CN105354116B (zh) * | 2015-10-23 | 2019-03-01 | 青岛海信移动通信技术股份有限公司 | 一种热插拔检测方法、装置、系统及移动终端 |
CN105704802A (zh) * | 2016-04-01 | 2016-06-22 | 努比亚技术有限公司 | 一种移动终端及其通信方法 |
WO2018000193A1 (zh) * | 2016-06-28 | 2018-01-04 | 北京小米移动软件有限公司 | 引脚控制方法及装置 |
CN106372012A (zh) * | 2016-08-25 | 2017-02-01 | 长沙丰灼通讯科技有限公司 | 一种不使用握手控制线的串口唤醒系统及串口通信方法 |
CN106372012B (zh) * | 2016-08-25 | 2018-12-25 | 长沙丰灼通讯科技有限公司 | 一种不使用握手控制线的串口唤醒系统及串口通信方法 |
CN107589824A (zh) * | 2017-09-21 | 2018-01-16 | 上海顺舟智能科技股份有限公司 | 一种降低仅支持io唤醒mcu功耗的方法 |
CN107589824B (zh) * | 2017-09-21 | 2021-02-26 | 上海顺舟智能科技股份有限公司 | 一种降低仅支持io唤醒mcu功耗的方法 |
CN108988840A (zh) * | 2018-06-12 | 2018-12-11 | 北京车和家信息技术有限公司 | 单线双向唤醒电路及车辆 |
CN108988840B (zh) * | 2018-06-12 | 2023-02-21 | 北京车和家信息技术有限公司 | 单线双向唤醒电路及车辆 |
CN109765799A (zh) * | 2018-12-25 | 2019-05-17 | 哈尔滨工业大学 | 一种基于dsp的用于垂直起降飞行器制导控制的串口数据收发方法 |
CN110378155A (zh) * | 2019-06-25 | 2019-10-25 | 苏州浪潮智能科技有限公司 | 一种服务器串行口禁用保护电路、方法 |
CN110378155B (zh) * | 2019-06-25 | 2021-06-29 | 苏州浪潮智能科技有限公司 | 一种服务器串行口禁用保护电路、方法 |
CN110334046A (zh) * | 2019-07-11 | 2019-10-15 | 南方电网科学研究院有限责任公司 | 一种spi全双工的通信方法、装置及系统 |
CN110990066A (zh) * | 2019-11-26 | 2020-04-10 | 江苏嘉则信息技术有限公司 | 一种通信终端的睡眠唤醒方法 |
CN110990066B (zh) * | 2019-11-26 | 2023-12-05 | 江苏嘉则信息技术有限公司 | 一种通信终端的睡眠唤醒方法 |
CN111338856A (zh) * | 2020-02-21 | 2020-06-26 | 深圳震有科技股份有限公司 | 一种串口硬件流控实现方法、智能终端及存储介质 |
CN111244881A (zh) * | 2020-03-12 | 2020-06-05 | 甄十信息科技(上海)有限公司 | 电子设备自动掉电或卡死自重启的方法和装置 |
CN113868185A (zh) * | 2020-06-30 | 2021-12-31 | Oppo广东移动通信有限公司 | 多芯片系统、电子设备及数据传输方法 |
CN114647448A (zh) * | 2020-12-17 | 2022-06-21 | 航天科工惯性技术有限公司 | 一种多单片机间唤醒通信的方法、装置、设备及存储介质 |
CN113177016A (zh) * | 2021-05-25 | 2021-07-27 | 惠州Tcl移动通信有限公司 | 一种串口通讯方法、装置、终端设备及存储介质 |
CN113285856A (zh) * | 2021-07-22 | 2021-08-20 | 翱捷科技(深圳)有限公司 | 数据传输时延的处理方法及系统和数据传输方法及系统 |
WO2023207187A1 (zh) * | 2022-04-24 | 2023-11-02 | 深圳市广和通无线股份有限公司 | 上位机唤醒方法、装置、系统、电子设备及存储介质 |
CN115312049A (zh) * | 2022-06-30 | 2022-11-08 | 青岛海尔科技有限公司 | 指令的响应方法、存储介质及电子装置 |
Also Published As
Publication number | Publication date |
---|---|
CN101150809B (zh) | 2011-02-02 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101150809B (zh) | 移动终端处理器串口唤醒与流控的方法 | |
CN100373299C (zh) | 用于控制两处理器之间的数据通信的方法和双处理器装置 | |
CN102984059B (zh) | 千兆以太网冗余网卡及其链路切换条件判定结果控制方法 | |
CN107589824B (zh) | 一种降低仅支持io唤醒mcu功耗的方法 | |
CN111277478B (zh) | 一种基于不同波特率从设备的rs485总线复用控制方法 | |
CN101820347A (zh) | 计算设备和网络间的中介设备中使用的方法和以太网设备 | |
JP3454297B2 (ja) | ネットワーク・スイッチ間のリンクをテストするための方法および装置 | |
CN100411365C (zh) | 一种多数据链路监测维护的方法 | |
CN101924667B (zh) | 一种基于串口的modem异常侦测、断电重启控制方法 | |
CN103095703A (zh) | 一种实现网络与串口数据交互的方法、设备及系统 | |
US20180020061A1 (en) | Method for maintaining transmission control protocol connection and computer system using the method | |
US10891242B2 (en) | Embedded USB2 (eUSB2) repeater operation | |
US6625163B1 (en) | Collision detection on a differential bus | |
CN104639358A (zh) | 批量网络端口切换方法及切换系统 | |
JP2024504296A (ja) | 電源オフアラーム方法及び関連デバイス | |
CN104251536A (zh) | 一种一对多的电流环通信方法及通讯装置 | |
CN103634885A (zh) | 一种识别卡及其运行方法 | |
US6493351B1 (en) | Collision detection on a differential bus | |
CN109800201A (zh) | 基于linux的RS485实时收发控制的驱动方法 | |
CN101626331B (zh) | 用于钢铁连续退火系统的以太网通信控制方法 | |
CN101478448B (zh) | 以太网交换设备的控制方法及装置 | |
CN106411616A (zh) | 一种通过1553b总线管理以太网终端的装置及方法 | |
CN110536467A (zh) | ZigBee网络化工业控制系统通信调度方法及其协调器 | |
CN112468348B (zh) | 适配总线型网络和交换型网络的系统 | |
CN111083772B (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 |
Granted publication date: 20110202 Termination date: 20191103 |
|
CF01 | Termination of patent right due to non-payment of annual fee |