• 回复
  • 收藏
  • 点赞
  • 分享
  • 发新帖

使单片机达到最高效率的方法探讨

效率问题一直很受关注,其中相关单位因素大多是代码写的简洁合理,嵌套少,main中尽量少的进行运行等,最近在看到一篇关于单片机效率问题的文章,并不是常见的提高效率方式,大家来讨论一下,看看是否可行。

文章:

我是PC机底层编程转过来的,以前从来没接触过单片机,五个月前学习AVR,在这里学到很多东西。但也意识到电子工程师们的硬件编程思想与PC机底层编程思想上的很多不同,引发了一些思考。我说一说,供大家参考,只为学习,无意争论。

我第一次看到教程里Delay()函数的代码时我吓了一跳,竟然让单片机空转以实现和外界同步,这怎么可能?

试想,如果PC机CPU空转一秒,那么音乐会断一秒、画面会停顿一秒、下载文件会断一秒,这怎么可行?

我看到很多单片机程序,它们的单片机99.9%的工作时间都在打空转,99.9%大家可能感到有些危言耸听,那就让我们算一算:

已内部8M频的AVR单片机来说,单指令周期仅为1/8 = 0.125us,那一毫秒可以执行多少个单周期指令? 1%0.125*1000 = 8000个

而我看到论坛里下到的绝大多数程序,两个延时函数之间代码的执行时间要远远小于8000个指令周期。

说实话,很多16K以上的程序,把所有延时函数去掉,总体能执行几毫秒就不错了。

换句话说,我说单片机的利用率小于0.01%还是口下留情了。

要说怎么解决问题,就要先找到问题,我问问大家,程序中,我们为什么延时?

原因很多,可能是外设速度太慢,也可能是为了躲过人眼视觉停留时间,等等。

总之就是与外界不同步,而我们想要同步。

所以说这些延时应该是很有道理的,我不否定这一点,但问题的关键这些延时空转,我们为什么不能把这些时间回收起来做一些别的事呢?

试想,如果把这99.9%的时间回收,那可以一笔相当巨大的资源。

有很多人有些特殊方法回收过这些空转时间,比如说在延时函数中做点事。

但这些往往都不通用,下面我说一些我的两种方法:

1、前后台模式下延时时间回收的方法:

前后台模式就是大家最常用的主程序大循环 + 中断的模式。

首先解决外设太慢问题,像串口、键盘、LCD、SD卡等IO,这些收发可以建立外部缓冲区。比如串口收发在中断中完成保存到缓冲区,而主程序操作缓冲区而不直接操纵串口,这已经看到很多人这样用了。但像矩阵键盘的缓冲区,我很少看到有人这么用,在中断中接收按键信息保存到缓冲区。

还有像LCD,我们一个个往显存中写数据是很浪费的,也应该建立缓冲,统一处理。

建立缓冲区这类方式中间有一些技术难点,比如像串口接收,无法判断对发是否全部发完,怎么办?可以设立定时,如果一个字节接收之后1ms之内没收到下一个,则认为接收完毕。这只是一个思想,具体应用大家掌握。

可能有人会说,除了外设太慢,还有像视觉停留的问题怎么解决,总不能让流水灯快到人眼都看不清吧。

这就我下面要说的问题,这些延时的时间怎么回收?就是全部放到定时中断中!

可能又有些人会说,书里、教程都说了,中断处理东西的时间要尽量短,你这样整个中断有太多判断、很长,时间很长,这不行。

这是一种教条的思想,把书读死了。可以在中断中这样处理,比如:

void (*Task)(void);

ISR

{

(*Task)(void);

}

中断里用的内容通过函数指针来调用,这样可以在主程序根据需要时任意改变要执行的任务,还可以改任务的周期。所用的判断都是在主程序需中执行,然后改变指针的指向,来确定中断中下一步的任务。

这样,在前后台系统中主程序将任务分配完,还有很多余力处理很多事。

比如有很多个键盘、LED点阵、数码管等,它们都需要实时响应,很容造成编程困难、响应迟钝,其实只要把延时的时间回收,处理这些就非常从容了。

可能还有人会说,有些项目用不了这么苛刻的时间,你回收的时间用不了,要那么多干嘛?

其实这时,你就可以用死循环扫描事件,可以实时响应。你的系统跟原来空循环延时比,实时性要高了不知多少倍。

2、变异的协作式内核

