再谈可移植性与系统架构

    许多人认为，可移植性就是软件从一个平台换到另一个硬件平台，仍然能正常运行的能力。这种说法是很笼统的，我们在细想一下，其中至少存在以下几个层面：
是否需要修改代码。
是否需要修改配置。
是否需要重新编译。
是否能够运行。
运行的结果是否正确。

    听过有人说：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  看看，你会有所收获的。

顶！

第二次看到这东西，还是糊涂。。。