[原创] 【碉堡了水军团】系统的基本拓扑结构和程序的大体框架

      鉴于现在F7核心板才刚到手（我的还在坑爹的快递小哥手上），以及具体的需求啥的还没完全确定，当前的讨论感觉乱糟糟的。
最基本的主干结构没出来，基本的原型没出来，反而是各种细节的讨论不断蔓延，我真的担心这样下去 项目 会 蔓延下去，没完没了。


     之前我在提交给柱哥的个人信息里，说过，我主要是看看程序怎么组织这些比较框架性的东西。
所以我想了想，我先提出一个基本的方案。
大家讨论讨论，顺带我尽可能提出一些 接下去可以做的一些具体的工作，比如确定一些参数，一些基本的数据表 等。

功能框图

之前讨论时 基本的 功能框图

系统大致构成

   F7为主机，带人机界面，可以直接操作传感器，执行机构。同时，为了可以让手机app远程查看、控制，应带无线网络接入功能，暂时比较一致的看法是wifi。为了避免复杂的网络协议，这里采用ESP8266串口转wifi模块。

        对于F7主机和其他传感器执行机构是否需要分布式安装，这是后话，按照柱哥的看法，暂时不考虑分离式的情况。而即使是分离，不管具体采用什么方式组网，我都建议让F7主机直接控制这些分离式的传感器执行机构，手机app仍然只能通过f7间接操作它们，避免让手机有过高的操作权限。
   所以，f7即是一个主控，也是一个网关，这样做的好处是，避免传感器执行机构被恶意操作，提高安全性。另外也简化了整个系统的拓扑结构。

程序的大致构成

    现在硬件上的东西很多都没定，但是这并不影响软件层面的抽象，因为他们都是一样的。任何外设，通过什么样的通信方式链接都好，最终都如同主控的外部存储器一样进行读写。
   这一部分是软件的最底层，而在此上，则是具体的应用。为了程序方便扩展和多人共同开发，需要模块化，决定采用RTOS的多任务机制作为程序的基本框架。
   不同模块之间尽可能独立，尽量减少耦合过多、模块之间的通信可能的数据冲突等问题，采用多任务机制可以简化这方面的处理。
    这里我个人考虑我玩过的freertos，它是一个标准的带独立堆栈的可抢占实时操作系统内核，信号量锁等必要的进程间同步机制一应俱全。
   FreeRTOS作为一个商用免费，源码完全开放的RTOS，比起ucos来说，要轻量许多，因而更容易理解学习，上手使用。
   至于其他组件，尽管FreeRTOS只是一个RTOS内核，但它很容易与其他中间件类似文件系统儀络等猀栀攀氀氀等结合使用——更为重要的是，其官网提供了大量这样的实际例子，可以减轻难度。

   如果团队里更多的人熟悉别的系统可以提出讨论更换，这并不是太重要的事情，因为最后都应该由熟悉的人移植封装好，然后提供给每个模块的作者一个独立的进程，这样也就一并协调了cpu时间个存储器空间这两个最重要的资源分配。至于任务、模块集成时可能的其他冲突也只能具体问题具体解决。

一个公共的存储模块

   另外，在这里，为了解决各个任务之间的数据交换问题，还需要一个最基本的存储模块，不管是文件系统还是简单的参数列表，他都可以用来解决这个问题。
比如读取到的传感器内容存在一个固定的存储器里，则网络模块可以在任何时候读到当前最新的数据，而不需要和具体的任务模块发生任何联系，独立性非常好。
关于HMI
实际上需要注意的是，在这个系统里，一套人机界面是F7上的触控屏，另一套是手机app。但需要认识到的是，这两套界面尽管看起来不一样，但对于F7而言，它的功能是等同或者说至少等同的，所以，程序里完全可以用同一套机制来处理它们，只不过它们的数据通信管道不一样而已。
这里选择一般的基于事件机制的HMI方案。我手上有一套可以借鉴的简易人机界面（尽管还没完全清理干净）
为了简化HMI模块和F7系统其他模块之间的通信，除了需要上述提到的那个共同的存储模块，还需要一套HMI的操作指令，这其实是一套简易型的协议。至于是按照标准的工业协议modbus等，还是自行定义，有待讨论。
假如采用标准modbus等，那么可能要选择合适的第三方开源代码来实现，还要根据modbus的语意来套我们应用里涉及的内容。如果采用简易型的协议，则可能更加轻量简单。但是，将来就可能遭遇因不是标准协议而兼容性不好的弊端。

其他模块1：公共的存储模块

   另外，在这里，为了解决各个任务之间的数据交换问题，还需要一个最基本的存储模块，不管是文件系统还是简单的参数列表，他都可以用来解决这个问题。
比如读取到的传感器内容存在一个固定的存储器里，则网络模块可以在任何时候读到当前最新的数据，而不需要和具体的任务模块发生任何联系，独立性非常好。

其他模块2：HMI

       实际上需要注意的是，在这个系统里，一套人机界面是F7上的触控屏，另一套是手机app。但需要认识到的是，这两套界面尽管看起来不一样，但对于F7而言，它的功能是等同或者说至少等同的，所以，程序里完全可以用同一套机制来处理它们，只不过它们的数据通信管道不一样而已。
       这里选择一般的基于事件机制的HMI方案。我手上有一套可以借鉴的简易人机界面（尽管还没完全清理干净）
       为了简化HMI模块和F7系统其他模块之间的通信，除了需要上述提到的那个共同的存储模块，还需要一套HMI的操作指令，这其实是一套简易型的协议。至于是按照标准的工业协议modbus等，还是自行定义，有待讨论。
       假如采用标准modbus等，那么可能要选择合适的第三方开源代码来实现，还要根据modbus的语意来套我们应用里涉及的内容。如果采用简易型的协议，则可能更加轻量简单。但是，将来就可能遭遇因不是标准协议而兼容性不好的弊端。

最近有点忙都没注意群里讨论，现在这个确定下来了吗？

还没完全定下来，但我的程序架子差不多要可以定下来了