嵌入式系统的入门

前言

从事嵌入式开发已经4年了，从一个非专业的专科生起步，一路走到现在，讲真还是挺难的，没有学历，没有经验，基础差，在小公司里摸爬滚打，总算是走到了开始对嵌入式系统的思考这一步，而这不过是专业对口的人在大学阶段或者毕业一年内做的事，我却花了这么多年的努力，再次深刻体会到选择大于努力这句话的意义。

1.什么是嵌入式系统

  在我看来，嵌入式系统是一种程序框架，他提供了一些基础而常用的函数，数据结构，模块，驱动等代码，规范了一些代码格式和结构，使代码更直观易懂，容易开发。
  从刚入门开始，我们的程序都写在main函数，随着函数的增多和重复代码的出现，我们开始接触函数封装复用，将重复的代码封装成函数，main函数中调用外部函数执行程序。再然后，我们开始接触中断，这个被称为前后台系统，或者叫前后台框架，main函数while中的程序是后台程序，中断程序是前台程序，后台程序处于一直运行的状态，前台程序需要执行时，打断后台程序优先处理，处理结束后后台程序继续执行。
  前后台系统是我们最开始接触的嵌入式系统，也是最常用的系统，但是随着项目功能的增多和逻辑的复杂度提升，后台程序按顺序不断运行开始无法满足需求了，我们开始对某些程序的运行有了更多的要求，例如多久执行一次或者什么条件执行一次，这时候我们开始使用计数变量，随后while中增加延时，控制一次while循环一次的时间，用计数变量来控制后台程序多久执行一次，比如每次循环延时5ms，每4次循环执行一次，那么这个程序就大概是20ms执行一次，当然实际上还有其他程序的运行时间和前台程序的执行时间，但这时候我们的要求没那么严格，因此这样就足够了，这就是最简单的时间片轮询系统。
  当我们对程序的执行频率有更高的要求时，简单的时间片轮询系统就无法满足了，因此我们引入了硬件定时器，使用定时器提供1ms的时间基准，简称时基，同时要求前台系统不能占用后台系统太长时间，减少在主循环中调用堵塞延时函数。这时候，时间片轮询系统变成了前台触发时，处理简单事情，比如拷贝数据，设置标志位，复杂的逻辑在主循环中判断标志位来决定是否执行。后台系统的程序根据定时器提供的时基来决定是否执行。
  需求在不断变化，功能也在不断进化，我们对程序的要求更高了，中断设置标志位然后在主循环中执行无法满足我们对程序实时性的要求，简单的时基控制后台系统的执行也无法满足我们对某些程序不同状态下不同的执行频率要求，函数开始限制不能使用堵塞延时，但对延时的需求仍然存在，于是我们开始寻求更好的系统，这时候实时操作系统开始进入我们眼中。
  最简单的实时操作系统，是将程序的执行函数放入队列，设置执行频率，然后在定时器1ms中断中不断计数，同时判断是否有程序已经到了需要执行的时间，这个定时器的中断等级通常设置较低，防止其他中断得不到处理，因为它执行频率高，占用的资源较多。函数在中断中调用，就不能使用堵塞延时函数了，因为这会影响其他函数的执行，为了满足对延时的需求，我们开始在程序中引入状态机模型，通过计时器来切换状态，这样当需要延时时，状态机为等待状态，仅判断是否达到延时时间不处理任何事就退出，对其他程序的影响就很小。
  人是懒惰的，但懒惰也是创造的源动力。我们开始想要偷懒了，不想每一次工程都重新写，甚至拷贝粘贴然后修改都不乐意，就想拷贝粘贴就能用，于是我们开始封装常用的函数，数据结构，模块，驱动，控制策略，希望做到无论在哪里使用，都能尽可能的少修改甚至不修改就能用，将这些可以简单复用的代码与操作系统组合起来，就形成了嵌入式系统。

框架

论框架，谈的最多的应该是互联网前后端和C++了，在嵌入式谈论的相对较少，我见识浅薄，看到的仅仅是模块化思想，应用层和底层分离，再多就是应用层、业务逻辑层、框架层、OS层、驱动层等自由组合，每个人都有自己的分层思路。
随着摸鱼时见到的前后端框架讨论越来越多，我开始思考，能不能在嵌入式引入这些框架呢？随后慢慢搜索资料研究，发现果然还是有很多大神在思考这些，如C的面向对象，MVC框架等，这里推荐大家搜索大神”傻孩子“的专栏。

