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]