CN117270663A - 一种基于uart通信的车辆电源处理方法、装置及设备 - Google Patents
一种基于uart通信的车辆电源处理方法、装置及设备 Download PDFInfo
- Publication number
- CN117270663A CN117270663A CN202311213650.XA CN202311213650A CN117270663A CN 117270663 A CN117270663 A CN 117270663A CN 202311213650 A CN202311213650 A CN 202311213650A CN 117270663 A CN117270663 A CN 117270663A
- Authority
- CN
- China
- Prior art keywords
- soc
- sleep
- byte
- mcu
- uart communication
- 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.)
- Pending
Links
- 230000006854 communication Effects 0.000 title claims abstract description 89
- 238000004891 communication Methods 0.000 title claims abstract description 88
- 238000003672 processing method Methods 0.000 title claims abstract description 23
- 230000007958 sleep Effects 0.000 claims description 106
- 238000002360 preparation method Methods 0.000 claims description 54
- 230000005059 dormancy Effects 0.000 claims description 33
- 238000000034 method Methods 0.000 claims description 32
- 230000004044 response Effects 0.000 claims description 29
- 238000012545 processing Methods 0.000 claims description 24
- 230000002618 waking effect Effects 0.000 claims description 20
- 238000012790 confirmation Methods 0.000 claims description 12
- 230000002452 interceptive effect Effects 0.000 abstract description 8
- 230000019371 dormancy process Effects 0.000 description 22
- 230000008569 process Effects 0.000 description 17
- 230000015654 memory Effects 0.000 description 14
- 238000010586 diagram Methods 0.000 description 11
- 230000003993 interaction Effects 0.000 description 9
- 230000006870 function Effects 0.000 description 8
- 230000002159 abnormal effect Effects 0.000 description 7
- 230000001960 triggered effect Effects 0.000 description 7
- 230000002427 irreversible effect Effects 0.000 description 6
- 230000005856 abnormality Effects 0.000 description 3
- 230000009286 beneficial effect Effects 0.000 description 2
- 238000004590 computer program Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 238000002955 isolation Methods 0.000 description 2
- 230000000670 limiting effect Effects 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000013515 script Methods 0.000 description 2
- 238000006467 substitution reaction Methods 0.000 description 2
- 230000032683 aging Effects 0.000 description 1
- 238000004422 calculation algorithm Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000018109 developmental process Effects 0.000 description 1
- 230000036961 partial effect Effects 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
Landscapes
- Power Sources (AREA)
Abstract
本申请提供了一种基于UART通信的车辆电源处理方法、装置及设备，借助串口通信，实现电源的交互协议，从协议上确保了MCU在进行电源管理时，各个状态是可查询、可控的，避免了整机陷入黑屏或者需要断蓄电池强制下电的情况。
Description
技术领域
本申请涉及车俩电源控制技术领域，尤其涉及一种基于UART通信的车辆电源处理方法、装置及设备。
背景技术
随着硬件的进步，车机和仪表可以采用硬隔离(仪表和车机在不同的CPU簇/核上运行)或者软隔离(比如hypervisor虚拟化方案，仪表和车机在同样的硬件上运行)的方案运行在同一块SoC上。考虑到快速启动、CAN网络的管理以及休眠静态电流的要求，一般采用MCU+SoC的方案，MCU负责CAN网络、电源管理及部分快速启动需求，SoC负责仪表和车机的应用业务。
在需要休眠时，MCU需要先给SoC下电，然后MCU也进入休眠模式，保证整机在休眠时满足静态电流的要求。传统的车机和仪表分属两个不同的CPU，可以独立进行上下电控制；座舱域控中仪表和车机在同一颗SoC上实现，但仪表和车机的电源需求不同，所以就需要有电源协议来进行交互，确保座舱域控制器运行的稳定。
在车机、仪表进入休眠的过程中可能会出现某些车身信号的突然活动导致不能继续休眠，转而进入工作状态；在休眠时也会因为车机、仪表出现异常导致无法响应相关的消息。不论哪些异常的产生，都会导致休眠过程被意外打断，整机的处理流程陷入异常，对外表现就是黑屏、死机、无响应等，严重影响体验和安全。
发明内容
有鉴于此，本申请实施例提供了一种基于UART通信的车辆电源处理方法、装置及设备，能够借助串口通信，实现电源的交互协议，从协议上确保了MCU在进行电源管理时，各个状态是可查询、可控的，避免了整机陷入黑屏或者需要断蓄电池强制下电的情况。
本申请实施例的技术方案是这样实现的：
第一方面，本申请实施例提供一种基于UART通信的车辆电源处理方法，应用于MCU，所述车辆包括所述MCU和SoC，所述MCU和所述SoC通过UART通信协议进行通信，所述方法包括：
响应所述车辆启动/唤醒，获取并存储此次启动/唤醒的启动/唤醒原因；
对所述启动/唤醒原因进行判断处理，若所述启动/唤醒原因为复位，向所述SoC发送复位指令，以使所述SoC满足复位时序；若所述启动/唤醒原因为正常启动，向电源发送上电指令，以使所述SoC上电；
向所述SoC发送握手请求，当超过预设的第一等待时间后未收到所述SoC的握手确认，控制重启所述SoC。
第二方面，本申请实施例提供一种基于UART通信的车辆电源处理方法，应用于MCU，所述车辆包括所述MCU和SoC，所述MCU和所述SoC通过UART通信协议进行通信，所述方法包括：
当所述车辆的车机和仪表需要休眠或上下电时，向所述SoC发送休眠请求；
响应所述SoC的休眠确认，接收所述SoC返回的休眠准备信号；其中，所述SoC返回所述休眠准备信号后进入休眠准备状态，所述休眠准备状态仅保留UART通信；
向所述SoC发送查询请求，其中，所述查询请求用于查询所述SoC是否可以下电；
接收所述SoC返回的所述休眠准备状态，并基于所述休眠准备状态控制所述SoC取消休眠或下电或重启。
第三方面，本申请实施例还提供一种基于UART通信的车辆电源处理装置，包括MCU和SoC，所述MCU和所述SoC通过UART通信协议进行通信，所述装置包括：
第一响应模块，用于响应所述车辆启动/唤醒，获取并存储此次启动/唤醒的启动/唤醒原因；
判断模块，用于对所述启动/唤醒原因进行判断处理，若所述启动/唤醒原因为复位，向所述SoC发送复位指令，以使所述SoC满足复位时序；若所述启动/唤醒原因为正常启动，向电源发送上电指令，以使所述SoC上电；
第一发送模块，用于向所述SoC发送握手请求，当超过预设的第一等待时间后未收到所述SoC的握手确认，控制重启所述SoC。
第四方面，本申请实施例还提供一种基于UART通信的车辆电源处理装置，包括MCU和SoC，所述MCU和所述SoC通过UART通信协议进行通信，所述装置包括：
第二发送模块，用于当所述车辆的车机和仪表需要休眠或上下电时，向所述SoC发送休眠请求；
第二响应模块，用于响应所述SoC的休眠确认，接收所述SoC返回的休眠准备信号；其中，所述SoC返回所述休眠准备信号后进入休眠准备状态，所述休眠准备状态仅保留UART通信；
查询模块，用于向所述SoC发送查询请求，其中，所述查询请求用于查询所述SoC是否可以下电；
接收模块，用于接收所述SoC返回的所述休眠准备状态，并基于所述休眠准备状态控制所述SoC取消休眠或下电或重启。
第五方面，本申请实施例还提供一种电子设备，包括：处理器、存储介质和总线，所述存储介质存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储介质之间通过总线通信，所述处理器执行所述机器可读指令，以执行第一方面任一项所述的基于UART通信的车辆电源处理方法，或执行第二方面任一项所述的基于UART通信的车辆电源处理方法。
第六方面，本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行第一方面任一项所述的基于UART通信的车辆电源处理方法，或执行第二方面任一项所述的基于UART通信的车辆电源处理方法。
本申请实施例具有以下有益效果：
通过借助串口通信，实现电源的交互协议，MCU端启动时需要主动和SoC握手，若等待一定时间仍然无法和SoC握手，就重启SoC；当握手丢失后需要能够再次建立握手；握手成功后仪表、车机都需要给MCU发送心跳，心跳超时后会触发MCU给SoC复位；对于下电、休眠流程，休眠流程不可逆，如果发生休眠进入的过程被唤醒的情况，会走重启流程；如果休眠过程中发生丢失信号且超时的问题，也会重启，系统重启后会再次判断休眠条件，如果满足休眠条件会再次进入休眠流程，满足休眠条件时车机和仪表是没有显示的，所以从用户角度感受不到；整体上确保了MCU在进行电源管理时，各个状态是可查询、可控的，避免了整机陷入黑屏或者需要断蓄电池强制下电的情况。
附图说明
为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。
图1是本申请实施例提供的步骤S101-S103的流程示意图；
图1a是本申请实施例提供的硬件原理框图；
图1b是本申请实施例提供的MCU与SoC的交互流程图其一；
图2是本申请实施例提供的步骤S201-S204的流程示意图；
图2a是本申请实施例提供的MCU与SoC的交互流程图其二；
图3是本申请实施例提供的基于UART通信的车辆电源处理装置的结构示意图；
图4是本申请实施例提供的另一基于UART通信的车辆电源处理装置的结构示意图；
图5是本申请实施例提供的电子设备的组成结构示意图。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，应当理解，本申请中附图仅起到说明和描述的目的，并不用于限定本申请的保护范围。另外，应当理解，示意性的附图并未按实物比例绘制。本申请中使用的流程图示出了根据本申请的一些实施例实现的操作。应该理解，流程图的操作可以不按顺序实现，没有逻辑的上下文关系的步骤可以反转顺序或者同时实施。此外，本领域技术人员在本申请内容的指引下，可以向流程图添加一个或多个其他操作，也可以从流程图中移除一个或多个操作。
在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。
另外，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。
在以下的描述中，所涉及的术语“第一\第二\第三”仅仅是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。
需要说明的是，本申请实施例中将会用到术语“包括”，用于指出其后所声明的特征的存在，但并不排除增加其它的特征。
除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语是为了描述本申请实施例的目的，不是在限制本申请。
在车机、仪表进入休眠的过程中可能会出现某些车身信号的突然活动导致不能继续休眠，转而进入工作状态；在休眠时也会因为车机、仪表出现异常导致无法响应相关的消息。不论哪些异常的产生，都会导致休眠过程被意外打断，整机的处理流程陷入异常，对外表现就是黑屏、死机、无响应等，严重影响体验和安全。
本方案采用UART通信承载通信协议，设计了MCU和SoC的交互流程，确保在异常条件发生时，整机也可以被正确的休眠、唤醒。
具体的：
1)MCU端通过硬件看门狗确保自身的稳定工作。
当MCU异常时会被MCU的硬件看门狗复位，由于MCU的功能简单且承载的主要是电源和CAN网络管理功能等基础服务，当MCU异常复位时，SoC(车机和仪表)也会被复位。
MCU端启动时需要主动和SoC握手，若等待一定时间仍然无法和SoC握手，就重启SoC；当握手丢失后需要能够再次建立握手；握手成功后仪表、车机都需要给MCU发送心跳，心跳超时后会触发MCU给SoC复位；
MCU端需要实现的电源管理为：
A.响应车机、仪表的电源请求。当车机、仪表需要休眠或者上下电时，通过通信协议请求MCU执行请求，MCU在收到请求后，会根据当前系统的状态来确定如何执行请求。
B.发送当前的电源状态。MCU的电源状态发生改变时，会主动通过通信协议通知车机、仪表。车机仪表会根据不同的电源状态进行相应的响应，当车机、仪表均进入休眠状态时，MCU才能给SoC下电。
C.实现对电源的操作接口。
D.异常逻辑的处理。
以上协议能确保SoC(车机、仪表)通信未丢失时，通过重发和确认机制保证电源消息都有响应；SoC通信丢失后，无需拔插蓄电池的正极即可让座舱域复位；复位后，仍然可以继续和MCU建立通信，保证应用业务能继续执行。
第一实施例：
参见图1，图1是本申请实施例提供的基于UART通信的车辆电源处理方法步骤S101-S103的流程示意图，将结合图1示出的步骤S101-S103进行说明。
在步骤S101中，响应所述车辆启动/唤醒，获取并存储此次启动/唤醒的启动/唤醒原因。
在步骤S102中，对所述启动/唤醒原因进行判断处理，若所述启动/唤醒原因为复位，向所述SoC发送复位指令，以使所述SoC满足复位时序；若所述启动/唤醒原因为正常启动，向电源发送上电指令，以使所述SoC上电。
在步骤S103中，向所述SoC发送握手请求，当超过预设的第一等待时间后未收到所述SoC的握手确认，控制重启所述SoC。
在一些实施例中，所述方法还包括：
接收所述Soc发送的心跳信号；其中，所述心跳信号为车机和仪表的心跳信号；
当超过预设的第二等待时间后仍未收到所述Soc发送的所述心跳信号，向所述Soc发送重启指令，以控制所述SoC重启。
示例的，请参见图1a和图1b，图1a是本申请实施例提供的硬件原理框图，图1b是本申请实施例提供的MCU与SoC的交互流程图其一，如图1a所示，需要休眠时，MCU需要先给SoC下电，然后MCU也进入休眠模式，保证整机在休眠时满足静态电流的要求。传统的车机和仪表分属两个不同的CPU，可以独立进行上下电控制；座舱域控中仪表和车机在同一颗SoC上实现，但仪表和车机的电源需求不同，所以就需要有电源协议来进行交互，确保座舱域控制器运行的稳定。
启动时电源交互及异常处理逻辑如图1b所示，在启动或唤醒时，MCU会存储此次启动的原因并进行判断，若启动原因是复位，那么对应的，也需要控制SoC复位以确保满足复位时序；若启动原因为正常启动，则通过电源向SoC上电，等待SoC启动。MCU端启动时需要主动和SoC握手，若等待一定时间仍然无法和SoC握手，就重启SoC；当握手丢失后需要能够再次建立握手；握手成功后仪表、车机都需要给MCU发送心跳，心跳超时后会触发MCU给SoC复位。在本申请实施例中，心跳可以为1S一次。
在一些实施例中，所述UART通信协议的协议栈采用如下规范：
数据帧的前两个字节为帧头，分别固定为0xc3和0x3c；
第三个字节为控制字节，所述控制字节用于对数据帧、应答帧、是否需要应答的控制字进行识别；
第四个字节为数据长度；
最后一个字节为校验字节，用于对数据帧进行校验；
所述第四个字节和所述最后一个字节之间为应用协议内容。
协议栈在设计时，考虑到数据丢失的情况，设计了重发和应答机制；同时设计了两个不同的发送队列，对发送优先级进行管控，时效要求较高的数据通信可以选在快速发送队列。通信协议数据规范表1所示：
表1
| HEAD(2Byte) | CMDCTRL | LEN | CMDMAIN | CMDSUB | SN | DATA0～DATAN | CHECK |
| 0xc3 0x3c | 0x00 | 0xNN |
这里，数据帧的头两个字节为帧头，固定为0xc3 0x3c；第三个字节为控制字节，用以对数据帧、应答帧、是否需要应答的控制字进行识别；第四个字节为数据长度，之后跟随具体的应用协议内容。在数据帧的最后一个字节是校验字节，可根据需求对数据帧计算校验值，放入最后一个字节，收到数据后根据同样的校验算法计算出校验值和收到的数据帧的最后一个字节比较，以确定通信过程是否出错。
电源交互协议设计时，按请求和响应设计两类的交互协议，能够实现电源状态的发送和电源请求即可。
SoC上电后，车机和仪表开运行各自的系统，收到MCU的握手指令后，各自给MCU发送心跳；应用启动后即可通过通信协议获取电源状态或者进行电源请求。具体流程参考MCU的上电流程。
第二实施例：
参见图2，图2是本申请实施例提供的基于UART通信的车辆电源处理方法步骤S201-S204的流程示意图，将结合图2示出的步骤S201-S204进行说明。
在步骤S201中，当所述车辆的车机和仪表需要休眠或上下电时，向所述SoC发送休眠请求。
在步骤S202中，响应所述SoC的休眠确认，接收所述SoC返回的休眠准备信号；其中，所述SoC返回所述休眠准备信号后进入休眠准备状态，所述休眠准备状态仅保留UART通信。
在步骤S203中，向所述SoC发送查询请求，其中，所述查询请求用于查询所述SoC是否可以下电。
在步骤S204中，接收所述SoC返回的所述休眠准备状态，并基于所述休眠准备状态控制所述SoC取消休眠或下电或重启。
在一些实施例中，所述基于所述休眠准备状态控制所述SoC取消休眠或下电或重启，包括：
向所述SoC发送取消休眠指令；
接收所述SoC返回的当前状态，当所述当前状态为已进入休眠准备阶段且无法撤销时，调用重启系统和复位系统；
通过所述重启系统对所述SoC进行下电或者通过所述复位系统对SoC进行重启。
在一些实施例中，通过所述重启系统和所述复位系统对SoC进行下电和重启，包括：
在满足预设条件时，执行下电流程，以及在不满足预设条件时，执行重启流程；其中，所述预设条件为不超时且SoC返回的当前状态准备完成。
示例的，参见图2a，图2a是本申请实施例提供的MCU与SoC的交互流程图其二，如图2所示，休眠流程不可逆，如果发生休眠进入的过程被唤醒的情况，会走重启流程；如果休眠过程中发生丢失信号且超时的问题，也会重启，系统重启后会再次判断休眠条件，如果满足休眠条件会再次进入休眠流程，满足休眠条件时车机和仪表是没有显示的，所以从用户角度感受不到。
在一些实施例中，所述UART通信协议的协议栈采用如下规范：
数据帧的前两个字节为帧头，分别固定为0xc3和0x3c；
第三个字节为控制字节，所述控制字节用于对数据帧、应答帧、是否需要应答的控制字进行识别；
第四个字节为数据长度；
最后一个字节为校验字节，用于对数据帧进行校验；
所述第四个字节和所述最后一个字节之间为应用协议内容。
同样的，在该实施例中，协议栈的设计与实施例一相同，具体原理请参见实施例一，此处不再赘述。
另外，除了UART外，也可以利用SPI总线设计通信协议进行电源管理。对于MCU而言UART和SPI总线相对简单，易于上层协议的实现。
综上所述，通过本申请实施例具有以下有益效果：
通过借助串口通信，实现电源的交互协议，MCU端启动时需要主动和SoC握手，若等待一定时间仍然无法和SoC握手，就重启SoC；当握手丢失后需要能够再次建立握手；握手成功后仪表、车机都需要给MCU发送心跳，心跳超时后会触发MCU给SoC复位；对于下电、休眠流程，休眠流程不可逆，如果发生休眠进入的过程被唤醒的情况，会走重启流程；如果休眠过程中发生丢失信号且超时的问题，也会重启，系统重启后会再次判断休眠条件，如果满足休眠条件会再次进入休眠流程，满足休眠条件时车机和仪表是没有显示的，所以从用户角度感受不到；整体上确保了MCU在进行电源管理时，各个状态是可查询、可控的，避免了整机陷入黑屏或者需要断蓄电池强制下电的情况。
基于同一发明构思，本申请实施例中还提供了与第一实施例中基于UART通信的车辆电源处理方法对应的基于UART通信的车辆电源处理装置，由于本申请实施例中的装置解决问题的原理与上述基于UART通信的车辆电源处理方法相似，因此装置的实施可以参见方法的实施，重复之处不再赘述。
如图3所示，图3是本申请实施例提供的基于UART通信的车辆电源处理装置的结构示意图。基于UART通信的车辆电源处理装置包括MCU和SoC，所述MCU和所述SoC通过UART通信协议进行通信，还包括：
第一响应模块301，用于响应所述车辆启动/唤醒，获取并存储此次启动/唤醒的启动/唤醒原因；
判断模块302，用于对所述启动/唤醒原因进行判断处理，若所述启动/唤醒原因为复位，向所述SoC发送复位指令，以使所述SoC满足复位时序；若所述启动/唤醒原因为正常启动，向电源发送上电指令，以使所述SoC上电；
第一发送模块303，用于向所述SoC发送握手请求，当超过预设的第一等待时间后未收到所述SoC的握手确认，控制重启所述SoC。
本领域技术人员应当理解，图3所示的基于UART通信的车辆电源处理装置中的各单元的实现功能可参照前述第一实施例中的基于UART通信的车辆电源处理方法的相关描述而理解。图3所示的基于UART通信的车辆电源处理装置中的各单元的功能可通过运行于处理器上的程序而实现，也可通过具体的逻辑电路而实现。
在一种可能的实施方式中，第一发送模块303还包括：
接收所述Soc发送的心跳信号；其中，所述心跳信号为车机和仪表的心跳信号；
当超过预设的第二等待时间后仍未收到所述Soc发送的所述心跳信号，向所述Soc发送重启指令，以控制所述SoC重启。
在一种可能的实施方式中，所述UART通信协议的协议栈采用如下规范：
数据帧的前两个字节为帧头，分别固定为0xc3和0x3c；
第三个字节为控制字节，所述控制字节用于对数据帧、应答帧、是否需要应答的控制字进行识别；
第四个字节为数据长度；
最后一个字节为校验字节，用于对数据帧进行校验；
所述第四个字节和所述最后一个字节之间为应用协议内容。
上述基于UART通信的车辆电源处理装置通过借助串口通信，实现电源的交互协议，MCU端启动时需要主动和SoC握手，若等待一定时间仍然无法和SoC握手，就重启SoC；当握手丢失后需要能够再次建立握手；握手成功后仪表、车机都需要给MCU发送心跳，心跳超时后会触发MCU给SoC复位；对于下电、休眠流程，休眠流程不可逆，如果发生休眠进入的过程被唤醒的情况，会走重启流程；如果休眠过程中发生丢失信号且超时的问题，也会重启，系统重启后会再次判断休眠条件，如果满足休眠条件会再次进入休眠流程，满足休眠条件时车机和仪表是没有显示的，所以从用户角度感受不到；整体上确保了MCU在进行电源管理时，各个状态是可查询、可控的，避免了整机陷入黑屏或者需要断蓄电池强制下电的情况。
基于同一发明构思，本申请实施例中还提供了与第二实施例中基于UART通信的车辆电源处理方法对应的基于UART通信的车辆电源处理装置，由于本申请实施例中的装置解决问题的原理与上述基于UART通信的车辆电源处理方法相似，因此装置的实施可以参见方法的实施，重复之处不再赘述。
如图4所示，图4是本申请实施例提供的另一基于UART通信的车辆电源处理装置的结构示意图。基于UART通信的车辆电源处理装置包括MCU和SoC，所述MCU和所述SoC通过UART通信协议进行通信，还包括：
第二发送模块401，用于当所述车辆的车机和仪表需要休眠或上下电时，向所述SoC发送休眠请求；
第二响应模块402，用于响应所述SoC的休眠确认，接收所述SoC返回的休眠准备信号；其中，所述SoC返回所述休眠准备信号后进入休眠准备状态，所述休眠准备状态仅保留UART通信；
查询模块403，用于向所述SoC发送查询请求，其中，所述查询请求用于查询所述SoC是否可以下电；
接收模块404，用于接收所述SoC返回的所述休眠准备状态，并基于所述休眠准备状态控制所述SoC取消休眠或下电或重启。
在一种可能的实施方式中，接收模块404基于所述休眠准备状态控制所述SoC取消休眠或下电或重启，包括：
向所述SoC发送取消休眠指令；
接收所述SoC返回的当前状态，当所述当前状态为已进入休眠准备阶段且无法撤销时，调用重启系统和复位系统；
通过所述重启系统对所述SoC进行下电或者通过所述复位系统对SoC进行重启。
在一种可能的实施方式中，接收模块404通过所述重启系统和所述复位系统对SoC进行下电和重启，包括：
在满足预设条件时，执行下电流程，以及在不满足预设条件时，执行重启流程；其中，所述预设条件为不超时且SoC返回的当前状态准备完成。
在一种可能的实施方式中，所述UART通信协议的协议栈采用如下规范：
数据帧的前两个字节为帧头，分别固定为0xc3和0x3c；
第三个字节为控制字节，所述控制字节用于对数据帧、应答帧、是否需要应答的控制字进行识别；
第四个字节为数据长度；
最后一个字节为校验字节，用于对数据帧进行校验；
所述第四个字节和所述最后一个字节之间为应用协议内容。
本领域技术人员应当理解，图4所示的基于UART通信的车辆电源处理装置中的各单元的实现功能可参照前述第二实施例中的基于UART通信的车辆电源处理方法的相关描述而理解。图4所示的基于UART通信的车辆电源处理装置中的各单元的功能可通过运行于处理器上的程序而实现，也可通过具体的逻辑电路而实现。
如图5所示，图5为本申请实施例提供的电子设备500的组成结构示意图，所述电子设备500，包括：
处理器501、存储介质502和总线503，所述存储介质502存储有所述处理器501可执行的机器可读指令，当电子设备500运行时，所述处理器501与所述存储介质502之间通过总线503通信，所述处理器501执行所述机器可读指令，以执行以下步骤：
响应所述车辆启动/唤醒，获取并存储此次启动/唤醒的启动/唤醒原因；
对所述启动/唤醒原因进行判断处理，若所述启动/唤醒原因为复位，向所述SoC发送复位指令，以使所述SoC满足复位时序；若所述启动/唤醒原因为正常启动，向电源发送上电指令，以使所述SoC上电；
向所述SoC发送握手请求，当超过预设的第一等待时间后未收到所述SoC的握手确认，控制重启所述SoC。
在一种可能的实施方式中，所述处理器501还包括：
接收所述Soc发送的心跳信号；其中，所述心跳信号为车机和仪表的心跳信号；
当超过预设的第二等待时间后仍未收到所述Soc发送的所述心跳信号，向所述Soc发送重启指令，以控制所述SoC重启。
在一种可能的实施方式中，所述UART通信协议的协议栈采用如下规范：
数据帧的前两个字节为帧头，分别固定为0xc3和0x3c；
第三个字节为控制字节，所述控制字节用于对数据帧、应答帧、是否需要应答的控制字进行识别；
第四个字节为数据长度；
最后一个字节为校验字节，用于对数据帧进行校验；
所述第四个字节和所述最后一个字节之间为应用协议内容。
所述处理器501执行所述机器可读指令，以执行以下步骤：
当所述车辆的车机和仪表需要休眠或上下电时，向所述SoC发送休眠请求；
响应所述SoC的休眠确认，接收所述SoC返回的休眠准备信号；其中，所述SoC返回所述休眠准备信号后进入休眠准备状态，所述休眠准备状态仅保留UART通信；
向所述SoC发送查询请求，其中，所述查询请求用于查询所述SoC是否可以下电；
接收所述SoC返回的所述休眠准备状态，并基于所述休眠准备状态控制所述SoC取消休眠或下电或重启。
在一种可能的实施方式中，所述处理器501基于所述休眠准备状态控制所述SoC取消休眠或下电或重启，包括：
向所述SoC发送取消休眠指令；
接收所述SoC返回的当前状态，当所述当前状态为已进入休眠准备阶段且无法撤销时，调用重启系统和复位系统；
通过所述重启系统对所述SoC进行下电或者通过所述复位系统对SoC进行重启。
在一种可能的实施方式中，所述处理器501通过所述重启系统和所述复位系统对SoC进行下电和重启，包括：
在满足预设条件时，执行下电流程，以及在不满足预设条件时，执行重启流程；其中，所述预设条件为不超时且SoC返回的当前状态准备完成。
在一种可能的实施方式中，所述UART通信协议的协议栈采用如下规范：
数据帧的前两个字节为帧头，分别固定为0xc3和0x3c；
第三个字节为控制字节，所述控制字节用于对数据帧、应答帧、是否需要应答的控制字进行识别；
第四个字节为数据长度；
最后一个字节为校验字节，用于对数据帧进行校验；
所述第四个字节和所述最后一个字节之间为应用协议内容。
实际应用时，所述电子设备500中的各个组件通过总线503耦合在一起。可理解，总线503用于实现这些组件之间的连接通信。总线503除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图5中将各种总线都标为总线503。
上述电子设备通过借助串口通信，实现电源的交互协议，MCU端启动时需要主动和SoC握手，若等待一定时间仍然无法和SoC握手，就重启SoC；当握手丢失后需要能够再次建立握手；握手成功后仪表、车机都需要给MCU发送心跳，心跳超时后会触发MCU给SoC复位；对于下电、休眠流程，休眠流程不可逆，如果发生休眠进入的过程被唤醒的情况，会走重启流程；如果休眠过程中发生丢失信号且超时的问题，也会重启，系统重启后会再次判断休眠条件，如果满足休眠条件会再次进入休眠流程，满足休眠条件时车机和仪表是没有显示的，所以从用户角度感受不到；整体上确保了MCU在进行电源管理时，各个状态是可查询、可控的，避免了整机陷入黑屏或者需要断蓄电池强制下电的情况。
本申请实施例还提供了一种计算机可读存储介质，所述存储介质存储有可执行指令，当所述可执行指令被至少一个处理器501执行时，实现以下步骤：
响应所述车辆启动/唤醒，获取并存储此次启动/唤醒的启动/唤醒原因；
对所述启动/唤醒原因进行判断处理，若所述启动/唤醒原因为复位，向所述SoC发送复位指令，以使所述SoC满足复位时序；若所述启动/唤醒原因为正常启动，向电源发送上电指令，以使所述SoC上电；
向所述SoC发送握手请求，当超过预设的第一等待时间后未收到所述SoC的握手确认，控制重启所述SoC。
在一种可能的实施方式中，所述可执行指令被至少一个处理器501执行时，还包括：
接收所述Soc发送的心跳信号；其中，所述心跳信号为车机和仪表的心跳信号；
当超过预设的第二等待时间后仍未收到所述Soc发送的所述心跳信号，向所述Soc发送重启指令，以控制所述SoC重启。
在一种可能的实施方式中，所述UART通信协议的协议栈采用如下规范：
数据帧的前两个字节为帧头，分别固定为0xc3和0x3c；
第三个字节为控制字节，所述控制字节用于对数据帧、应答帧、是否需要应答的控制字进行识别；
第四个字节为数据长度；
最后一个字节为校验字节，用于对数据帧进行校验；
所述第四个字节和所述最后一个字节之间为应用协议内容。
当所述可执行指令被至少一个处理器501执行时，实现以下步骤：
当所述车辆的车机和仪表需要休眠或上下电时，向所述SoC发送休眠请求；
响应所述SoC的休眠确认，接收所述SoC返回的休眠准备信号；其中，所述SoC返回所述休眠准备信号后进入休眠准备状态，所述休眠准备状态仅保留UART通信；
向所述SoC发送查询请求，其中，所述查询请求用于查询所述SoC是否可以下电；
接收所述SoC返回的所述休眠准备状态，并基于所述休眠准备状态控制所述SoC取消休眠或下电或重启。
在一种可能的实施方式中，所述基于所述休眠准备状态控制所述SoC取消休眠或下电或重启，包括：
向所述SoC发送取消休眠指令；
接收所述SoC返回的当前状态，当所述当前状态为已进入休眠准备阶段且无法撤销时，调用重启系统和复位系统；
通过所述重启系统对所述SoC进行下电或者通过所述复位系统对SoC进行重启。
在一种可能的实施方式中，通过所述重启系统和所述复位系统对SoC进行下电和重启，包括：
在满足预设条件时，执行下电流程，以及在不满足预设条件时，执行重启流程；其中，所述预设条件为不超时且SoC返回的当前状态准备完成。
在一种可能的实施方式中，所述UART通信协议的协议栈采用如下规范：
数据帧的前两个字节为帧头，分别固定为0xc3和0x3c；
第三个字节为控制字节，所述控制字节用于对数据帧、应答帧、是否需要应答的控制字进行识别；
第四个字节为数据长度；
最后一个字节为校验字节，用于对数据帧进行校验；
所述第四个字节和所述最后一个字节之间为应用协议内容。
在一些实施例中，存储介质可以是磁性随机存取存储器(FRAM，FerromagneticRandom Access Memory)、只读存储器(ROM，Read Only Memory)、可编程只读存储器(PROM，Programmable Read Only Memory)、可擦除可编程只读存储器(EPROM，ErasableProgrammable Read Only Memory)、电可擦除可编程只读存储器(EEPROM，ElectricallyErasable Programmable Read Only Memory)、快闪存储器(Flash Memory)、磁表面存储器、光盘、或只读光盘(CD ROM，Compact Disc Read Only Memory)等存储器；也可以是包括上述存储器之一或任意组合的各种设备。
在一些实施例中，可执行指令可以采用程序、软件、软件模块、脚本或代码的形式，按任意形式的编程语言(包括编译或解释语言，或者声明性或过程性语言)来编写，并且其可按任意形式部署，包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。
作为示例，可执行指令可以但不一定对应于文件系统中的文件，可以被存储在保存其它程序或数据的文件的一部分，例如，存储在超文本标记语言(HTML，HyperTextMarkupLanguage)文档中的一个或多个脚本中，存储在专用于所讨论的程序的单个文件中，或者，存储在多个协同文件(例如，存储一个或多个模块、子程序或代码部分的文件)中。
作为示例，可执行指令可被部署为在一个计算设备上执行，或者在位于一个地点的多个计算设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算设备上执行。
上述计算机可读存储介质通过借助串口通信，实现电源的交互协议，MCU端启动时需要主动和SoC握手，若等待一定时间仍然无法和SoC握手，就重启SoC；当握手丢失后需要能够再次建立握手；握手成功后仪表、车机都需要给MCU发送心跳，心跳超时后会触发MCU给SoC复位；对于下电、休眠流程，休眠流程不可逆，如果发生休眠进入的过程被唤醒的情况，会走重启流程；如果休眠过程中发生丢失信号且超时的问题，也会重启，系统重启后会再次判断休眠条件，如果满足休眠条件会再次进入休眠流程，满足休眠条件时车机和仪表是没有显示的，所以从用户角度感受不到；整体上确保了MCU在进行电源管理时，各个状态是可查询、可控的，避免了整机陷入黑屏或者需要断蓄电池强制下电的情况。
在本申请所提供的几个实施例中，应该理解到，所揭露的方法和电子设备，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。
所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，平台服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
以上仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。
Claims (10)
1.一种基于UART通信的车辆电源处理方法，其特征在于，应用于MCU，所述车辆包括所述MCU和SoC，所述MCU和所述SoC通过UART通信协议进行通信，所述方法包括：
响应所述车辆启动/唤醒，获取并存储此次启动/唤醒的启动/唤醒原因；
对所述启动/唤醒原因进行判断处理，若所述启动/唤醒原因为复位，向所述SoC发送复位指令，以使所述SoC满足复位时序；若所述启动/唤醒原因为正常启动，向电源发送上电指令，以使所述SoC上电；
向所述SoC发送握手请求，当超过预设的第一等待时间后未收到所述SoC的握手确认，控制重启所述SoC。
2.根据权利要求1所述的方法，其特征在于，所述方法还包括：
接收所述Soc发送的心跳信号；其中，所述心跳信号为车机和仪表的心跳信号；
当超过预设的第二等待时间后仍未收到所述Soc发送的所述心跳信号，向所述Soc发送重启指令，以控制所述SoC重启。
3.根据权利要求1所述的方法，其特征在于，所述UART通信协议的协议栈采用如下规范：
数据帧的前两个字节为帧头，分别固定为0xc3和0x3c；
第三个字节为控制字节，所述控制字节用于对数据帧、应答帧、是否需要应答的控制字进行识别；
第四个字节为数据长度；
最后一个字节为校验字节，用于对数据帧进行校验；
所述第四个字节和所述最后一个字节之间为应用协议内容。
4.一种基于UART通信的车辆电源处理方法，其特征在于，应用于MCU，所述车辆包括所述MCU和SoC，所述MCU和所述SoC通过UART通信协议进行通信，所述方法包括：
当所述车辆的车机和仪表需要休眠或上下电时，向所述SoC发送休眠请求；
响应所述SoC的休眠确认，接收所述SoC返回的休眠准备信号；其中，所述SoC返回所述休眠准备信号后进入休眠准备状态，所述休眠准备状态仅保留UART通信；
向所述SoC发送查询请求，其中，所述查询请求用于查询所述SoC是否可以下电；
接收所述SoC返回的所述休眠准备状态，并基于所述休眠准备状态控制所述SoC取消休眠或下电或重启。
5.根据权利要求4所述的方法，其特征在于，所述基于所述休眠准备状态控制所述SoC取消休眠或下电或重启，包括：
向所述SoC发送取消休眠指令；
接收所述SoC返回的当前状态，当所述当前状态为已进入休眠准备阶段且无法撤销时，调用重启系统和复位系统；
通过所述重启系统对所述SoC进行下电或者通过所述复位系统对SoC进行重启。
6.根据权利要求5所述的方法，其特征在于，通过所述重启系统和所述复位系统对SoC进行下电和重启，包括：
在满足预设条件时，执行下电流程，以及在不满足预设条件时，执行重启流程；其中，所述预设条件为不超时且SoC返回的当前状态准备完成。
7.根据权利要求4所述的方法，其特征在于，所述UART通信协议的协议栈采用如下规范：
数据帧的前两个字节为帧头，分别固定为0xc3和0x3c；
第三个字节为控制字节，所述控制字节用于对数据帧、应答帧、是否需要应答的控制字进行识别；
第四个字节为数据长度；
最后一个字节为校验字节，用于对数据帧进行校验；
所述第四个字节和所述最后一个字节之间为应用协议内容。
8.一种基于UART通信的车辆电源处理装置，其特征在于，包括MCU和SoC，所述MCU和所述SoC通过UART通信协议进行通信，所述装置包括：
第一响应模块，用于响应所述车辆启动/唤醒，获取并存储此次启动/唤醒的启动/唤醒原因；
判断模块，用于对所述启动/唤醒原因进行判断处理，若所述启动/唤醒原因为复位，向所述SoC发送复位指令，以使所述SoC满足复位时序；若所述启动/唤醒原因为正常启动，向电源发送上电指令，以使所述SoC上电；
第一发送模块，用于向所述SoC发送握手请求，当超过预设的第一等待时间后未收到所述SoC的握手确认，控制重启所述SoC。
9.一种基于UART通信的车辆电源处理装置，其特征在于，包括MCU和SoC，所述MCU和所述SoC通过UART通信协议进行通信，所述装置包括：
第二发送模块，用于当所述车辆的车机和仪表需要休眠或上下电时，向所述SoC发送休眠请求；
第二响应模块，用于响应所述SoC的休眠确认，接收所述SoC返回的休眠准备信号；其中，所述SoC返回所述休眠准备信号后进入休眠准备状态，所述休眠准备状态仅保留UART通信；
查询模块，用于向所述SoC发送查询请求，其中，所述查询请求用于查询所述SoC是否可以下电；
接收模块，用于接收所述SoC返回的所述休眠准备状态，并基于所述休眠准备状态控制所述SoC取消休眠或下电或重启。
10.一种电子设备，其特征在于，包括：处理器、存储介质和总线，所述存储介质存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储介质之间通过总线通信，所述处理器执行所述机器可读指令，以执行如权利要求1至3任一项所述的基于UART通信的车辆电源处理方法，或执行如权利要求4至7任一项所述的基于UART通信的车辆电源处理方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311213650.XA CN117270663A (zh) | 2023-09-19 | 2023-09-19 | 一种基于uart通信的车辆电源处理方法、装置及设备 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311213650.XA CN117270663A (zh) | 2023-09-19 | 2023-09-19 | 一种基于uart通信的车辆电源处理方法、装置及设备 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN117270663A true CN117270663A (zh) | 2023-12-22 |
Family
ID=89209863
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311213650.XA Pending CN117270663A (zh) | 2023-09-19 | 2023-09-19 | 一种基于uart通信的车辆电源处理方法、装置及设备 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117270663A (zh) |
-
2023
- 2023-09-19 CN CN202311213650.XA patent/CN117270663A/zh active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9424022B2 (en) | Method for updating firmware of an electronic device within a computer | |
| CN107656856A (zh) | 一种基于cpld的系统状态显示方法及装置 | |
| CN115576258B (zh) | 车辆芯片系统控制方法、系统级芯片以及车辆 | |
| CN114661368B (zh) | 一种芯片及其启动方法 | |
| CN101165636A (zh) | 微型计算机、程序和车载电子控制器 | |
| CN117555760B (zh) | 服务器监测方法及装置、基板控制器及嵌入式系统 | |
| CN109669728A (zh) | VxWorks操作系统的软件关机方法及装置 | |
| CN111767174A (zh) | 一种bios刷新控制方法及服务器、存储介质 | |
| CN117270663A (zh) | 一种基于uart通信的车辆电源处理方法、装置及设备 | |
| CN102141920B (zh) | 一种动态配置C-State方法和通信设备 | |
| CN115756622B (zh) | 芯片控制方法及芯片 | |
| CN116225541B (zh) | 一种带内cpu与带外管理bmc通信的方法及通信系统 | |
| CN116691367A (zh) | 一种车辆动力扭矩控制方法、装置、电子设备及存储介质 | |
| CN111858186B (zh) | 车载终端系统监控方法及系统、电子设备及可读存储介质 | |
| CN114116028B (zh) | 行车电脑ecu的唤醒方法、装置、车辆及存储介质 | |
| CN112462909B (zh) | 一体机转接设备的复位控制方法、装置及存储介质 | |
| CN111966199B (zh) | Cpld在线升级缓启方法、装置、设备及存储介质 | |
| CN109857237B (zh) | 工业车载显示屏低功耗控制的方法及工业车载显示装置 | |
| EP2691853B1 (en) | Supervisor system resuming control | |
| CN112208588A (zh) | 一种列车唤醒和休眠系统及方法 | |
| CN115599457B (zh) | 一种基于spi接口的从芯片唤醒与启动方法 | |
| CN113656085B (zh) | 仪表启动方法、装置、设备、存储介质及程序产品 | |
| CN113650498B (zh) | 一种电动车的上电方法、装置、电动车及存储介质 | |
| CN114328044B (zh) | 一种AIC+box拓扑的测试方法、装置和系统 | |
| CN117251103B (zh) | 低延迟进入深度低功耗状态的存储设备及其方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |