完善资料让更多小伙伴认识你，还能领取20积分哦， 立即完善>
3天内不再提示
|
我一直在找一个中断响应很快的系统
看了一下rtt的代码，临界段处理也是通过关中断来实现的，感觉这种处理虽然简单，但是对中断响应有比较大的影响，限制了在一些快速事件中断场合中的应用。有的时候需要捕捉到快速中断事件，可以延后处理，但是不能丢失事件。 看到ucosiii与ucosii比，改进了临界段的处理方式，用锁定调度来实现，操作系统对中断延时的影响几乎为零，这个很重要。这是否会是一个趋势，不知道rtt是否会考虑改进临界段的处理？ 
0
|
|
相关推荐
4个回答
|
|
|
这个其实是个双刃剑，锁定调度器比关闭中断的代价要高。RTT目前考虑的更多是从减少关闭中断时间来入手，当然也不排斥锁定调度器的方式。
在更高的响应能力上，芯片的处理能力也非常重要。 |
|
|
|
|
|
因为实时系统主要就是看能否在规定的时间里响应。所以一直关注RTT的开关中的时间, 好像这部分一直没有任何修改！
|
|
|
|
|
|
这个我们原来的思路是把一些极端苛刻的实时需求方到另外一个非关中断的环境中去，这样的话，实时性能就能够非常棒了，<1us。所以RT-Thread本身就这样吧，这样的方式能够满足98%的需求了，极端苛刻的实时需求，单独处理。
|
|
|
|
|
|
您提到的另外一个非关中断的环境中去。这个方法能详细一点吗？因为RT-thread整个生态现在已经很好了。
1） 单CPU，是不是通过修改开关中断的方法的地方，在M3中使用BASEPRI的精细控制？ 像FREERTOS一样不使用的系统中断调用的部分，可以不被系统开关中断？ 我现在统计内核中开关中断的语句，评估在STM32F4下的开关中断时间。其实即便完全开关中断也是没有问题的，但是最主要的原因是这个参数不清楚，导致很难评估是否可以使用这个操作系统。例如5uS紧急度级别的，10uS紧急度级别的，或者1ms紧急度级别的等等。 2） 非中断环境 您指的是另外一个CPU？ |
|
|
|
|
你正在撰写答案
如果你是对答案或其他答案精选点评或询问，请使用“评论”功能。
795 浏览 0 评论
4743 浏览 0 评论
如何使用python调起UDE STK5.2进行下载自动化下载呢？
2605 浏览 0 评论
开启全新AI时代 智能嵌入式系统快速发展——“第六届国产嵌入式操作系统技术与产业发展论坛”圆满结束
2949 浏览 0 评论
获奖公布！2024 RT-Thread全球巡回线下培训火热来袭！报名提问有奖！
31683 浏览 11 评论
73067 浏览 21 评论
/6 
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 （电路图） 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证：合字B2-20210191
工商网监
湘ICP备2023018690号
4584
评论
淘帖
719
