news 2026/10/18 1:34:54

MCU功耗从几百mA到几uA:系统级低功耗设计实战指南

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
MCU功耗从几百mA到几uA:系统级低功耗设计实战指南

1. 从几百毫安到几微安:这个数量级跨越到底意味着什么

第一次看到“把MCU功耗从几百mA压到几个uA”这个目标时,很多人的直觉反应是“换个低功耗芯片不就行了”。但真正做过电池供电产品的人都知道,事情远没有这么简单。几百mA通常是MCU在满速运行、外设全开、射频模块工作时的瞬态电流;而几个uA则是它在深度休眠、只保留极少数唤醒源时的静态电流。这两者之间隔着的不是一颗芯片的差距,而是一整套系统级设计思路的转变。

我接触过不少做便携设备、无线传感器节点、穿戴类产品的团队,他们最常遇到的困境是:原理图看起来没问题,代码逻辑也跑得通,但实测待机电流就是下不去,电池续航远远达不到预期。问题往往出在几个容易被忽视的地方——未配置的GPIO引脚、始终使能的内部稳压器、忘记关闭的外设时钟、甚至是PCB上一颗不该有的上拉电阻。这些细节在功能调试阶段完全不会暴露,只有在功耗测试仪上才会现出原形。

这篇文章适合两类人看:一类是正在做低功耗产品、被续航问题困扰的嵌入式开发者;另一类是对MCU功耗优化感兴趣、想建立系统认知的工程师。我会从功耗的构成拆解开始,逐步讲到电源模式的选择逻辑、外设与时钟的精细管理、GPIO的隐藏漏电路径、以及实测中那些“数据手册没写但实际会坑你”的经验。整个过程不依赖特定厂商的芯片,思路是通用的,你可以在任何平台上复现。

需要提前说明的是,低功耗优化是一个“木桶效应”极其明显的领域。你做了九十九件事把电流降下来了,只要有一件事没做对,最终结果可能就是差一个数量级。所以下面的内容,我会尽量把每个环节的“为什么”讲清楚,而不是只给一堆配置代码让你照抄。

2. 先搞清楚电流到底被谁吃掉了:功耗构成的逐项拆解

2.1 动态功耗与静态功耗的分界线

MCU的功耗可以粗略分为两大部分:动态功耗和静态功耗。动态功耗来自晶体管翻转时的充放电,公式是P=CV²f,其中C是负载电容,V是供电电压,f是开关频率。这部分功耗和主频、电压呈正相关,所以降频和降压是最直接的动态功耗优化手段。静态功耗则来自晶体管的漏电流,包括亚阈值漏电、栅氧漏电等,这部分和工艺节点、温度强相关,在深度休眠时占主导。

很多人在优化时只盯着动态功耗,觉得把主频降下来就万事大吉了。但实际上,当MCU进入深度休眠后,动态功耗几乎为零,此时静态功耗才是决定待机时间的关键。一颗采用较老工艺节点的MCU,即使频率降到最低,其漏电流也可能在几十uA级别;而采用先进低功耗工艺的芯片,深度休眠可以做到1uA以下。这就是为什么选型阶段就要把静态功耗作为核心指标来考量。

2.2 数据手册上的典型值、最大值与实测值

数据手册里关于功耗的参数通常有三列:典型值、最大值和测试条件。新手最容易犯的错误是只看典型值,忽略测试条件。比如某款MCU标注深度休眠电流为0.5uA,但仔细看注释会发现,这个值是在25°C、3.0V供电、所有外设时钟关闭、RAM保持不使能的条件下测得的。如果你的应用需要保持RAM数据、工作在3.6V、环境温度可能到60°C,实际电流可能是典型值的五到十倍。

我在实际项目中养成的一个习惯是:拿到新芯片后,先不写任何业务代码,而是烧一个最简单的休眠程序,把所有GPIO配置为模拟输入或最低功耗状态,然后测量不同电源模式下的实际电流。这个“基线功耗”是你后续所有优化的参照点。如果基线本身就偏高,那说明要么芯片选型有问题,要么硬件设计有缺陷,这时候再怎么优化软件都是事倍功半。

2.3 那些不在MCU数据手册里的耗电项

