| 在openARM中协同开发的方法 | 任何一个采用集市(bazaar)方式进行开发的开源软件项目都有一个基本的共同点，就是修改采用补丁(patch)的方式提交，使得整个开发过程以一种渐进和可控制的方式进行。这也许在软件项目中看起来是理所当然的，但是当我考虑如何协同一个开源硬件设计项目时，我发现“补丁提交”却是采用源代码形式最大的优势。开源硬件项目往往需要涉及原理图、PCB图等等不能以源代码形式出现的设计文档，组织和协调就成了一个大问题。当然，在商用软件中早就有了协同工作的功能，但是从降低开发门槛出发，我们只能立足于简单的现有软件。解决协同开发的方法有三个：
1、Softwarize Hardware(硬件设计“软件化”)。在OpenARM项目中，所有的外部逻辑---无论是粘合逻辑(glue
logic)还是功能逻辑(function logic)都是在一片FPGA中完成的，这就使硬件设计可以基于HDL(Hardware
Description
Language)进行。对于不得不进行硬连线的设计，尽量简单和可靠，以避免修改。在OpenARM中，硬连线部分包括SA1110和SDRAM以及FLASH的连接、电源和外部接口等等，基本上无需调试。当存在一个简单和可靠的基本系统板的时候，这个硬件项目就变成一个基于SA1110
bootloader和Linux内核源程序以及FPGA HDL语言的软件项目，此时可以完全按照开源软件的组织模式进行开发；
2、Release Early, Release Often(早发布，常发布)。实际上，在ESR的The Cathedral and
the
Bazaar这篇**中，我常常考虑的一个内容。必须保持开发人员和潜在的开发人员对于OpenARM项目的兴趣，每一个开发人员都希望看到自己的修改立即被采纳，每一个潜在的开发人员都不会加入一个进度缓慢、前途渺茫的项目，所以能否RERO(早发布、常发布)决定了一个项目开发过程是良性还是恶性循环。由于对于原理图修改的提交，大多采用在论坛或者邮件列表上口头描述的方式进行，所以及时发布snapshot还可以使其他成员尽早看到修改的效果，从而开始新一轮的思考和讨论(或者简单地叫做“debug”)。OpenARM项目在开发最活跃的时段里，基本上对每一次修改都立即发布snapshot版本，这使得修改的提交可以尽可能快地得到反馈，实际上我就成了一个手工的CVS，
:-) 。而在snapshot发布不够活跃的时候，大量的参与人员明显开始流失，比如2001年的9月到11月；
3、尊重每一个人。也许这和协同开发的技术方面无关，但是对于保持一个良好的协作氛围是非常重要的。OpenARM项目得益于中国Linux论坛的嵌入式系统版，而嵌入式版也因为有了OpenARM项目才会发展到现在这样的人气，这在技术论坛中是比较难得的。在嵌入式系统---尤其是软件方面---的技术水平上，我本人并不是一个好的版主，所以每当有人叫着“斑竹救命”给我发私信的时候，我总是脸红地告诉他们到论坛上去问。我只知道一点，就是保持大家的注意力和兴趣，让每个人都知道OpenARM还活着而他是必不可少的，每个人的建议都不会杳无音信。对于每一个原则性的改动，都要放到论坛上讨论并最后由大家作出决定，这一点是非常重要的，让每一个人都有参与感。因为在开源硬件设计的项目中，vxworks和我的作用仅仅是协调人(coordinator)和仲裁人(moderator)。
|
|
楼主
标题置顶
标题高亮
