RT-Thread/AVR32分支？

ffxz

看了watercat的帖子，
http://www.ourdev.cn/bbs/bbs_content.jsp?bbs_sn=3254837&bbs_page_no=1&bbs_id=1030

其中提到“有MPU的处理器用起来就是爽利，使分步分模块研发变成了很简单的事情”这个应该是用MPU来做memory的保护吧，它能设置多少个Unit？如果模块多的话，也不能做到每个模块一个Unit进行保护。

前几天也还在ARM7上做RT-Thread动态模块支持（原本是想在STM32上做的），基本的加载都没问题了，只要在操作系统级别再完善下就初步可用。后来一切换到STM32下，用armcc的编译器一编译就傻眼了，armcc在thumb2模式下居然不支持生成位置无关代码！

那么，是否可以考虑做一款RT-Thread/AVR32分支呢？

RT-Thread需要的基本资源（还可以小些，但放宽一些比较好）：
ROM: 12K
RAM: 6k
（如果要做动态模块加载，显然RAM还需要更大，假设一个module是8K（包括RO，RW），需要/能够加载几个module？）

相应的如果要做这个分支，哪款芯片&开发板比较合适？

watercat

？MPU虽然有若干个区域设置，对于小任务来说确实够用了，不过，没人规定用了MPU就不能搞进程上下文切换吧？有上下文切换、并且每个模块都是相对编译的话，理论上你开多少个任务都没影响啊……当然真要做无限多任务的话，实时性也就自然没有了

其实在我看来，MPU相对于MMU，最主要的区别是：前者不能为每个进程提供平坦的虚拟内存空间；同时后者没有前者那样的实时性

另一方面，RT-Thread没怎么用过，不过RTOS原则上只要能提供基本的功能，则越小越好，而且这东西毕竟不是Linux，通读代码没有什么复杂度，所以具体用什么RTOS环境我个人认为无所谓——只要接受者够多就是了

芯片的话，作为实验平台用，自然首选UC3A0256，256K Flash/64K RAM，有以太网MAC和基本音频功能，还能外扩数兆的SDRAM，很宽裕也很好玩

但如果打算作为产品，则最好还是以UC3B064作为目标，毕竟成本和封装尺寸摆在那儿……

考虑到综合成本，建议就直接用邮购部的“AVR32 UC3B064小板”（当然，主芯片最好还是换成UC3B0256），虽然我没用过这个版本，但从电路设计和做工上看，这个版本显然比之前的版本更成熟可靠——就是不知道阿莫这里能不能完整加工了……毕竟一个一个元件自己焊也还是很费力气的……

ffxz

可能我理解有误，引用部分：
"？MPU虽然有若干个区域设置，对于小任务来说确实够用了，不过，没人规定用了MPU就不能搞进程上下文切换吧？有上下文切换、并且每个模块都是相对编译的话，理论上你开多少个任务都没影响啊……当然真要做无限多任务的话，实时性也就自然没有了 "

一般MPU能设置的unit比较少，例如ARM946E的是8个。如果每个动态载入模块都需要用MPU保护，而又有8个动态模块需要同时加载的时候，那么就不够用了(难道这进行模块切换时做MPU设置的切换？！)。但仔细一想，动态模块实际上和MPU关系并不大，因为它并不一定都需要保护。(任务多和实时性没任何关系，如果因为任务多而造成实时性下降，那么肯定是这个RTOS设计得有问题，因为它不能满足最基本的调度器时间确定性)

RT-Thread中的动态模块加载被设计成和操作系统中的内核对象密切相关，模块所属线程创建的内核对象都统一挂在模块的控制块上，当模块卸载的时候也会跟着一起卸载。设计RT-Thread之初就努力的希望RT-Thread能够朝着微内核的方向发展。通用操作系统改造的实时系统因为大量的使用了MMU，虚拟地址空间，内核态与用户态造成实时性相对较差，而微内核也混淆在其中，并试图通过进程与进程之间通信机制把各个模块之间的耦合性降低。那么RT-Thread是否可另辟蹊径，走一条动态模块加载的道路呢？单独的核心做成一个细粒度的微内核，再通过动态加载的方式把一些服务启动起来(例如协议栈、文件系统)，这样模块与模块之间的通信可以继续延续传统RTOS的方式实现零拷贝的消息传递，效率大大提升(相对于传统通用操作系统)，而实时性能依然健在。

不过动态模块加载也有代价，就是动态符号解析的代价，特别是当模块比较大的时候，吃内存+速度慢！加载成功后就和传统意义的RTOS一样了。

谢谢watercat的推荐，那哪里能弄UC3B0256开发板呢？唉，本人硬件能力也很低下啊～～

watercat

举个例子说（其实这例子在很多介绍MPU应用的书中都有）

8种区域，区域0范围是全地址，权限是全禁止；区域1范围是系统空间，权限是系统可读写、用户禁止；区域2范围是外设空间，权限是系统可读写、用户只读；区域3权限是用户可读写