系统功耗不等于MCU功耗。板级上还有很多“隐形消费者”:LDO的静态电流、电平转换芯片的漏电、外部存储器的待机电流、传感器的不工作电流、LED指示灯的分流、甚至PCB表面的微弱漏电。我见过一个案例,团队把MCU休眠电流调到了2uA,但整机待机电流始终在200uA下不去,最后排查发现是一颗用于电平转换的芯片在使能引脚悬空时进入了不确定状态,自身消耗了上百微安。

所以功耗优化必须建立“系统视角”。在动手改代码之前,先拿万用表或功耗分析仪,逐个断开板上的功能模块,测量每个部分的实际耗电。这个步骤看起来笨,但能帮你快速定位大头。很多时候,把一颗LDO换成静态电流更低的型号,效果比在MCU代码里抠半天寄存器还明显。

3. 电源模式的选择逻辑:不是越深越好

3.1 从运行模式到深度休眠的阶梯

绝大多数低功耗MCU都提供多个电源模式,常见的有:运行模式、睡眠模式、停止模式、待机模式、关机模式。不同厂商的命名可能不同,但核心区别在于:哪些时钟还在跑、哪些电源域还在供电、哪些唤醒源还有效、SRAM和寄存器的内容是否保持。

运行模式功耗最高,但响应最快;深度休眠功耗最低,但唤醒后需要重新初始化时钟和外设,唤醒时间也最长。选择哪个模式,取决于你的应用对唤醒延迟、数据保持、唤醒频率的要求。比如一个每秒采集一次温度的传感器节点,如果每次采集只需要几毫秒,那99%以上的时间都应该待在深度休眠里;而一个需要实时响应外部中断的设备,可能只能用到停止模式。

3.2 唤醒时间与功耗的权衡计算

这里有一个很实用的估算方法:假设深度休眠电流为1uA,运行电流为10mA,唤醒并完成一次任务需要5ms。如果每秒唤醒一次,那么平均电流约为10mA×0.005s/1s + 1uA×0.995s/1s ≈ 50uA + 1uA = 51uA。如果改成每十秒唤醒一次,平均电流降到约6uA。可以看到,降低唤醒频率对平均功耗的贡献非常显著。

但唤醒频率不能无限降低,因为要满足应用的数据更新率要求。这时候可以考虑用硬件外设来替代CPU完成部分工作。比如用DMA搬运数据、用硬件比较器触发中断、用RTC定时唤醒,让CPU尽可能少地介入。有些MCU还支持在低功耗模式下让某些外设自主运行,比如低功耗定时器、看门狗、甚至简单的ADC采样,这些都能在CPU休眠时完成工作,进一步压缩运行时间。

3.3 实际项目中如何选定休眠策略

我的经验是:先列出所有必须周期性执行的任务,算出每个任务的最短执行时间和执行频率,然后倒推需要的唤醒间隔。如果任务之间有依赖关系,考虑能否合并到同一个唤醒窗口里完成。比如温度采集和无线发送可以放在同一个唤醒周期里,采集完直接发送,避免两次唤醒。

另外要注意的是,唤醒源的配置也会影响功耗。比如用外部中断唤醒时,如果引脚上一直有抖动信号,MCU会频繁被唤醒,平均功耗反而上升。这时候需要在硬件上加RC滤波,或者在软件上做去抖处理。还有RTC唤醒,有些芯片的RTC在低功耗模式下仍然需要外部32.768kHz晶振运行,如果晶振的负载电容配置不当,起振困难或频率偏移,也会导致功耗异常。

4. 外设与时钟:关掉一切不必要的,但别关错

4.1 时钟树的修剪原则

MCU的时钟系统就像一棵树,从根部的振荡器到各个外设的分支,每一级都可以开关和分频。优化功耗的第一步,就是把这棵树修剪到只剩必需的枝叶。高速晶振、PLL、高速总线时钟,在不需要的时候统统关掉。很多芯片在进入低功耗模式时,硬件会自动切换到一个低速时钟源,但前提是你要在寄存器里配置好。

一个常见的坑是:以为调用了低功耗进入函数就万事大吉,实际上如果某个外设的时钟使能位没有清除,芯片可能无法进入最深的休眠模式,或者进入后功耗仍然偏高。我在调试时习惯在进入休眠前打印或记录所有时钟使能寄存器的状态,确保没有遗漏。有些IDE还提供低功耗检查工具,能在编译时提示哪些外设时钟还开着,这个功能很值得用起来。

4.2 外设的“假关闭”与“真关闭”

