前言
老实说，我不记得当时在方案中写了些什么，只是隐约记得一个思想，集群控制的思想，既然被选上了，我也只能老老实实地将方案进行完整的构思，并将整个系统的框架进行构建。
集群控制系统的思想来源于人体的神经系统，它由几个关键点，一是：被控制家具的行为单调性，比如一个电灯只有通断两种状态，空调的控制相当于一系列点击脉冲，二是控制的中继器行为的机械性，不应该具有过多的逻辑控制，只是单纯的对二进制信号进行传递，三是核心控制器的高效处理能力，最好能应对每秒几十次的接受信息。
集群系统三个关键元件，核心控制器，我们称为“脑”，其掌握着所有被控制器件的信息；传递型中继器，机械性的肢体，可复制性强，对输入输出进行机械的分流和汇集；控制型中继器，对于一些简单操作指令本质也是机械的，但目前有许多家电已经自带智能控制系统，我们的想法是将控制型中继器行为嵌入到家电中。
思想源头
从神经系统到家具神经
人体的神经系统由复杂的反射弧组成，但基本结构是简单的，我们可以轻松地将其与我们的控制系统进行对应
p1.png有人可能会觉得将一个简单的控制系统搞得如此复杂，有什么意义吗？又有什么用呢？
首先我们搞清楚一点，这个系统并不复杂，除了核心控制器以外的其它原件只具有机械的应答能力，又或者是极其简单的状态机逻辑。我们的理想是对上百的家具进行集群控制，对于可复制性强的中继器而言，数量越大意味着成本也会越低，而且这样的硬件制造简单，技术含量也不高。整个系统真正重要的是核心控制器，其保存着整个系统的控制信息，也就是在整个系统中，真正需要进行管理、控制和保护的就它一个而已。
操作系统的作用
进行过许多嵌入式开发的我，曾思考过，操作系统对于嵌入开发作用很大吗？对于需要智能的系统而言，操作系统提供了高效的数据管理方式，不仅提供了丰富的可控数据类型，还封装了各种硬件资源的管理，特别是内存管理。不过在我看来，操作系统更重要的作用果然还是跨硬件性了，对于面向硬件的编程而言，操作系统做了些什么？在很多情况下好像是种累赘。在这次的比赛中，所用的硬软件中就会出现这样一种情况，如果在tos的task内调用了硬件的Delay_Ms或Delay_Us进行时间延迟的话，再调用tos的tos_task_delay的话，整个task就无限停止了。至于原因的话，作为一个调包侠，肯定不会去深入探究，但这表明了一个事实，那就是操作系统确实有可能会妨碍到原生硬件的开发。
在此基础上，我们容易知道，对于简单的硬件控制而言，操作系统是没有必要的，靠原生C语言强大的控制能力，基本可以征服所有硬件了。但操作系统对于智能控制又是不可或缺的，比如主流的人工智能程序基本都基于Python，但没有操作系统的话，像这样的高级语言是难以存在的，虽然有MicroPython，但移植是困难的。但如果对每个微控制器都引入操作系统的话，不仅麻烦，而且维护的工作量也十分巨大，至少从长远角度进行考虑的话，进行局部的智能控制永远也无法成为主流，因为不可能每个人都是工程师。
个体无法完成的事，我们可以靠群体来实现，将复杂而且维护复杂的部分集中于一个地方，所有的逻辑控制与复杂的数据处理均集中在这里。而对于操作机械，只需进行简单元件替换即可维护完成的部分，进行广度分布，最终形成一个集群系统。
p2.png有人可能会觉得，这不就是云思想、服务器思想吗？因为我只是说了这个系统的框架，所以看起来好像确实如此，等我详细说明以后，你或许有些不同的看法。而且这个树状的网络，运行起来不像是个高效的系统？而且还是串口通信，会不会出现请求冲突的情况？而且核心控制系统又怎么在众多请求中，如何保持对各个元件情况的掌握？
串口协议
接下来我们要介绍，在整个控制系统中起重要，串口控制协议，此协议为二进制流协议，且是单向协议，协议的散播与协议的收集，是两个互不相同的过程。协议的基本结构十分简洁，主要还是为了防止中继器的行为过于复杂。
p3.png协议的散播
在整个控制系统运行的过程中，核心控制器只会在复位的时候，主动散播一次INIT指令协议，其它的指令协议均是被动发出的。INIT指令的作用是为了使核心控制器将它的身体结构掌握，但它的作用并非一个，它还是中继器进行信息上报的指令，中继器时我们会继续说明。
CD指令表明了当前的中继器是传递型中继器，个数位表明有几个子节点，也对应接下来有几段数据要发给它的子节点，每段数据的长度位表明转发数据的长度。
DJ和TD指令表明了当前的中继器是控制型中继器，个数位存储可能需要的数据，接下来只有一段数据，长度位表示数据的长度，数据位记录请求的内容。对于TD，1表示一次脉冲，0表示不管；对于TD，1表示通电，0表示断电。
这类协议在8位1比特的系统下实现是十分繁琐的，但如果抛弃系统的观点，单纯通过电路实现是可能的，值得注意的是，在INIT指令时，核心控制系统不知道身体的结构，所以没有携带数据部分，这对中继器也是一样的，中继器也不知道身体的结构，但可以通过向子节点发送INIT指令，使得在协议收集时获得收集数据。
协议的收集
协议的收集，发生于三种情况，一是从父节点收到INIT指令，二是控制型中继器收到用户的认证请求或修改请求，三是子节点传来收集数据。由此我们可以知道传递型中继器并不会主动进行协议的收集，而控制型中继器则可以由用户的输入而主动收集协议。
RZ和XG指令都只能在控制型中继器中继器中产生，用来表示用户的请求；BC指令每个节点都会产生，此时数据位将存放报错信息，核心控制器可以将其与初始化树对比，得到报错节点的位置。除了以上指令，所有的回传指令都为INIT，它将子节点的数据收集后，并传给父节点，我们会在中继器部分进行详细地说明。
最后给张图来形象地说明协议的散播和收集过程
p4.png这时，我们好像发现一个问题，在串口传输中，在给定波特率的情况下，越长的数据传输的越慢，但按照我们的构思，核心控制器的传输数据应该比节点多得多才对。越多需要传输数据的地方，却有着越慢的传输速度，这其实是一种错觉，接下来，我们介绍一下中继器的运行原理，你就会明白了。
中继器
中继器有两种类型，传递型和控制型，它们的差别是细微的，本质都可以视为中继器的一部分，中继其的行为可以使用自动机来描述，与传统自动机不同之处在于，其并非自动读取下一个数据，而是在某个接口收到某个数据。数据的接受采用串口协议，无数据传输的时候维持高电平，当出现低电平时开始按照波特率和协议进行数据读取。
p5.png控制型中继器没有子节点，整体逻辑比较简单，比较关键的是与用户交互的部分，这部分可以用简单的输入输出来实现，没有比较复杂的通信过程。此中继器只有一个需要监听的任务，即父节点的输入，当父节点传入INIT指令时，表明父节点不知道当前中继器的情况，我们则将相应的状态信息进行回传即可。另一种情况对于用户的控制指令，中继器则携带控制信息，以相同的格式回传。也就是，无论指令到底如何，回传的目的是告诉核心控制器，它将来会是什么状态，对于父节点的非INIT指令，控制器只需要执行即可。
传递型中继器有子节点，对于此类中继器，只有当收到所有子节点的回传数据时，它才会向父节点回传数据。为了表示数据传递，此中继器有两种状态，监听态表示中继器没有回传数据的打算，当它收到父节点的INIT指令，或子节点的回传数据时，进入等待状态；等待态表示中继准备向父节点回传数据，此时它将维护一个子节点状态表，并对所有未收到回传的子节点发送INIT指令，如果在期间收到已更新的子节点信号的话，则对相应的子节点状态表进行更新，一旦得到所有子节点的回传数据则，向父节点回传数据，并变回监听态。至于来自父节点的非INIT指令，直接不断地下传即可。
过程或许有些复杂，但只要搞清散播和收集的过程，整个系统实际是十分简洁的。整个传递的过程有两条主线，非INIT引导的不回传散播系，INIT引导的回传收集系。
p6.png对于散播系指令没什么好说的，甚至可以直接视为隧道直连，然后在适当的时候分叉。对于收集系而言，有两个任务，通过INIT来回收整个身体的结构，并将每个部件的请求最后形成一个整体，交由核心控制器来进行判断。
核心控制器
核心控制器是整个集群控制系统的主要部分，虽然我们声称它具有最高的智慧，但真的仔细考究的话，它其实也只是一个响应程序罢了，但智慧的强大在于响应多样性，从一段简单的二进制流中，做出各式各样的应对。不过嘛！如今可控元件的操作性，相较于机械而言是十分简单的，智能系统并不能表现出它的智慧，但我们依旧完成了它。
p7.png当它还未出现的时候，我们总觉得它充满了无限的可能，但一番探索，研究，并最终实现它以后，发现好像有些无聊，为啥点个灯，点个按钮，还得搞得如此复杂。不过，我们还是有一些憧憬的，或许简单的东西复杂化，也不是件坏事。
模拟实现
实现的讲解
由于中继器并不是实际存在的器件，我们本质上，不可能实现这个目标的，不过为了完成任务，我们决定采用模拟的方式，在这块板上实现一个简单集群系统。
p8.png为什么不在模拟一个传递中继器，主要是官方提供的几个跳线帽不够用了，又懒得买新的了，而且本来就不能实机的东西，能实机就已近不错了。
演示视频
作品PPT
小结
感觉自己选择了一个十分奇怪的课题，本来就抱着不会被选上的心理，不过即来之则安之吧。整个探索的过程中，通过操作系统来模拟中继器的行为有点麻烦也有些不太合理，还有就是tencentOS提供的数据结构用起来感觉怪怪的，还不如多提供一些C 的数据结构，这样实现“脑”的过程也不会这么繁琐了。不过实现一个专精二进制数据控制的超微型系统也许也不错。
