遇到 ESP32-C2 系统崩溃，最核心的 debug 手段是解析 Backtrace（回溯栈）。

1. 快速定位工具：idf.py monitor (首选)
   如果你是在开发环境下，直接使用 idf.py monitor 烧录并观察串口。当崩溃发生时，它会自动调用底层的 addr2line 工具，将 十六进制地址直接转换成文件名和行号。
2. menuconfig 中开启gdb调试(量产不要开启,否则会卡在gdb界面要手动重启)
   开启 GDB Stub：在 menuconfig 中将 Component config -> ESP System Settings -> Panic handler behaviour 改为 Invoke GDBStub。崩溃时会自动进入 GDB 模式，你可以输入 bt 查看完整的调用栈。
3. 内存检测：在 menuconfig 中开启 Heap sentinel (堆哨兵) 或 Lightweight scan，排查是否有内存越界。
   3.1 开启 Heap Sentinel (堆哨兵)
   堆哨兵会在分配的内存块前后加入“魔数”，如果代码写越界了，释放内存时会触发报错。
   路径： Component config -> Heap memory debugging -> Heap corruption detection
   设置项： 选择 Comprehensive (综合模式) 或 Light impact (轻量模式)。
   Comprehensive：每次 malloc/free 都会检查，性能损耗稍大，但最精准。
   Light impact：仅在某些特定操作下检查，性能损耗小。
   3.2. 开启 Heap Trace (内存追踪)
   如果你怀疑有内存泄漏或者异常分配，可以开启追踪。
   路径： Component config -> Heap memory debugging -> Enable heap tracing
   注意： 开启后需在代码中调用 heap_trace_start() 才会真正开始记录。
   3.3 开启 Stack Overflow Check (栈溢出检测)
   针对任务（Task）栈空间的监控，防止函数嵌套太深导致崩溃。
   路径： Component config -> ESP System Settings -> Check for stack overflow
   设置项： 建议选择 Internal watchdog
   3.4 Canary bytes
   Canary bytes：在栈末尾放置特殊字节，任务切换时检查，最常用。
   选择路径: Component config->FreeRTOS->Kernel->Check for stack overflow (在此處選擇 Check using canary bytes)

YD/T2583.14-2013;GB 4943.1-2022