关闭外设不是简单地把使能位清零就完事。很多外设即使使能位关闭,如果引脚还配置为复用功能,或者内部有模拟开关未断开,仍然会有漏电流。比如ADC,关闭后如果输入引脚还悬空,可能会因为输入级电路的不确定状态产生额外功耗。正确的做法是:先关闭外设使能,再把相关引脚配置为模拟输入或最低功耗状态,必要时还要断开内部模拟开关。

UART、SPI、I2C这些通信外设也是耗电大户。它们在空闲时如果时钟还在跑,功耗可能达到几百微安。所以在不通信的时候,应该彻底关闭它们的时钟,并把引脚配置为GPIO输出高或输入上拉,避免引脚悬空导致输入级振荡。但要注意,有些芯片的I2C引脚即使外设关闭,如果外部有上拉电阻,引脚被拉高时也可能通过内部保护二极管产生微弱漏电,这个在超低功耗场景下需要特别留意。

4.3 低功耗外设的替代价值

如果你的应用需要持续监测某个信号,比如电池电压、环境光、加速度,可以考虑用硬件外设来替代CPU轮询。比如用低功耗比较器监测电压阈值,用硬件I2C从机响应主机的查询,用DMA在休眠时搬运数据。这些外设的功耗通常远低于CPU唤醒处理。

有些MCU还提供了“低功耗定时器”或“自主外设”的概念,它们可以在CPU休眠时独立运行,按预设的逻辑触发中断或修改输出。比如用低功耗定时器产生PWM驱动LED呼吸灯,CPU全程不用参与。这类外设的配置通常比普通外设复杂一些,需要仔细阅读参考手册中关于低功耗模式下外设行为的章节,但带来的功耗收益非常可观。

5. GPIO的隐藏漏电路径:最容易被忽视的耗电元凶

5.1 悬空引脚为什么会耗电

一个没有配置的GPIO引脚,如果处于浮空输入状态,其输入级的MOS管栅极电压不确定,可能导致上下管同时部分导通,形成从电源到地的直通电流。这个电流可能不大,单个引脚可能只有几微安,但如果板上有十几个悬空引脚,加起来就相当可观了。更糟糕的是,悬空引脚容易受外界电磁干扰,导致输入级频繁翻转,动态功耗也会增加。

正确的做法是:所有未使用的GPIO,要么配置为模拟输入(如果芯片支持),要么配置为输出并固定到一个确定的电平,要么配置为输入并启用内部上拉或下拉。具体选哪种,取决于引脚的外部连接。如果引脚在PCB上直接悬空,配置为模拟输入通常是最省电的;如果引脚外部有上拉电阻,配置为输入上拉可以避免通过外部电阻产生电流。

5.2 上拉/下拉电阻的代价

内部上拉和下拉电阻虽然方便,但它们本身就会消耗电流。一个典型的内置上拉电阻在几十千欧量级,如果引脚被外部拉低,那么3.3V除以50kΩ就是66uA的持续电流。这个数字在毫安级应用里不算什么,但在微安级目标下就是致命的。所以对于需要保持确定电平的引脚,优先考虑用外部低阻值电阻分压,或者用输出模式直接驱动,而不是依赖内部上拉。

外部上拉电阻同样要谨慎。I2C总线的上拉电阻通常在4.7kΩ到10kΩ之间,如果总线在大部分时间处于空闲高电平,那么每个上拉电阻都会持续消耗电流。假设3.3V除以4.7kΩ约等于700uA,两个上拉就是1.4mA。对于电池供电的设备,这个电流在待机时是不可接受的。解决方案是:用MOS管控制上拉电阻的供电,在通信结束后断开上拉;或者降低通信速率,用更大的上拉电阻,牺牲一些上升沿时间来换取更低的静态功耗。

5.3 引脚状态与外部电路的交互

GPIO的功耗不仅取决于自身配置,还和外部电路密切相关。比如一个引脚外部接了一个LED到地,如果你把它配置为输出高,LED就会亮,电流可能几毫安;配置为输出低,LED不亮,但如果你启用了内部上拉,电流就会通过上拉电阻和LED流向地。所以对于驱动LED的引脚,不工作时应该配置为输出低或高阻态,具体取决于LED的接法。

