开源分段中断架构RTOS?

发布于 2024-08-31 03:59:25 字数 1539 浏览 2 评论 0原文

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

怀念你的温柔 2024-09-07 03:59:25

我相信这有时也被称为“延迟中断”服务或处理,因此可能值得使用该术语来寻找候选者。

也许可以通过为 ISR 服务保留最高优先级任务级别来“伪造”它,因此假设您有 32 个中断向量,您将为 ISR2 级别保留优先级 0 到 31(假设零为高)。每个实际中断只需设置一个事件标志来指示 ISR2 任务。在这种情况下,您有责任不要在 ISR2 任务中调用阻塞函数,坚果非阻塞内核服务可以自由使用。

我不确定这是否会给你带来完全相同的效果(我必须比我更全面地研究它 - 或者现在关心),但这确实意味着你可以在真正的 ISR 中做最少的工作,并且真正的 ISR 总是会抢占任何 ISR2。

I believe this is also sometimes referred to as "deferred interrupt" servicing or handling, so it may be worth using that term to find candidates.

It is perhaps possible to 'fake' it by reserving the highest priority task levels for ISR servicing, so say you have 32 interrupt vectors, you would reserve priority levels 0 to 31 (assuming zero is high) for the ISR2 levels. Each real interrupt then simply sets an event flag signalling the ISR2 task. It remains your responsibility in this case not to call blocking functions in the ISR2 tasks, nut non-blocking kernel services can be used freely.

I am not sure whether this gives you exactly the same effect (I'd have to study it more fully than I have - or care to right now), but it does mean that you can do minimal work in the true ISR, and a true ISR will always preempt any ISR2.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文