您的位置: OpenADSP社区论坛 -> Blackfin专区 -> 新手上路 -> BLACAKFIN的GPIO中断问题。
本帖共有1274个阅读者
发表帖子 发表投票 回复主题
BLACAKFIN的GPIO中断问题。
tzg74500(论坛游民)
tzg74500
头衔:社区公民
帮派:无帮无派
帖数:87
金钱:806
积分:110
注册时间:2011/7/31
楼主信息 | 留言 | Email | 主页 | 编辑 | 管理 | 离线
BLACAKFIN的GPIO中断问题。

大家好,我使用BF504F的PG6,PG8,PG10,作为GPIO中断使用,配制为双边沿中断,使用PG口中断B组,这三个引脚公用B组中断。

现在发现,当单独使用PG6或8或10时,程序是可以双边沿中断,但3个IO口一起公用中断时,程序只能响应上升边沿中断,为什么呢????


这家伙很懒,什么也没有留下!
等级:论坛游民 参考IP地址:*.*.*.*
2012/1/31 16:23:41
tzg74500(论坛游民)
tzg74500
头衔:社区公民
帮派:无帮无派
帖数:87
金钱:806
积分:110
注册时间:2011/7/31
1信息 | 留言 | Email | 主页 | 编辑 | 管理 | 离线

void STEP_X_Loc_Gpio(void)         //X轴电机定位设置为gpio
{
*pPORTG_MUX   |=1<<9;
*pPORTG_MUX   |=1<<8;
*pPORTG_FER   &=~step_x_loc;
*pPORTGIO_DIR  &=~step_x_loc;      //设置为输入
*pPORTGIO_INEN |=step_x_loc;       //打开外部中断
}

void STEP_X_Loc_Eint(void)         //设置为外部中断
{
STEP_X_Loc_Gpio();
*pPORTGIO_EDGE  |=step_x_loc ;      //设置双边沿出发中断
*pPORTGIO_BOTH  |=step_x_loc ;      //双边触发中断
*pPORTGIO_MASKB |=step_x_loc ;

*pSIC_IAR5 = ((*pSIC_IAR5) & 0XFFFFFF0F) | (((uint32)2)<<4);   //中断等级为9
register_handler(ik_ivg9, step_x_loc_isr);
*pSIC_IMASK1 |= (1<<9);                      //使能中断
}

void STEP_Y_Loc_Gpio(void)         //Y轴电机定位,设置为gpio
{
*pPORTG_MUX   |=1<<9;          //Y轴电机,定位
*pPORTG_MUX   |=1<<8;
*pPORTG_FER   &=~step_y_loc;
*pPORTGIO_DIR  &=~step_y_loc;      //设置为输入
*pPORTGIO_INEN |=step_y_loc;       //打开外部中断
}

void STEP_Y_Loc_Eint(void)         //设置为外部中断
{
STEP_Y_Loc_Gpio();
*pPORTGIO_EDGE  |=step_y_loc ;      //设置双边沿出发中断
*pPORTGIO_BOTH  |=step_y_loc ;      //双边触发中断
*pPORTGIO_MASKB |=step_y_loc;

*pSIC_IAR5 = ((*pSIC_IAR5) & 0XFFFFFF0F) | (((uint32)2)<<4);   //中断等级为9
register_handler(ik_ivg9, step_x_loc_isr);
*pSIC_IMASK1 |= (1<<9);                      //使能中断
}

void STEP_Z_Loc_Gpio(void)         //将Z轴定位设置为GPIO
{
*pPORTG_MUX   |=1<<11;          //Z轴电机,定位
*pPORTG_MUX   |=1<<10;
*pPORTG_FER   &=~step_z_loc;
*pPORTGIO_DIR  &=~step_z_loc;      //设置为输入
*pPORTGIO_INEN |=step_z_loc;       //打开外部中断
}

void STEP_Z_Loc_Eint(void)         //设置为外部中断
{
STEP_Z_Loc_Gpio();
*pPORTGIO_EDGE  |=step_z_loc ;      //设置双边沿出发中断
*pPORTGIO_BOTH  |=step_z_loc ;      //双边触发中断
*pPORTGIO_MASKB |=step_z_loc;

*pSIC_IAR5 = ((*pSIC_IAR5) & 0XFFFFFF0F) | (((uint32)2)<<4);   //中断等级为9
register_handler(ik_ivg9, step_x_loc_isr);
*pSIC_IMASK1 |= (1<<9);                      //使能中断
}