再比如,一个引脚外部接了一个按键到地,如果启用内部上拉,按键按下时会有电流流过;如果配置为浮空输入,按键未按下时引脚悬空,又会有漏电。这种场景下,比较好的做法是:用外部上拉电阻配合输入模式,并且在软件上定期扫描按键,而不是一直使能上拉。或者用专用的按键控制器,它在待机时几乎不耗电,只有按键动作时才唤醒CPU。

6. 实测与调试:从毫安到微安的排查链路

6.1 测量工具的选择与陷阱

工欲善其事,必先利其器。测量微安级电流,普通的万用表往往力不从心,因为它的分流电阻会引入压降,影响MCU的实际工作电压,而且采样速率低,捕捉不到瞬态电流。专业的功耗分析仪或者带高精度电流测量功能的源表是更好的选择,它们通常能提供nA级的分辨率和高速采样。

如果没有专业设备,也可以用一些替代方案。比如在电源路径上串联一个高精度采样电阻,用示波器测量电阻两端的压差,再换算成电流。采样电阻的阻值选择要权衡:太大则压降大,影响MCU工作;太小则信号弱,信噪比差。对于微安级电流,通常需要几千欧到几十千欧的采样电阻,这时候压降可能达到几十毫伏,要确认MCU的最低工作电压是否还能满足。

6.2 分阶段排查:从整机到芯片到模块

排查功耗问题的正确顺序是:先测整机电流,再测MCU供电电流,然后逐个关闭外设和功能模块,观察电流变化。这个过程要像剥洋葱一样,一层一层往里查。我通常会准备一个表格,记录每次修改后的电流值,这样能清晰地看到哪个改动带来了最大的收益,哪个改动没有效果。

一个实用的技巧是:在代码里预留一个“功耗测试模式”,通过串口命令或按键组合进入。在这个模式下,可以单独开启或关闭某个外设、切换电源模式、改变GPIO状态,然后实时读取电流值。这样不用反复烧录程序,排查效率会高很多。这个测试模式的代码在量产版本中可以通过宏定义去掉,不会影响最终固件。

6.3 那些“改了代码但电流没变”的情况

有时候你明明按照手册配置了寄存器,但电流就是降不下来。这时候要怀疑几个方向:一是编译器优化导致某些寄存器写入被省略或重排,需要用volatile关键字或内存屏障来保证顺序;二是芯片的某些状态位需要轮询确认,比如低功耗模式是否真正进入,不能只写寄存器就完事;三是硬件上存在放电路径,比如某个电容在断电后缓慢放电,导致测量值在短时间内偏高。

还有一种情况是调试器的影响。很多调试器在连接目标板时,会通过SWD或JTAG接口向MCU注入电流,或者阻止MCU进入深度休眠。所以在测量低功耗时,一定要断开调试器,让MCU独立运行。如果必须保留调试接口,要确认调试引脚的配置不会引入额外功耗,有些芯片在休眠时会自动禁用调试接口,有些则需要手动配置。

7. 硬件设计中的低功耗细节:原理图阶段就要考虑的事

7.1 电源域划分与开关控制

好的低功耗设计从原理图阶段就开始了。如果板上有多个功能模块,尽量给它们独立的电源域,用MOS管或负载开关控制供电。这样在不需要某个模块时,可以彻底切断它的电源,而不是让它进入休眠。比如传感器、无线模块、显示屏背光,这些都可以用GPIO控制的负载开关来管理。

选择负载开关时,要注意它的静态电流和导通电阻。静态电流要尽可能低,最好在nA级别;导通电阻要小,避免在负载工作时产生过大压降。另外,负载开关的控制引脚本身也可能有漏电,要确保在关闭状态下控制引脚被拉到一个确定的电平,不会让开关处于半导通状态。

7.2 去耦电容与储能电容的取舍

去耦电容对MCU的稳定运行至关重要,但它们也会在电源断开后储存电荷,导致断电后电流不能立即归零。对于需要频繁开关电源的应用,要考虑电容的放电时间。如果放电太慢,可能会影响下一次上电的时序,或者在测量时造成误判。

储能电容则用于在无线发射等瞬态大电流场景下提供峰值电流,避免电源电压跌落。但储能电容越大,上电时的冲击电流也越大,对电源的要求越高。这个需要根据实际负载的电流波形来权衡,通常可以通过示波器观察电源电压的跌落情况来调整电容值。

7.3 PCB布局对漏电流的影响