MVC框架

MVC框架，是软件系统模块化设计的一种方法，它给软件系统划分为三个大的部分，分别是Model(模型)、View(视图)、Controller(控制器)。

嵌入式软件设计之美
这里引用大佬的理论：

Model模型
模型就是负责具体功能、业务逻辑实现的，它通常是一个产品内部的一些业务逻辑组成；例如，接下来我们要做的一个项目里有一个MQ-2传感器，MQ-2传感器的气体检测流程可以认为是一个模型。

View视图
视图就是负责展示、响应其它模块处理结果的。例如，有一款设备拥有一个LCD屏幕，然后上面移植了一个GUI系统，它用于显示当前MQ-2传感器的数据，那么这个GUI系统就是一个视图。当MQ-2传感器检测到的阈值超出我们所设定的阈值时，蜂鸣器或者LED报警了，那么蜂鸣器、LED也可以认为是一个视图。当然，视图不局限于以上这些内容，视图也可以是IOT前端、也可以是一个Shell终端，甚至可以是一个进程或者线程。

Controller控制器
控制器就是用来接收用户输入的。通常，一个设备上可能有按键、触摸屏、鼠标等输入设备，那么当用户控制输入设备时，根据产品内部的业务逻辑，界面可能会发生跳转(视图)，用户看不到的另一面会启动应用业务逻辑(模型)，然后设备内部的业务逻辑处理完毕后，又会通知界面，例如弹窗或者仅仅是界面上控件数据更新(视图)。

思考

虽然已经存在很多嵌入式系统了，如rt-thread，鸿蒙系统，阿里IOT，腾讯IOT等等，但总是会有些不如意，如系统太大太难入门，模块不好用等等，还是会想自己重复造轮子，一个是可以更深入的学习嵌入式系统，一个是做一些定制化，自己用的舒服的系统。后续想法是在模块化的基础上引入MVC框架，将模块进行分类，引入FreeRTOS实时操作系统或者时间片轮询系统管理工程，搭建工程模型，定制静态分配的数据结构，常用算法，状态机模块，事件驱动模块，跳表，pipe与协议，总线，设备类。
这些年经历过不少事情，比如：
1.用过不少不同的芯片，次次研究好几天库，移植以前的代码。
2.接触过因考虑不周而不断变更的协议，每次改协议就开几天会这个说我改不了那个说工作量太大。最后自己代码大改全部功能重新测。
3.学习过BLE，USB，WIFI，LoRaWAN这样的大型协议，底层协议实在是太难啃了。
4.换过好几个平台，也收到过某5的律师函，看着一堆的按钮和配置头疼。
5.见识过难用的库中库（新库封装接口兼容旧库但配置没兼容，没错！就是你Nordic的sdk_config！），添加一个模块各种依赖报错，引入依赖后依赖的依赖报错。
6.接手过同事所有程序在main.c，80%逻辑代码全部在一个中断中处理的工程，写个代码要背下常用的函数名，不然根本找不到函数，改一下工程结构结果程序跑不起来，最后所有底层排查发现驱动没写好，因为要等待下降沿处理，之前在下降沿中断跑所有程序所以没问题，丢到main函数就完了。
7.维护过代码中各种malloc，while循环等条件的循环体里面malloc，各种死机、跑飞，根本排查不到bug。
8.经历过写好脚本双击就能用但是客户总是这里有问题那里不会的离谱事情。
9.在家新开一个工程，下载环境各种失败，网站打不开，最后只能找魔法。
10.在公司只需要做软件，但是钱少，想增加收入，发现能接触到的，都是别人挑剩下的，个人根本做不了，钱也不多。比如要源代码，PCB源文件，APP，数据库，上位机，前后端。个人哪会这么多，有团队接这个分给每个人塞牙缝都不够，时间要要求紧。
越来越觉得工作难，想赚钱更难。软件工程师的能力是有极限的，我在这短暂的软件生涯中学的一件事，越是精于软件，反而越是容易陷入意想不到的困境，前功尽弃，除非超越软件……我不做软件工程师啦！我要当全栈！