刚才想到这个问题，突然有一个洞见。
企业的核心竞争力就是对客户需求的深刻理解和独特实现。
微软的纳德拉说，未来企业要有竞争力，就必须将企业的独特内在知识沉淀为AI大模型的独特能力。这里说到了AI数据主权。只有自己的模型沉淀了自己的企业能力，才可以说是有自己的数据主权。
我刚刚有一个洞察，这么多年居然都没有想到的一件事情。一个人对需求的理解，是与其他人不同的。我很惊讶，我到现在居然才深刻认识到这一点。我曾经以为，如果大家看到了同一个需求，经过正确的推理，一定能获得相同的理解。就好像大家看到一个数学题，经过相同的推理，一定能获得同一个答案一样。然而现实却完全不是这回事。如果还用数学题来比喻。那一个需求其实是多道数学题，而且每道数学题可能都有多种不同的解。然后现实是一个有限资源的决策。需要在有限的资源下，决定到底要解决哪道数学题，用哪种方式，获得哪种解才是最高效的。同样的，由于每个人都是一个有限资源体，他所能发现的，要解决的问题，也是和其他人不同的。再加上每个人的背景、经验和能力不同，他看待每一道题的可解性上面也有很大不同。同样对于同一道数学题，可以用代数、几何等等不同的方式来去解决。这就会造成最终解题思路和形态的不同。另外一些数学题可能只能用专用的知识，比如微积分来解决。而不懂微积分的人可能认为这道题是无解的，或者说是给出一种特别复杂的、极耗资源的方案。
所谓对客户需求的深刻理解，就是找出所有的数学题，了解哪些数学题需要通过哪些知识可以最高效地解决，并且用最高效的路径实现。企业为客户提供的价值，就是客户旧的解决方案所需代价与企业提供的新的解决方案所需代价之间的差额。企业的利润就是最高效路径的耗费成本与收到客户的新方案费用之间的差额。
这一切当然都可以转化为成本、利润与销售额的简单算式。但是成本加利润等于销售额的算式里面，掩盖了不同公司成本为何会不同，销售额和利润为何不同的原因。归根结底就是能不能提供新的解题思路。
所谓一个行业是否成熟，就是这个行业的所有企业是否最终都不约而同地采用了相同的、最高效的解题思路。这就解释了一个行业的发展周期。早期阶段，只有少数公司能发现少量的解题思路。行业快速发展阶段，有众多公司发现了众多不同的新的思路。行业成熟期，解题思路变得更加的单一、高效、节约资源，企业也逐渐淘汰，向少数头部集中。衰退期是行业的单一思路被新的知识所提供的新思路替代，或者是原本的算术题，也就是需求消失了。
一个需求可能是一个树状结构。子需求是父需求的解决方案。从这个角度来说，需求（问题）和解决方案的定义是相对的。一个需求，它到底是需求还是方案，在需求树中，就看它是相对于父需求，还是相对于子需求来说了。
从业者经常会混淆需求、问题和解决方案这三个名词。为了明确，我需要对这三名词进行重新的关系定义。需求既是问题，也是解决方案，相对于其父需求，它就是解决方案。相对于其子需求，它就是问题。所有的需求向前追溯，也许都有一个根需求。那这个根需求可以称之为终极问题。
举个例子，人对计算的需求自古至今一直是有的。其解决方案有算筹、有算盘、有计算机。那如何制造算筹、算盘和计算机？这又变成了一个新的问题。算筹的解决方案可能有竹签、有象牙、有对应的不同工艺。计算机，那就更复杂了，解决方案包括硬件和软件，如何实现硬件和软件？这两个问题又有极其复杂多变的子需求。计算的需求往计算机这个子需求上面走，就会形成一个极其庞大、枝繁叶茂的树。需求向后生长，最终的需求可以说是最终交付的解决方案。
从计算机的这个需求上来说，软件的需求为什么最终会超过硬件？这是因为软件的这棵树可以开得更加枝繁叶茂。从软件上实现计算，有不同的编程语言，有Excel、有前端、后端、数据库…简直无法穷尽呢。
现在AI又带来了一个新需求。它既能成为现在计算这个终极问题的新方案，又提出了更多该如何实现AI的新问题。
一个解决方案的成本并不是固定不变的。它会随着整个环境和时代的不同而改变。原因是一个解决方案需要依赖的上下游供应链关系是不同的。在不同的环境和时代中，是否能提供这个上下游供应关系，就不一定了。或者简单来说，解决方案是最终产品，需要供应链来解决。供应链要能提供解决方案所需要的原材料，解决方案才可以最终实现。在不同的时期，能否提供原材料的可能性不同，能否提供这些原材料的能力也不同，所以其价格也不同。这就是所谓一个解决方案的供应链是否成熟的问题。为什么早20年或者更早的时间就有很多企业觉得电动车是未来，并且付诸于实践并解决其问题。然而并不能成功的原因，就是因为在那个时候，其上游供应链并不能提供成熟的、丰富的、有价格竞争力的原材料。
当一个需求的解决从一种解决方案往一种新的解决方案上面迁移的时候，旧的解决方案的上游供应链也会被逐渐抛弃，从而带来旧方案的涨价。这种涨价进一步推进了旧方案走向衰亡。

Blender做渲染和动画设计的时候有很多要求, 在设计产品用于3D打印的时候,却似乎减少了很多要求.
比如: 不能用N-gon(超过5个顶点的多边形, 默认生成圆柱体的顶面底面都是N-gon), 不要内藏面, 但是用于3D打印似乎都不重要了. 即便是有N-gon, 有内藏面, 以bambu studio为例, 都能正确形成打印路径, 不会把内藏面打印出来.
要能3D打印, 物体必须是封闭的. 如果不封闭, 则这个物体即便可以在bambu studio中显示也无法打印出来. 不封闭的物体A靠在封闭物体B上, 视觉上封闭了A, 但A仍然不能被打印.
另外,STL文件导出后, 在Windows 3D builder中和bambu中都是把米变为了毫米. 在3D builder中, 还可以切换单位, 但是默认是毫米. 我以为是blender导出过程中丢失了单位, 但是将此文件重新导入blender,单位仍然是米. 查询了stl的定义, 原来这个文件本身是不带有单位的.

很久没有动ESP32和IDF这套东西了，这里记录一下过程

