Kermit’s Gossip ? Blog Archive ? 对嵌入式开发的一点思考

对嵌入式开发的一点思考

刚才在网上看到了一个介绍Qt嵌入式编程的教程（其实也是该硬件公司的产品宣传），我突然发现，一向让我感到神秘的嵌入式变成原来如此简单。呵呵，这个有点吹牛了，因为我没有做过嵌入式，所以这篇写的都是些想当然的东东，如果有不正确的地方，还望指正;p
我说嵌入式简单，意思只是说它和PC程序开发没有什么本质的区别，甚至比PC程序还要简单。由于嵌入式设备硬件平台往往比较固定，所以几乎不用考虑移植性的问题，程序员的任务往往只是调试出在当前平台上运行程序即可。
设计软件就是设计不同层次的接口，而编程只是使用已实现的接口来实现自己设计的这些接口而已，嵌入式也不外乎此。对于安装Linux系统的嵌入式设备其实就是根据此系统已有的接口设计并实现新的接口。如果熟悉Linux，再按照说明书了解一下目标硬件/软件平台，完成这些任务应该是不在话下的。
我们通常听说嵌入式难，那其实是因为我们使用的接口的抽象层次太高了，这些接口对于嵌入式设备而言是毫无用武之地的，那些.NET程序员就是典型的例子。但是，对于一个熟悉LinuxKernel的程序员来说，任何给予Linux系统的嵌入式设备都应该是不在话下的，他们要做的只有三个工作：1.看看说明书，了解一下自己可用的接口；2.搭建开发平台；3.充分考虑资源限制。
要一定说嵌入式难，我倒是觉得不是难在开发上，而是难在平台的搭建上。嵌入式开发平台基本上都是交叉编译的平台，这种开发方式的特点就是不能在搭建系统的平台上进行测试，必须把编译、链接好的可执行文件拿到目标平台上去调试。所以，我觉得，除非借助于虚拟机制，不然gdb这类调试工具应该是没有用处的，因为程序根本就无法在编译平台上运行，而只能在由于资源限制而无法安装和使用调试工具的目标平台上运行。这样，我觉得调试器的用处实际上已经不大了，尤其是一些涉及到更底层的实现时更是如此。这就让人想起了HurbertXu以前讲的那点经验：把gdb这个拐杖扔掉，想办法把可能出错的地方转换成可输出的信息输送到屏幕上！
报料一下：我以前过早地扔掉了gdb这个“学步车”，以至于面试的时候人家问我怎么显示函数的stack时，我居然傻眼了——那时候我还不知道，我还是个小孩，还需要gdb这个车子；当然了，现在也是……
gdb虽然可能在某些地方派不上用场，但是我们还有一个工具： 条件编译。我在自己的程序中喜欢用自己定义的D_OUTPUT宏来得到自己想要的信息：
#ifndef MY_DEBUG_H_
#define MY_DEBUG_H_
#ifdef DEBUG
#include
#define D_OUTPUT(a)   std::cerr << (a);
#endif //DEBUG
#endif //MY_DEBUG_H_
除此之外，还可以用到__FILE__，__LINE__，__FUNCTION__等预定义宏。和gdb相比，这种方法灵活性更高，但同时需要程序员有更高的悟性，写程序的人要能估计出程序可能出现问题的地方，不然加再多的输出也没用。我一般比较喜欢结合gdb和条件编译来调试。 因为gdb能很快找到程序中止的地方，而此处在绝大多数情况下就是发生错误的地方。
我觉得最后，也是最重要的一个困难应该就是资源限制。我在网上看了一下，好像现在的一般的ARM设备都只有几十K的RAM和几百K的Flash(这个数据不准确，知道的麻烦说一下)，这种配置应该是不能运行GUI程序的吧，要是可以那简直太神奇了。就是CUI界面，这点可怜的资源也会很容易就被吃掉，在这种情况下，想用C++似乎都得要考虑下了。所以，这个时候的嵌入式程序最麻烦，动辄就要考虑资源不足的问题。
就写这么多了——完全地空想嵌入式主义，哈哈！


Categories:编程实践 Posted By: Kermit Mei
Last Edit: 03 四 2009 @ 07 29 上午
Email •Permalink

Previous Next


Amankwah 说：
2009年04月3日于6:51 下午
嗯，能空想到这个程度不错了。不过，我指出几点错误：
第一：可以移植性，如果一个公司有一个产品、你在上边写一个一个应用，这个产品做完了？然后，后来又有两个差别不大的平台，也需要这个应用，然后你重写一 遍？其实，我感觉相对来说，你恰恰说反了，PC因为其体系结构的固定性，有时候不考虑往其他平台架构移植可能也可以。但是嵌入式的软件产品，如果写程序的 时候不考虑，以后可能光改软件就得改哭你。
第二：嵌入式平台难在平台搭建上。这个观点有两面，如果你把设计硬件也算在平台搭建里边的话，可能是比较难。但是我接触到的东西，平台搭建都不是什么难 度，特别是gcc本身就支持的平台。你可以看看关于gcc和libc的交叉编译的资料，顶多就是耗费时间的很而已。我认为嵌入式开发真正的难度在于，嵌入 式开发，往往都是多线程的，把哪些认为规为那个线程，线程之间的数据关系，那些数据是需要加锁保护的，在这种情况下，还要保证系统的稳定、避免竞争条件、 还有性能要求，这样写程序简直是戴着枷锁跳舞。
第三：gdb，有一个东西，叫做gdbserver，你可以看看。不过说实话，我比较赞同你的 观点，我更倾向于在程序里把东西输出出来，带上文件名函数名和行号。
第四：现在嵌入式平台不是你查到的那样了，不知道你在什么地方查到的。比如我就见过x86的嵌入式平台有2G内存的。我接触到的ARM也往往至少有32M 内存，64M和128M常见。我手机还有128M内存呢。NAND Flash往往是128往上，因为这个现在很便宜。而NOR Flash往往有1～2M。也还不错了。当然，如果是有些片子片内，估计就比较紧张了。所以现在嵌入式编程，除了一些极限情况，资源并不算太紧张。我的感 觉GUI消耗资源的原因在于，这些平台往往没有图形芯片，用CPU来渲染图形界面，有时候刷新频繁的时候，就比较恼火罢了。
Amankwah 说：
2009年04月3日于6:53 下午
你的这个博客系统和东八区有三个小时时差？？？？
Kermit Mei 说：
2009年04月4日于10:32 上午
多谢指点！老大给俺写了这么多，真是感激不尽:) 尤其是上面的第四点，俺真是闭门造车了。
那个gdbserver我回头看看。至于线程的那些问题，我建议你不妨用面向对象的方式写代码，这种思想绝对是个节省脑力劳动的好办法:) 我也把自己的想法总结一下，写在另一篇中。
BTW：时区问题已经改正。
Amankwah 说：
2009年04月4日于12:08 下午
面向对象？现在用的虽然是C，但是程序设计基本上都是OO的啊？但是，面向对象能解决线程调度优先级以及一些公共变量在线程之间访问加锁的问题吗？愿闻其详，现在正给同步问题折磨这呢～