12
返回列表 发新帖
楼主: uniqueeefocus41

[已解决] KL系列的中断处理问题(已解决)

[复制链接]
  • TA的每日心情
    难过
    2021-12-15 16:01
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]初来乍到

    305

    主题

    4701

    帖子

    0

    中级会员

    Rank: 3Rank: 3

    积分
    377
    最后登录
    2023-8-16
    发表于 2014-7-1 17:43:13 | 显示全部楼层

    RE:KL系列的中断处理问题

    如果相同优先级的话,可能会由模块的中断不同引起不同的处理。
    该会员没有填写今日想说内容.
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    10

    主题

    65

    帖子

    0

    新手上路

    Rank: 1

    积分
    94
    最后登录
    1970-1-1
     楼主| 发表于 2014-7-2 08:51:59 | 显示全部楼层

    回复:KL系列的中断处理问题

    回复第 10 楼 于2014-07-01 17:06:45发表:
    回复第 6 楼 于2014-07-01 12:43:27发表:
    回复第 4 楼 于2014-07-01 11:11:34发表:
    回复第 3 楼 于2014-07-01 11:03:31发表:
    回复第 2 楼 于2014-07-01 10:49:36发表:
    你好,楼主!
    你设置的是中断的优先级,当SPI通信时,不管哪个中断都可以它的,当然在其他中断处理过程中,SPI的中断触发了,SPI中断也可以打断其它中断。
     
    对啊,所以很奇怪,咋就丢字节了呢
    这就要看你SPI的通信过程啊,举个例子,当你用轮询的方式检测SPI通信过程,这时候USB中断触发,就有可能打断轮询的连续行,导致SPI丢包!
     
    啊?SPI通信也是中断哦,不是主程序轮询的,而且中断优先级比USB的中断优先级高。
    刚刚没仔细看,“当SPI通信时,不管哪个中断都可以它的”,这个的意思是其他中断可以打断SPI通信吗?为什么?SPI的优先级是设为最高的,凭什么低优先级可以打断高优先级的
     
    Sorry,前面我的理解有误。是不是很可能在你的USB中断函数有禁止全局中断使能的指令,导致SPI中断无法触发呢。
     
    有道理!
    看了看代码。应该是没有在USB处理时禁止全局中断。
    USB用的是原厂提供的协议栈中的USB Host->USB FAT FS Generic这部分。
    出问题时是在用f_write写文件
    麻烦斑斑有空给看一看,是不是有这个问题

     

     

     

     
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    124

    主题

    3600

    帖子

    0

    金牌会员

    Rank: 6Rank: 6

    积分
    5781
    最后登录
    1970-1-1
    发表于 2014-7-2 11:13:31 | 显示全部楼层

    回复:KL系列的中断处理问题

    回复第 12 楼 于2014-07-02 08:51:59发表:
    回复第 10 楼 于2014-07-01 17:06:45发表:
    回复第 6 楼 于2014-07-01 12:43:27发表:
    回复第 4 楼 于2014-07-01 11:11:34发表:
    回复第 3 楼 于2014-07-01 11:03:31发表:
    回复第 2 楼 于2014-07-01 10:49:36发表:
    你好,楼主!
    你设置的是中断的优先级,当SPI通信时,不管哪个中断都可以它的,当然在其他中断处理过程中,SPI的中断触发了,SPI中断也可以打断其它中断。
     
    对啊,所以很奇怪,咋就丢字节了呢
    这就要看你SPI的通信过程啊,举个例子,当你用轮询的方式检测SPI通信过程,这时候USB中断触发,就有可能打断轮询的连续行,导致SPI丢包!
     
    啊?SPI通信也是中断哦,不是主程序轮询的,而且中断优先级比USB的中断优先级高。
    刚刚没仔细看,“当SPI通信时,不管哪个中断都可以它的”,这个的意思是其他中断可以打断SPI通信吗?为什么?SPI的优先级是设为最高的,凭什么低优先级可以打断高优先级的
     
    Sorry,前面我的理解有误。是不是很可能在你的USB中断函数有禁止全局中断使能的指令,导致SPI中断无法触发呢。
     
    有道理!
    看了看代码。应该是没有在USB处理时禁止全局中断。
    USB用的是原厂提供的协议栈中的USB Host->USB FAT FS Generic这部分。
    出问题时是在用f_write写文件
    麻烦斑斑有空给看一看,是不是有这个问题

     

     请问你使用的是那个例程?

     

     

     
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    10

    主题

    65

    帖子

    0

    新手上路

    Rank: 1

    积分
    94
    最后登录
    1970-1-1
     楼主| 发表于 2014-7-2 12:49:23 | 显示全部楼层

    回复:KL系列的中断处理问题

    回复第 13 楼 于2014-07-02 11:13:31发表:
    回复第 12 楼 于2014-07-02 08:51:59发表:
    回复第 10 楼 于2014-07-01 17:06:45发表:
    回复第 6 楼 于2014-07-01 12:43:27发表:
    回复第 4 楼 于2014-07-01 11:11:34发表:
    回复第 3 楼 于2014-07-01 11:03:31发表:
    回复第 2 楼 于2014-07-01 10:49:36发表:
    你好,楼主!
    你设置的是中断的优先级,当SPI通信时,不管哪个中断都可以它的,当然在其他中断处理过程中,SPI的中断触发了,SPI中断也可以打断其它中断。
     
    对啊,所以很奇怪,咋就丢字节了呢
    这就要看你SPI的通信过程啊,举个例子,当你用轮询的方式检测SPI通信过程,这时候USB中断触发,就有可能打断轮询的连续行,导致SPI丢包!
     
    啊?SPI通信也是中断哦,不是主程序轮询的,而且中断优先级比USB的中断优先级高。
    刚刚没仔细看,“当SPI通信时,不管哪个中断都可以它的”,这个的意思是其他中断可以打断SPI通信吗?为什么?SPI的优先级是设为最高的,凭什么低优先级可以打断高优先级的
     
    Sorry,前面我的理解有误。是不是很可能在你的USB中断函数有禁止全局中断使能的指令,导致SPI中断无法触发呢。
     
    有道理!
    看了看代码。应该是没有在USB处理时禁止全局中断。
    USB用的是原厂提供的协议栈中的USB Host->USB FAT FS Generic这部分。
    出问题时是在用f_write写文件
    麻烦斑斑有空给看一看,是不是有这个问题

     

     请问你使用的是那个例程?

     回斑斑,用的例程是USB FAT FS Generic,加了SPI。很是困惑

     

     

     
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    124

    主题

    3600

    帖子

    0

    金牌会员

    Rank: 6Rank: 6

    积分
    5781
    最后登录
    1970-1-1
    发表于 2014-7-2 16:27:10 | 显示全部楼层

    回复:KL系列的中断处理问题

    回复第 14 楼 于2014-07-02 12:49:23发表:
    回复第 13 楼 于2014-07-02 11:13:31发表:
    回复第 12 楼 于2014-07-02 08:51:59发表:
    回复第 10 楼 于2014-07-01 17:06:45发表:
    回复第 6 楼 于2014-07-01 12:43:27发表:
    回复第 4 楼 于2014-07-01 11:11:34发表:
    回复第 3 楼 于2014-07-01 11:03:31发表:
    回复第 2 楼 于2014-07-01 10:49:36发表:
    你好,楼主!
    你设置的是中断的优先级,当SPI通信时,不管哪个中断都可以它的,当然在其他中断处理过程中,SPI的中断触发了,SPI中断也可以打断其它中断。
     
    对啊,所以很奇怪,咋就丢字节了呢
    这就要看你SPI的通信过程啊,举个例子,当你用轮询的方式检测SPI通信过程,这时候USB中断触发,就有可能打断轮询的连续行,导致SPI丢包!
     
    啊?SPI通信也是中断哦,不是主程序轮询的,而且中断优先级比USB的中断优先级高。
    刚刚没仔细看,“当SPI通信时,不管哪个中断都可以它的”,这个的意思是其他中断可以打断SPI通信吗?为什么?SPI的优先级是设为最高的,凭什么低优先级可以打断高优先级的
     
    Sorry,前面我的理解有误。是不是很可能在你的USB中断函数有禁止全局中断使能的指令,导致SPI中断无法触发呢。
     
    有道理!
    看了看代码。应该是没有在USB处理时禁止全局中断。
    USB用的是原厂提供的协议栈中的USB Host->USB FAT FS Generic这部分。
    出问题时是在用f_write写文件
    麻烦斑斑有空给看一看,是不是有这个问题

     

     请问你使用的是那个例程?

     回斑斑,用的例程是USB FAT FS Generic,加了SPI。很是困惑
     
    Sorry,我没找到这个例程,是FRDMKL26带的例程还是USB stack提供的例程呢?

     

     

     

     
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    10

    主题

    65

    帖子

    0

    新手上路

    Rank: 1

    积分
    94
    最后登录
    1970-1-1
     楼主| 发表于 2014-7-3 08:49:04 | 显示全部楼层

    回复:KL系列的中断处理问题

    回复第 15 楼 于2014-07-02 16:27:10发表:
    回复第 14 楼 于2014-07-02 12:49:23发表:
    回复第 13 楼 于2014-07-02 11:13:31发表:
    回复第 12 楼 于2014-07-02 08:51:59发表:
    回复第 10 楼 于2014-07-01 17:06:45发表:
    回复第 6 楼 于2014-07-01 12:43:27发表:
    回复第 4 楼 于2014-07-01 11:11:34发表:
    回复第 3 楼 于2014-07-01 11:03:31发表:
    回复第 2 楼 于2014-07-01 10:49:36发表:
    你好,楼主!
    你设置的是中断的优先级,当SPI通信时,不管哪个中断都可以它的,当然在其他中断处理过程中,SPI的中断触发了,SPI中断也可以打断其它中断。
     
    对啊,所以很奇怪,咋就丢字节了呢
    这就要看你SPI的通信过程啊,举个例子,当你用轮询的方式检测SPI通信过程,这时候USB中断触发,就有可能打断轮询的连续行,导致SPI丢包!
     
    啊?SPI通信也是中断哦,不是主程序轮询的,而且中断优先级比USB的中断优先级高。
    刚刚没仔细看,“当SPI通信时,不管哪个中断都可以它的”,这个的意思是其他中断可以打断SPI通信吗?为什么?SPI的优先级是设为最高的,凭什么低优先级可以打断高优先级的
     
    Sorry,前面我的理解有误。是不是很可能在你的USB中断函数有禁止全局中断使能的指令,导致SPI中断无法触发呢。
     
    有道理!
    看了看代码。应该是没有在USB处理时禁止全局中断。
    USB用的是原厂提供的协议栈中的USB Host->USB FAT FS Generic这部分。
    出问题时是在用f_write写文件
    麻烦斑斑有空给看一看,是不是有这个问题

     

     请问你使用的是那个例程?

     回斑斑,用的例程是USB FAT FS Generic,加了SPI。很是困惑
     
    Sorry,我没找到这个例程,是FRDMKL26带的例程还是USB stack提供的例程呢?

     

     是USB stack哦,HOST->USB FAT FS Generic。不可能找不到吧

     

     

     
    回复 支持 反对

    使用道具 举报

    您需要登录后才可以回帖 注册/登录

    本版积分规则

    关闭

    站长推荐上一条 /3 下一条

    Archiver|手机版|小黑屋|恩智浦技术社区

    GMT+8, 2025-7-20 08:52 , Processed in 0.095530 second(s), 25 queries , MemCache On.

    Powered by Discuz! X3.4

    Copyright © 2001-2024, Tencent Cloud.

    快速回复 返回顶部 返回列表