1. 环境安装。可以使用乐心最新推出的EIM ESPIDF环境安装工具来安装，选择版本5.4.3。不要用国内的仓库来下载，还是要用GitHub。Python仓库可以用国内镜像。下载完毕后在EIM中打开5.4.3的环境。这一步必须非常小心，因为可能会由于网络的问题导致部分IDF的仓库或者说子模块没有下载完整，最终导致编译失败。
2. 首先从GitHub上下载DOIT_AI，并解压缩，而不是通过git clone命令来克隆它。因为项目作者不小心上传了一些NTFS的流文件，其中含有冒号，会导致git clone的时候这些文件无法在Windows上创建，进而导致整个目录中的文件全部创建失败而消失不见。
3. 进入 DOIT_AI目录，运行：

   idf.py set-target esp32c2
   idf.py menuconfig

   配置board为doit-ai-01， 保存退出。

4. 使用idf.py build进行编译。
5. 使用idf.py merge-bin合并为一个从0x0开始的bin文件merged-binary.bin

有时候在远程仓库的页面上看到文件内容都有, 也不存在分支不对的问题, 然而windows下使用git clone之后进入目录却是空的.
一种情况是远程仓库中存在部分文件以:Zone.Identifier结尾。因为文件中含有:, 无法在windows中正常创建文件, 导致所有的文件都没有被创建.
这类文件通常是因为在 Windows 系统下从互联网下载了文件。
机制：Windows 的“附件管理器”会自动在下载的文件中添加一个名为 :Zone.Identifier 的隐藏流。
内容：该流记录了文件的来源区域（例如 ZoneId=3 代表 Internet）。这也就是为什么运行下载的 .exe 时会提示“此文件来自其他计算机，可能被锁定”的原因。
为何进入 Git：如果在 Linux 或 macOS 环境下将这些带有 NTFS 流属性的文件提交到了 Git 仓库，而这些系统并不强制处理 NTFS 特性，它们会被当作普通文件（或文件名的一部分）存储 .
我觉得有可能是在windows的linux子系统中做了git commit导致的.
解决方式: 不要通过git clone, 改用下载zip包的方式, 通过7-zip解压缩后, 会发现7-zip自动将:转换成了., 如果不解压缩直接查看压缩文件, 还能看到这些文件名中含有:

今天在思考常规的产品塑胶外壳，开模贵、周期长的这件事情。由此又想到之前各种专家总是提，未来的产品需要DIY个性化。那按照这种开模的思路，那肯定是不可能的。并且一般的产品如果要盈利，或者说至少把模具费赚出来的话，至少得2000个以上吧。开模的话，一套模具几万，一个产品会有好几套模具。那随随便便都会有十几万甚至几十万的一个费用。除非你做非常小的产品，并且它的塑胶件数非常少。我们为了减少开模的费用，曾经甚至用了铝型材来做。铝型材的模具费用很低，一两千或两三千块钱就可以，但是材料费用比较高。
除了塑胶模具之外，还能做出塑胶壳的这种质感的，一个就是3D打印，另外一个就是硅胶模具。硅胶模具比塑胶模具的价格便宜，但据说能制作的塑胶成品大概只有几百套而已，几百套之后模具就变形严重，不太好去做了。
3D打印需要预先设计好产品，设计这一步还是略有门槛，可能专业的需要考虑用Solidworks之类的产品3D建模设计软件来去做。免费的就只有Blender和FreeCAD这两个产品。我自己没有3D打印机，需要外发打印，中间也会需要有个好几天的来回的时间。所以门槛还是略高一些的。一方面是软件的学习门槛，另外一方面就是这个时间，以及3D打印的费用或者是软件购买费用。
今天看到一个产品还是挺惊讶的，叫做拼豆。就是把很小的圆柱形管子拼在一起，然后用熨斗压实，就成一个连接在一起的片材。从视频上看，这个东西似乎有点软，并且不太好去做立体造型。如果有办法去拼上加强筋，或者做一些立体造型，可能就更加有趣了。假如说还能拼上去螺丝柱，或者拼上去卡扣，那真的就可以做一些产品了。
其他一些产品，包括热塑片，也是主要做平面的产品。超轻粘土，做出来东西比较脆弱，不好做结构件。3D打印笔不好做外观光滑的东西，而且形状比较难控制。软陶、石塑粘土、树脂粘土，这些都需要一定的塑型雕刻能力。其中软陶的质感可能最好，通过在烤箱加热，最后质感会比较接近陶瓷表面。石塑粘土、树脂粘土和超轻粘土，都是需要自然条件下经过一两天的风干。
回到拼豆上面。拼豆之所以只能做平面的，大概是因为它需要用熨斗正反面压平。如果有高温器件可以给它压成弧面，那应该也可以做弧形的产品。

