LPC812M101JDH20FP 用在小型联网传感节点

一个读取温度、监测触点并定期上报的室内节点，面对的网络可能很复杂，主控本身的计算任务却可以很小。LPC812M101JDH20FP 适合这种设计的前提，是分工足够清楚：MCU 负责采集与确认测量结果，独立的无线或通信模块负责建立链路。该器件没有集成无线电收发功能。如果把网络认证、大报文和通用通信软件框架一起放进主控，看似简单的节点可能在传感程序写完之前就耗尽存储空间。

NXP 的 LPC81xM 数据手册第 4.7 版列出了 LPC812M101JDH20 基础器件的配置：TSSOP20 封装、16 KB Flash、4 KB SRAM、3 路 USART、2 路 SPI、1 路 I2C、1 个比较器和 18 个 GPIO，Cortex-M0+ 内核最高运行频率为 30 MHz。这些数据对应 DH20；名称相近的 SO20 版本串行外设数量有所不同。本文的电气与引脚判断以 DH20 条目为依据，采购时仍需核对完整订货后缀。下面讨论的是数字环境传感器、干接点输入、串行通信模块和少量本地控制组成的节点。

先把通信模块承担的工作说清楚

首先要决定网络软件运行在哪里。提供精简命令接口的模块，可以让 LPC812 只维护固定长度的测量记录和有限的状态转换。只暴露原始无线数据包的收发器，则可能要求主控处理寻址、重传、安全和协议状态。两者都能连接 USART 或 SPI，但对 Flash、RAM 和响应时间的要求相差很大。选择模块时，除了无线链路参数，还要检查模块向主控提供的软件边界。

报文格式应直接反映这项分工。例如，可以用一个固定 16 字节的有效载荷表示序号、温度、触点状态和有效性标志。16 字节只是设计示例，并非器件限制。传输头由谁添加，凭据由谁管理，哪一端确认数据到达下一个网络节点，都应提前明确。串口返回成功可能只表示模块收到了命令；如果应用需要确认送达，主控状态机就必须区分“模块已接收”和“网络已送达”。

通信暂时不可用时，主控也需要明确的处理规则。用于舒适度监测的节点，保留最新读数和漏报计数可能已经足够；要求每个样本都保留的记录仪，则必须根据最长中断时间配置存储。4 KB SRAM 不适合直接充当长期记录空间。先确定产品是否允许新读数替换尚未发出的旧读数，再决定缓存容量，否则即使预留了较大的区域，也说不清究竟保护了什么信息。

模块启动期间的输出同样属于接口约定。模块可能在主控发送第一条命令之前输出状态信息，也可能在错误时返回比正常应答更长的消息，甚至在 MCU 持续运行时自行重启。应规定最大可接收长度和重新寻找报文边界的方法。主控需要能丢弃不完整或无效消息，然后继续采样，而不能无限等待某条预期应答。如果模块输出的边界无法确定，它就不太适合这个容量有限的主控。

按任务重叠时的占用计算存储

第二项判断是采集任务的规模和数据保留时间。应以包含实际驱动、启动代码、中断处理和通信解析器的发布构建为起点，查看链接后的占用。源文件很短或调试版本能编译成功，都不能说明 Flash 还有多少余量。格式化库、诊断字符串和引导程序可能在应用逻辑尚不复杂时就占用不少空间。16 KB 容量需要容纳交付设备真正运行的代码，同时留出项目约定的修改空间。

RAM 要看同一时刻有哪些对象共存。静态数据、当前调用栈、中断嵌套、串口接收区和待发送样本可能同时存在。单条 16 字节记录看起来很小，但每秒记录一次、连续保留五分钟，就需要 4,800 字节，尚未计算时间信息和软件状态，已经超过 4 KB SRAM。需要这种保留能力时，应减少保存内容、调整上报策略、增加合适的外部存储，或更换容量更大的主控。

对于数字温度传感器和触点输入，固定大小的数据对象比较容易核算。把当前采样与最后一次成功上报的数据分开保存，避免通信应答错误地确认了后来才获得的新数据。时间戳和序号应随所属的测量记录存放。除非预算已经覆盖重复占用，否则不要同时保留每条消息的文本版和二进制版。受长度限制的解析器可以逐字节处理输入，不必等整段长字符串接收完成后才开始工作。

