板子功耗高的原因有哪些

低功耗蓝牙应用对功耗要求越低越好,功耗越低电池续航时间就越长,用户体验就越好。当你发现你板子功耗偏高时,建议按照如下步骤进行自检:

1)       确认理论功耗值。BLE功耗跟广播间隔或者连接间隔是成正比关系的,所以20ms连接间隔下的功耗几乎是1s状态下的50倍!,单纯地问“1mA功耗高不高?”是没有意义的,必须结合特定的应用场景才有意义。不管是广播还是连接,特定的使用场景会有一个理论功耗值,大家可以访问网址: https://devzone.nordicsemi.com/power/,以获得你的使用场景下理论功耗多少,比如连接模式下,每1秒钟发20个字节的数据包,这种模式下理论功耗为:7.6uA

2)       确定板子漏电流。如果板子包含的元器件比较多,那么也有可能是其他非nRF5元器件导致的高功耗,比如传感器,codec,或者电路设计本身的问题等。为了确定高功耗是来自nRF5器件还是其他器件,根据自己的情况,有如下三个方法供你参考:一如果你的固件可以直接在Nordic官方DK上运行,那么你可以把你的固件直接下载到DK上,然后通过DK测量nRF5芯片的功耗,如果这个功耗正常,那么大电流应该是由其他非nRF5元器件引起的;如果这个功耗偏高,那么大电流的确是由nRF5芯片固件引起的,此时请参考后续操作步骤说明。二如果你的固件不能在DK上直接运行,那么可以让nRF5芯片进入深度睡眠模式(System OFF模式),此时nRF5芯片功耗只有零点几微安,nRF5芯片所有IO口将处于floating状态,此时再测量板子电流。如果板子电流恢复正常,那么大电流应该是由nRF5芯片固件引起的;如果板子电流还是不正常,那么大电流应该由其他非nRF5元器件引起的。关于如何进入深度睡眠模式,你可以参考工程:nRF5_SDK_15.0.0_a53641a\examples\peripheral\ram_retention\pca10040\blank\arm5_no_packs,或者参考ble_app_hrs工程中函数:sleep_mode_enter。三如果你的板子太复杂,无法按照上面两种方法来确定漏电流,那么只能将板子其他非必需元器件焊下来,只留下一个nRF5最小工作系统,然后再测量此时的板子电流是否正常。

3)       确定板子已经退出J-Link模式。如果板子一直是电池供电,那么在某些情况下,即使程序下载完成而且运行正常,此时板子有可能还处在J-Link模式。J-Link模式下板子会有2mA左右的额外电流。要退出J-Link模式,有2种方式,一是给板子进行上电复位,二是通过nrfjprog发出—pinreset(nRF51系列)或者—reset指令(nRF52系列)。两种方式都能让板子退出J-Link模式,从而进入应用模式。

4)       如果最终确认大电流的确是由nRF5芯片引起的,那么几乎可以肯定系统在进入idle模式(System ON模式)之前,没有关掉不需要的模块。模块没有关掉,它就一直在耗电,从而导致功耗过大。Idle模式下,如下模块会耗费比较多的电流,若允许建议全部关掉。

  • 进入Idle模式。先说明一下什么是idle模式,所谓Idle模式,Nordic芯片手册也称为System ON模式,就是CPU可以不工作而外设可以继续工作的一种低功耗模式。idle模式下,当CPU和所有外设都不工作时,系统电流也就有2uA左右。(注:除了idle模式,nRF5芯片还支持一种更低功耗的低功耗模式:sleep模式(Nordic芯片手册称为System OFF模式),sleep模式下,CPU和所有外设都强制关闭,所以功耗非常低:只有零点几微安。由于sleep模式下,芯片无法发出广播包或者与手机保持蓝牙连接,所以sleep模式在BLE应用中运用得并不是很多)。Idle模式可以被任何中断唤醒(sleep模式只能被IO口唤醒),所以idle模式在实际应用中使用得比较多。在idle模式下,芯片仍然可以正常发出广播或者与手机保持蓝牙连接,所以大部分BLE应用都是工作在idle模式下,这样既保持了BLE功能又可以实现低功耗。有softdevice时进入idle模式的函数是:
sd_app_evt_wait

无softdevice时进入idle模式的代码是:

  __WFE();
 // Clear the internal event register.
 __SEV();
 __WFE();

这里我们顺便把进入sleep模式的函数也贴出来,供大家对比参考。有softdevice时进入sleep模式的函数是:

