裸奔嵌入式实时操作系统HotTask51概况介绍
HotPower农会主席 菜农
本操作系统的应用限制于MCS51族类,最小配置为8X52开始,基本要求节拍定时器为
MCS51系列MCU的T2定时器,内核资源占用50个字节左右的RAM,2K字节的程序空间.
由于应用的专一和局限，故本实时操作系统RTOS在命名和设计上都不追求华丽的外
表和系统臃肿齐全的功能，而是追求实用、安全及灵巧。
所以，本裸奔嵌入式实时操作系统被命名为基于MCS51硬件平台下可进行简单任务
调度的实时操作系统. 菜农不想追求什么“RTOS之名分”，故本RTOS被菜农低调地冠以
Hot+Task+5+1.
本操作系统的特点在于“裸”，它的内核实际追求“零占用”，即不占用MCU任何不该
有且最紧张的资源与空间。
HotTask51在原始设计阶段就被约束到安全、微小且能与裸奔比拼的苛刻框架之内。
设计被赋予不管采取任何手段，只要结果不要过程，不追求完美，只要满足现实。
HotTask51的目标：强实时、零切换、零占用、零死锁、跨平台。
一.任务
HotTask51的基本单元由任务构成，它与通用的RTOS基本类同，更具备专一应用。
它将硬件和软件编译环境的极限都发挥到极至, 吸收了MCS51从诞生到如今的非经典
应用之精华。
二.中断
HotTask51和任何RTOS一样,必须具备一个专用的硬件定时器作为系统运行跳动的
脉搏，即任务节拍定时器,节拍在固定的间隔内产生硬件中断，随即引发执行节拍中断
服务程序。
HotTask51的节拍中断级别选择MCS51硬件中断系统的最低级别的定时器T2.选择它
主要是T2具有时间常数自动装载功能，再就是有几个与HotTask51的"天地巧合及姻缘"。
其一就是MCS51由于资源的紧缺，优先级是事先按顺序依次排列固定死的，每个中
断的级别只有高低之分。而HotTask51所需的最低中断优先又恰好是IP.5.
其二的巧合就是MCS51在Intel设计之初的8031上只有2个定时器T1/T0. 虽可实现
时间常数的自动装载，但定时器计数位数不能满足在大部分12MHz主频1MHz的10mS节拍
之应用，在其后的MCS51系列里都配置了16位T2定时器为基本配置。满足了长节拍需求。
其三的巧合更为怪异并20余年找不出答案所在--T2定时器溢出标志TF2必须手工清
除。在T1/T0的硬件中断服务程序中，TF1/TF0被硬件中断自动清零。
多年来一直不解为什么???Intel为何做出这样的设计，为何与T1/T0不同，为何升
级T2定时器自动装载寄存器组RCAP2H/RCAP2L而留下了总被菜鸟遗忘的TF2=0;语句。
现在终于明白了TF2的用途---判断节拍中断是硬件中断还是由软中断引发。
在MCS51系列里，无软中断指令和软中断向量表，在后来的ARM/DSP等“高档MCU”系列都
有软中断指令和软中断向量表。
MCS51系列虽无标准的软中断定义，但却实际存在软中断之应用.
最具代表的有TI=1;这条“软中断指令”, 它代表串口硬件发送空或完，引发中断以便
串口的连续数据发送 。
MCS51系列的软中断非典应用当属用INT0/INT1作为控制IO, 其控制后的处理程序
只用一条NOP来替代，而真的处理程序却在其对应的外部中断INTX服务程序中。这属于
一种“任务隐身”的“加密”方式，是正向工程对付逆向工程的一种非常规之“战法”。
MCS51系列的软中断最可恶的应用是定时器未启动(TRX=0)，但中断位开放(ETX=1)
搞个TFX=1，即“软中断”去执行秘密任务。
若TimerXIsr()中断服务程序是个死循环，则TFX = X != Y;即可把"敌人"搞死~~~
因为正确地表达式永远为TFX = 0;//即永远不会死循环~~~
所以，TF2不清零，则任务提前退出或其他中断降级为事件时，可以用一些手段
跳入节拍中断服务程序而不会改变TF2的状态，那么，在真的节拍未到时，不会进行
任务的节拍就绪判断处理。更深的应用自己琢磨。
三. 事件
在HotTask51中，定义事件为硬件中断服务程序采用调用一次RETI后隐身达到降低
其原有中断级别并继续处理更为复杂和耗时的任务。
中断隐身后最大的好处在于既能继续工作又能放行同级中断任务去执行此时的急需
任务。而且“自成”任务环而不需设置标志、发送消息等方法回到
主循环中等待运行。
当然非典型应用是要付出代价的，但只要严格遵守"非典型应用操作规范"，那么
“可恶的非典”就能造福与其应用，并能达到奇妙之效果。
重申：“非典”绝非“技巧”，也不能等同看待，因为本不是一个“数量级的产物”。
四. 汇编数组与COM接口
通常数据是存放在数组内的，即数组内存放的只是需要的数据。
而汇编数组内存放的是汇编代码及数据。
为了得到MCU的最大效率，汇编语言是任何高级语言所不能替代的，高级语言的出现
只是对代码序列进行的封装，其代码实现功能的结果用人类熟悉及习惯交流的方式体现
出来，即用高级计算机语言来表述汇编代码内部有序的排列和组合。
不同的语言表述及编译器得出的结果代码都有很大差异，但实现的目的结果都是一致
的。只是执行的效率、路径的不同而已。
HotTask51用COM接口封装了汇编数组，使HotTask51在适应C语言在嵌入式领域的普及
方面的同时，也考虑了在不同硬件平台上HotTask51的适应和开展。
当用COM接口技术将各硬件开发平台需要的不同CPU的汇编数组封装起来后，如同底层
驱动一样实现了HotTask51的跨硬件平台的作战能力。其思路如同Java虚拟机。
如将HotTask51用于PIC单片机时，由于硬件平台的地基与MCS51不同，但是只要修改
汇编数组中的“数据”而非“代码”，即可在PIC编译器下对HotTask51的母体C函数重新编译
即可运行在新的环境下为新主人做OS全面服务。
所以，在HotTask51的研制开始，就像用此法实现跨各种硬件平台。这也是HotTask51
需要实现的祈望之一。这是HotTask51的终极梦想。
即只需替换汇编数组中的(数据)代码，通过COM接口与任何MCU/ARM/DSP平台对接，让
HotTask51在上面无缝地裸奔~~~
五. HotTask51目标之实现及方法概述
首先HotTask51定格为“51环境下的超任务”，但其设计框架在汇编数组的配合下，将
在此基础下被移植到其他MCU/ARM/DSP上。
HotTask51首战51，但HotTask51内“51”与MCS51字同义非同。这要参见菜农的“中国
象棋数字编码”中对“5”和“1”之定义。
HotTask51尿童版设计为8个任务，8个级别。专供“拇指一族”们学习HotTask51玩耍。
设计要求:
任务参数设置“傻瓜化”，任务功能“积木化”，仿真调试“可视化”，灾难预报“实时化”
设计目标：“强实时、零切换、零占用、零死锁、跨平台”。
实现及方法概述:
1. 强实时
由于HotTask51的任务机制设计的合理，理论上能保证用户7个任务的强实时要求。
任务的2次间隔延时不可避免，但一定保证其延时的固定偏差，故任务间隔周期永远
都是一致的。
2. 零切换
HotTask51采用任务级别就绪和延时节拍的早期预测和运算，可在任务就绪前即可
完成对将要发生的任务进行裁决的及时预处理。
当任务就绪后立即进行与刚被节拍事件打断的任务进行任务的切换。即只进行现场
和断点等简单的不可避免的处理。
3. 零占用
采用任务的编译前即设计阶段的创建任务工作，将不需要变更的所有变量移入Flash
空间内，即内部程序区。
保证了HotTask51在工业现场数据的可靠和安全性，简化了看门狗任务的处理工作。
并给与它更高的决策处理权利。
4. 零死锁
RTOS有个固有的问题，因为级别高的任务不主动放权，则低级别任务永远无法执行。
它和基于时间片(在HotTask51里等同所有任务同级别优先)的RTOS不同。
HotTask51在设计上看门狗任务是整个系统除硬件中断外最高的事件.各事件或任务
必须在创建时告诉HotTask51自己独占的节拍数，超时则看门狗会进行任何手段的处理。
总之，HotTask51中任何事件和任务都应该牢记：一切权利归农会---看门狗事件！
5. 跨平台
在菜农先期研究并完成85%工作量的DSP54系列的裸奔嵌入式实时操作系统HotBios
中，已有汇编与COM接口与HotBios无缝连接的成功案例，若想实现跨平台之愿望，只需
在汇编数组与COM接口之间再套接一层虚拟码接口，如同硬件驱动一样，实现不同平台
下只需配套自己的汇编数组和改虚拟码即可，这样做几乎不用大的改动，即可在新的
硬件平台下运行原先HotTask51核下的用户程序。
到那时HotTask51的底层种类可能繁多复杂，但这都是“专业HotTask51驱动程序”
编制者的工作，用户只需如何得到此“驱动程序”。
最近和嵌入式OS专家吴旭光教授探讨时，他对此很感兴趣，俺之做法不知是否符合
他对跨平台的构思，今后愿与他继续探讨此问题。
HotTask51设计者菜农HotPower@126.com 2009.2.23 于雁塔农会总坛 |
楼主
标题置顶
标题高亮