PCB布局也会影响功耗。比如,高阻抗的模拟信号走线如果靠近数字信号线,容易受到串扰,导致输入级振荡;电源走线如果太细,压降过大,可能导致MCU工作在较低电压下,反而增加电流;地平面分割不当,可能形成地环路,引入噪声。这些因素在毫安级应用中可能不明显,但在微安级目标下就会被放大。

另外,PCB表面的清洁度也很重要。助焊剂残留、灰尘、湿气都可能导致微弱的表面漏电,尤其是在高湿环境下。对于超低功耗产品,建议在PCBA清洗后做三防漆处理,并且在外壳设计上考虑防潮措施。这些看起来是生产环节的事,但如果在设计阶段不考虑,后期整改成本会很高。

8. 软件架构层面的功耗意识:从写第一行代码开始

8.1 事件驱动与轮询的功耗差异

轮询架构下,CPU需要不断检查各个外设的状态,即使没有事件发生也要保持运行,功耗自然高。事件驱动架构则让CPU在无事可做时进入休眠,由中断来唤醒。对于低功耗产品,应该尽可能采用事件驱动,把轮询任务改成中断触发或DMA触发。

但事件驱动也有代价:中断响应需要保存和恢复上下文,如果中断太频繁,上下文切换的开销可能超过轮询。所以需要根据事件的发生频率来权衡。对于高频事件,可以考虑用DMA批量处理;对于低频事件,中断是更好的选择。有些RTOS提供了tickless模式,在空闲时停止系统节拍,进一步降低功耗,这个功能值得研究。

8.2 任务调度与休眠时机的配合

如果使用RTOS,任务调度器的行为会直接影响功耗。默认情况下,调度器会定期产生系统节拍中断,即使没有任务需要运行,CPU也会被唤醒。tickless模式通过动态调整节拍中断的间隔,让CPU在空闲时进入更深的休眠。但tickless模式需要RTOS和硬件定时器的配合,配置起来有一定复杂度。

对于裸机程序,可以在主循环的空闲分支里直接调用低功耗进入函数。但要注意,进入休眠前要检查所有任务是否都已完成,有没有挂起的中断或DMA传输。如果休眠条件判断有误,可能会导致数据丢失或通信超时。我通常会在休眠前设置一个“允许休眠”的标志,只有所有模块都确认可以休眠时才置位,这样比较稳妥。

8.3 固件升级与日志输出的功耗代价

固件升级和日志输出是开发阶段常用的功能,但它们对功耗的影响很大。串口打印会占用CPU时间,阻止休眠;调试接口可能阻止芯片进入深度休眠;固件升级时的Flash擦写电流也远高于正常运行。所以在功耗测试时,一定要关闭这些功能,或者把它们隔离到独立的测试模式中。

量产固件中,日志输出应该被完全移除或重定向到内存缓冲区,只在需要时通过特定命令导出。调试接口可以在生产完成后通过熔丝或选项字节永久禁用,防止被意外唤醒。这些措施不仅能降低功耗,还能提高产品的安全性。

9. 温度、电压与工艺角:那些让功耗翻倍的变量

9.1 温度对漏电流的指数级影响

半导体漏电流对温度非常敏感,通常温度每升高10°C,漏电流大约翻一倍。这意味着在25°C下测得1uA的休眠电流,到了60°C可能变成8uA甚至更多。对于工作在户外或工业环境的产品,必须考虑高温下的功耗预算。如果数据手册只给了25°C的典型值,可以通过芯片厂商提供的功耗估算工具或热特性曲线来推算高温值。

应对温度影响的方法包括:选择漏电流更低的工艺节点、降低工作电压、在高温时主动降低性能或增加休眠深度。有些MCU内置了温度传感器,可以根据温度动态调整功耗策略,这个功能在极端环境下很有用。

9.2 供电电压与功耗的平方关系

动态功耗与供电电压的平方成正比,所以降低电压对省电非常有效。很多低功耗MCU支持宽电压范围,比如1.8V到3.6V。在满足性能和外设要求的前提下,尽量用较低的电压供电。但要注意,降低电压可能会影响Flash读写速度、模拟外设精度和IO电平兼容性,需要逐一确认。

另外,电池供电的设备在电池电量下降时,电压也会降低,这反而有助于省电。但低压时MCU可能无法维持最高主频,需要动态调频。有些电源管理芯片支持动态电压调节,可以根据负载情况实时调整输出电压,这个在高端低功耗设计中很常见。

9.3 工艺角与批次差异

