.Net Micro Framework研究—Digi开发板初探

简介: 写的比较基础全面,由于我们北航的研发团队先研究了Digi的开发板,所以直到今天Digi开发板才到我的手上,我的《Micro Framework研究》系列文章以后也会陆续推出

9月18日,.Net Mirco Framework 2007技术大会在北京召开(相关文章请参见:http://blog.csdn.net/yefanqiu/archive/2007/09/18/1790404.aspx ),张欣第一时间写了关于Digi开发板的相关文章(文章请参见:http://mobileside.cn/blogs/breakstring/archive/2007/10/06/MorseCodeOnDotNETMF.aspx ),写的比较基础全面,由于我们北航的研发团队先研究了Digi的开发板,所以直到今天Digi开发板才到我的手上,我的《Micro Framework研究》系列文章以后也会陆续推出,内容方面和张欣写的并不重复,应该是一个有力补充吧。

 

我的开发场景:

image.png

(图:MF071027001.JPG)

张欣的笔记本由于没有串口,所以串口方面的内容并没有写,这里我优先测试的了串口部分内容,我的笔记本本身也没有串口,我是扩充了一个PCMCIA串口卡,这种方式的串口比USB转串口要好一些,特别是连接需要RTS/CTS控制的设备。

 

Digi指导作业书上关于连接串口的步骤是这样的:

1、  MFDeploy选择菜单中选择”Serial”这一项,我的当前串口是“COM1”

2、  用串口连接线连接PC和MF开发板

3、  确保MFDeploy程序唯一使用COM1口

4、  重启开发版

5、  单击Ping按钮

6、  如看到“Error:No response from device”,则继续单击Ping按钮

7、  出现“Pinging … TinyBooter”则表示通信成功

image.png

(图:MF071027000.JPG)

很遗憾,我试了多次都是失败。

 

我打开超级终端程序,参数配置如下:115200,无校验,8个数据位

重启开发板,串口在5~6秒钟会收到如下信息:

image.png

(图:MF071027004.JPG)

在出现“Program found at 0x0a070000”之前会等待3~5秒钟的时间(其实这个3~5时间就是等待接收上位机串口命令的)。

 

然后关闭该程序,重新打开MFDeploy程序,在此之前,先打开串口监控程序“PORTMON.EXE”,注意MFDeploy程序单击ping按钮的串口操作如下:

image.png

(图:MF071027005.JPG)

 

这时候仍然是失败,但是请注意串口参数是:115200,偶校验,8个数据位

 

关上该程序,打开串口调试程序,参数设置为:115200,无校验,8个数据位

 

MFDeploy程序串口会发送如下四种指令(每个指令会重复发出6遍)

4D 53 70 6B 74 56 31 00 3A AA 3A 1D 94 B9 43 B7 00 00 00 00 4B 79 00 00 00 00 00 00 08 00 00 00 02 00 00 00 00 00 00 00

4D 53 70 6B 74 56 31 00 28 03 FA 0A 94 B9 43 B7 00 00 00 00 4C 79 00 00 00 00 00 00 08 00 00 00 02 00 00 00 00 00 00 00

4D 53 70 6B 74 56 31 00 2E E0 0C 0D 94 B9 43 B7 00 00 00 00 4D 79 00 00 00 00 00 00 08 00 00 00 02 00 00 00 00 00 00 00

4D 53 70 6B 74 56 31 00 24 C5 17 05 94 B9 43 B7 00 00 00 00 4E 79 00 00 00 00 00 00 08 00 00 00 02 00 00 00 00 00 00 00

image.png

(图:MF071027006.JPG)

 

在出现“Program found at 0x0a070000”之前,开发发送这四条指令,这时候你发送digi开发板是响应该命令的,并且等待时间被延长,上图的数据是我设置16进制/ascii交替显示的。

如果把参数修改为:115200,偶校验,8个数据位,则出现乱码,digi开发板对命令也没有什么响应了。

 

到了这里我只能得出如下结论:MFDeploy程序有问题(但看指导书上,图例是用串口通信成功了的)或digi开发板的默认串口参数可修改。

 

由于MFDeploy串口参数无法设置,我用.net反编译程序反编译MFDeploy程序,不过效果不是很好,大部分代码可以正确反编译出来,但工程无法正确编译,所以也就无法通过源码修改串口参数了。

有时间再深入研究,同时也希望这方面有研究的朋友,提出自己的看法。

 

下面该通过网口和digi开发版进行连接了,我的笔记本有wifi和普通网卡两种,如张欣的文章所说,同时连接是有问题的,所以只好关闭wifi连接了。

 
image.png

(图:MF071027002.JPG)

 

多次切换到tcp/ip选项,它会自动探测digi开发版的ip地址,我探测到的ip地址为169.254.128.66,这时候如果你单击“ping”按钮,是无法连接成功的,你必须修改你ip地址为同一个网段,才能连接成功。连接成功后直接单击“plug-in”菜单中的参数配置选项,修改digi开发板的ip地址,如下图:

image.png

(图:MF071027003.JPG)

 

注意:DHCP 的Enable要取消掉,然后在单击update按钮,修改后,记得修改你PC的ip地址,好与新修改的ip为同一个网段。

 

 

开始调试程序,相关配置请参见张欣的文章,我这里偷懒省略了J

 

默认的示例程序是三个灯连续亮的,我们修改为5个灯。相关代码修改如下:

BlinkingLed led0 = new BlinkingLed((Cpu.Pin)0, true);

            BlinkingLed led1 = new BlinkingLed((Cpu.Pin)1, true);

            BlinkingLed led2 = new BlinkingLed((Cpu.Pin)2, true);

            //------------

            //新加代码

            BlinkingLed led3 = new BlinkingLed((Cpu.Pin)5, true);

            BlinkingLed led4 = new BlinkingLed((Cpu.Pin)6, true);

 

 

            while (true)

            {

                led0.On = false;

                led0.Blink(200);

                Thread.Sleep(200);

                led0.StopBlink();

 

                led1.On = false;

                led1.Blink(200);

                Thread.Sleep(200);

                led1.StopBlink();

 

                led2.On = false;

                led2.Blink(200);

                Thread.Sleep(200);

                led2.StopBlink();

 

          //------------

            //新加代码

 

                led3.On = false;

                led3.Blink(200);

                Thread.Sleep(200);

                led3.StopBlink();

 

                led4.On = false;

                led4.Blink(200);

                Thread.Sleep(200);

                led4.StopBlink();

 

            }

注意,你直接编译运行,你会发现,还是三个灯交替闪烁,这是因为下面还是原先的程序,必须要单击菜单中的“部署”选项,先把程序部署下去,这时候在调试就是5个灯交替闪烁了。

不足之处:从Digi开发板来看,启动时间还是偏长,实际测试大约25秒左右(由上面可知,要5~6后TinyBooter才加载成功),从这一点上与以往单片程序相比差距甚大,希望以后性能能进一步提升。 

好,今天先写到这里,后续的文章我会陆续详细介绍串口、网口、IO入等等相关操作。

相关文章
|
3月前
|
C++ Windows
.NET Framework安装不成功,下载`NET Framework 3.5`文件,Microsoft Visual C++
.NET Framework常见问题及解决方案汇总,涵盖缺失组件、安装失败、错误代码等,提供多种修复方法,包括全能王DLL修复工具、微软官方运行库及命令行安装等,适用于Windows系统,解决应用程序无法运行问题。
230 3
|
5天前
|
开发框架 安全 .NET
Microsoft .NET Framework 3.5、4.5.2、4.8.1,适用于 Windows 版本的 .NET,Microsoft C Runtime等下载
.NET Framework是Windows平台的开发框架,包含CLR和FCL,支持多种语言开发桌面、Web应用。常用版本有3.5、4.5.2、4.8.1,系统可同时安装多个版本,确保软件兼容运行。
230 0
Microsoft .NET Framework 3.5、4.5.2、4.8.1,适用于 Windows 版本的 .NET,Microsoft C Runtime等下载
|
1月前
|
C++
提示缺少.NET Framework 3.5 安装错误:0x80070002、0x800F0950\0x80004002
.NET Framework常见问题及解决方法汇总,
275 0
|
2月前
.NET Framework 3.5离线安装包合集下载
本文介绍了如何获取和安装.NET Framework运行库离线合集包。用户可通过提供的链接下载安装包,安装过程简单,按提示逐步操作即可完成。安装时可选择所需版本,工具会自动适配架构,无需手动判断,方便高效。
878 0
|
3月前
|
C++ Windows
WindowsDLL修复专家,MSVCP**、DLL修复vcruntime**、DLL修复、`.Net Framework`缺失、DirectX类DLL修复、VC运行库修复
Windows DLL修复专家是一款专为解决因DLL文件缺失、版本错误导致的软件或游戏无法运行问题的系统工具。它支持一键扫描和修复各类DLL异常,涵盖MSVCP、vcruntime、.NET Framework、DirectX等多种常见问题。具备自动检测、备份还原功能,确保修复过程安全可靠。适用于软件报错、系统异常及新系统适配场景,降低用户手动修复门槛,提升系统稳定性与兼容性。
141 3
使用的是.NET Framework 4.0,并且需要使用SMTP协议发送电子邮件
使用的是.NET Framework 4.0,并且需要使用SMTP协议发送电子邮件
158 1
|
8月前
|
人工智能 机器人
D1net阅闻 | 谷歌DeepMind研究发现LLM新特性
D1net阅闻 | 谷歌DeepMind研究发现LLM新特性
|
12月前
|
开发框架 缓存 监控
NET Framework 到 .NET 5/6 的迁移是重大的升级
本文详细介绍了从 .NET Framework 4.8 迁移到 .NET 5/6 的过程,通过具体案例分析了迁移策略与最佳实践,包括技术栈评估、代码迁移、依赖项更新及数据库访问层的调整,强调了分阶段迁移、保持代码可维护性及性能监控的重要性。
165 3
|
12月前
|
机器学习/深度学习 编解码 算法
【小样本图像分割-4】nnU-Net: Self-adapting Framework for U-Net-Based Medical Image Segmentation
《nnU-Net: 自适应框架用于基于U-Net的医学图像分割》是一篇2018年的论文,发表在Nature上。该研究提出了一种自适应的医学图像分割框架nnU-Net,能够自动调整模型的超参数以适应不同的数据集。通过2D和3D U-Net及级联U-Net的组合,nnU-Net在10个医学分割数据集上取得了卓越的性能,无需手动调整。该方法强调数据增强、预处理和训练策略等技巧,为医学图像分割提供了一个强大的解决方案。
439 0
【小样本图像分割-4】nnU-Net: Self-adapting Framework for U-Net-Based Medical Image Segmentation