标签: 休眠唤醒

系统休眠唤醒技术是电源管理中的关键技术。 它允许系统在闲置时将功耗降至最低，将外部设备、芯片内部IP和时钟置于低功耗状态或完全关闭电源状态，以极大地延长续航时间。此外，在用户需要时，系统也能够迅速恢复电源、时钟、芯片内部IP以及外部设备的工作状态，确保用户的使用体验不受干扰。 飞凌嵌入式OK113i-S开发板支持两种休眠方式：freeze和mem。这两种方式可以通过/sys/power/state文件节点进行操作，用户可以通过在该文件节点写入freeze或mem来触发相应的休眠状态。 在进行休眠之前，系统会配置唤醒源。一旦系统进入休眠状态，可以通过这些唤醒源（如按键、RTC等）在需要时唤醒系统。这种设计允许用户根据需要选择何时以及通过何种方式快速唤醒系统，实现了功耗最小化和快速恢复的平衡。这一机制使得系统在休眠状态下能够极大地减少功耗，同时保留了用户在唤醒后迅速使用系统的便利性。 本篇内容小编会为大家介绍如何让飞凌嵌入式OK113i-S开发板进入休眠模式，以及如何通过RTC时钟实现定时唤醒。 1、关于两种休眠模式 freeze 冻结I/O设备，将它们置于低功耗状态，使处理器进入空闲状态，唤醒最快，耗电比其它方式高。实测OK113i-S开发板在只接串口线的情况下5V供电，电流约为0.112A。 mem 挂起到内存，计算机将目前的运行状态等数据存放在内存，关闭硬盘、外设等设备，进入等待状态。此时内存仍然需要电力维持其数据，但整机耗电很少。恢复时计算机从内存读出数据，回到挂起前的状态，恢复速度较快。实测OK113i-S开发板在只接串口线情况下5V供电，电流约为0.076A。 （1）cat /sys/power/state可以看到OK113i-S开发板支持的模式有哪些： /sys/power/state 进入freeze模式： /sys/power/state 进入mem模式： 2 、通过RTC定时唤醒 注意：此处需要使用内部RTC，外部RTC不支持唤醒功能，后面我们还会提及。 进入开发板的内核配置： root@ubuntu: /home/forlinx/work/linux/OK113i-linux-sdk# ./build.sh menuconfig 根据下图框选进行功能选择： 配置完成后保存，然后修改设备树文件，打开内部RTC功能。 保存后进行编译： 编译成功后打包成镜像，烧写完成后，我们在串口终端进行测试。 进入串口终端进行测试： /sys/class/rtc/rtc0/wakealarm 此处为15秒定时，可自由设置时间，命令执行后就会生效，RTC会单独计时，如果是15秒后才进入休眠，不会触发唤醒。（注意此处需要使用内部RTC，外部RTC不支持唤醒功能） /sys/power/state （这里两条指令输入时要紧凑，两条指令间，间隔太长就无效了) （这里需要注意，我们在未打开内部RTC时，我们的外部RTC默认节点是rtc0，修改后外部rtc设备节点会变更成rtc1。） 到这里，我们就完成了在飞凌嵌入式OK113i-S开发板上实现休眠以及通过RTC定时唤醒的全部操作了，当然，不同的主控平台板卡的具体操作会有差异，但是整体思路是一样的，具体可以根据相对应的平台查看相关资料来确定具体步骤，希望本文提供的方法能够对屏幕前的工程师朋友们的项目开发有所帮助。

