物联网可编程逻辑控制器(一)_proconos eclr-优快云博客

本文介绍了如何使用MiCO系统开发物联网可编程逻辑控制器(PLC)，探讨了资源限制、开发板特性以及编程语言的选择。作者强调了PLC编程的直观性和调试便利性，并提及了PxC SW的MULTIPROG编程系统和ProConOS eCLR内核在移植到MiCO系统中的过程。

十一长假结束了，这次申请的基于MiCO的物联网可编程控制器方案可以正式开始了，申请的MiCOKit-Nucleo开发板，128KB的RAM以及512KB的FLASH，资源对物联网可编程控制器方案来说也是捉襟见肘，具体资源占用情况在后面几个星期的章节中会详细分析为啥资源不太够，好在后续会有推出EMW3166模块有256KB的RAM以及1MB的FLASH强大支持，所以先基于MiCOKit-Nucleo开始原型开发，资源挤挤总会挤出来的。

下图是收到的开发板 (昨天收到了MiCO团队邮寄的天线还有USB线缆，赞一个，天线还是需要的，不然离路由器远一点点就只能呵呵了):

图片1.1

核心板采用STM32F411RE的MCU，外扩了MiCOKit-STmems V2.0扩展板，这个扩展板上采用的是EMW1062核心模块通过SPI接口与NUCLEO-F411底板来进行通讯，通过实际测试个人感觉SPI接口还是没有与EMW3165/3166的SDIO接口速度响应快，在实际应用过程中还是选择SDIO接口的方式与HOST CPU来进行交互吧。MiCOKit-STmems V2.0扩展板上的传感器资源比MiCOKit-3165上更丰富，竟然还带了数字麦克风接口，这是要向语音识别方向发展的信号吗？将来有可能来个双数字麦克风搞个远场语音识别，提供一套基于MiCO的语音识别SDK？有意思，期待。

图片1.2

废话说多了，扯远了，回归主题，这次我们的目标是实现基于MiCO系统的物联网可编程逻辑控制器(Programmable Logic Controller,后面简称PLC)，一句话来解释PLC：可编程逻辑控制器，是一种采用一类可编程的存储器，用于其内部存储程序，执行逻辑运算、顺序控制、定时、计数与算术操作等面向用户的指令，并通过数字或模拟式输入/输出控制各种类型的机械或生产过程(摘自百度百科)。

大家如果接触到工业控制相关知识，就非常熟悉PLC了，对于嵌入式开发或者互联网领域的同学们是否有点抽象？PLC本质目的与大家使用的C/C++开发没有区别，都是使用基础的算法实现对目标对象进行控制，在符合IEC61131-3标准的PLC中也同样有各种类型的变量，结构体/数组，多任务，程序，算法，功能模块等等类似概念，但是……PLC的编程方式不是使用C/C++这种高级语言，而是使用更加形象的功能块图编程语言(Function Block Diagram)以及梯形图LD(Ladder Diagram)编程语言：

图片1.3

图片1.4

但是也有类似高级语言的结构化文本编程语言ST(Structure Text):

图片1.5

也有类似汇编的指令表编程语言IL(Instruction List):

图片1.6

竟然还有类似状态图的顺序流程图编程语言SFC(Sequential function chart):

图片1.7

是否有些晕菜了，总结一点，PLC编程与调试就是简单实用，编程非常形象，拖拉几个模块就可以对MiCO模块编程。调试过程都可以在编程逻辑旁看到当前控制器中变量运行值，不需要花费大量时间学习C/C++高级语言，再也不用断点或者printf去监控调试变量值了啦。

大家可能有疑问了，实现这么复杂的一整套编程系统一个人真的可以在几个月之内搞定？当然不是从零开始，市场上就有现成的方案可以实现这样的功能。本人所在的公司菲尼克斯电气软件公司(Phoenix Contact Software，简称PxC SW)就提供基于不同嵌入式平台的PLC方案，所以借助工作之便可以在不同的嵌入式平台上玩玩PLC方案了。前面提到PLC编程系统其实就不用开发了，PxC SW已经提供了在Win7以及以上系统的编程系统MULTIPROG。下图是完整的MULTIPROG 5.5 SP1 Professional软件截图:

图片1.8

然而如果MiCO系统中没有运行PLC运行内核，MULTIPROG也不是凭空能够将编写好的图形化逻辑下载MiCO系统中的，PxC SW提供的PLC运行核心名称是ProConOS eCLR，其实就是一堆C/C++库文件还有头文件，所以要让MULTIPROG能够对MiCO模块编程，还是需要使用MiCO系统的C/C++开发工具将eCLR的软件核心移植到MiCO系统，并通过eCLR的API进行算法的扩展，最终才可以使用MULTIPROG对MiCO模块进行编程。虽然目前MiCO已经支持GCC，但是我们一般还是选择IAR工具作为C/C++开发环境，使用GCC又要多占用RAM和FLASH，对于目前128KB RAM与512KB Flash的开发板来说，能省就省吧。下图是eCLR内核在IAR编译环境中的体现：

图片1.9

原来PLC内核也没啥，不就是在IAR下的一个静态库:eclrlib_M4_VFP_MT_InPlace.a以及一堆头文件还有源代码文件么，的确如此！

需要额外提到的一点是，移植eCLR内核需要有操作系统支持，MiCO系统虽然是支持实时多任务，但是API并不是完全足够移植eCLR内核，通过IAR编译MiCO的MAP文件看了看其实MiCO系统中使用了FreeRTOS以及LwIP的开源组件，所以把FreeRTOS 7.x的头文件加入到了MiCO SDK 2.5中。为啥不用MiCO SDK 3.0？此前评估MiCO SDK时候，Fogcloud的库无法在MiCO SDK 3.0下运行，因为MiCO SDK 3.0里面socket接口已经更改为LwIP的socket接口方式，大家可以对比下，而此前fogcloud库使用的是MiCO SDK 2.x的socket接口，两者是不一样的，自然无法兼容。国庆长假回来结果MiCO发布了fogcloud2.0版本直接支持MiCO SDK 3.0，那么就全面切换到MiCO SDK 3.0吧，想想前面想尽办法把FreeRTOS7.x的头文件加入到MiCO SDK 2.5里面正常跑起来，看了下新发布的fogcloud2.0源代码，虽然有种晕倒的感觉，但是还是很高兴MiCO团队能够直接把支持MiCO SDK 3.0的fogcloud2.0源代码发布，赞一个。