This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
本程序中,共有两次进入低功耗模式,第一次是为了响应I2C的收发中断,第二次是时钟延迟中断。你其实是误解了,当程序响应中断进入中断服务子程序时,msp430会从低功耗中自主唤醒为活跃状态,执行服务子程序,当执行完服务中断子程序后又会自主进入之前设置的低功耗模式。这个时候如果没有人为的唤醒那么程序就会请留在 __bic_SR_register_on_exit(CPUOFF)这条语句处,不能往下执行,所以说在中断服务子程序末尾加一句 __bic_SR_register_on_exit(CPUOFF),就是为了让msp430退出低功耗以便让程序可以往下执行,本程序中当通过I2C读取了温度计里的数据后,由于要进行判断,所以在中断服务子程序中加了一句__bic_SR_register_on_exit(CPUOFF)以便退出之前的低功耗模式,进入AM模式来进行数据判断,以及之后的操作。
谢谢您的回答!
对于延迟中断,在进入该中断前,_bis_SR_register(CPUOFF)使得430处于低功耗模式,进入延迟中断后,_bis_SR_register_on_exit(CPUOFF);使得CPU被唤醒;对于I2C数据收发中断,在进入该中断之前,同样_bis_SR_register(CPUOFF)使得430处于低功耗模式,进入中断后,在接收数据的过程中,仍然为低功耗模式,
只有当数据全部接收完之后,才唤醒CPU并返回主循环程序对该数据进行比较处理。这样理解对吧?
但我的疑问也出现了,延迟中断唤醒了CPU,但之后CPU并没有事情可做,为什么要在此做延迟中断呢?不做延迟中断,不是更省功耗吗?
你还是没理解,首先你得看看题目程序说明,此程序是每隔62ms对温度计进行一次数据读取然后判断温度是否满足条件,然后进行相应操作,延时中断唤醒CPU后往下执行进入到下一个循环,重新执行该程序,因为在第一次循环中收发中断服务子程序中, UCB0CTL1 |= UCTXSTP语句已经结束了此次I2C数据传输,并且只有UCB0CTL1 |= UCTXSTT这条语句才可以产生I2C通信开始条件,如果这时延时中断之后不唤醒,那么I2C通讯条件永远停留在_bis_SR_register(CPUOFF)产生I2C通讯开始条件,除非延时中断后唤醒cpu进入到下一个循环,才可以重新执行这条语句UCB0CTL1 |= UCTXSTT产生I2C通讯的必要条件。
还有就是只要进入中断服务子程序msp430就会自己,自主唤醒进入到AM状态,执行完_bis_SR_register(CPUOFF)之前的语句后又会重新返回到低功耗模式,这个过程是不需要自己设置的,当执行_bis_SR_register(CPUOFF)此时这个是人为的唤醒了。
我刚刚看到资料上有这么一句“在使用低功耗模式下的USCI模块提供了自动时钟激活。如果因为设备处于低功耗状态而导致USCI模块的时钟源关断时,如果需要,无论时钟源控制位设置如何,USCI模块都可自动激活”
“在I2C从模式下由于时钟是由外部设备提供的,所以内部时钟源并不是必须的。在设备处于LPM4状态下的 并且所有内部时钟源被禁止时,USCI可以工作在I2C从模式下。接收或者发送中断都可以将CPU从任何一种低功耗状态下唤醒。”
您说的很对!
在主循环中,UCB0CTL1|=UCTASTT;产生起始条件,当主机接收到第一个数据并发送应答信号之后,UCRXIFG=1; 并在使能接收中断和总中断的条件下,CPU自主从CPUOFF状态中唤醒,进入中断服务程序,当数据接收完毕,退出中断,又将恢复至低功耗状态,但我们需要进行数据比较,不能让CPU低功耗,于是在接收中断程序末尾添上 _bis_SR_register(CPUOFF)让CPU继续处于唤醒状态。数据处理完之后,TACCTL0|=CCIE;_bis_SR_register(CPUOFF+GIE);CPU又将进入低功耗模式,但是我们需要进入下一个循环,需要通过UCB0CTL1|=UCTXSTT产生下一轮的起始条件,所以需要延迟中断重新唤醒CPU。呃。。这样理解还有错吗?