Microsoft .NET Gadgeteer 为开发小型电子模块或嵌入式设备的用户，提供一个快速构建原型机的平台。它结合了面向对象编程的优点，提供一系列电子模块，可以快速地用这些模块进行计算机辅助设计。
通过.NET Gadgeteer模块可以很容易的构建简单或复杂的设备。每个模块都可以提供相应的功能，诸如显示图片、播放音乐、采集图像、获取环境参数等等。
该平台构建在.NET Micro Framework平台之上，在Visual Studio IDE环境中，采用C#开发语言对小型电子设备进行编程和调试。
这种强大的组态特性，使构建一个功能齐全设备的用时仅为几个小时，而不是原来的几天或几周。
我以前就曾经说过.NET Micro Framework就是嵌入式领域内的脚本语言，就像网页开发之于脚本语言一样，可以大大提高开发效率，节省大量开发时间。 不过有人质疑性能问题，和汇编和C语言相比，这确实是一个问题，不过在物联网领域，在需要互相通信交互的领域，开发语言本身的运算性能已变的不甚重要，因为最终设备的性能决定在通信链路（或者说通信规则本身）上，而这个目前确是一大瓶颈，就像目前制约网页浏览的瓶颈在于网络通信本身一样。 前段时间，我对一些设备进行通信测试，发现就与设备通信而言，.NET Micro Framework的交互性能反而略好于PC系统，相关测试结果如下：
1 测试环境
嵌入式硬件平台：Atmel sam9261-EK 开发板 主频：200MHz
嵌入式软件平台：.Net Micro Framework V4.0
PC硬件配置：HP Compaq dc7800 主频：2.33GHz
软件平台： Windows Vista + .Net Framework V3.5
相同的.Net C#测试程序
2 Modbus RTU通信测试
2.1 Modbus RTU Slave设备
西门子 S7-PLC 224
2.2 波特率19200 无校验
单字节传输时间：10*1000/19200 = 0.52ms
2.3 波特率 115200无校验
单字节传输时间：10*1000/115200 = 0.087ms
2.4 性能分析
通信时间 = 发送帧传输时间 + 从设备响应时间 + 返回帧传输时间 + 主设备处理时间
绝对传输时间 = 发送帧传输时间 + 返回帧传输时间
由于Modbus从设备大都是一些基于8位单片机的设备，CPU运算能力低，并且要计算CRC校验，所以通信的瓶颈主要在从设备响应时间上，从测试结果上看，也反映了这一点。在某些测试项上，嵌入式设备甚至领先PC，这是因为嵌入式设备专注相关通信，而不像PC同时执行多任务操作。
结论：在和硬件设备通信方面，嵌入式设备和PC旗鼓相当。
3 RFID 读卡测试
3.1 硬件设备
设备：EHUOYAN公司YHY632型号读卡器
卡片：S50 EEROM 1K字节
3.2 波特率115200 无校验
读卡步骤：
1、 获取卡的类型
2、 获得卡号
3、 选定卡
4、 设定指定扇区的密钥KEY
5、 读取指定扇区、指定块16字节的数据
3.3 性能分析
读一次卡信息，一般需要5次交互时间，通信瓶颈来源两个环节：
1、RFID卡 和 读卡器之间
由于RFID卡上仅含控制器（无CPU模块），还需要从EEROM上读取数据，并且要进行加解密运算，所以相对耗时。RFID卡的响应时间是最大的时间瓶颈。
2、读卡器和嵌入式设备或PC之间
这个和Modbus RTU通信项类似，不同的是，不同厂家读卡器的通信协议有可能不同，读写时间会有些许差别，但没有数量级上的差别。
由于嵌入式设备专注于与设备通信，其测试结果优于PC。
结论：嵌入式设备优于PC
------------------------
演示视频：http://research.microsoft.com/apps/video/default.aspx?id=139105
相关网址：
http://research.microsoft.com/en-us/projects/gadgeteer/default.aspx
http://blogs.msdn.com/b/netmfteam/archive/2010/09/28/net-gadgeteer.aspx
http://blogs.msdn.com/b/netmfteam/archive/2010/08/30/making-the-robot-arm-move-again.aspx
