搜索
bottom↓
回复: 3

再谈可移植性和系统架构【恢复】

[复制链接]

出0入0汤圆

发表于 2009-1-12 16:49:09 | 显示全部楼层 |阅读模式
    许多人认为,可移植性就是软件从一个平台换到另一个硬件平台,仍然能正常运行的能力。这种说法是很笼统的,我们在细分一下,其中至少存在以下几个层面:

是否需要修改代码。

是否需要修改配置。

是否需要重新编译。

是否能够运行。

运行的结果是否正确。



    听过有人说:C语言编写的代码,哪有移植性的问题。这种看法谬之大矣,等于说:我用拼音输入法写文章,所以我的文章是可移植的。关于C语言程序的可移植性,我的文档《都江堰操作系统与嵌入式产品设计》的第16章有详细的说明。用标准c语言写的程序,只能保证在支持标准C的编译环境中成功编译,不能确保能够正确运行。

    比如下面这段代码,用指令实现10uS延时:

    for(i=100; i>0; i--);

    该语句无论在什么平台下,它都可以编译、运行,但结果可能不正确。具体延时量,与CPU的速度、编译器的效率、编译器的优化级别等都有关系,我们称之为”耦合“,在《都江堰操作系统与嵌入式产品设计》的第11章论述了什么是耦合以及如何解耦。含上述代码的软件,在移植时,必须修改代码。一种改进的方法是,把100定义为符号常量,如下:

    #define cn_10us     100

    for(i=cn_10us; i>0; i--);

    这种方法只不过增加了代码的可读性,并降低了代码修改的工作量而已,本质上还是要修给代码并重新编译。djyos提供的改进方法是,有操作系统提供几个共享变量,他们是在操作系统初始化过程中被赋值的:

1.  uint32_t  u32g_ns_of_u32for; 

当 delay_var是 32 位无符号整数时,每个循环消耗的纳秒数。 

2.  uint32_t  u16g_ns_of_u32for; 

当 delay_var是 16 位无符号整数时,每个循环消耗的纳秒数。 

3.  uint32_t  u8g_ns_of_u32for; 

当 delay_var是 8 位无符号整数时,每个循环消耗的纳秒数。 

4.  volatile uint32_t    u32g_delay_10uS; 

用 32 位无符号数做循环变量,延时 10uS 需要的循环次数。 

在si模式下,若用下列语句做指令延时,可确保延时时间是100微秒。

volatile uint32_t    delay_var; 

for(delay_var =100000/u32g_ns_of_u32for; delay_var>0; delay_var --); 



    然而,这只是djyos解除软件与CPU运行速度之间耦合的一个小技巧而已,djyos更着重的是从系统架构入手,帮助项目经理和开发经理组织团队,帮助系统架构师理清组件之间数据流动和代码互动之间的关系。

    

    现在的嵌入式产品开发,从一个新平台重新开始开发的机会相对会少一些。更常见的情况是,拿一套已经有了型的代码到处修改客户化做新项目,或者依据市场需求把产品改一改,添加一点新的需求,去掉一些老的功能,做系列化型号。广义地,就一个功能组件来说,它的运行环境整个由硬件、操作系统、以及应用项目的其他组件共同组成。应用项目某组件的变化,也是运行环境的变化,也可能需要移植,而且这种移植更加广泛,更加受项目经理的重视。djyos系统更加关注的是广义的移植,从这个角度,即使硬件和操作系统部分不改变,某组件的运行平台的数量,也跟使用该组件的衍生产品型号一样多。如果不注意广义平台的可移植性,一个组件往往会在这个型号中好使,那个型号中就不行了,按下葫芦浮起瓢,防不胜防,烦不胜烦!最后造成的是,实现相同功能的组件,在不同的衍生型号中就是不一样。日子久了,这样的东西就会充斥企业的产品中,并与企业历史相结合,企业历史留下来的人和流下来的势力格局有限制了改进问题的机会,许多企业里面软件版本繁多而且凌乱,难于管理,就是这样造成的。解决这个问题,需要一个优秀的系统设计师,在项目设计之初就确定一个良好的系统架构,djyos从技术角度上,对项目经理和系统工程师提供帮助,为新项目的开发和老项目的改造都提供支持。试举例如下:

    某工程由多个团队协同开发,某中断的初始化以及ISR代码由团队B负责,另外一个组件由团队A开发,组件A有一个线程需要阻塞等待某中断发生。那么,在传统模式下,团队A和团队B之间在技术上,至少有一个信号量在联系,线程等待信号量而中断释放信号量。别看这个简单联系,它造成的后果就是两个模块互相关联(耦合),中断ISR中至少有一句是跟组件A相联系的,线程和ISR之间至少有一个共享变量——信号量句柄!ISR和线程之间至少失去了独立的命名空间,即使你不用共享变量,那么,ISR至少需要提供一个手段,使线程能够把信号量的地址告知。总之,两个团队之间不可能再是完全独立的关系。而使用djyos的异步信号同步技术,则团队A可以根本不知道团队B的存在。

    多团队共同开发的项目中,项目经理最希望看到的是,两个团队之间各自完成自己的任务,各自的任务之间不互相依赖,这样两个团队之间的开发进度就可以异步安排。而如果两个组件之间有耦合的话(就像刚才的例子,通过信号量耦合),至少有一些团队协调工作要做。而djyos中,两个团队是完全独立工作的,独立开发、独立编译、独立加载运行。

    djyos在许多地方体现了协助项目经理”孤立“团队的策略,今天先写到这里吧,下次继续谈。

    

    关于djyos以及其相关文档,可以到

    www.djyos.com  看看,你会有所收获的。

阿莫论坛20周年了!感谢大家的支持与爱护!!

一只鸟敢站在脆弱的枝条上歇脚,它依仗的不是枝条不会断,而是自己有翅膀,会飞。

出0入0汤圆

发表于 2009-1-12 21:00:26 | 显示全部楼层
顶楼主,楼主应该主持这里的嵌入式OS的板块

出0入0汤圆

发表于 2009-1-12 19:56:06 | 显示全部楼层
明天继续。

出0入0汤圆

发表于 2012-3-4 09:00:49 | 显示全部楼层
读到拍案叫绝  
回帖提示: 反政府言论将被立即封锁ID 在按“提交”前,请自问一下:我这样表达会给举报吗,会给自己惹麻烦吗? 另外:尽量不要使用Mark、顶等没有意义的回复。不得大量使用大字体和彩色字。【本论坛不允许直接上传手机拍摄图片,浪费大家下载带宽和论坛服务器空间,请压缩后(图片小于1兆)才上传。压缩方法可以在微信里面发给自己(不要勾选“原图),然后下载,就能得到压缩后的图片】。另外,手机版只能上传图片,要上传附件需要切换到电脑版(不需要使用电脑,手机上切换到电脑版就行,页面底部)。
您需要登录后才可以回帖 登录 | 注册

本版积分规则

手机版|Archiver|amobbs.com 阿莫电子技术论坛 ( 粤ICP备2022115958号, 版权所有:东莞阿莫电子贸易商行 创办于2004年 (公安交互式论坛备案:44190002001997 ) )

GMT+8, 2024-3-29 14:21

© Since 2004 www.amobbs.com, 原www.ourdev.cn, 原www.ouravr.com

快速回复 返回顶部 返回列表