【工程师6】+理论类+RTT进阶应用之道。。。

课题1：先来个干货，也就是你认为嵌入式软件设计的时候，最复杂的部分处在哪里？

先来讲讲构架的问题，大部分裸奔的工程只有一种选择，那就是前后台的设计方式：

对于程序的设计有时候很难会做驱动与应用程序的区分，大家都混在一起所以当有需求需要更改的时候

改会变成一件很痛苦的事情，大部分的更改来自于逻辑部分，也就是应用部分，假如把一个单片机干的活

不计成本的用十个单片机来实现，可能还有俩单片机在玩，啥也不干，这样的分解后程序设计会是怎样呢？

其实RTOS的核心目的就是为了让一个单片机用出十个甚至上百个单片机存在的效果而存在的。

他的目的并不是复杂化我们的设计，相反是为了减轻我们设计的复杂度。

课题2：驱动程序的设计及验证是单片机设计的第二大课题。

单片机软件是需要直接和底层的很多硬件直接打交道，例如时钟芯片，存储芯片，通信芯片，传感器芯片等等，设计驱动程序在很大一部分程度上还是相当复杂的尤其是踏入一个新的领域的应用时，传统的一些驱动芯片的程序，都是在其他驱动程序的基础上， 进行修修改改就OK了，可以用了，一旦涉及到驱动程序的编写，也将是一部分很大的工作，其中有的涉及的MCU的内部外设，有的涉及到外部的通信接口的协议定制，有没有想过有人把很多标准的驱动固化到了RTOS的一部分，这样子来缩短开发周期呢，

课题3：正视C语言：面向对象 or 面向过程 ？

面向对象和面向过程是针对软件工程来讲的，与C语言无关，大部分时间我们应用C语言都是应用面向过程进行程序设计，虽然软件复杂度的上升，面向对象是一个更好的选择，像RTOS就是选择面向对象作为设计的核心，除了少量汇编代码的工作，大部分全部采用C语言进行设计的，也就是你也可以采用面向对象的设计思想应用C语言来设计程序。面向对象的支持C++更加全面一些。

课题4：RTT是如何采用面向对象的方式实现I/O设备模型框架的（这是一个实战的案例）

用面向对象的方式实现I/O设备模型框架的实现方式和之前我们做软件设计驱动的方式有很大的普通，具体要说优势在哪里，说实话还是讲不太出来，但是实现方式还是能够理解的，先来看看他的设计框架模型：

传统设计驱动程序，很少涉及到注册的概念，我们会涉及到层的概念，通过函数调用的方式，从最上层找到最底层的应用。

而面向对象的设计是将每一层的设计全部都固化的本身，不会显式的调用底层的东西，这样做了很好的隔离，无论底层如何变动，都与上层无关。

而如果找到最底层的正确的驱动呢，是通过注册的行为，将每一层之间用对象连接起来，实际上每一层操作的是同一个对象。

面向对象，最核心的部分就是继承，继承可以单继承或者多层继承，在应用面向对象将层进行连接时，最主要的手段就是通过继承，你可以使用在继承线路上的任何一个对象，以此为切入点而找到其父亲，爷爷，上上一背，就像是大家都姓王，你说爷爷（类型），大家知道是指王大锤，父亲，大家知道是指王二锤，儿子，大家知道是王小锤。同一对象以王小锤作为入口，对于三层构架，底层设备，驱动层，I/O管理层，通过注册函数，让每一层都找到自己对应的类型，从而做自己该处理的事情。这就是核心。

下面看一看，三锤构架，大锤：rt_object，二锤：rt_device，小锤：rt_serial_device

二锤的内部构造（类型定义）：

感觉技术很牛的，学习学习！

共同学习

这个与STM32编程有啥直接关联？

接下来我们讲解下层的构造，其实层本身是一个抽象的概念，无法实例化的理论是最难的理解的，这里将层映射到实际的文件，每一层在我看来就是一个.C文件，这样讲解不一定准确，但是却很好理解：

APP层：uart_sample.c

I/O设备管理层：device.c位于kernel域中，属于os核心组成部分。

串口设备驱动框架层：serial.c （属于os组件部分）

串口驱动程序：drv_usart.c

stm32只是众多硬件平台中的一个，RTT是平台解决方案的存在，支持基本市面上你能看到的几乎所有的硬件平台，简单来讲就是后面你可以不再过多考虑硬件底层的编程，专注于应用层，底层她帮你解决，不需要自己去设计各种外设的驱动，只需要适配和调试。

既然是进阶之道，还是对核心代码做一些分析：

drv_usart.c中主要对stm32的串口外设进行驱动设计，其代码中，关于中断部分就不做深入解析了，看一下，串口要想正常工作底层必备的几个函数：

串口的基本操作都在这里，配置，更改模式，发送，接收，在配合中断就可以实现串口最底层基本功能；

不论何种外设，在使用之前初始化是必不可少的，底层驱动除了完成初始化功能以外，同时将设备驱动程序注册了整个系统的构架中，类似于Windows某些软件想要使用的时候，需要注册一样，将层与层之间连接起来，register来自于设备管理层，而非驱动层。

到这里还没有提过很难理解的用法，其实是有的，而且实现非常美，这一步部分不理解并不影响你的应用，rt_hw_usart_init并非显式的调用，而是被事先安排到了会按顺序执行的内存中，等待算法列表的调用，全局搜索时发现，

