msp430修改IO的问题
用的msp430,它不像stm的芯片那样有BRR寄存器,因此修改单个IO只能P1OUT &= ~BIT1。问题来了,如果主程序在读出端口的数值的时候,中断发生了,并且也修改该端口的另一个IO,那么回到主程序岂不又改回来了?针对这类问题,除了关中断,还有办法吗? 顶一下,大家看看 如果你的主程序和中断都有对同一个IO的读写,那就说明这个IO是互斥资源,按道理就应该使用互斥访问。这和访问一个变量没任何区别。而防止中断和主程序同时访问一个互斥资源的唯一方法就是关中断。
可以看看操作系统的书,例如UCOS,这个属于临界资源的访问,在操作系统中使用关中断或信号量解决 关键是我没有用操作系统,而且在主函数里频繁用到那个端口,液晶显示,所以关中断影响太大 MSP430有给变量单独置位清零的指令,所以,改变某个端口操作是原子的,不存在覆盖的问题了 不明白你这个岂不是又改回来了 的意思?
P1OUT &= ~BIT1
只影响P1.1啊在中断改了P1.2 关P1.1什么事???
我在中断中只要不操作这个IO口,中断回来继续操作,不会影响结果的。
但是中断一般会时间很短,不会影响的呀。。。
marshallemon 发表于 2013-5-18 20:29 static/image/common/back.gif
可以看看操作系统的书,例如UCOS,这个属于临界资源的访问,在操作系统中使用关中断或信号量解决 ...
他这个是中断抢占,信号量锁不住啊。 laujc 发表于 2013-5-19 02:43
我在中断中只要不操作这个IO口,中断回来继续操作,不会影响结果的。
但是中断一般会时间很短,不会影响的 ...
不行的,我要求实时性非常高,回来后要到什么时候才操作那个端口都不知道 信号量肯定锁不住,中断里不可能等待,也不可能跳过 jetlib 发表于 2013-5-19 08:10 static/image/common/back.gif
他这个是中断抢占,信号量锁不住啊。
晕,所谓的信号量只是一个占用的标志,在操作系统中对付多任务共同访问的资源,其实前后台程序也可以认为是2个任务,对付中断一样有效的,设置一个标志位,访问资源前先判断此标志位,如果被占用则不访问此临界资源,如果没被占用,则设置此标志,使用完临界资源就清除此标志位。后台中也是一样,后台中如果觉得不保险,则在设置此标志时关中断,设置完成后开中断,这样开关中断的时间比较短,影响并不大 晕,所谓的信号量只是一个占用的标志,在操作系统中对付多任务共同访问的资源,其实前后台程序也可以认为是2个任务,对付中断一样有效的,设置一个标志位,访问资源前先判断此标志位,如果被占用则不访问此临界资源,如果没被占用,则设置此标志,使用完临界资源就清除此标志位。后台中也是一样,后台中如果觉得不保险,则在设置此标志时关中断,设置完成后开中断,这样开关中断的时间比较短,影响并不大 楼上,中断不可能打断主函数,这是肯定的。所以只需在中断里查询信号量,假如发现被占用,怎么办?等待,那是不可能,不退出中断进不了主函数释放信号量,忽略,那就和没加信号量一回事了。 gold 发表于 2013-5-19 08:54 static/image/common/back.gif
不行的,我要求实时性非常高,回来后要到什么时候才操作那个端口都不知道 ...
这种操作,看下汇编,可能P1OUT &= ~BIT1编译成了 P1OUT.1= 0了就不会出现这个问题了。。。
laujc 发表于 2013-5-19 10:26
这种操作,看下汇编,可能P1OUT &= ~BIT1编译成了 P1OUT.1= 0了就不会出现这个问题了。。。
...
没错,汇编过后是AND.B 0x01 &P1OUT
一条指令搞定了,所以不会出问题了 gold 发表于 2013-5-19 10:38 static/image/common/back.gif
没错,汇编过后是AND.B 0x01 &P1OUT
一条指令搞定了,所以不会出问题了
{:victory:}
{:handshake:} 学习了。 个人认为,这个问题貌似是个问题,其实是个伪问题,和有没有BRR、BSRR毫无关系,真正的原因是资源访问调度方法问题。
页:
[1]