Juanyun Thermal Management Hardware and Firmware Archive卷云科技热管理硬件与固件开发档案

Why These Materials Sit Together为什么放在一起

Juanyun 的这组材料很难切成一个整齐的“项目包”。外机板、底座固件、DHT11 / AM2302 小板、螺线管阀门与风扇驱动、DIY 压风式散热原型、硬件 SOP，看起来大小不一，实际一直在反复碰同几件事：电源怎么进系统，信号落在哪块板，固件多久读一次传感器，执行器接口怎么留证据，文件以后还能不能读懂。

The Juanyun materials do not fit neatly into one board-firmware-demo package. ACUnit boards, base-unit firmware, the DHT11 / AM2302 breakout, solenoid and fan-driver fragments, the DIY pressure-flow cooling prototype, and the hardware SOP all keep returning to the same questions: how power enters the system, where each signal belongs, how often firmware should touch a sensor, how actuator interfaces should be recorded, and whether the files will still make sense later.

So this page works as a work trail for the thermal-management direction. Some branches are large, some are small. Together they show the part of hardware work that is easy to miss in a polished screenshot: interfaces, timing, version records, and the habit of explaining a folder before it turns into archaeology.

所以这页更像热管理方向的一条工作线索。有的支线很大，有的支线很小，放在一起能看到漂亮截图之外更容易被忽略的东西：接口、节拍、版本记录，以及在目录变成文件考古之前把它解释清楚的习惯。

Interface Pressure接口压力

The ACUnit work is the heaviest part of the page. A thermal-control board has to meet compressors, fans, pressure transmitters, NTC and DHT sensors, an electronic expansion valve, OLED, encoder input, keys, and reserved communication modules. The pressure comes from the way these signals share power, space, connectors, and debugging time.

外机控制平台是这页里最重的一条。一个热管理控制板要接压缩机、风机、压力变送器、NTC 和 DHT 传感器、电子膨胀阀、OLED、编码器、按键，还要预留通信模块。压力来自这些信号要共享电源、空间、连接器和调试时间。

V2.0 reads like a stage where the main links were being collected. V2.1 is clearer because it splits the system into a main board, power board, and interaction board. That split gives power distribution, user interaction, and MCU-side signals their own places, which makes later fault tracing less dependent on guessing.

V2.0 更像是在把主要链路先收拢起来。到了 V2.1，拆成主控板、分电板、交互板以后，结构清楚很多。电源分配、用户交互和 MCU 周围信号各自有位置，后面排查问题时就少一点靠猜。

Board Evidence板卡证据

This page keeps reviewed diagrams and renders for the current-product ACUnit direction. Raw production packages and editable design packages stay outside the website. The point is to explain the work from structure and constraints: the V2.1 system block diagram, main/power/interaction board renders, pressure-transmitter parameters, and PWM-fan parameters all show how external devices shaped both hardware and firmware.

这页保留外机方向已经审核过的框图和板卡渲染。原始生产包和可编辑设计包留在网站之外。页面要讲的是结构和约束：V2.1 系统框图、主控/分电/交互板渲染、压力变送器参数、PWM 风机参数，都能说明外部器件怎样反过来影响硬件和固件。

Firmware Rhythm固件节拍

The firmware side has a very similar problem. CubeMX can create the STM32 project quickly, but compressor logic, FG speed sensing, electronic expansion valve stepping, NTC sampling, DHT22 reads, OLED refresh, encoder input, and keys all need different update rhythms. A single main loop becomes hard to read once every function is squeezed into it.

固件这边遇到的是类似问题。CubeMX 很快能生成 STM32 工程，但压缩机逻辑、FG 测速、电子膨胀阀步进、NTC 采样、DHT22 读取、OLED 刷新、编码器和按键都有不同节拍。所有功能挤进一个主循环以后，代码很快就不好读。

The external-unit firmware notes care about Core, App, Service, BSP_drivers, CMake, VSCode, OpenOCD, release notes, and pin records because those details reduce future search time. A 1 ms valve task, a 10 ms input task, a 100 ms NTC update, a 500 ms OLED refresh, and a 2000 ms DHT22 read should stay visible as separate rhythms.

外机固件笔记会写 Core、App、Service、BSP_drivers，也会写 CMake、VSCode、OpenOCD、release notes 和引脚记录，因为这些细节能减少以后翻代码的时间。1 ms 阀门步进、10 ms 输入扫描、100 ms NTC 更新、500 ms OLED 刷新、2000 ms DHT22 读取，都应该作为不同节拍被看见。

The BaseUnit firmware is smaller and feels closer to a complete small device. It reads ambient and outlet temperature/humidity, checks position, controls a fan, displays state on OLED, reports over Bluetooth, and stores settings in Flash. The Flash part matters because a device that forgets every setting after power loss quickly feels rough in repeated use.

底座板固件规模小一些，反而更像一个完整小设备。它要读环境和出风口温湿度，要判断设备在不在位，要控制风扇，要在 OLED 上显示状态，还要通过蓝牙上报，并且用 Flash 记住设置。Flash 这部分很关键，因为设备断电以后什么都忘，反复使用时会显得很粗糙。