处理时间应围绕任务截止时间分配。传感器需要等待转换完成，并不意味着 CPU 必须一直空转。可以先启动转换，再安排稍后读取，期间处理其他任务。触点变化可能需要多次观察才能确认，输出脉冲则可能有宽度要求。应分别确定这些事件允许的延迟，再选择能在实际中断负载下满足要求的时钟配置，而不是直接把最高频率当作运行方案。

该器件的模拟外设是比较器，并非通用 ADC。比较器可以在规定的输入和参考电压条件下判断阈值，但不能直接给出电桥、电池电压或热敏电阻分压的多位数值。需要数值型模拟测量时，应采用数字输出传感器或外部转换器，并把接口、转换时间和结果存储一并计入预算。如果模拟采集是主要任务，增加外部转换器后，小型 MCU 原本看似简单的方案未必仍然合适。

先保留固定功能，再分配可移动信号

第三项判断是接口和唤醒信号的实际引脚分配。开关矩阵允许把部分串口和定时器信号映射到不同 GPIO，有利于紧凑布板，但它不会增加焊盘数量，也不会让所有引脚具有相同的电气特性。20 个引脚中，电源和地先占两个；调试、复位、外部时钟、比较器输入和唤醒输入还可能继续占用剩余的 18 个位置。数字总线应在这些约束明确之后再安排。

NXP 指定 PIO0_10 和 PIO0_11 为实现完整 I2C 兼容性时使用的真正开漏引脚。需要这种兼容性时，应将传感器总线分配到这两个引脚，并结合总线电压、电容和上升时间选择上拉电阻。把 I2C 功能映射到其他位置，并不自动获得相同的电气保证。传感器断电时也要检查总线状态：除非其接口明确允许，否则不能让上拉或高电平信号经输入端给传感器反向供电。

设备仍需要可靠编程和调试时，应保留 SWDIO 与 SWCLK。默认调试功能便于首次上电；如果过早把它们改作普通应用信号，后续恢复就可能依赖已经正常运行的固件。复位也需要类似安排。小板可以用测试焊盘替代较大的连接器，但焊盘必须具备可重复接触的位置与明确的参考电压。原理图需要说明应用程序损坏后，设备如何再次烧录。

模块的发送、接收、硬件流控、复位以及唤醒或就绪指示，应作为完整接口分配。3 路 USART 不代表可以同时接出三组完整串口，再保留全部其他功能；2 路 SPI 加上片选后同样需要不少引脚。应维护一份对应 TSSOP20 的引脚分配表，并在布线前与初始化代码核对。开关矩阵的价值在于减少交叉布线，同时保住必要的唤醒与恢复通道。

让定时器维持短任务的节奏

多速率定时器、状态可配置定时器和自唤醒定时器分别适合不同的时序任务，但不能由此推断它们在所有低功耗状态下都继续工作。在相应时钟运行时，多速率定时器可以触发周期性软件任务；需要确定边沿或输出波形时，可评估状态可配置定时器。应按手册中的时钟与电源行为分配任务，避免把多个互不相关的延时都堆到忙等待循环中。

触点输入可以说明这种区别。第一个电气边沿只表示观察开始，随后通过定时确认窗口判断触点是否稳定。门状态上报通常可以接受这一确认延迟，而脉冲计数可能需要边沿捕获和有界的处理间隔，才能分辨连续事件。这些要求由应用决定，不能仅凭 30 MHz 内核频率推断。中断处理应足够短，使反复出现的输入事件不会妨碍串口接收。

通信状态机也可以分别规定模块启动、命令应答和报告完成的时限。超时后采取明确动作，同时保持当前测量的有效性含义。看门狗能帮助恢复停滞的软件路径，但如果在一个无关的周期中断里无条件喂狗，就可能掩盖解析器或通信状态机卡住的问题。只有负责推进任务的处理确实完成了预期工作，才应更新看门狗。是否节能仍须通过完整节点实测确认。

模块的长应答可能破坏短测量记录

