开发者社区> 技术小美> 正文

.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

 






本文转自yefanqiu51CTO博客,原文链接:http://blog.51cto.com/yfsoft/952447,如需转载请自行联系原作者

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
动态调用WebService
using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.
741 0
Netty原理篇-ByteBuf
NIO ByteBuffer的概述。 Netty ByteBuf的详细讲述,包括读、写、扩容、mark、reset、duplicate等操作。 核心类的源码分析。 堆内存缓冲区、直接内存缓冲区。 实际上7种基本类型boolean除外都有自己的缓冲区实现不过因为功能、方法、原理基本一致所以仅讨论ByteBuffer。
5842 0
竞彩足球混合过关赔率API调用示例代码
<?php// +----------------------------------------------------------------------// | 竞彩足球混合过关赔率API调用示例代码 - 麦趣数据// | 在线接口文档:http://www.
3501 0
Netty原理篇-Channel、Unsafe
Channel的主要方法介绍。 Channel的继承结构,以及核心类核心代码分析。 Unsafe的继承结构,以及核心类核心代码分析。
2317 0
OTL调用Oracle存储过程
OTL很早前用过,今天写东西要调存储过程,程序写完了,调试死活通不过,折腾了一早晨。 最后才发现错误,这里总结一下: 1、代码写的不规范。 有个参数后边少写了个“,”以至于总是抱错。而单独写的测试例子就没问题,后来一步一步跟踪了后才发现。
1451 0
【OkHttp】Android 项目导入 OkHttp ( 配置依赖 | 配置 networkSecurityConfig | 配置 ViewBinding | 代码示例 )(一)
【OkHttp】Android 项目导入 OkHttp ( 配置依赖 | 配置 networkSecurityConfig | 配置 ViewBinding | 代码示例 )(一)
140 0
+关注
6819
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
JS零基础入门教程(上册)
立即下载
性能优化方法论
立即下载
手把手学习日志服务SLS,云启实验室实战指南
立即下载