Windows 10电脑上出现了用鼠标选择任意文本就会自动复制的问题。这个很头痛，因为我很习惯选择后进行一些其他操作，而不是复制。尤其是选择后直接粘贴，预期的结果是用剪切板的内容覆盖掉选择的内容，然而这个神秘的自动复制，让这个操作就失效了。并且是在任意窗口都会这样。
先是让AI写了一个自动的Python脚本去检测按键输入。很顺利的检测到了，在鼠标选择文本之后，会有一个虚拟按键输入，左Ctrl加Insert。
接下来就要去找到底是哪个程序输入的，这个过程千难万阻，最终也没有成功。依次尝试了Process Monitor、Spy++、API Monitor、Inside clipboard等等这些方法。但是由于Windows它不会记录虚拟按键发送者的名称，所以找起来真是大海捞针。Spy++ 和API Monitor可能更接近于成功，但是这两者都只能监控一个控件或者一个窗口，无法做全系统的监控，这也可以理解，因为全系统的这种消息实在是太多了。
最后想到一个办法，是不是可以拦截左Ctrl加Insert键，让它不再复制？发现微软官方的PowerToys就可以做到。在它的键盘管理器里面可以去重新映射快捷键。将左Ctrl加Insert键映射为Disable就解决了。
郁闷的是，一直不知道这个在背后捣鬼的程序是谁。AI都猜测是某个类似于画词翻译的程序。

使用的qiniu服务器，也就是小智ESP32 Server开源服务器。对于意图识别，似乎必须是从用户端的话语中判断的，无法从系统提示词中进行意图识别。也无法进行条件判断式的意图识别。举例如下。
如果在系统提示词中写入满足一定的条件，便进行MCP调用的时候，那MCP永远不会调用；但是如果系统提示词中写入满足一定的条件，大模型进行特定的回复的时候，却是可以进行的。
在用户下达的指令中，提出满足一定的条件去调用MCP工具的时候，大模型听到这句话不等这个条件达成，便立即进行了调用。
因此我估计，这是属于MCP Client端也就是服务器端实现的问题，而不完全是大模型本身的问题。可能需要看一下服务器端对MCP Client实现的源码。

小程序开发时 wx.showActionSheet 这个函数， 在点击对应选项后，有时候ActionSheet不会自动隐藏，是什么原因，如何改进为必然自动隐藏?
在小程序开发中，wx.showActionSheet 通常在点击选项后由系统自动收起。如果出现不自动隐藏的情况，通常是由于逻辑阻塞或系统/版本差异导致的。

1. 常见原因分析
   回调函数内存在阻塞逻辑：在 success 回调中执行了耗时过长的同步操作（如复杂的循环计算），导致 UI 线程响应滞后。
   并发冲突：在 success 回调中立即触发了另一个模态框（如 wx.showModal 或 wx.showLoading），部分 Android 版本下，新的 UI 层可能会干扰 ActionSheet 的正常销毁流程。
   Android 版本特异性：在旧版 Android（6.7.2 以下）中，点击背景蒙层或取消按钮的行为与 iOS 不同，若逻辑依赖于 fail 回调执行清理，可能会出现异常。
   itemList 溢出或限制：如果 itemList 长度超过 6 个，或者在点击后立即执行了页面跳转/重载，可能导致组件状态未能正确更新.

我的小程序中是因为立即调用了showModal导致的, modal显示后actionSheet没有消失反而叠加在其上. 并且只有第一次会出现, 第二次就不再出现了(我猜测可能showActionSheet所有已经加载到了内存中).
需要使用延时的方法来解决(100ms足够), 如果是用await调用wx.showActionSheet, 也需要在调用后进行延时再处理其他逻辑.

wx.showActionSheet({
  itemList: ['选项A', '选项B'],
  success(res) {
    // 先让 ActionSheet 消失，再处理逻辑
    setTimeout(() => {
      // 这里放置业务代码，如打开 Loading 或 跳转
      console.log('点击了第', res.tapIndex, '项');
    }, 100); 
  }
});

首先要把mcp库升级到最新的版本, 旧版本是不支持的.

pip install --upgrade mcp

关键代码:

from mcp.server.fastmcp import FastMCP, Context