同一款芯片的不同批次之间,由于制造工艺的波动,功耗也可能有差异。数据手册上的最大值就是用来覆盖这些差异的。在做功耗预算时,应该用最大值而不是典型值来计算最坏情况。如果产品对续航有严格要求,可能需要在生产测试环节对每台设备进行功耗筛选,把功耗偏高的个体挑出来。

对于大批量产品,还可以考虑与芯片厂商沟通,选择功耗分布更集中的批次,或者定制低功耗版本。这些商务层面的操作虽然不涉及技术细节,但对最终产品的竞争力有直接影响。

10. 一个完整的优化案例:从300mA到3uA的实操记录

10.1 初始状态与基线测量

曾经有一个无线传感器节点的项目,MCU在运行时的电流约为300mA(包含无线发射),待机电流始终在500uA左右,而目标是把待机电流降到5uA以下。拿到板子后,我先烧了一个最简单的休眠程序,所有外设关闭,GPIO配置为模拟输入,测得基线电流为120uA。这说明硬件本身就有问题,因为芯片手册标称的深度休眠电流是1uA。

接下来我逐个断开板上的模块:断开传感器供电,电流降到80uA;断开无线模块供电,降到50uA;断开调试器,降到30uA。剩下的30uA来自MCU本身和电源电路。检查原理图发现,MCU的复位引脚上有一个10kΩ的外部上拉电阻,而复位引脚内部也有上拉,两个上拉并联导致额外电流。去掉外部上拉后,电流降到15uA。

10.2 软件配置的逐项修正

硬件问题解决后,开始排查软件。发现代码在进入休眠前没有关闭ADC和比较器的时钟,虽然它们没有在工作,但时钟仍在跑。关闭后电流降到8uA。继续检查发现,有一个GPIO配置为输出高,驱动了一个外部MOS管的栅极,而那个MOS管在休眠时应该关闭。把这个GPIO改为输出低后,电流降到4uA。

最后还有2uA的差距。用示波器观察电源纹波,发现有一个周期性的小脉冲,频率约1Hz。排查后发现是RTC的闹钟中断在唤醒CPU,虽然中断服务程序很短,但每次唤醒都会消耗能量。把RTC闹钟间隔从1秒改为10秒后,平均电流降到2.5uA。最终通过优化唤醒后的任务执行时间,把平均电流稳定在3uA左右,达到了目标。

10.3 量产一致性验证与余量设计

实验室达标不代表量产没问题。我们抽了50台样机,在不同温度和电压下测量待机电流,发现分布范围在2.5uA到6uA之间。高温60°C时,部分样机电流上升到8uA。为了确保所有产品都能满足续航要求,我们在软件里增加了温度补偿逻辑:当温度超过45°C时,自动延长休眠间隔,减少唤醒次数。同时把电池容量预算从理论值打了七折,留出足够的余量。

这个案例给我的最大体会是:低功耗优化没有捷径,就是一层一层地剥、一项一项地查。每个环节看起来只贡献了几微安,但加起来就是几百微安的差距。而且很多问题在功能测试阶段完全暴露不出来,只有用高精度电流表长时间监测才能发现。所以如果你正在做低功耗产品,建议尽早把功耗测试纳入日常开发流程,而不是等到最后才来补救。

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/10/18 1:34:47

一条命令核对 app.asar 是否被篡改:REA ASAR 完整性校验完整指南

一条命令核对 app.asar 是否被篡改:REA ASAR 完整性校验完整指南 【免费下载链接】rea Reverse engineer anything with agents, from app behavior down to native binaries. 项目地址: https://gitcode.com/GitHub_Trending/rea2/rea 拿到一份来路不明的 E…

作者头像 李华
网站建设 2026/10/18 1:32:42

从习题到冒险:数学教育游戏Numera Quest的完整开发实录

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

作者头像 李华
网站建设 2026/10/18 1:29:46

ComfyUI-LTXVideo 实战:LTX-2 视频生成与高清上采样完整上手指南

ComfyUI-LTXVideo 实战:LTX-2 视频生成与高清上采样完整上手指南 【免费下载链接】ComfyUI-LTXVideo LTX-Video Support for ComfyUI 项目地址: https://gitcode.com/GitHub_Trending/co/ComfyUI-LTXVideo ComfyUI-LTXVideo 是一套围绕 LTX-2 视频生成模型搭…

作者头像 李华