原创 用OS的思想去分析--“抢占式多主多从”单总线冲突裁决方案

2009-3-1 09:21 3325 3 3 分类: MCU/ 嵌入式
HotC51 发表于 2009-3-1 09:25 裸奔式实时操作系统HotTask51 ←返回版面 按此察看该网友的资料 按此把文章加入收藏夹 按此编辑本帖

楼主: 用OS的思想去分析--“抢占式多主多从”单总线冲突裁决方案


HotTask51采用和Linux类似的动态优先调度算法。(但HotTask51的级别0最小,7最大,共8个任务)

TickCount每次在节拍中断中所有任务被遍历减一,当跳变为 0时表示该任务时间片用完,进入
就绪状态。若遍历时遇到多个跳变为0的任务时,表示有相同的优先级在同一时间片内发生冲突
故需要对同级任务进行再判,但HotTask51采用从最低优先级任务开始遍历,遍历过程中如遇到
TickCount跳变为 0,则立即将任务号入保存该节拍中断的就绪寄存器中,注意被挂起的任务除外

最后跳变就是该同级任务的最高级别的任务。它就会第1个被切换。
注意遍历时,TickCount跳变为 0时ready都会被置1 并一直被保存到切换时ready被清零!!!

故HotTask51任务优先级可以相同,这个要优于ucOS-II任务不能同级别优先的缺点.
当然我们应该尽量来避免同级任务给系统的“实时”带来不必要的麻烦。
故HotTask51也建议任务不要同级。但HotTask51自身具备动态优先级调度的设计不应该产生非议。



“抢占式多主多从”单总线冲突裁决方案

1-Wire是一种非常好的“一主多从”单总线标准,但它还存在一定的局限性。
用户在设计自己的单总线系统时,挂接在单总线上的接口设备往往是独立工作的。这就要求单总线无主从设备之分,在任意时刻,每个设备都可申请为主设备,当然该时刻只能有一个设备申请为主设备,而其他只能被迫沦为从设备,且必须等待“单总线冲突裁决时序”过后才能再次抢线,这就是所谓的“抢占式多主多从”单总线系统。
    由于在任意时刻可能有多个设备同时申请“升级”为主设备,故总线冲突不可避免。
为了解决单总线冲突问题,必须给挂接在单总线上的所有接口设备赋予不同的唯一编码即用户序列码。
1-Wire采用1字节设备码+6字节用户序列码+1字节CRC循环冗余码校验方案。
其中用户序列码为全球唯一码共6个字节48位,再加上设备码共7个字节56位。
但这正是1-Wire在单总线冲突裁决技术中的最大缺点,正因为如此它只能作为“一主多从”单总线标准,它注重了“全球唯一”,忽略了“冲突裁决”,从而被迫采用“按位裁决”。
由于在多个设备同时抢占时,在单总线上将发生“线与”现象,CRC将出现错误,本次抢占失败。由于无法裁决,故可能永远抢下去,互不相让,造成总线瘫痪。
解决总线冲突的较好方法是在发送原码后再发送其反码。
由于一般系统不可能挂接很多设备,故可将1-Wire编码方案改造如下:
半字节设备码+半字节设备码+3字节序列码+3字节序列反码+1字节前7个字节的CRC。
以上是“抢占式多主多从”单总线编码,它的优点是冲突裁决已隐含在编码之中,且校验功能大大增强,缺点是最多只能挂接2^24=16777216个设备码相同的不同设备,再加上16个设备号,本方案最大可挂接2^28=268435456个不同设备,但一般系统不可能有如此之多个设备。
由于编码中已隐含冲突裁决,故改造后的单总线就升级为“多主多从单总线标准”。它在应用中比1-Wire只多出了“单总线冲突裁决时序”,其它时序不变或根据实际需要而定。
本人喜欢称其为“群魔乱舞单总线标准”,主从不分,随心所欲。
可能有人会问“冲突裁决已隐含在编码之中”,HotPower又在吹牛!
牛会被一个简单的单总线冲突裁决例子吹破的…



可以看出:

OS为每个任务都配备了一个计数器,每次发生节拍中断或其他需要遍历计数

时,大家都减一。

若规定级别高的计数小时,遍历肯定它先减到零。这对于CPU来讲最简单不过。

但是“单总线”不同,它无任何“资源”,就靠一条线互相捆绑着,就像被绑的

蚂蚱一样~~~

所以其优先和识别问题可能后者更重要。

假若设备及产品都有自己的唯一序列码,那么单总线俺认为正反码各发一次

可能是最好的识别方法,俺真想不出其他好的方法~~~

但俺绝不会想出美国佬如此高明的方法~~~俺真被雷翻了~~~

所以,OS遍历减即动态优先调度算法和菜农的“抢占式多主多从”单总线

冲突裁决方案

都是一种方法,但由于应用场合不同,所以样子就不同。实际都是一个道理~~~

PARTNER CONTENT

文章评论0条评论)

登录后参与讨论
我要评论
0
3
关闭 站长推荐上一条 /3 下一条