这时候，只要在每次任务切换时，把区域3的范围设定在当前将执行的任务所在地址空间上，就可以简单的实现多任务内存访问权限控制了，而这时候还能剩下4种不同的区域设定

或者换句话说，MPU的区域设置，实际上应该理解为“权限组”，并不代表特定的“用户”，而实际使用时，需要根据情况，将特定的用户加入特定的权限组，仅此而已

捎带说一句，MMU也是要这么用法的……

另外，对于这种类型的MPU操作而言，结合动态模块加载，确实会在任务数量过多时导致实时性丢失的，具体原因，希望你能自己理解一下

robinyuan

搬板凳听课

ffxz

理解了，这种做法就是相当于针对当前任务做MPU保护区调整，当前任务一变就需要重新做一次调整。

另外这么做，可能还会涉及到用户态、系统态的问题了。

watercat

对，不过一般用到MPU的时候，极少会存在真多任务的情况，因此不需要考虑核心态数据重入的情况

同时，一般使用MPU的情况下，每个任务最多只有四个不同的权限需求：代码、数据区1（通常为私有数据或任务栈）、数据区2（通常为共享数据区）、受许可直接使用的外设控制区

而这四个权限区只需要一次查表就能够完成，因此，整个任务上下文切换的过程所需要的时间并不多，而且在任务总数有限的情况下，确实可以保证上下文切换的时间是定值

另外，就以AVR32UC3B为例，虽然MPU的区域设置粒度仍然过粗（最小4KB，最大4GB），但至少就外设控制区来说，确实已经把几个有重要功能区别的区域以4KB为单位单独划分了，各区功能分别如下：

1、USBOTG

2、总线矩阵及Flash烧写、保护控制

3、DMA控制器、内外中断、电源管理、实时时钟、看门狗

4、GPIO、3组USART、SPI、TWI(IIC)

6、PWM、SSC、通用定时/计数器和ADC

基本来说，经常需要组合在一起使用的功能其外设控制区大都被以4KB为单位独立划分了，确实有利于任务划分和系统控制

不过，SSC控制区与PWM和定时/计数器和ADC控制区地址过近，难于单独抽出，在我看来还是有点败笔的意味，毕竟SSC作为一种独立而高效的通信方式，确实很适合单独开个任务进行管理的

当然，瑕不掩玉，无论如何，有MPU的情况下，任务间的外设保护才能不是一句空谈，毕竟，除非是很小的项目，否则没几个人能写出绝对无错的程序，错误一旦出现，影响范围自然是越小越好

ffxz

谢谢watercat的教导，这样看来这个MPU确实是很有用的，能够让模块间内存保护成为现实

watercat

其实在我看来，AVR32配合支持MPU、动态模块和等优先级时间片比例轮换调度算法的RTOS之后，在外设功能无冲突的前提下，完全可以用一片代替5～10片AVR级别的普通8位MCU，或者2片左右的ARM7，在成本上会有明显优势，性能上还可能更高——毕竟借助OS API的单一MCU内部通信总会比借助外部通信线路的用法更快捷稳定

当然，Cortex-M3核心的处理器一样可以做到这样的效率，不过，起码STM32是阉割版CM3，没有MPU的，而没有MPU，这类“一片顶过去五片”的玩法就充满了各种不确定因素（这一点上，我完全反对ID“香水城”那位仁兄对MPU的理解）

另外，流明诺瑞的LM3S是有MPU的CM3处理器，不过不得不说，相比其较低的性能和可靠性，以及混乱的设计理念，其价格绝对要算是昂贵了……所以目前不纳入考虑之列……

kingofkings

【8楼】 watercat
嗯，AVR32内核设计的时候考虑借鉴到了很多的问题~
深入设计的时候就会发现很多很好用的特性，挪威的那帮人时不时会给你整个惊喜出来

watercat

惊喜不惊喜，不能拿来用也是白费

就我看到的情况，目前常见的RTOS，基本上没有哪个能够用好MPU的，更加没有一个能够切实发挥出AVR32UC3性能的

所以如果真想把AVR32的优势打出来，恐怕还是必须定制一个RTOS才行——还好RTOS可大可小，而且总归没有通用OS那样难学难写

另外，供货也是个大问题……

kingofkings

【10楼】 watercat
哎，今天一天跑去杭州给人培训去了，B0的订单已经下去了，正在确认交期……

watercat

我一直觉得ATMEL的产品质量很好，但营销方面在中国一向不怎么灵光……

kingofkings

【12楼】 watercat
呵呵，很多事情慢慢来改善了~

ffxz

确定下来了，有时间先在simulator中试试，然后再找块开发板来跑跑，这样估计也是最快捷的方法了

刚把AVRStudio和GNU GCC下载下来装上了……！

呵呵，watercat还请多提提你心目中的AVR32 RTOS应该是什么样的