INIT_BOARD_EXPORT这是一个宏，具体实现如下：

这是涉及C 编译器  内存的一种综合用法，如果感兴趣的同学可以从网上找资料学习一下。这种变成方式，像是已经为函数留好了入口，而实现者不需要关心在哪里调用的问题，仅需要通过宏将函数连接入入口对应的内存就好。

设备驱动层实现对于串口的通用用法的实现及封装，在讲串口应用的问题，其实最复杂的部分来自于接收，发送的逻辑实现其实并不复杂，这一层不想展开太细的讲：这里是根据目前通用的串口接收及发送的应用，进行软件设计。

其实对于设备来讲，无论是串口 还是IIC 或者其他设备，统一入口在device层，真正应用的时候你不需要之道底层，中间层到底是如何实现的，只要关注device层的规则进行软件就可以实现相关的功能：

RTT应该是面向物联网方向的吧？

嗯，主要是面向物联网的操作系统

课题5：你以为的真的是你以为的吗？这一课题或许是本篇进阶之道最重要的课题，也是废话最多实战最少的课题，但我却认为是最重要的课题。

          你以为的真的是你以为的吗？你能在这条路上走多远，取决于你以为的尽头在哪里。工作多年，前进的时间能有多少，大部分时间都在原地打转，一度怀疑是否是自己的能力和智商有极限，只能走到这里了。

           我们真正缺的并不是能力和智力，假如你能看到这里，我们缺的是一种叫做逆向思维的东西。

           什么是逆向思维，我觉得很难用文字解释，当你每一次突破人生或自我的瓶颈，你就在运用逆向思维的利器。

           

        

   以软件为例，我觉得这条路真的是越来越难走，因为要学要会要通的东西实在是太多，精力有限，这么走下去，真的是越来越慢，其实问题并不是这条路越来越难走，问题是你是否觉得软件是一个人的工作，还是一项原本就是需要很多人协作的工作，假如是后者，那么你是否应该选择信任相互协作的人，就像是造一辆车子，有人做好了发动机，你是直接拿过来用，还是拿过来拆开先看看内部设计是否合理，是否有问题，这是否真的有必要？哪怕你特别想知道它内部是如何工作的？现在的问题是造一台车子出来重要，还是先把所有零部件解剖一遍重要？        

  以前我以为，只要是工程中引用的软件就必须搞懂搞通这样才能确保软件质量及稳定运行，在需求快速增长的现在，无论是软件的哪一部分读起来都并不那么容易，这些软件的生产者也没有你想象的那样粗制滥造，虽然bug不可避免。

            现在我以为，哪怕这台车子真的有问题，那也要让他先跑起来，在慢慢调教看看问题出在设计上，还是我的装配上。假如没有问题，那么我会去研究其他的车型，而不是把这台车子打散重新研究一遍。            你以为的也许并不是正确的，真的能够在遇到瓶颈时候学会反思，你才能突破现在的自己，重新上路。

课题6：下一层AT组件应用：（AT组件主要应用在各种各样的通信模组上，本例基于esp8266WiFi模组应用）

            通信模组采用ESP8266-01S开发模组，底板采用正点原子战舰mini开发板。

            

AT组件建立在device层的基础上， 也就是I/O管理的框架基础之上。

RT工作就是任务调度，需要注意优先级及嵌套层次。

软件的设计就需要架构合理，后续维护及升级都容易。尽可能的模块化设计。

楼主是做什么物联网的设计工作了？面向应用是哪个领域？

主要是智能家居和共享领域

的确是。

基于AT组件，RTT扩展出软件包，供大家选择和使用，这里的组件层和内核（本篇帖子没讲）说实话这篇帖子想接着讲的内容还有很多，但考虑到核心进阶的内容已经讲到，帖子太长，就不展开继续了，到这里看一下如何添加AT_DEVICE软件包以及注意事项：

这里用的是乐鑫的ESP8266WiFi模组，注意固件的版本，推荐使用V2.1.0，这里够用了，当然不同的应用场景可以自行选择需要的版本：

 利用env变异生成工程后，烧录到目标板中，利用finsh组件可以交互使用相应的功能了

测试一下经常用到的网络测试命令，确认at设备正常工作：

在AT_device的基础之上可以添加通信协议与服务器建立连接，这里以通信猫为例，添加测试MQTT协议：

编译整个工程后，烧录到目标板中，通过finsh组件测试MQTT协议是否正常工作：

这是官方提供的一个demo，中间调试略有曲折，费点事一天搞定，如果感兴趣的同学，在调试中遇到什么问题，可以交流沟通，吃过一次螃蟹，我就知道怎么教你怎么吃了，只要你请客。这篇帖子就到这结束吧，最后讲一个很关键的东西：

RTT本质是生态的存在，也就是开发者和目前RTT开发团队并行开发的结构，目的是为了构建生态，丰富应用层，这中间会有匹配的问题存在，也就是你使用的软件包虽然是RTT提供的，但并不是RTT团队制作并维护的，他的提供者和你我一样，都是云云开发者，所以有时候会出现软件包与RTT构架不匹配的问题，这时候可以多试几个软件包的版本，不一定是最新最好。

本篇进阶之道到此结束吧，最后来一张硬件的特写，线做的稍微有点乱，sayonara~！

搬凳来学习