一种失效来自只按正常事务设计接收解析器。连接不稳定或模块重启时，较长的状态信息恰好与传感器读取重叠。如果接收数据越过缓存边界，或程序直接信任未经检查的长度字段，下一条测量记录就可能被破坏。表面现象可能是离谱的温度、倒退的序号或难以解释的 MCU 复位，容易让排查方向转向传感器，实际起点却在串口接收。

处理方法是在复制之前明确检查长度，对待处理数据设置容量上限，并让解析器在规定时间后放弃不完整报文。模块支持合适的流控时，应保留相关引脚并确认握手时序；不使用流控时，接收服务间隔必须能承受模块允许的最大突发。溢出策略应丢弃通信数据而不改动采样结构，同时累计事件次数，使其能在后面的定时验证中被观察。

测量结果还需要独立的有效性字段。只有传感器事务和必要的确认完成后，数值才可用于报告。发送成功也必须对应实际发送的序号。这样，错误恢复路径才不会把旧数据或只写入一部分的数据当成新测量悄悄发出。

进入休眠后，原定唤醒事件可能失效

另一种失效发生在跨电源状态复用同一套引脚安排时。NXP 将 PIO0_4 指定为深度掉电模式的外部唤醒引脚，并要求需要这条唤醒路径时不要为其分配可移动功能。如果正常运行时把它用于串口或定时器信号，节点就可能进入一种无法由预期触点事件唤醒的状态。重新上电后设备看似正常，却在第一次长时间空闲后停止上报。

休眠过程应从唤醒来源开始设计。需要 PIO0_4 时应保留该引脚，遵守外部上拉条件，同时考虑深度掉电模式对复位引脚的要求。唤醒后的软件上下文应按所选模式的规定处理，不能把更深的掉电状态视为普通睡眠的直接延续。MCU 与模块还要明确谁能够唤醒谁，以及任意一端关闭电源后，状态信号是否仍有意义。

修正办法是按状态设计引脚和电源关系，而不只是延长唤醒脉冲。应将实际引脚配置与进入休眠的代码一起核查，并检查实物上的偏置路径。如果较浅的模式能保留需要的上下文或外设唤醒能力，且能耗符合实测预算，就可以选择它。独立 MCU 的睡眠电流更低，并不能补偿漏掉输入事件，或每次报告都要重新建立模块连接所带来的代价。

用一个带测量记录的上报周期验证选择

可以用可重复的上报周期统一验证采集、通信扰动和休眠恢复。在目标 PCB 上运行发布固件，接入实际传感器与模块，并使用产品要求规定的电源和温度条件。每个周期从选定的空闲状态开始，施加已知触点变化，取得传感读数并请求上报。让模块依次出现正常应答、允许的最大突发和达到应用超时的延迟应答，再加入 MCU 保持供电、模块单独重启的情况。

测量输入事件到样本确认的间隔，以及样本确认到相应通信应答的间隔。记录栈的峰值使用量、接收溢出计数、复位原因、序号连续性和完整周期电流。同一验收记录中还应保留链接映射文件，用于核对固定分配与实测栈需求。逻辑时序记录用于确认信号先后，电流积分用于求得每周期电荷。如果调试设备阻止节点进入目标低功耗状态，测量能耗时需要断开。

比较主控之前先定验收条件。输入到有效样本的最大延迟必须小于产品规定的截止时间；每个上报序号必须对应一条确认有效的读数，主动丢弃的报告必须由约定计数反映。不得出现未检查的越界写入或无法解释的复位。静态 RAM 加实测栈需求，应在 4 KB 内保留项目规定的余量；完整固件应在 16 KB 内留出约定的更新空间。每个要求的唤醒事件都必须使节点回到预期采集状态。

用实际报告间隔把周期电荷换算为平均电流，并计入活跃周期以外的空闲时间。稳压器损耗、传感器待机、上拉通路和无线模块都应包含在内，不能只用 MCU 电流推算电池寿命。通过足够的重复周期和工作条件覆盖前述通信与唤醒情况后，才有依据做选择：完整采集与控制任务能够带余量装入时保留 LPC812；如果存储、模拟采集或协议职责已经超出范围，就换用更大的主控。