stm32太阳能追光储能系统V2
大家好！我是小杰学长~
前言：
追光储能系统=
stm32太阳能追光储能系统V2.
加入了基于命令行的操作界面以及内置的AT指令解析机制（该系统允许通过串口通信发送AT指令来控制其各种功能）；更换掉了原有的SPI接口并采用硬件方案；重新配置了硬件电源配置；新增添加了PCB原理图文件，并附上了对应的PCB源代码；引入了基于FreeRTOS的操作系统支持互斥锁机制、内存池配置、消息队列处理以及任务管理流程；构建了一个基于UART通信的 shell 命令行界面框架，并提供了完整的命令序列列表
请各位先初步了解最初版本的追光系统 追光系统初代链接跳转
仅保留了有修改的代码文件和CubeMX的ioc工程文件
直接用cubeMX打开ioc后生成工程
再把对应位置的代码进行比较 然后拷贝进去就行stm32追光储能系统实物功能演示视频
各组件实现原理博客网址
-
光敏adc采集：
-
舵机pwm控制：
-
INA226功率监测I2C：
-
TFT彩屏io模拟SPI原理：
-
TFT彩屏驱动库解析：
-
硬件SPI控制TFT彩屏：会在本篇博客讲解
也没啥好讲的
把底层io模拟的接口换成hal_spi_transmit就行 -
CLI-AT协议解析代码框架：在文章末尾
所使用的硬件
- 如下图
相比一代 硬件有所改动，如下：
1 去掉了充电功能
因为这属于硬件领域的事。对于软件工程师而言，在测试设备时能够检测电流方向。只需了解充电与放电的状态即可。因此模拟出一个类似于太阳发电系统的模型。在面试中也可以这样表述。
2 电阻型号
可调电阻换成了1kΩ电阻
3 电源模块
换了个电源模块
能满足系统用电需求
支持2个18650电池输入
4 pcb底板
写代码的时候发现i2c1与spi1的内存地址映射冲突了
改成使用硬件spi2
嘉立输出的pcb原始数据采用JSON格式。
项目底板路径跳转已设置为图片 2024年6月6日发布（在我gitee上）。
本人不具备拉线工程师资质 也不太熟悉相关技术细节。
cubeMX初始化
在cubeMX系统中，我对所有外设的内部参数进行了全面的优化设置。您可以根据个人需求采用不同的配置方案。具体方法将基于您参考的相关技术博客内容。
1 cubeMX硬件引脚
引脚定义
单片机板子的各个引脚连线
通过cubeMX软件打开文件夹中的IOC配置文件
从而能够清楚地了解到每个模块所使用的接口
它们都连接到了32号引脚上
当然，并非所有的模块都必须采用相同的IO口接法
如下图：
SPI
spi2
彩屏只需要接收
所以我们只需要开启只发送主机spi模式即可
UART
115200波特率
记得使能串口中断
2 cubeMX freeRTOS配置
统一图片演示
你们自己看 看不明白 看代码
其他默认
rtos系统配置
堆大小改大一点 原来的不够用了
rtos功能配置
任务和队列
就弄了三个
在命令行界面的代码中，在开发过程中还另外也自行创建了：一个线程；一个用于串口通信的互斥锁；用于串口中断接收中断的地方；三个消息队列；三个内存池被创建以供使用。cubeMX中没有内存池。自行在头文件中进行了初始化配置，并通过示例图解展示了操作流程。
导航路径中的链接跳转-> （在个人Gitee上）
系统框图
硬件系统框架
被引导去阅读过去发布的博客内容追光系统初代链接跳转
CLI-AT协议解析代码框架
我学生写了 我就不写了 大家自己看
工作流程图 位于我的gitee仓库中
通读了一遍《源码解析》，让你们受益匪浅。
很快学会了如何利用硬件UART实现中断DMA机制。
在注册命令行配置时采用的是链表结构。
这是我的学生掌握的核心技术。
这种组织方式是否与智能家居中设备层级化的控制链表相似？
AT指令的其他注册方式更换了；采用数组进行操作会更加高效准确；他俩之间存在明显的区别吗？为何会感到如此？关于简历撰写技巧的具体问题，请您自行解决；哈哈（苦笑）
展望与写进简历
展望
有人批评cli-at框架的白板演示令人糟糕透顶。看起来像老师一样需要改进。
有人批评缺乏通信协议框架以及未采用PID自适应控制算法。
特别适用于需要精确控制的行业通常会采用这样的技术方案。
在电机控制系统中涉及的关键环节包括信号采集、电源管理以及系统的全面调控。
建议所有用户尝试采用无刷电机配合PID自适应控制算法实现角度精准跟踪。
对于这一问题，您可以将Lwip内核导入到项目中以实现高效的网络通信功能。
- 另外一种方法是通过USB-CDC进行命令行交互（CLI界面），随后就能使用comshell进行登录操作，并支持使用退格键进行输入操作。
- 使用OTA固件进行升级后显得更加先进（逼格提升），成功将mcuboot程序迁移至目标设备中（虽然不确定内存是否足够），但无需担心问题（事情似乎还能继续下去），直接更换芯片即可。
- 命令行解析得到AT指令后，
AT指令解析框架可能会遇到功能较为复杂的挑战，
可以通过启动一个独立的任务来处理这些情况，
这样就不会影响命令行系统继续接收并处理来自串口的新数据了。
该框架负责协调硬件层相关操作的执行，并建议引入一个中间层来隔离软件与硬件代码以避免直接关联。这类似于我们在智能家居项目中采用的posix消息队列机制来实现不同组件之间的独立管理。通过将设备链表的硬件控制与控制链表进行分离管理，在提高系统稳定性的同时确保各环节运行顺畅。
- spi-lcd+gpio-key实现一两个ui画面切换
写进简历
- 不提及其所用的总线及硬件外围设备
- 希望与您就TFT彩屏驱动库相关事宜展开讨论
- CLI-AT协议解析代码框架
- 对于展望部分提到的内容，请您自行标注那些我们有能力自行实现的部分
- 涉及freertos互斥锁、内存池、消息队列以及任务管理方面的内容
- 嘉立创原理图设计部分的内容，请您自行处理
key实现一两个ui画面切换
写进简历
- 采用哪种总线硬件外设的具体情况暂不做详细说明。
- 关于TFT彩屏驱动库的相关信息可进一步探讨。
- 基于CLI-AT协议的代码解析框架设计已初步完成。
- 对于展望中提及的内容，请您自行判断是否具备实现能力并考虑加入。
- 包括互斥锁机制、内存池配置、消息队列优化以及任务管理流程等。
- 嘉立创的原理图设计工作目前尚未完全确定具体方向。