zoukankan      html  css  js  c++  java
  • .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,
    
    };

    宿主调用流式驱动接口的时候,把这个g_GeneralStream_Function地址直接传个流式驱动即可。这种方法的优点是,不受系统固件的升级影响,但是缺点也很明显,就是系统给你提供了什么接口,你才能用什么接口(其实这个时候,第一种方法仍然有效,不过可以算作黑客的做法了)。

    另外值得一提的是,由于这是驱动层面的开发,驱动程序理论上可以访问系统的任何资源,所以驱动程序一定尽可能在预先为自己规划好的代码区和RAM区工作,以免对系统的稳定性造成影响。

    以上思路仅仅是一个初步,我们完全也可以像PE文件一样,为流式驱动程序加上一个类PE头,把导出的函数指针和需要引用的系统API指针等等资源,填写到类PE头上去。这样系统就可以根据PE头信息,自动加载各种流式驱动,以供上层应用程序调用。

    下面一张截图是MDK开发流式驱动的场景,至于如何具体编写流式驱动和使用,后续我会专门写一篇.NET Micro Framework动态加载C/C++代码的应用篇。 

     MF简介:http://blog.csdn.net/yefanqiu/article/details/5711770

    MF资料:http://www.sky-walker.com.cn/News.asp?Id=25

     

  • 相关阅读:
    16. 3Sum Closest
    17. Letter Combinations of a Phone Number
    20. Valid Parentheses
    77. Combinations
    80. Remove Duplicates from Sorted Array II
    82. Remove Duplicates from Sorted List II
    88. Merge Sorted Array
    257. Binary Tree Paths
    225. Implement Stack using Queues
    113. Path Sum II
  • 原文地址:https://www.cnblogs.com/yefanqiu/p/2620941.html
Copyright © 2011-2022 走看看