ESP32 LED灯阵列

网络卡顿无法加载图片请访问备用网址

ESP32 物联网项目 (flowus.cn)

一、总设计思路

1.1概述

手机作为客户端，ESP32及其外设作为服务端，客户端与服务端进行通信，实现通过手机对板载LED灯进行各种操作。

1..2客户端与服务端通信

客户端与服务端通过TCP/IP协议进行通信，TCP协议为面向连接的可靠通信，使用TCP_Socket套接字确保连接的唯一性。

图1.2 客户端与服务端TCP通信流程图

Socket()进行套接字资源的初始化，bind()为服务端绑定本地IP和端口，listen()为服务端设置最大连接数，accept()为阻塞函数，等待客户端连接，connect()为客户端开始与服务器建立连接，close()进行关闭TCP连接。

二、客户端软件设计

考虑到软件的复杂程度和开发时间，客户端软件开发平台选择AppInventor，通过图形化编程将各个功能模块进行拼接。

2.1 组件设计

图2.1.1 Screen操作界面

                                                            图 2.1.2Screen2操作界面

图 2.1.3 Screen2非可视组件展示

图2.1.4Snake_Screen开发界面

7×7点灯按钮阵列：用来实现操控板子对应49个灯的亮灭
Clear清空按钮：实现将灯全部熄灭
R色值调整数字滑动条：调整灯的R色值
G色值调整数字滑动条：调整灯的G色值
B色值调整数字滑动条：调整灯的B色值
亮度调整数字滑动条:调整灯的亮度
帧模式-画面帧按钮：实现进入“画面帧”模式⑪⑫⑬⑭⑮
帧模式-点帧按钮：实现进入“点帧”模式
模式选择下拉框:用来选择更多模式
调试信息显示标签若干：用于观察各隐式参数以便调试程序
收到服务器发来的的信息标签：用于接受服务器发来的消息
TCP组件：用来实现和ESP32芯片进行TCP通信
计时器1：通过计时器构成循环逻辑结构，让计时器循环发送模式和灯的相关参数
状态机计时器：用以刷新灯的参数和更新调试信息标签中的文本
Screen1、Screen2、Snake_Screen：三个屏幕，用来切换不同操作页面

2.2 自定义过程设计

自定义过程是APP Inventor提供的类似于函数的编程设计，用来定义一个需要重复使用的过程

连接

连接的逻辑设计是检测设备是否与服务器相连，若没有，则调用TCP组件，传入服务器IP和端口号进行连接操作。

图2.2.1 自定义过程-连接

统一颜色

对客户端49个点灯按钮进行统一颜色操作，这里没有给服务端发送清空命令。从这一个自定义过程的编写也能看出APPInventor在软件开发上的不足：无法对同类组件进行类管理，需要独立编写每个按钮对象的操作，而不是在循环中对按钮n进行操作的编程，这使得代码的编写变得繁琐。

图2.2.2 自定义过程-统一颜色（部分展示）

帧

当点帧或画面帧模式开启时，是这个自定义过程有效的必要条件，这个自定义过程会向一个全局列表中加入49个点灯按钮按下时的位置、亮度、R、G、B信息，并传入全局列表中。

图2.2.3 自定义过程-帧

允许点灯

启用49个点灯按钮。
禁止点灯

禁用49个点灯按钮。

设置这个过程的目的是防止客户端在调用TCP组件进行发送消息未完成时又调用该组件发送消息，使程序崩溃。

2.3 组件配合

组件配合完成客户端的人机交互以及客户端与服务端的通信。

图2.3 组件配合图

2.4 细节优化

① TCP组件调用冲突的处理

由于有多个组件能够调用TCP组件对服务器发送信息，因此需要避免同时调用TCP组件造成冲突，需要进行调用前的限定。

49个点灯按钮、clear、计时器1按钮都能对TCP组件进行调用操作，因此需要做调用条件的限定。

Clear按钮和49个点灯按钮只有在点灯模式才能够调用TCP组件发送数据；计时器1只能在非点灯模式下进行信息的发送。而对于49个点灯按钮来说，为了防止同时按到两个按钮造成冲突，设计了当按下按钮时马上调用“禁止点灯”让点灯按钮全部禁用，而在发送完信息之后再次打开。

此外，还有其他防止冲突的限定。如开启画面帧模式或点帧模式时，在“完成”按钮点击之前，调用“允许点灯”，在点成点击之后，调用“禁止点灯”，画面帧和点帧按钮无法同时启用等。

②TCP组件调用过快的处理

在测试中发现TCP通信时而断开的问题。查阅了TCP通信的协议后，发现如果过快调用TCP发送数据违背了通信协议，TCP是面向连接的通信协议，每当客户端发送出一个字节的数据时，服务端需要回复客户端已收到的信息，然后客户端继续发送数据。如果计时器1频率过快地发送信息，会造成服务端来不及回复信息，TCP组件处于等待回复的状态，而客户端又开始调用TCP组件进行发送数据的操作，从而造成客户端崩溃。因此，设计了让服务端向客户端发送“listening”和“received”。当服务端收到信息时会向客户端发送”received”,从而让客户端以此为依据不再向服务端发送信息，当服务端处理完上一次接受的数据包后，发送”listening”，客户端又可以进行调用计时器1进行发送信息。但是实际调试时仍然出现客户端崩溃的问题，说明以上操作并未完全解决问题，计时器1仍然过快地发送数据造成客户端崩溃。新问题在于在服务端发送来“listening”时计时器1仍然频繁发送数据包，从而造成客户端崩溃，而实际上只需要在”listening”状态让计时器1只发送一次数据包即可，因此在客户端软件中加入了一个用以验证只发一次数据的变量，当服务端处于”listening”状态的时候这个变量值为1，当客户端发送一次数据后这个变量马上置0，在下一个”listening”状态时再次置1，从而形成了一个闭环的变量更新机制，让计时器1具有类似于触发器的功能，在特定场景才能触发发送数据。