.NET Micro Framework动态调用C/C++底层代码（原理篇）-阿里云开发者社区

.NET Micro Framework和WinCE系统不同，从应用开发角度来说，仅支持C#开发（从V4.2版本开始，才支持VB.NET开发），而不像WinCE应用开发，既可以用C#/VB.Net，也可以用EVC等工具进行C/C++开发。针对.NET Micro Framework平台由于C#等.NET语言是托管代码，系统需要对中间语言进行解释执行，所以运行效率上和原生的C/C++相比，效率是打了一个折扣的，这样对一些实时性要求比较高的应用来说，是很难实现的。

如果非要用.NET Micro Framework开发一些实时性高的应用，通常的做法就是从底层移植（Porting kit）入手，专门用C/C++写一个驱动，然后再封装一个可供C#调用的接口，以供应用开发者调用（参见《Micro Framework Interop功能实现》）。但是这种方法，必须要熟悉.NET Micro Framework系统移植，另外手头还必须有一套系统源码，不仅需要熟悉C/C++，还需要熟悉C#，以需上下结合，完成相关功能。从这个角度来说，对普通开发者来说太苛刻了，不仅对技术能力要求高，开发周期长，并且还需要重新编译固件，对原有系统进行升级。

在几年前，我就一直考虑能否采用Windows或WinCE平台的dll动态调用的思路，来实现.NET Micro Framework动态调用C/C++代码。所以后续也看了不少PE文件结构的文章，还有一些编译原理的书籍，但是由于自己知识储备不够，再加上该技术实现难度也比较高，一直不得其门。

在.NET Micro Framework系统移植和开发过程中，深深感受到，封装一个专有的硬件驱动接口是一件比较麻烦的事，所以受WinCE平台上流式驱动开发（可以参见我以前写的《我的第一个WINCE驱动》）的启迪，我封装了一套基于.NET Micro Framework的流式接口（目前基于这个接口，我已经开发了DHT11温湿度模块、超声波模块和看门狗的驱动程序，后续将发博文一一介绍），其C#语言的接口如下：

public sealed class GeneralStream                     {          public GeneralStream();          public event GeneralStreamEventHandler Notice;          public int Close();          public int IOControl(int code);          public int IOControl(int code, int parameter);          public int IOControl(int code, byte[] inBuffer, int inCount, byte[] outBuffer, int outCount);          public int Open(string name);          public int Open(string name, int config);          public int Open(string name, string config);          public int Read(byte[] buffer, int offset, int count);          public int Write(byte[] buffer, int offset, int count);      }

比较有特色的是，还提供了一个事件通知接口，这样就为各种硬件驱动开发提供了更灵活的支持。

有了这个流式接口，一般情况下，为上层C#语言提供专有的硬件底层功能，就不需要再编写接口相关的代码了，直接写相关的C/C++代码，然后编译链接即可。

由此，我突然想到，能否把基于流式接口开发的驱动，实现动态加载。

最初我开发的流式接口和各个流式驱动是在一个项目里面的，最终会编译成一个obj文件，后来考虑到便于调试和维护，把流式接口部分和各个流式驱动分开，每一个流式驱动都是一个单独的obj文件。

又受到ER_Config和ER_DAT的启发，在编译的时候，它们可以指定编译的起始位置，并且可以独立编译成一个bin（或hex）文件，所以我们的一个流式驱动也是可以独立的编译成一个bin文件的，这样部署的时候就可以单独部署了。

由于每个流式驱动的接口都是一致的，我们自然就可以想到，这个bin文件理论上是可以替换的，比如刚开始我们加载的是A功能的流式驱动，那么我们根据需要也可以替换为B功能的流式驱动。

那用户怎么开发这种相对独立的流式驱动模块呢？

如果还是基于.NET Micro Framework整个Porting kit开发环境，那对一般开发者来说，简直就是梦魇，因为光搭建环境，熟悉环境就得花很长时间。

所以最好的办法，就是用MDK开发环境，并且可以基于一个简单的流式驱动模块工程来开发驱动。

先等一下,我们暂且先不要考虑如何搭建MDK开发环境，让我们理一下思路，即使我们解决了开发和编译问题，但是最重要的是——需要解决流式驱动模块如何和宿主（也就是TinyCLR）进行交互的问题。

这里面有两个问题需要解决，一是宿主如何获取流式驱动模块的接口地址？二是流式驱动模块如何访问宿主的资源（我们在windows或wince平台就是通过所谓的API接口，访问系统资源的）。

第一个问题，看似简单，但是实现起来我走了不少弯路。

首先，我们很容易想到，我们把流式驱动函数接口的指针存储到一个变量中去，如下面的代码所示：

const IGeneralStream g_GeneralStream_UserDriver  =  {           &GeneralStream_Open1_UserDriver,           &GeneralStream_Open2_UserDriver,              &GeneralStream_Close_UserDriver,                &GeneralStream_IOControl1_UserDriver,            &GeneralStream_IOControl2_UserDriver,            &GeneralStream_Read_UserDriver,           &GeneralStream_Write_UserDriver,       };

我们只要知道g_GeneralStream_UserDriver的地址，就知道各个函数接口的地址了，换句话说，我们编译的时候，其实可以指定g_GeneralStream_UserDriver变量的地址的。但是问题来了，如果我编译的时候指定g_GeneralStream_UserDriver变量的地址，我们就无法固定流式驱动模块编译的起始地址，这样我们就不知道这个编译好的bin文件该部署到什么位置。另外g_GeneralStream_UserDriver变量也无法保持在和bin文件一个相对确定的位置上去（这和实际代码的多寡都有关系），所以解决这个问题我还是颇费周折的（如果大家有更好的方法确定g_GeneralStream_UserDriver地址的方法，可以交流一下）。

第一个问题，我们算解决了，我们实现了宿主加载和调用流式驱动接口。

第二个问题，我最初的做法是绝对定位，先根据系统函数的原型声明一个函数指针，然后根据编译后的map文件，查到这个函数的绝对地址，做一个转换。如下面的代码：

typedef  void (*MF_lcd_printf)(char const * format,...);  #define lcd_printf   ((MF_lcd_printf)0x0805ab73)

经过这一步后，我们就可以在流式驱动接口里直接调用这个系统函数了。但是这样做有一个明显的问题，就是一旦系统固件升级（需重新编译），那么这些绝对的地址，可能会发生变化。一旦有变化，这对流式驱动来说是致命的，不仅调用失败，并且非常可能导致系统挂起（如果是windows系统，此时就是蓝屏了）。

所以，我采用了另一种方式，和流式驱动提供流式驱动接口的方式一样，系统的API接口，也定义在一个变量中，如下面的代码所示：

const IGeneralStream_Function g_GeneralStream_Function  =  {               &Notice_GenerateEvent,             &lcd_printf,             &debug_printf,               &HAL_Time_Sleep_MicroSeconds_InterruptEnabled,               &CPU_GPIO_DisablePin,              &CPU_GPIO_EnableInputPin,              &CPU_GPIO_EnableOutputPin,             &CPU_GPIO_GetPinState,              &CPU_GPIO_SetPinState,              &CPU_TIMER_Initialize,              &CPU_TIMER_Uninitialize,             &CPU_TIMER_Start,             &CPU_TIMER_Stop,             &CPU_TIMER_GetState,             &CPU_TIMER_SetState,  };