先说说嵌入式操作系统的内核,简单的说,它就是个任务调度器,让多个任务在同一个CPU上同时执行,所谓同时也是相对的,无非就第一个任务执行几毫秒、第二个任务在执行几毫秒。。。外表看起来就是同时执行。

至于可剥夺式内核和协作式内核的区别,大家可以百度一下。

说道能在单片机上用的嵌入式操作系统,大家会说出一些如uCosII、FreeOS等操作系统。

还有很多人对这些操作系统十分抗拒、十分反对,他们的理由是什么?

1、这些操作系统占用大量RAM、ROM

2、这些实时操作系统所谓的实时是相对非实时操作系统的,跟裸机比实际上是慢了

这些理由不是没道理,因为这些商用操作系统都是可剥夺式内核,它们的原则是保证最高优先级任务在可确定的时间内响应。

它们的有优点是任务切换时间是确定的,不会随任务的多少而改变。

有了这些确定性,让它们在商用产品大放光彩。因为其时间稳定性。

但它们的缺点也很明显,中断级节拍浪费很多时间。任务间同时调用时引发同步问题而引入许多如信号量、邮箱等机制浪费大量RAM、ROM。

综上,可剥夺式内核稳定可定量,在越高级的单片机上越有优势,在8位机上可用,但需要大量裁剪,并不一定合适。

而协作式内核的核心思想是什么?它不像剥夺式内核保证最高级任务速度最快,而是保证所有任务的平均速度最快!

正如我前面的说法,我连续两个延时函数之间的代码很难超过1ms,甚至很难超过100us,我们可以将其忽略。这样10个任务,第一个执行完主动放弃单片机控制权,交给第二个任务,第二个任务执行完主动放弃控制权,交给第三个任务。10个任务之间无间隙,每一个任务需要延时时,就主动放弃控制权。

基于这种思想,我们的就达到了回收空转延时的目的,而且应为每个任务是执行完后主动放弃,所以不存在剥夺式内核的同步问题,基本不需要邮箱、信号量等机制,对RAM、ROM的要求就非常低了。

这样来看,协作式内核非常适合8位机。但可能有太多嵌入式系统的书中对剥夺式内核不分场合的认可,造成很多人误解。而且uCos等系统的权威,也让很多RTOS作者争相效仿,没用对8位机的场合做合理分析。

商用系统中没有协作式内核,而民用的,还少有优秀的协作式内核,都是基于传统节拍。

传统协作式内核需要定时中断为时钟基准,也会间歇性打断任务,造成不必要的损失,这并不是我们想要的。

我们其实可以仅仅是让定时器以大分频系数开着, 而不给其产生中断的机会。当任务将要放弃使用权时,读取定时器,作为时钟基准,然后清零。

做法一句两句说不清,而效果是什么?可以做到任务是以不受干扰,与裸机相同的工作状态,这是传统协作式内核做不到的,而仅当它需要延时了,才放弃使用权,将延时的时间给其它任务。这正符合我全文的目的 -- 回收空转延时时间

这样的内核体积会非常小,运行方式与裸机无异,仅仅是把空转延时时间干些其它事。对使用者还没什么要求,不想以往系统那么复杂。

可惜市面上并没有基于这种方式的内核,我已经写了一个,非常精简,运行稳定。但作为一个想应用实际的内核,还需要检验。

全部回复(5)
正序查看
倒序查看
stony_s
LV.3
2
2014-02-10 14:53
比较赞同这说法,现在搞单片机的延时函数用的太多,很多教材很多老师也都这样讲,好像这都成了习惯了
0
回复
matou
LV.3
3
2014-02-10 15:25
研究的很深呀,先收藏了,以前写过按键扫描,没有延时的,效率确实很高,但时基要把握好
0
回复
2014-02-10 16:19
还可以参照PC机的模式,用一个定时器(如定时器0)作为时间基准,通过中断使变量(如i,j等)加1,或加几,然后再在主函数中以查询的方式(如while(i) if(i == 7)等)作为延时的功能
0
回复
for_real
LV.3
5
2014-02-10 16:45
我个人写程序的话一般情况下大于1ms的延时都不会用,而是用状态机+定时器去实现,这样就可以实现高效的利用
0
回复
wooda
LV.1
6
2018-10-13 18:23

说的不错,真正发挥单片机性能的,需要对任务以及任务切换有很深的理解才行。

最近也在看非抢占式os,感觉这种方式比较稳定,抢占式还是有很多限制,并且临界时间太多,会有不稳定现象并且非常难以debug

0
回复