近年来，汽车的节能问题备受关注，消减不必要的能源损耗是一种非常有效的方法。当前，大多数车辆在点火钥匙打到OFF档之后，部分功能仍需要使用，例如：车辆防盗、电子驻车功能等。为了降低电量消耗，避免蓄电池电量消耗过多导致汽车无法启动，需要KL30节点在OFF档之后能进入低功耗状态，关闭大部分不需要的功能，尽可能减少电量消耗。对于分布式功能网络，由于连接到总线上的节点需要协同工作，所以各节点遵循同样的协议以实现同步睡眠及唤醒。 当前，大多数的车辆都是遵循OSEK或者AUTOSAR网络管理协议，来实现节点休眠唤醒功能的。由于目前车辆的电子电气系统越来越复杂，KL30节点也越来越多，当前的网络管理协议也逐渐呈现出一些弊端。例如：IG OFF时，当某个功能需要总线上的一个节点与另一个节点进行通信时需要把该网段上的所有节点唤醒，如果跨网段，还需要唤醒两个网段上的所有节点，不相关的节点都进入非低功耗状态，这样就造成不必要的电量消耗。又例如：为了保证车辆安全，在点火钥匙打到OFF档后，部分节点还需要通信一段时间，通常为几分钟到几十分钟，此时，由于部分节点的通信需求，网段上的所有节点都不能进入低功耗状态，极大地消耗蓄电池电量。 为了解决这个问题，欧洲一些汽车厂商已经开始制定新的网络管理方案-局部网络（Partial Network，简称PN）管理，以实现分组睡眠和唤醒。 局部网络管理概念 与传统网络管理同睡同醒的逻辑不同，局部网络管理根据不同的电子电气EE功能（feature）在整个网络内划分出多个虚拟的局部网络，各个局部网络间可以实现单独的休眠唤醒功能，互不影响。如图1所示，根据EE功能（feature），网络上的若干节点被划分为2个PN组，PN1组为车门解锁相关feature，PN2组为Radio相关feature。在点火钥匙处于OFF档且所有节点处于睡眠状态后，PEPS需要对车门解锁，此时PEPS只需唤醒与解锁功能相关的BCM和IC，其他与该功能不相关的节点仍然处于睡眠状态。 图1 局部网络示例 1)唤醒逻辑：节点只有收到所属PN组内的特定报文（通常是网络管理报文），才被唤醒。PEPS发送的NM报文只能将IC和BCM唤醒，而Radio和Tuner仍处于睡眠状态； 2)睡眠逻辑：节点所属的PN组内的所有节点均满足该PN的睡眠条件后，该PN组内的节点实现协同睡眠。其他PN组的节点通信不受影响。 因此，根据功能来划分局部网络的方式，可以在一个功能激活的时候，仅使相关节点被唤醒并进行通信，而其他的节点仍然可以保持睡眠状态，这样就极大程度上减少了电量消耗。PN组的划分非常灵活，不仅可以对同一网段上的节点进行分组，还可以将跨网段的节点划分到同一PN组内，除此之外，一个节点可以属于一个或多个PN。 局部网络管理实现 相对于传统的CAN通信硬件和软件实现，局部网络管理需要实现以下几个部分： 硬件实现 在CAN总线中报文是以广播形式发送的，当节点处于休眠状态时，大部分收发器检测到总线中的报文时会唤醒节点。这就会使网络管理的局部网络功能失效。 为实现部分节点唤醒的功能，需要特殊的收发器支持。特殊收发器具有报文滤波功能，只在收到特定报文之后才能被唤醒。NXP已经率先推出支持局部网络管理的收发器TJA1145和UJA1168。TJA1145是一种高速CAN收发器，而UJA1168是集成5V/100mA微处理器供电的CAN系统基础芯片。 除了传统收发器的TX、RX引脚，NXP的两款支持PN的收发器均通过SPI与CAN控制器相连。通过SPI，MCU可控制CAN收发器的模式转换以及设置收发器的报文滤波，实现特定报文唤醒的功能。连接方式参见图2。 图2 支持PN的收发器连接实例图 软件实现 除了需要支持硬件滤波的收发器外，在软件部分，还需要遵循一套支持PN的网络管理协议来配合应用程序实现分组协同睡眠和唤醒。AUTOSAR组织已经推出支持PN的网络管理协议AUTOSARR3.2.1，该协议主要通过特定的网络管理报文来实现分组睡眠。 AUTOSAR 3.2.1中定义的CAN网络管理报文格式如图3所示。Byte 0表示源节点地址，Byte 1为固定格式ControlBit Vector.不同的bit有特殊的含义，如图3所示，该字节的bit 6（Partial Network Bit）就表明该报文是否与PN相关。NM报文中其余字节为User data，可根据用户需求自定义。OEM可根据EE功能定义，指定User data中的不同的位来表示不同的PN组是否需要保持唤醒。例如，将Byte 2的bit 0设定为PN1组的唤醒指示位时，如节点欲保持PN1组唤醒，则需将其置为1；如不需要保持PN1组唤醒，则将其位置为0或停发网络管理报文。当网络上同属于PN1的所有节点都没有保持唤醒的要求时，PN1组按照睡眠逻辑协同进入睡眠。 图3 默认网络管理报文格式定义 图4 Control Bit Vector格式定义 每个节点只关心自己所处的PN组的状态，在节点发送的网络管理报文加入所属PN的信息(User data)，就可以实现不同PN分组休眠和唤醒。 结论 本文介绍了局部网络（PN）管理的概念及优势，并阐述了其在CAN总线上的硬件及软件实现。可以看到，随着汽车EE功能越来越复杂，局部网络管理的分组睡眠和唤醒的机制是一种有效的节省电量的方法。 《电子设计技术》网站版权所有，谢绝转载