看板Electronics
标 题Re: [问题] 请问有没有专门讨论关於韧体程式的版?
发信站无名小站 (Thu Jun 1 18:38:17 2006)
转信站ptt!ctu-reader!Spring!ctu-peer!news.nctu!netnews.csie.nctu!wretch
常用的副程式或是module可以写成副程式的方式
但是假使使用call的方式 可能要把一些暂存器push/pop 会影响效能
不用call的方式 直接执行该段程式 听起来很白木 免了push/pop却占rom size
但是执行起来却是效能比较快 有时候这本身就是需要取舍
就如同使用c/asm写一些51的code一样 可读性高不代表效能好
这也是有取舍的 有时候为了挤出一点效能却得牺牲可读性
除非到高阶的CPU 所谓的OO的概念才能有所发挥
不然很多低阶的CPU用OO不见得能达到最大的投资报酬率
※ 引述《[email protected] (爱笑的蚵仔煎加蛋)》之铭言:
> : 哇... 有人在提有趣的东西了:P
> : 小弟平时是做韧体方面的比较多 但大学以前主要是接触软体方面
> : 也和别人一起接过要用上四个design pattern的较大型的软体专案
> : 坦白说 在目前韧体上 小弟认为要用到OOA/OOD还太早
> 是这样没有错,可是我总是常常在想,
> 就算没有OO的compile,
> 可是程式的写法跟意境,其实还是可以放在里面的
> 有人说过OO只是ㄧ种概念,甚至也可以用再组合语言
> 对这个我深信不疑,但我还不会
> 所以才想提昇自己功力
> : 可能小弟用的都是low level的CPU吧
> : 一方面不是所有CPU的complier都支援C++支援得很好
> : 另一方面CPU的速度不够快到可以奢侈地写漂亮的code
> : 另一方面记忆体更是少得可怜
> 对对,我也有遇到过一样的情形,
> 我师父跟我说:ㄧ样功能的程式有三种写法
> 节省ROM SIZE,节省RAM SIZE,效能考量
> 当初我开发是再ROM快到极限的情形下写程式
> total ROM SIZE 有64K,可是已经用掉了60K
> 所以有时候要牺牲效能,或牺牲RAM
> : 您提到mp3 player, 之前小弟自己做了mp3 player来玩
> : 在FAT32的部分 就不可能把code写得太漂亮
> 这我也有切身之痛喔
> 可是每次只要拿到原厂给的程式
> 程式架构和软体技巧有够华丽的
> 就会觉得自己写的东西真像屎
> : 简单的说 你不可能用recursive去解folder下的folder
> : 因为解一次可能就是0.5K的memory size
> : 可是完成这个工作只需要1K以下的memory(目前小弟做到1K而已)
> : 另一个方面 在embeeded system上 CPU换来换去
> : 要做到hardware abstraction layer不难
> : 但小弟每每都将code写成chip dependency或I/O dependency
> : 因为每次k spec的时间太长 若code不写成呆呆的样子
> : 会把跟spec的部分写不单纯 拿出来看很难一页就能从code反译成spec
> : 我同意写韧体要尽量做硬体/韧体/软体的切割
> : 但是基於以上小弟的一些想法 其实小弟的firmware code总常会有一种
> : 写漂亮不是最重要的想法 去抗拒我写太好看XD
> 这样讲也很道理,不过我一直在想这算不算是瓶颈呢?
> 应该有两全其美的方法,只是我不知道而已
> : 小弟认为目前object based还有可能 object-oriented似乎还太早
> : 而且因为不是每个complier都是有C++支援 CPU常常是换来换去的
> : 所以.......:P
> : 小弟对这方面也很有兴趣 抛砖引玉一下
> : 上面的想法多半是个人经验罢了 欢迎高手指正一下:)
> 用c写出OO概念的程式一直是我的梦想
> 降子就没有complier的问题了吧^^
> 感谢您的分享喔
--
夫兵者不祥之器物或恶之故有道者不处君子居则贵左用兵则贵右兵者不祥之器非君子
之器不得已而用之恬淡为上胜而不美而美之者是乐杀人夫乐杀人者则不可得志於天下
矣吉事尚左凶事尚右偏将军居左上将军居右言以丧礼处之杀人之众以哀悲泣之战胜以
丧礼处之道常无名朴虽小天下莫能臣侯王若能守之万物将自宾天地相合以降甘露民莫
之令而自均始制有名名亦既有夫亦将知止知止可以不殆譬道之在天下203.69.97.52海