sd_power_system_off

无softdevice时进入sleep模式的代码是:

// Enter System OFF and wait for wake up from GPIO detect signal.

NRF_POWER->SYSTEMOFF = 0x1;
  • UART/UARTE。由于UART需要实时检测RX线上有没有下降沿,所以一旦UART初始化成功,高频时钟将一直处于打开状态,从而导致UART模块消耗的电流比较大,虽然UART模块本身只需要55uA的工作电流,但是自动打开的高频时钟电路需要消耗250uA左右电流。如果使能了UARTE的easyDMA(52810 easyDMA是强制打开的),那么DMA还需要消耗额外的2mA电流。这样UARTE工作总共需要消耗:55uA + 250uA + 2mA。因此在进入idle模式之前,强烈建议将UART关掉,以节省系统功耗。注:为了达到低功耗和实时性双重目的,在设计UART通信的时候,我们经常会额外再加2个IO口用来通知对方UART要传送数据了。
  • GPIOTE。GPIOTE中断有两种工作模式:高精度模式(hi_accuracy为true)和低精度模式(hi_accuracy为false)。hi_accuracy为true将使能IN event中断;hi_accuracy为false将使能Port event中断。IN event中断功耗比Port event中断功耗高很多,因此,如果是检测一般的沿或者IO口电平,那么建议使用低精度模式,即使用如下初始化语句:
 GPIOTE_CONFIG_IN_SENSE_TOGGLE(false)   //低功耗低精度IO口中断模式
  • DMA。Nordic大部分外设都自带DMA功能,如果DMA可以关闭的话(有些设备DMA是不能关闭的),用完DMA之后,记得把DMA关掉,否则会有2mA左右的功耗。使用ADC的时候尤其要注意这点。
  • FPU。只要程序中使用了浮点数,Cortex M4会自动把FPU打开,FPU是耗能大户,其将消耗7mA以上的电流。此种情况下,进入idle模式之前必须手动关闭FPU,手动关闭FPU代码如下所示:
/* Clear FPSCR register and clear pending FPU interrupts. This code is base on

         * nRF5x_release_notes.txt in documentation folder. It is necessary part of code when

         * application using power saving mode and after handling FPU errors in polling mode.

*/

__set_FPSCR(__get_FPSCR() & ~(FPU_EXCEPTION_MASK));

(void) __get_FPSCR();

NVIC_ClearPendingIRQ(FPU_IRQn);
  • Timer0/1/2/3/4。Timer的工作电流大概为70uA,对低功耗应用来说,已经非常大了。如果你的定时精度要求不高,而且是毫秒的倍数,那么强烈建议你使用app_timer来实现定时功能,app_timer的功耗只有0.2uA左右。
  • SPI/TWI。在进入idle模式之前,建议把SPI和TWI模块也uninit。

原文地址:https://www.cnblogs.com/iini/p/9351048.html

时间: 2024-07-30 17:04:45

板子功耗高的原因有哪些的相关文章

直播疑难杂症排查(10)— 直播功耗高

