- 主题:有谁介绍一下RTOS编程的精髓
但消息发出去了，什么时候能响应也不能确定啊。
【 在 straitfire 的大作中提到: 】
: 消息机制提供任务执行的确定性。这是实时系统的根本。
: 都用硬件中断了，搞消息机制这种软件中断就没意义了。
:
--
FROM 120.235.21.*
实时系统就是要保证这个啊
这都保证不了 就不叫实时系统了
【 在 heyuanlie 的大作中提到: 】
: 但消息发出去了，什么时候能响应也不能确定啊。
--
FROM 61.48.133.*
所以一直觉得实时操作系统挺牛的，居然这都能实时。
【 在 Qlala 的大作中提到: 】
: 实时系统就是要保证这个啊
: 这都保证不了 就不叫实时系统了
:
--
FROM 120.230.113.*
调度器保证高优先级的任务会被及时唤醒执行，除非消息接受方优先级太低，那你也不着急接收了啊
【 在 heyuanlie 的大作中提到: 】
: 但消息发出去了，什么时候能响应也不能确定啊。
:
--
FROM 112.64.60.*
rtos响应实时性的能力，现在的linux根本达不到，这和软件设计相关。rtlinux无论用信号，还是等待队列，硬件中断到用户层响应，快的100us，慢的几百us都可能，主频还是600mhz的arm。而rtos，按照要求编程，顶多几十us，而且还是有保证的，rtlinux没法保证。有的场景没法光用fpga，比如浮点数计算，用fpga实现稍微复杂点的算法，写和测都很麻烦。
【 在 Qlala 的大作中提到: 】
: 1 如果用了RTOS，是不是软件自动就RT了，剩下只需要不要把单个操作搞得太耗时？
: 2 Free RTOS /Vx /RTLinux 这几种分别适合用在什么场景
: 3 RT Linux的开源实现 主流是哪个 preempt-rt？可用度如何，实时性如何
--
FROM 117.136.106.*
哦？那你精准采样试试力大砖飞？
【 在 Oriphia 的大作中提到: 】
: 现在用新的mcu就不需要考虑实不实时的问题，力大砖飞，用典型的160Mhz risc-v想不实时都很难。
: 实时只是一个相对概念，高并发的用FPGA就不讨论了，用mcu的话，100us以内我都认为是实时的。对于现在mcu主频来说太轻易了。
: 用FreeRTOS就行了，因为现在mcu主频太高了，基本上程序瞎写也不会慢，不需要做什么优化。
: ...................
--
FROM 180.116.131.*
有意义的，比如你用MCU做TCP/IP通讯和CAN，485等，硬件是能中断，但是来了一个通讯请求，如果你正在通讯又来了一个通讯请求，第一个通讯又不能挂起的时候，就必须用软中断
【 在 heyuanlie 的大作中提到: 】
: 都用硬件中断了，搞消息机制这种软件中断就没意义了。
:
--
FROM 180.116.131.*
对，多任务必须，但是其实力大砖飞也行，比如你的系统最多要处理10种任务，普通一个M0，3个硬中断，再利用软中断可以了，你可以力气大一点，买个H7回来，直接10个硬中断，随便造
【 在 DraculaW 的大作中提到: 】
:
: 你多任务又要实时 不就得软硬中断加优先级加消息机制么
--
FROM 180.116.131.*
简单的并行其实MCU是可以实现的，但是必须是简单任务，比如利用DMA并行处理数据，然后主程序再一起处理一下，可以算半个并行了
【 在 heyuanlie 的大作中提到: 】
: 我理解是并行要么用硬件实现，像fpga、gpu这种。
: 否则，在串行CPU上软件实现的并行多线程，其实不是并行。
: 其实实时系统用并行还是串行实现不是重点，能满足响应时间要求就行。
: ...................
--
FROM 180.116.131.*
这样的软中断是不是相当于让软中断排队等着？
【 在 dismoon 的大作中提到: 】
: 有意义的，比如你用MCU做TCP/IP通讯和CAN，485等，硬件是能中断，但是来了一个通讯请求，如果你正在通讯又来了一个通讯请求，第一个通讯又不能挂起的时候，就必须用软中断
:
--
FROM 120.235.21.*