.Net Micro Framework系统架构如下图所示，其中移植工作主要在平台抽象层（PAL）和硬件抽象层（HAL），大部分常用的PAL层的程序已经写好，基本上不需要什么修改，只有HAL会根据特定的硬件进行微调。不过如果添加新的设备驱动，则HAL和PAL层都需要定义和重写，假设CLR层不支持类似的设备接口，就只有通过Interop接口来访问了。后续的文章我会介绍一个最简单的串口驱动来说明MF的驱动是如何设计的，这篇文章我就先介绍一下MF中的CLR运行时原理。
MF中的CLR称之为TinyCLR（这让我想起了AB PLC第三方模块中的TinyDOS系统了），确实和Windows和wince中的CLR相比，它太小了，不过麻雀虽小，五脏俱全，有兴趣的朋友可以下载一份MF3.0 SDK，在类对象中查看相关接口。GPIO、SPI、I2C、USBClient等CLR类想必Windows和wince平台中的CLR也不具备，这越来越显示出TinyCLR的特色了：）
MF系统目前最为人诟病的就是，它不是一个实时系统。WINCE至少还算一个软实时系统，可MF不是，虽然V3.0版本引入了Interop接口，就是为了缓解人们对嵌入式实时性的应用需要。但这不可能从根本上去解决这个矛盾。据说明年推出的MF V4.0将是一个实时系统，这确实令人非常期待，不过时间紧迫，我真为美国微软MF开发团队捏把汗。
TinyCLR仅一个执行绪，接管所有的内存分配。采用轮询算法，根据线程的优先级，分配最小为20ms的时间片。
运行原理图如下：
TinyCLR中的线程分5种优先级：
0 = Lowest 最低的
1=BelowNormal 比正常偏低
2=Normal 常规
3=AboveNormal 比整个偏高
4=Highest 最高的
以两倍的CPU时间单位作为这种优先级的量度等级。越高级的线程，获得时间片就越多。
由以上可以看出，20ms的时间片，再加上CLR的垃圾回收机制，确实谈不上实时系统。不过，如果我们想在V3.0版本上开发一个对时间要求比较迫切的应用该怎么办？也许Interop是目前唯一的办法，后续的文章我就介绍这方面的内容。