本文为 <直播疑难杂症排查系列的>第十篇文章,我们重点看看直播功耗高的问题. 1.  问题现象 直播过程中手机发热严重,耗电快. 2. 问题排查 导致手机功耗高,发热严重的根本因素,无外乎就是一点:CPU/GPU 占用率高,所以,我们首先要分析下,哪些因素会导致 CPU/GPU 占用率高. 2.1 数据量太大 直播主要由:视频采集 -> 视频处理(剪裁.美颜.滤镜) -> 编码 -> 推流 这些环节组成. 在这整个流程中,决定数据量大小的因素有哪些呢 ? - 视频的尺寸(例如

如何解决直播过程中的直播功耗高问题 | 直播疑难杂症排查

继<直播技术详解>系列文章之后,我们推出了这个新的系列<直播疑难杂症排查>,把解决直播问题的经验逐步分享出来,同时也会穿插一些音视频开发的基础知识和优化经验,希望能够帮助到直播领域的开发者们. 本系列会涵盖的内容包括但不限于如下一些主题: 播放失败 直播卡顿 首开慢 延时高 音画不同步 马赛克严重 播放黑屏.花屏.绿屏 播放杂音.噪音.回声 点播拖动不准 直播发热问题 其他问题(待续) 问题现象 直播过程中手机发热严重,耗电快. 问题排查 导致手机功耗高,发热严重的根本因素,无外乎

Linux下分析某个进程CPU占用率高的原因

  Linux下分析某个进程CPU占用率高的原因 通过top命令找出消耗资源高的线程id,利用strace命令查看该线程所有系统调用  1.top 查到占用cpu高的进程pid 2.查看该pid的线程:top -H -p 9532 3.查看这个线程所有系统调用:strace -p 10017 不停循环输出Connection timed out,让开发查看问题 原文地址:https://www.cnblogs.com/chenjw-note/p/8370679.html

MongoDB 连接数高产生原因及解决

MongoDB Sharding架构下连接数很容易达到很高,这里连接数分为几个概念: tcp 连接数 netstat可以统计的,一般这个是最高.如果mongod/mongos在同一台服务器,更明显. 参考命令:netstat -ant|awk ‘{print $5}’ |awk -F: ‘{print $1}’|sort |uniq -c|sort -rn mongos/mongod 连接数 mongostat/db.serverStatus()/connPoolStats可统计. 连接数多高算

知网论文检测价格高的原因是什么

关于价格,一直相信贵有贵的道理,检测也是同理,虽然目前市场上出现的论文查重工具有很多,但是不同检测系统之间的差距还是很大的,数据库各不相同,这也是检测结果不一样的原因.高校普遍使用的是中国知网查重系统,知网系统有最强大最全面的数据库资料,成立比较早,积累了很多的经验,系统不断完善. 往往高版本的和学校一样的检查一次价格都比较贵.我们可以先用便宜的知网其他版本去检测,比如很多知网小分解,或者知网大分解.虽然对比库不是太全,但是都是知网数据库对比的,肯定比其他非知网检测来的更准确靠谱点.最后定稿的时

在VMware Workstation Pro 虚拟系统中CPU占用过高的原因?

分析原因: 在超线程单处理器主机上,采用虚拟 SMP 的虚拟机可能无法达到正常性能水平.即便在多处理器主机上,如果您运行了多个工作负载,导致整体 CPU 资源需求超过物理资源极限,虚拟机的性能也会受到影响. 在配置虚拟机处理器的时候建议根据物理主机配置仅设置处理器数量.每个处理器核心数量即可,如果勾选禁用二进制转换加速.虚拟化 Intel VT-x/EPT 或 AMD-V/RVI或虚拟化 CPU 性能计数器,将造成虚拟系统CPU占用过高.

MySQL 实例空间使用率过高的原因和解决方法

用户在使用 MySQL 实例时,会遇到空间使用告警甚至超过实例限额被锁定的情况.在 RDS 控制台的实例基本信息中,即会出现如下信息: 本文将介绍造成空间使用率过高的常见原因及其相应的解决方法.对于MySQL 5.6版本的实例,升级实例规格和存储空间后即可解锁实例,关于如何升级实例配置,请参见变更配置. 常见原因 造成 MySQL 实例空间使用率过高,主要有如下四种原因: Binlog 文件占用高. 数据文件占用高. 临时文件占用高. 系统文件占用高. 查看空间使用状况 您可以通过 DMS 中的

cpu使用率低负载高,原因分析

原因总结 产生的原因一句话总结就是:等待磁盘I/O完成的进程过多,导致进程队列长度过大,但是cpu运行的进程却很少,这样就体现到负载过大了,cpu使用率低. 下面内容是具体的原理分析:在分析负载为什么高之前先介绍下什么是负载.多任务操作系统.进程调度等相关概念. 什么是负载 什么是负载:负载就是cpu在一段时间内正在处理以及等待cpu处理的进程数之和的统计信息,也就是cpu使用队列的长度统计信息,这个数字越小越好(如果超过CPU核心*0.7就是不正常) 负载分为两大部分:CPU负载.IO负载 例

C# Winform程序CPU占用高的原因和解决方法

程序CPU占用高的可能原因: 1.存在死循环: 为什么死循环会导致CPU占用高呢?      虽然分时操作系统是采用时间片的机制对CPU的时间进行管理的,也就是说到了一定时间它会自动从一个进程切换到下一个进程.但是,当进入别的进程后,若该进程告诉系统它现在不需要做什么,不需要那么多的时间,这个时候,系统就会切换到下一个进程,当切换到死循环所在进程后,由于它一直在循环,永远告诉系统它有事情做(实质仅在死循环,没做任何事),那么系统就尽可能的将其他进程省下了的时间让它做死循环了,CPU占用不高才怪咧