这三个是初始化函数,分别将PG6,8,10初始化为双边沿中断



这家伙很懒,什么也没有留下!
等级:论坛游民 参考IP地址:*.*.*.*
2012/1/31 16:27:40
尊贵身份标志
andy(论坛版主)
andy
头衔:社区公民
帮派:无帮无派
帖数:2287
金钱:11132
积分:2263
注册时间:2011/6/8
2信息 | 留言 | Email | 主页 | 编辑 | 管理 | 离线

中断初始化函数建议合成一个函数,不要分3次定义同一个中断函数。

另外代码中没有看到你的中断函数,进入中断后是否清除中断标志?不知是否引起的异常?



这家伙很懒,什么也没有留下!
等级:论坛版主 参考IP地址:*.*.*.*
2012/2/6 12:20:28
tzg74500(论坛游民)
tzg74500
头衔:社区公民
帮派:无帮无派
帖数:87
金钱:806
积分:110
注册时间:2011/7/31
3信息 | 留言 | Email | 主页 | 编辑 | 管理 | 离线

我刚开始也是这么想的,和成过一个终端函数,调试过,现象和分成3个一模一样。。。。。。。呵呵,都不知道是神马问题导致这个现象,。。

中断函数里面肯定有清零。。。。现在问题在这里,当系统上电后,按照我的配置,GPIO肯定会进入中断,如果一次将这三个IO清0,返现问题和我描述的相同,如果分3次清0,因为*pPORTGIO这个寄存器上电配置后,里面的的这3个IO口都为1,所以没办法判断是那个IO产生的中断。。。呵呵,难点就在这里。。。。。。所以我一直认为,BLACKFIN的这种GPIO中断,无中断标志位,是很有缺陷的设计。。。


这家伙很懒,什么也没有留下!
等级:论坛游民 参考IP地址:*.*.*.*
2012/2/6 12:58:35
tzg74500(论坛游民)
tzg74500
头衔:社区公民
帮派:无帮无派
帖数:87
金钱:806
积分:110
注册时间:2011/7/31
4信息 | 留言 | Email | 主页 | 编辑 | 管理 | 离线
后来又试过,先将GPIO6,配置成中断,然后延迟200MS,等待GPIO6中断发生,然后将他清0,然后在配置GPIO8成中断,然后等待中断发生,然后再清0,然后再。。。。。。。。。。。。。。还是不行,调试结果发现,这三个GPIO中断,有时发生1次,有时发生2次,有事发生3次,究竟发生几次,根本不是个确定值。

这家伙很懒,什么也没有留下!
等级:论坛游民 参考IP地址:*.*.*.*
2012/2/6 13:10:08
tzg74500(论坛游民)
tzg74500
头衔:社区公民
帮派:无帮无派
帖数:87
金钱:806
积分:110
注册时间:2011/7/31
5信息 | 留言 | Email | 主页 | 编辑 | 管理 | 离线
另外声明下,我的处理流程,在单边中断时没有问题的,就是双边中断不OK.

这家伙很懒,什么也没有留下!
等级:论坛游民 参考IP地址:*.*.*.*
2012/2/6 13:13:47
尊贵身份标志
andy(论坛版主)
andy
头衔:社区公民
帮派:无帮无派
帖数:2287
金钱:11132
积分:2263
注册时间:2011/6/8
6信息 | 留言 | Email | 主页 | 编辑 | 管理 | 离线

双边中断,由于各个IO在发生中断后,其状态很难判断,不好区别是哪个发生中断了。你可以这样做绕开这个问题。PG端口有两个中断管理器,你使用的都是B,这样不好区分中断。你可以将一个IO用B,一个IO用A,然后使用两个独立的中断函数,互不干涉,进入哪个中断函数就是哪个管脚触发的,不需要判断。然后第三个中断用PH口的中断源,把3个中断分开,这样可能会好一点。


这家伙很懒,什么也没有留下!
等级:论坛版主 参考IP地址:*.*.*.*
2012/2/7 12:29:22
Powered by OpenADSP Copyright © 2010 www.Openadsp.com. All rights reserved.154329 Call, 1 Queries, Processed in 0.031250 second(s),