主页 > 知识库 > 网络编程 > ASP/.NET >

.NET Micro Framework动态调用C/C++底层代码

来源:中国IT实验室 作者:佚名 发表于:2012-08-14 13:18  点击:
.NET Micro Framework和WinCE系统不同,从应用开发角度来说,仅支持C#开发(从V4.2版本开始,才支持VB.NET开发),而不像WinCE应用开发,既可以用C#/VB.Net,也可以用EVC等工具进行C/C++开发。针对。NET Micro Framework平台由于C#等。NET语言是托管代码,系
  .NET Micro Framework和WinCE系统不同,从应用开发角度来说,仅支持C#开发(从V4.2版本开始,才支持VB.NET开发),而不像WinCE应用开发,既可以用C#/VB.Net,也可以用EVC等工具进行C/C++开发。针对。NET Micro Framework平台由于C#等。NET语言是托管代码,系统需要对中间语言进行解释执行,所以运行效率上和原生的C/C++相比,效率是打了一个折扣的,这样对一些实时性要求比较高的应用来说,是很难实现的。
   
    如果非要用。NETMicro Framework开发一些实时性高的应用,通常的做法就是从底层移植(Porting kit)入手,专门用C/C++写一个驱动,然后再封装一个可供C#调用的接口,以供应用开发者调用(参见《MicroFramework Interop功能实现》)。但是这种方法,必须要熟悉。NET Micro Framework系统移植,另外手头还必须有一套系统源码,不仅需要熟悉C/C++,还需要熟悉C#,以需上下结合,完成相关功能。从这个角度来说,对 普通开发者来说太苛刻了,不仅对技术能力要求高,开发周期长,并且还需要重新编译固件,对原有系统进行升级。
   
    在几年前,我就一直考虑能否采用Windows或WinCE平台的dll动态调用的思路,来实现。NET Micro Framework动态调用C/C++代码。所以后续也看了不少PE文件结构的文章,还有一些编译原理的书籍,但是由于自己知识储备不够,再加上该技术实现难度也比较高,一直不得其门。
   
    在。NET MicroFramework系统移植和开发过程中,深深感受到,封装一个专有的硬件驱动接口是一件比较麻烦的事,所以受WinCE平台上流式驱动开发 (可以参见我以前写的《我的第一个WINCE驱动》)的启迪,我封装了一套基于。NET Micro Framework的流式接口(目前基于这个接口,我已经开发了DHT11温湿度模块、超声波模块和看门狗的驱动程序,后续将发博文一一介绍),其C#语 言的接口如下:
   
    public sealed class GeneralStream
   
    {
   
    publicGeneralStream();
   
    public event GeneralStreamEventHandlerNotice;
   
    public int Close();
   
    public int IOControl(intcode);
   
    public int IOControl(intcode, int parameter);
   
    public int IOControl(intcode, byte[] inBuffer, intinCount, byte[] outBuffer, int outCount);
   
    public int Open(stringname);
   
    public int Open(string name,int config);
   
    public int Open(string name,string config);
   
    public int Read(byte[]buffer, int offset, intcount);
   
    public int Write(byte[]buffer, int offset, intcount);
   
    }
   
    比较有特色的是,还提供了一个事件通知接口,这样就为各种硬件驱动开发提供了更灵活的支持。
   
    有了这个流式接口,一般情况下,为上层C#语言提供专有的硬件底层功能,就不需要再编写接口相关的代码了,直接写相关的C/C++代码,然后编译链接即可。
   
    由此,我突然想到,能否把基于流式接口开发的驱动,实现动态加载。
   
    最初我开发的流式接口和各个流式驱动是在一个项目里面的,最终会编译成一个obj文件,后来考虑到便于调试和维护,把流式接口部分和各个流式驱动分开,每一个流式驱动都是一个单独的obj文件。
   
    又受到ER_Config和ER_DAT的启发,在编译的时候,它们可以指定编译的起始位置,并且可以独立编译成一个bin(或hex)文件,所以我们的一个流式驱动也是可以独立的编译成一个bin文件的,这样部署的时候就可以单独部署了。
   
    由于每个流式驱动的接口都是一致的,我们自然就可以想到,这个bin文件理论上是可以替换的,比如刚开始我们加载的是A功能的流式驱动,那么我们根据需要也可以替换为B功能的流式驱动。
   
    那用户怎么开发这种相对独立的流式驱动模块呢?
   
    如果还是基于。NETMicro Framework整个Porting kit开发环境,那对一般开发者来说,简直就是梦魇,因为光搭建环境,熟悉环境就得花很长时间。
   
    所以最好的办法,就是用MDK开发环境,并且可以基于一个简单的流式驱动模块工程来开发驱动。
   
    先等一下,我们暂且先不要考虑如何搭建MDK开发环境,让我们理一下思路,即使我们解决了开发和编译问题,但是最重要的是--需要解决流式驱动模块如何和宿主(也就是TinyCLR)进行交互的问题。
   
    这里面有两个问题需要解决,一是宿主如何获取流式驱动模块的接口地址?二是流式驱动模块如何访问宿主的资源(我们在windows或wince平台就是通过所谓的API接口,访问系统资源的)。

有帮助
(0)
0%
没帮助
(0)
0%