看本文请参考《都江堰操作系统与嵌入式系统设计》第15章，该书可在www.djyos.com下载。
djyos目前发布的是si版本，si版本是面向单片机的，有意思的是，到现在为止，djyos还没有在单片机上运行过。以前发布的几个平台，都有大片的内存，其实更加适合dlsp和mp版本，本次是首次把djyos搬到适合自己的家——单片机上生活。在豪宅生活惯了，回到经济适用房，肯定有一个适应期，本次移植，将面临更多挑战，会面临许多策略性的问题，也会解决更多问题。
1、前几次在三星系列cpu之间移植，平台差别都不大，本次移植是首次在差别很大的平台间移植，将会考验djyos的可移植性能。
2、将首次检验djyos在单片机上运行的适应性。
3、工程组织如何适应单片机细分型号众多的问题，也将在本次移植中解决。
上次定了调，现在就要开始写代码了吗？不急，在着手写代码之前，还要交代一下开发环境，开发环境有两个方面：编译环境和调试环境。
编译环境当然沿用gcc了，在V0.4.1版本文档《建立windows下djyos for arm的编译和调试环境.pdf》中有详细的说明，不再赘述了。
值得一提的是调试环境，原来用的RVDS2.2，由于不支持cm3，已经不能再用了，比较流行的能用于cm3的开发环境是MDK和IAR，还有就是gcc配套的gdb了，gdb也有windows下的图形化版本insight，虽然是图形化，但其界面一样丑陋无比，对被windows惯坏了的我来说，简直不可接受。
gcc编译出来的文件是elf格式的，现在各门各派的arm工具都声称支持elf，似乎**主义提前实现，世界大同的日子就要到来了。事实上并非如此，各家在实现elf时，或多或少会有些不同，也许是对elf标准理解不一致造成的吧，或者是其他目的。iar上，只要你一点调试按钮，程序立马退出运行，没有任何提示，尸体都不见——连料理后事都省了。MDK则要好很多，虽然不能利用其IDE来编译，但调试时还是可以识别gcc的elf文件，我是用了一个非常简单的程序测试的，不知道工程复杂了会怎样，先用着，以后有问题再说吧。
那现在可以写代码了吗？知道你心急了，但还是要等一定，嵌入式开发很重要的一个工作就是决定软件使用存储器的策略，这个可是人命关天的大事，不但操作系统，应用程序也一样。管理存储器是操作系统的核心工作之一，它是应用开发中如何选择操作系统的重要指标。也许有人会说，单片机没有mmu，存储器管理会很简单，大错特错了。成语云“巧妇难为无米之炊”，有米谁不会做饭，难的是东一把杂粮西一撮碎米，再加点野菜拌南瓜，也要把饭做好。单片机的存储器恰恰是这样，代码一部分在flash中运行，一部分在ram中运行，ram又分为多个区块，这些区块可能连续也可能不连续，不同区块的访问速度可能不一样，还要区别使用，即使地址连续，也不能撸在一起。如今的cm3还用位带的概念横插一杠子，如果要有效支持位带，存储器管理将变得更加复杂。djyos过去的平台中，系统启动后，flash就被扔掉，只留下连续的大块内存，管理起来就很简单。这里先粗线条地说一下存储器的使用思路：
1、绝大多数OS代码和应用程序在flash中运行，但允许应用程序配置中断相关的代码在flash还是RAM中运行。
2、堆分为多段，用户可以配置段数，每段尺寸，优先顺序。当用户调用m_malloc时，按照用户定义的优先顺序在各个堆中查找空闲内存。也可以由用户指定从哪个堆中分配。
3、如果用户设定中断在内部ram中执行中断代码，则片内ram从低地址到高地址的分布是：代码---->变量---->堆---->中断/异常栈（1K）。
4、如果不在ram中执行代码，则ram分布是：变量---->堆---->中断/异常栈（1K）。 |
楼主
标题置顶
标题高亮