Small Boards And Actuators小板和执行器

The DHT11 / AM2302 breakout is tiny: 30 mm x 14 mm, 3V3 / DATA / GND, one single-wire sensor interface. It still deserves a note because small boards often expose real completion quality. Pull-up, decoupling, optional damping, connector choice, package size, M2 positioning, 3.3 V power, power-on wait, sampling interval, and MCU verification all decide whether the board behaves cleanly.

DHT11 / AM2302 温湿度小板很小：30 mm x 14 mm，3V3 / DATA / GND，一个单总线传感器接口。它仍然值得写，因为小板很能看出事情有没有做完整。上拉、去耦、可选阻尼、连接器、封装、M2 定位孔、3.3 V 供电、上电等待、采样间隔和 MCU 验证，都会影响这块板能不能稳定工作。

The actuator and fan-drive branch is thinner, but it keeps useful clues: STM32F103 solenoid-valve source excerpts, IOC configuration, OLED and EC11 references, ULN2003 material, and a small BLDC quiet-fan board with BOM / EasyEDA files. The EEV driver-board render and schematic make the actuator side easier to read: MCU signal in, ULN2003A-centered low-side drive in the middle, valve connector out, and status LEDs around it.

执行器和风扇驱动这条支线材料薄一些，但留下了有用线索：STM32F103 螺线管阀门源码摘录、IOC 配置、OLED 和 EC11 参考、ULN2003 资料，以及一个带 BOM / EasyEDA 文件的小型 BLDC 静音风扇板。EEV 小板的 3D 渲染和电路图让执行器这件事更容易读：MCU 信号进来，中间是以 ULN2003A 为中心的低侧驱动，负载侧接阀，旁边有状态指示灯。

DIY Cooling PrototypeDIY 散热原型

The DIY pressure-flow cooling prototype is farther from the ACUnit product line, but it asks the same question in a rougher form: how do airflow structure, power, control, and a small user-facing demo connect?

DIY 压风式散热器离外机板产品线更远，但它用更粗糙的形式问了同一个问题：风道结构、电源、控制和一个能给人看的 demo 到底怎么接起来。

This branch has 3D-printed parts, an ESP32 / STM32 control direction, a desktop demo, PCB output, slicing files, and early-folder mess. The STM32-version PCB render and schematic are the closest pieces to the hardware story. Once USB-C, DC input, DCDC, switches, headers, and an MCU footprint appear on one board, the airflow prototype starts to look like a small control system.

这条线有 3D 打印件、ESP32 / STM32 控制方向、桌面端 demo、PCB 输出、切片文件，也有早期目录里很常见的混乱。STM32 版 PCB 渲染和原理图最接近硬件主线。USB-C、DC 输入、DCDC、按键、排针和主控封装都出现在同一块板上以后，这个散热原型就开始像一个小控制系统。

SOP And RecordsSOP 和记录

The self-authored hardware SOP is process material, and it may be the most useful artifact for future work. Hardware projects leave requirements, schematic versions, PCB versions, BOM, Gerber, pick-and-place, test notes, firmware pins, datasheets, photos, and several almost-identical folders. Naming, checking, exporting, and explaining are boring until a bad folder costs half a day.

自写硬件 SOP 属于流程材料，也可能是对以后最有用的一份。硬件项目会留下需求、原理图版本、PCB 版本、BOM、Gerber、贴片坐标、测试记录、固件引脚、数据手册、照片，还有几个看起来差不多的文件夹。命名、检查、导出和解释平时很无聊，直到一个坏目录让人浪费半天。

That is why the SOP sits beside the board and firmware notes. It records questions that every branch eventually meets: which version changed, which file is manufacturing output, which screenshot is only a reference, and which debug note explains an interface choice.

所以 SOP 会和板卡、固件笔记放在一起。它记录的是每条支线迟早会遇到的问题：版本之间改了什么，哪个文件才是生产输出，哪个截图只是参考，哪条调试记录说明了为什么选这个接口。

What Still Needs Work还要补什么

The strongest missing layer is still bring-up evidence. Board renders and planning PDFs explain intent; debugging logs explain reality. The next useful records would be power-on checks, interface tests, DHT22 failure handling, OpenOCD flashing screenshots, OLED refresh before/after optimization, electronic-expansion-valve stepping behavior, and physical photos that show how the boards were actually connected.

这页最缺的还是 bring-up 证据。板卡渲染和任务 PDF 能说明意图，调试日志才说明现实。后面最值得补的是上电检查、接口测试、DHT22 读取失败处理、OpenOCD 烧录截图、OLED 刷新优化前后、电子膨胀阀步进表现，以及能看出板子实际怎么接的实物照片。

Looking back, this Juanyun work is useful because it leaves more than a single "it ran" result. It keeps returning to the same practical questions: how power is split, how interfaces are placed, how firmware timing is kept readable, why small boards need clear notes, and how files can help a later person understand the work.

现在回头看，这组卷云材料有用，是因为它留下的不止一句“能跑”。它反复回到几个很实际的问题：电源怎么分，接口怎么放，固件节拍怎么保持可读，小板为什么也要写清楚，文件怎么帮助后来的人重新理解这件事。