zoukankan      html  css  js  c++  java
  • 再谈.NET Micro Framework移植

    再谈.NET Micro Framework移植

         没有想到,距第一次写.NET Micro Framework移植文章《移植初步:环境搭建》已经快两年半了。不过这两年多来的时光也没有虚度,还是做了不少工作的。从代码角度来说,不仅STM32F103的移植代码在不断完善,并且也已经移植和优化了基于STM32F207和STM32F407的相关代码。从硬件角度来说,也由最初完全借助第三方的硬件作为.NET Micro Framework开发板,演变为今天推出自行设计的开发板和物联网产品。      

          初次移植.NET Micro Framework是基于V 4.0版本,当前最新的版本已经是V4.2了,并且官方代码中也已经集成了第三方开发的基于STM32F103的代码,不过该代码移植的相对简单一些,并且大部分代码取之于ST官方的库,所以代码效率和未来扩展性方面还是有一定局限性的。

          此外在此期间深圳的莫雨也推出了基于STM32F103移植的书籍《玩转.NET Micro Framework移植-基于STM32F10x处理器》。

          基于STM32Fxxx的代码,我所移植的和官方还有莫雨移植的最大区别就是,没有基于ST的库代码,完全按照.NET Micro Framework一贯的风格,直接根据相关芯片手册,定义相关的寄存器结构体。此外就是对中断的处理,采用了动态设置,直接调用的技术。另外对时钟的处理也放弃了最初的Systick方式,采用了双时钟处理机制(这和官方的代码不同),而基于STM32F207芯片的代码,更是根据有些时钟计时变量可以支持32位的特点,做了特别的优化。另外一大特色在.NET Micro Framework标准功能的基础上,拓展了很多功能,比如支持TinyGUITinyIOsSystem .Windows.FormsGPRS、CAN、ModbusCamera.PTC01QuickPort等等扩展库。

         随着.NET Micro Framework的影响力不断扩大(最早基于.NET Micro Framework的两大产品系统是SideShowMSN Direct,目前由于物联网的不断发展,微软开始主推Microsoft .NET GadgeteerNetduino,这两类产品大大促进了.NET Micro Framework的发展),对.NET Micro Framework移植感兴趣的人也越来越多,这中间有不少人问我,移植的难度有大?

          我在台北做.NET Micro Framework的培训和为一些网友做移植介绍的时候都会这样评价移植的难度。个人认为,移植由难到易分三种难度层次:

          第一种:系统架构和CPU层面的移植最难

           以前.NET Micro Framework仅支持ARM7和ARM9架构,Cortex-M3架构并不支持,这二者的最大的区别就是中断模式,ARM7和ARM9架构有两种中断,普通中断和快速中断,而Cortex-M3的中断模式更类似X86架构,有中断向量表,硬件层面支持中断嵌套。所以如果涉及到这方面的移植,相关中断架构必须调整。

          目前官方的代码支持的MCU类型如下:

    Atmel:AT91SAM7X 、AT91SAM9RL64、AT91SAM9260、AT91SAM9261

    Analog Devices:ADSP-BF537

    恩智浦(NXP):LPC22XX、LPC24XX

    飞思卡尔(Freescale):MC9328

    英特尔(Intel):PXA271(XSCALE)

    瑞萨电子(RENESAS):SH2、SH2A、 SH7216、SH7264

    意法半导体:STM32F103

            如果你打算设计的硬件,所选的MCU恰好在上述列表,那么恭喜你,CPU相关层面的移植的工作就不需要做了。但是即使所选的MCU不在上述列表,移植的工作量也是有区别的,比如Atmel的 AT91SSAM9263虽然不在列表中,但是其寄存器定义和AT91SAM9260、AT91SAM9261有很大的相似性,所以工作量也相对较少。工作量最大的移植,就是MCU架构和已有的不同(非ARM7,ARM9和Cortex-M3),且MCU亦非上述列表的厂家,比如我曾经移植过的TI的DM355,这就需要你从零开始移植。

          目前不少Cortex-M3内核的MCU芯片厂家都提供了相应的支持库,所以直接采用库代码也是一种省时省力的选择。不过如果选择库,就对库有了一种依赖性,如果库本身的函数有bug,那么调试的难度就会加大,并且也受限于库本身所支持的功能,因为你在库的基础上再扩展一些功能,相对比较难一些。

         第二种:外围模块移植次难

          如果所选择的MCU就是第一种中所列的MCU,那么这部分工作一般情况下,就不需要做了,剩下的就看你所选择的LCD、触摸屏、NandFlash以及以太网等模块了,建议还是选择.NET Micro Framework已经支持的模块,这样你的工作量就会大大降低。

         第三种:模块集成和参数调整最易

          自己设计的板子已经和官方支持的平台兼容了,所选的模块也都是官方代码所支持的,那么剩下的工作,无非就是个别参数调整(比如RAM的大小,地址等等),还有工程文件把各个模块代码进行集成了。

          所有代码工作做好之后,最后一步,就是调试,调试,再调试了!!!这一步,老手,新手的差别就凸显出来了。嵌入式开发就是这样,代码完成仅仅占移植的工作量30%左右,剩下大部分工作就是调试,所谓老手,就是指调试经验异常丰富(其实不仅仅指调试功底,还应该包括对某些开发的原理异常清晰,比如USB,比如以太网,必须了解其运行机理,才能事半功倍的进行调试)的嵌入式开发者,所以说同样的开发工作有人几天就可以完成,而有人几个月不一定搞定,其缘由也在这里了。

          周立功曾经在他的微博中这样说,他们这样的公司,真正会进行系统移植的不超过5个人(后来又进一步明确指出,他所谓的移植就是对新出的MCU,在没有多少可参考的资料的情况下,进行移植)。不过这个微博发出后,不少人进行吐槽,说什么能进行移植的人一大把之类了,其实就是因为,每个人心目中移植的标准是不一样的,大部分人所谓的移植,估计很像普通人心目中的IT高手,就是会装机的高手一样,而不是真正的代码编写级别的移植高手。

         说了以上三种代码移植层次,其实这仅仅限于移植官方.NET Micro Framework现有的代码和功能,如果你想自己扩展自己的接口,并且希望自己的接口灵活,参数接口支持类,也支持事件等等功能,那么移植的难度会更上一个台阶,这就需要非常深入的了解.NET Micro Framework底层相关代码了。

         总体而言,.NET Micro Framework的移植工作,比UCOSII复杂,但是比Linux和WinCE又要简单的多。此外.NET Micro Framework不是所谓的嵌入式系统,而是一个框架,不仅可以独立运行,还可以移植到Linux、WinCE和UCOSII等系统平台上来,这样的好处就是基于.NET Micro Framework的代码也许可以真正做到,一次编译到处运行了。

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

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

     

     
  • 相关阅读:
    Java实现 蓝桥杯 算法提高 特等奖学金(暴力)
    Java实现 蓝桥杯 算法提高 特等奖学金(暴力)
    Java实现 蓝桥杯 算法提高 GPA(暴力)
    Java实现 蓝桥杯 算法提高 GPA(暴力)
    Java实现 蓝桥杯 算法提高 GPA(暴力)
    Java实现 蓝桥杯 算法提高 套正方形(暴力)
    Java实现 蓝桥杯 算法提高 套正方形(暴力)
    第一届云原生应用大赛火热报名中! helm install “一键安装”应用触手可及!
    云原生时代,2个方案轻松加速百万级镜像
    Knative 基本功能深入剖析:Knative Serving 自动扩缩容 Autoscaler
  • 原文地址:https://www.cnblogs.com/Leo_wl/p/2476606.html
Copyright © 2011-2022 走看看