不懂 RTOS 就不要胡扯。FreeRTOS 是抢占式多任务系统，属于典型的强实时操作系统。。。

怎么可能“任何动作, 都做不到比1ms更精细”。

“抢占式多任务”决定了只要一个任务达到了运行条件就一定会被调度执行，这个过程与 tick 无关。即使是定时任务也可以用系统中的其他定时中断发送信号量的方式触发，精度也可以比1ms 高。


【 在 Mikov 的大作中提到: 】
: 所谓rtos, 更侧重的是os而不是rt.
: rtos都有一个系统tick, 这个系统tick通常是1ms, 如果你用1ms的tick, 那么这个系统里的任何动作, 都做不到比1ms更精细, 上下文切换也要时间, 几个任务切换几次, 延迟就大了.
: 如果你要非常实时, 那就不要用任何os. 裸机汇编, 对着指令算时钟数吧, 这一定是最实时的.
: ...................
--
FROM 124.126.138.*

【 在 dormouseBHU 的大作中提到: 】
: 不懂 RTOS 就不要胡扯。FreeRTOS 是抢占式多任务系统，属于典型的强实时操作系统。。。
: 怎么可能“任何动作, 都做不到比1ms更精细”。
: “抢占式多任务”决定了只要一个任务达到了运行条件就一定会被调度执行，这个过程与 tick 无关。即使是定时任务也可以用系统中的其他定时中断发送信号量的方式触发，精度也可以比1ms 高。
: ...................


Re。

所以所谓 强实时，还有一个核心的概念是对于中断的响应时间。比如和非实时linux做比较，rtos就是内核态操作的时间都很短，可以快速退出，这样可以保证中断的及时响应。相比而言，linux一个spinlock就可能导致操作时间完全不可控。

上面那个不懂rtos胡说八道的，大概只记住了rtos的调度tick是1ms，所以就理解成这个1ms就跟光速一样不可逾越，是最小调度单位了...
--
修改:beanspower FROM 123.123.253.*
FROM 123.123.253.*

【 在 dormouseBHU 的大作中提到: 】
: 不懂 RTOS 就不要胡扯。FreeRTOS 是抢占式多任务系统，属于典型的强实时操作系统。。。
: 怎么可能“任何动作, 都做不到比1ms更精细”。
: “抢占式多任务”决定了只要一个任务达到了运行条件就一定会被调度执行，这个过程与 tick

抢占式多任务是指执行中的任务不用调用返回操作系统的函数也能被换下去，队列中的任务在预定的时间内必然能得到执行。但在轮到的时间片内能执行多少，跟CPU处理能力和算法有关，被控制设备能否产生“实时”效果，还不一定。非抢占式多任务，只要某一线程不主动调用回系统函数，CPU就一直在执行它，别的任务不能被运行
--
FROM 221.218.68.*

这说法有问题，xsemaphoregive是立即调度，但xsemaphoretake不一定是，而且大部分应用都不是立即调度。

比如串口通信中信号量的timeout绝大多数情况是portmaxdelay，这就一定是在tick调度中被唤醒的。

所有的数据通信函数默认都是阻塞函数，阻塞链表进出肯定在tick任务调度里完成的。

【 在 dormouseBHU 的大作中提到: 】
:
: 这里你理解的还是错的。业务处理是否实时与它是否放到中断里是没关系的。正常情况下，业务处理都是放到线程中的。中断只是触发线程调度的一种方式。
:
: 以串口中断为例，串口中断里通过信号量等方式将对应的线程状态转换成可执行态。中断结束后会触发一次线程调度。只要串口线程优先级够高就一定会被立刻调度为运行态。这个线程调度是和tick无关的。
:

#发自zSMTH@LYA-AL00
--
FROM 223.104.82.*

xsemaphoretake怎么可能是马上执行的？等待信号量的时候是block状态，任务就会移到delaylist里面，delaylist就是按tick来延时的，pdtrue和pdfalse的转换怎么可能是即时的？

【 在 beanspower 的大作中提到: 】
:
: 【 在 Oriphia 的大作中提到: 】
: : 这说法有问题，xsemaphoregive是立即调度，但xsemaphoretake不一定是，而且大部分应用都不是立即调度。
: : 比如串口通信中信号量的timeout绝大多数情况是portmaxdelay，这就一定是在tick调度中被唤醒的。
: : 所有的数据通信函数默认都是阻塞函数，阻塞链表进出肯定在tick任务调度里完成的。

#发自zSMTH@LYA-AL00
--
FROM 223.104.82.*