yunfenglw

辛昕 发表于 2014-5-8 10:57
这和中断不中断没什么关系
我意思是 它的任务函数从来没有被退出过，也不是靠反复调用来实现的，
这才 ...

可我理解的函数“反复调用”，就是不断地压栈出栈，不断地进入中断函数退出中断函数，不是这样么？求教

辛昕

yunfenglw 发表于 2014-5-8 11:29
可我理解的函数“反复调用”，就是不断地压栈出栈，不断地进入中断函数退出中断函数，不是这样么？求教

我的意思是
rtx中的 任务函数，在挂起时，并没有 退出函数，任务获得运行时，也不是重新进入函数

这和 函数反复调用 进栈出栈 什么的没关系。

我提到中断函数，只是一个对比。
和这个任务函数也没有关系。

辛昕

不过也许你说的是对的。

前不久正儿八经看contiki，其中也有一个真正的抢占式多线程，到时候再说吧。
呵呵，坐车上没事挖坟

lelee007

多任务不是简单的中断驱动的函数调用，任务切换会涉及到现场保护和恢复，因为任务切换时，这个任务不一定执行完成，被调度出去之后，下一次调度进来的时候，要恢复上次调度出去时的现场状态，这个时任务管理的一个重头工作

江山笑

的确是个问题，最近我也在研究这个。起因就是数码管，按键什么的都好办，10ms的片轮，这种简单的短小函数都很easy啊，可是遇到大点的任务，比如12864的显示，大多都100ms以上，这个和按键什么的处理起来也还好，就液晶屏自己复杂点，但要是再有复杂的任务呢？？这种方式就捉襟见肘了，我也正如同 辛昕 一样，想看看Linux等，看的是一头雾水啊。继续潜心研究吧。

江山笑

的确是个问题，最近我也在研究这个。起因就是数码管，按键什么的都好办，10ms的片轮，这种简单的短小函数都很easy啊，可是遇到大点的任务，比如12864的显示，大多都100ms以上，这个和按键什么的处理起来也还好，就液晶屏自己复杂点，但要是再有复杂的任务呢？？这种方式就捉襟见肘了，我也正如同 辛昕 一样，想看看Linux等，看的是一头雾水啊。继续潜心研究吧。

辛昕

江山笑 发表于 2015-1-31 16:33
的确是个问题，最近我也在研究这个。起因就是数码管，按键什么的都好办，10ms的片轮，这种简单的短小函数都很easy啊，可是遇到大点的任务，比如12864的显示，大多都100ms以上，这个和按键什么的处理起来也还好，就液晶屏自己复杂点，但要是再有复杂的任务呢？？这种方式就捉襟见肘了，我也正如同 辛昕 一样，想看看Linux等，看的是一头雾水啊。继续潜心研究吧。

最近我开始从 Contiki 或者 FreeRTOS这些 去真正研究 多任务机制是如何实现的
我开始发现我以前的很多对实现方法的理解可能都是错的，或者不全面。

这个事情可能真的不只是靠中断完成的。
更多的应该是 从汇编角度的 跳转指令 去实现的。

当然现在说这些为时过早。

因为我琢磨了Contiki的 protothread——这并不是一种严格意义上的 多任务机制，它是一种事件驱动机制。
而FreeRTOS ucos这些才是真正的 可抢占式 的 多任务机制。
之所以特别提及 抢占式，是因为 protothread这类，实质上是不可抢占的，而是一种阻塞式的方案。更确切的说，在我看来它只是一种trick

当然如今我对这个东西的观点是
尽管它不是真正的多任务机制，但它也有其适合的应用环境。

不过，之所以回复这个，只是一边折腾 这两个操作系统里的多任务机制，一边在这回味这些帖子。
想说的是，对这个问题，似乎我们的理解都不太对。

但愿我能早点把这些地方理解彻底，然后和大家分享～～

辛昕

江山笑 发表于 2015-1-31 16:33
的确是个问题，最近我也在研究这个。起因就是数码管，按键什么的都好办，10ms的片轮，这种简单的短小函数都很easy啊，可是遇到大点的任务，比如12864的显示，大多都100ms以上，这个和按键什么的处理起来也还好，就液晶屏自己复杂点，但要是再有复杂的任务呢？？这种方式就捉襟见肘了，我也正如同 辛昕 一样，想看看Linux等，看的是一头雾水啊。继续潜心研究吧。

差点忘了我回复你的原因
linux这些系统太复杂了，别说linux,就是ucos恐怕都很复杂。
今天晚上我开始看FreeRTOS，我发现它确实是个很精练很简单的操作内核。
你也许可以试试从这里入手 开始。

一起努力吧～～
给一个链接，这是网上一个叫 徐凯的大神 的博客，他的博客里有很多关于 操作系统 以太网 的学习笔记，而且还给了 移植成功的项目，真的是对我等非常有用，不敢私藏，分享与此～～

http://blog.csdn.net/xukai871105/article/details/13156977

辛昕

江山笑 发表于 2015-1-31 16:33
的确是个问题，最近我也在研究这个。起因就是数码管，按键什么的都好办，10ms的片轮，这种简单的短小函数都很easy啊，可是遇到大点的任务，比如12864的显示，大多都100ms以上，这个和按键什么的处理起来也还好，就液晶屏自己复杂点，但要是再有复杂的任务呢？？这种方式就捉襟见肘了，我也正如同 辛昕 一样，想看看Linux等，看的是一头雾水啊。继续潜心研究吧。

另外我想说的是
假如你只是想 解决 这种 按键 数码管 或者 12864 等显示 的 时间错开 问题 ——其实更专业点应该说是 平衡不同数量级操作时间 的 任务，其实有更加简单的办法。

那就是不要再函数里用大量的 直接 delay延时，而是把 函数执行的行为拆散，然后分步执行函数——就是函数每次调用也许只执行其中的一两个动作，用其他函数的运行时间 来 代替延迟。

这是我过去在无os环境下（确切的说，无多任务机制环境下）大量使用的方法。

它对于一般的情形——比如你提到这种，实在属于很一般的简单情形，相当有用，可以避免 使用复杂的 os.

当然，这会让每个任务写起来相对要费点劲。

——这里我也是慢慢才体会到，这其实是一种 费劲 的 转移。

如果我们采用os等多任务机制，我们会把几乎所有这种费劲的努力都转移到 os的实现或者移植上，而单独每个任务实现起来则会相对简单许多。
但是，如果我们不使用os，则几乎把这种费劲全数转移到 每个单独的人任务上来，甚至是每个任务都的来一次。

当然，这两者并不存在绝对优劣之分。
比如当情形不是太复杂时，每个任务都来一遍又如何？
毕竟引入os可实在是相当复杂。

特别是 对 空间资源，运行时间的巨大影响～～