- 主题:用freertos做了个系统
【 在 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.*
【 在 Oriphia 的大作中提到: 】
: 这说法有问题，xsemaphoregive是立即调度，但xsemaphoretake不一定是，而且大部分应用都不是立即调度。
: 比如串口通信中信号量的timeout绝大多数情况是portmaxdelay，这就一定是在tick调度中被唤醒的。
: 所有的数据通信函数默认都是阻塞函数，阻塞链表进出肯定在tick任务调度里完成的。
: ...................
串口通信线程(任务)，以接收为例，一般都是semTake，处于阻塞状态。
来了串口接收中断，中断程序里会semGive。退出中断的时候，系统会执行reschedule，如果串口接收任务优先级最高，那立马就执行开始读接收到的字符，和系统tick调度无关。
--
FROM 123.123.253.*
【 在 Oriphia 的大作中提到: 】
: xsemaphoretake怎么可能是马上执行的？等待信号量的时候是block状态，任务就会移到delaylist里面，delaylist就是按tick来延时的，pdtrue和pdfalse的转换怎么可能是即时的？
:
: #发自zSMTH@LYA-AL00
看明白了，你是真不懂....
semtake(..., forever)就会放到pending队列里了。
串口中断服务程序执行一个semGive，然后系统中断退出的时候再执行个reschedule，任务优先级最高的话，立马就会被执行，和tick没有一点关系。这也是rtos的一个核心要义，而不是啥都靠系统tick来做状态转换和调度。
嵌入式/rtos的面试内容可能就包括这个问题：线程/任务调度的时机都有哪些？
看样子这个帖子里没1，2个人能完全回答正确。
--
修改:beanspower FROM 123.123.253.*
FROM 123.123.253.*