@mcp.tool()
def change_agent(apidataId: str, roleName: str, ctx: Context) -> object:
    pprint(ctx.request_context.request.headers)

这会打印一个headers对象, 例如:

({'host': 'mcpserver.url.cn:port', 'accept': '*/*', 'accept-encoding': 'gzip, deflate', 'connection': 'keep-alive', 'user-agent': 'python-httpx/0.27.2', 'x-linx-device-id': 'xx:xx:xx:xx:xx:xx', 'x-linx-agent-id': 'xxxxxxxxxxxxxxxxxx', 'content-length': '176', 'content-type': 'application/json'})

在小程序中是不能借助客户端能力实现MCP inspector的, 因为要和服务器建立websocket连接, 而小程序建立socket连接或者http请求都要在后台添加url, 并且必须是ssl的形式(https/wss), 这样就无法对任意MCP服务进行inspect. 如果要对任意MCP服务进行inspect, 只能通过云服务的方式, 并且不能是小程序云函数, 因为小程序云函数不支持sse和WebSocket.
如果已经在云端建立了MCP inspector服务, 那么似乎是否一定是小程序载体就没有必要了, web似乎是更好的载体.

python方案 https://github.com/pupil-labs/pupil
浏览器js方案 https://github.com/brownhci/WebGazer 测试了下,需要校准,并且在比较低分辨率的摄像头上似乎效果很不准确.

AI大模型方案 moondream gaze detection https://moondream.ai/ 2B参数做到相对精准的检测. 今年年初发布的开源模型. 油管上有个视频介绍.但速度太慢了, 22秒的视频在RTX A6000上处理的12分钟.
另一个方案gaze-lle https://github.com/fkryan/gazelle 似乎没有找到视频介绍, 也不知道速度如何. https://huggingface.co/spaces/fffiloni/Gaze-LLE 我在huggingface上运行一张图片的时间要30多秒.

研究这个有个感悟, 就是旧方案解决的不是很好的领域, 使用AI可以得到更好的解决, 然而AI需要大量训练且速度更慢能耗与资源消耗高几个数量级. 已眼动跟踪来说, 旧方案如webgazer使用浏览器js即可运行, 而AI方案要A6000才能运行且效率极低.

对比来说, Tobii的方案能实现虚拟键盘打字确实就很厉害了, 虚拟键盘每行有十几个按键都能准确触发确实很了不起.而七鑫易维也能实现每行十多个按键的识别输入也很厉害. 按豆包的反馈, 高精度方案使用瞳孔角膜反射法, 并使用近红外光辅助摄像头捕捉普洱钦点. 还有高成本方案虹膜追踪, 低成本方案使用巩膜追踪法. 但是, 豆包这个成本说法不可信, 因为红外光和摄像头的成本是不高的, 如果算法在普通计算机上能运行, 那么运行成本也是不高的.

在尝试webgazer后发现其精度太差, 而核心其实是应该更近的拍摄眼睛, 因此想到VR/AR方案中也有眼动跟踪的需求, 于是又搜索到了这个方案:
EyeTrackVR https://github.com/EyeTrackVR/EyeTrackVR , 这个方案还有一个完善的文档网站 https://docs.eyetrackvr.dev/
接着在油管搜索 EyeTrack, 又发现两个项目, 这两个项目不用嵌入VR眼镜, 是独立的眼部跟踪:
基于py的: https://github.com/JEOresearch/EyeTracker
基于C++的: https://github.com/YutaItoh/3D-Eye-Tracker

到这儿就颇有些感悟, 眼动跟踪这个看起来有些高端昂贵的产品(比如tobii要一两万, 其他的价格也不低), 从第一性原理出发(SD分辨率摄像头+红外光), 硬件成本似乎并不高, 剩下的其实只是软件算法而已. 另一个感悟是, 摄像头能产生的价值似乎远比想象的还要高得多.

一般国内物联网平台多选用腾讯云 IOT Explorer/阿里云/涂鸦等, 好处是稳定操心少, 问题是有起订数量(1~10k), 沟通成本和初期投入成本略高.
Home Assistant, 主打本地局域网部署
Fastbee, 国内产品, 个人使用免费但是商用要收费
dgiot, 国内产品, Apache2.0证书,可商用, 5.1k star
thingsboard https://github.com/thingsboard/thingsboard, 国外产品, apache2.0证书, 20.6k star