谢绝(无视)留言与私信

元件的占位面积有高度的，是有用的，用于DRC检查。如果将元件占位面积的高度改为0，和实际不符，是有害的。但是默认3D预览板子时，如果没有3D模型的stepfile, 会将元件显示为黑立方体，实际上这个黑立方体就是代表元件(占位面积和元件高度)。没查到资料，怎么在3D预览时去掉这个占地面积的黑立方体。因为黑立方体将元件顶面的焊盘挡住了，如果要检查焊盘是否被一面盖油，就看不到效果。记得不用去动元件的封装库，好像3D模型预览就有不现实元件占位面积的选项。

本地的原理图库以前都在正常用。重装了cadence SPB 17.4, 重装完的SPB17.4中是没有自己的原理图库的。想将自己正常用的原理图库，配置进新安装的SPB17.4。

有的程序比较大，操作比较复杂，从界面上看，半天不动地方。e.g. 用AleegoCrackMasterV3.2.6强制卸载CadenceSPB17.4时，调用出来的Cadence程序卸载时，要准备好久才开始卸载，好慢。这时，如果不确定是否真的无响应，需要强行杀掉该无响应的程序?可以用工具先看一下，这个程序干活没有？如果一点活都没干，真的挂住了，那就杀掉他。

今天从备件中翻出来一个J-Link EDU mini,想做实验。10pin的接口好像是1.27mm 5x2P.用电子显微镜，配合钢尺和J-Link EDU mini的接口摆在一起，大概是1.27mm的引脚间距。正好有先见之明，已经买来1.27mm10pin接口转2.54mm20pin接口的转接块。J-Link EDU mini 的板子上，并没有引脚功能的丝印。在网上倒是找到了其他同学写的笔记，有J-Link EDU mini的接口引脚定义。

Smoothieware工程用的bootloader工程为LPC17xx-DFU-Bootloader.学习一下，看有没有机会来改进一下. e.g. 将MCU模拟U盘加进去，是否能在16KB的代码空间装下。

在看一个开源的固件工程，用makefile编译的.工程的历史提交次数不多，20~30次。就像从作者首次提交看起。因为只是学习，就将历史版本用sourcetree直接迁出，使版本头悬空。很奇怪的是，makefile编译总是报错.开始觉得，可能是作者开始提交时，makefile有bug，或者代码有bug.于是逐步想最新的提交点迁出，还是报错。最后查了makefile最新的修改点，迁出后编译还是报错。这时，开始怀疑是环境问题，或者makefile语法有错。

msys2-mingw64适合固件开发。安装软件时，如果不调整镜像源，速度很慢.msys2本身已经提供了镜像源文件。

同学说, 有人改了Smoothieware固件，给了一个样本。开始有点不信，改这干嘛?真有这能力么？分析一下，是否改了?如果真的改了，看看改了啥？实验不是一次就能做完，拆分为几个实验来做。这个实验，先确定固件是否被改了？改动的具体内容是啥？后续的实验再确定改动后的作用，和修改前的源码联系起来，并还原为C语言代码。再从源码编译，看看是否和样本实现相同。

前面做了实验(openpnp - MKS SGEN_L V2.0-002 烧录bootloader发现烧录bootloader正常，但是连上计算机，win10设备管理器会显示“USB不识别”。此时，只烧录了bootloader, MCU是不会模拟USB设备的。看厂家提供的原理图。应该是D+/D-上连的元件有问题，导致阻抗失配或噪声，从而导致win10枚举USB设备失败。用UsbView看对应的USB设备信息，也可以看到是USB设备枚举失败。

昨天，用编译出的bootloader烧录进 MKS SGEN_L V2.0-002，不好使。LPC17xx-DFU-Bootloader 是给冰沙Smoothieboard用的。想试一下LPC17xx-DFU-Bootloader烧录进Smoothieboard是否好使，如果好使，说明LPC17xx-DFU-Bootloader本身是没问题的，然后再找LPC17xx-DFU-Bootloader用在MKS SGEN_L V2.0-002板子上作为bootloader的不同点。

想学习Smoothieware固件工程, 开源的冰沙板子是没有引出SWD接口到排针的，只留了焊盘，不好接SWD的调试器。看到同学手中有一块MKS SGEN_L V2.0，引出了不带SWO的SWD接口。从咸鱼弄了一块。到手后，发现USB口(J7)坏了, 准备换USB口下图是换完好使的样子。拆卸前，先用新的焊锡将USB口的6个焊盘，都加锡。防止老锡不好融化。然后用热风枪340度将6个焊盘都热透，然后尝试往处拔。不要用力，有一点力量就行，如果热透了，才能凭借一点点力量拔下来。

InoServoShop_V4.10.0.31_20220429 提供了惯量识别的自动参数，但是无法使用。虽然不能用，但是能看到和惯量识别的参数位置为H0815，这个值自己手工改一下，实验一下，就能解决过冲问题。H0900, H0901是刚度参数需要的，不能改。H0905不用改。H0906按照实际运行的参数改，我这里是600rpm最高。H0907, H0908可以参照默认值来改，我这里先不改。

X轴丝杠用的是汇川伺服 Inovance IS620PS2R8I-IAB-C + 伺服电机MS1H1-40B30CB将物理齿隙(openpnp - 消除滚珠丝杠物理齿隙的方法)消除后，发现丝杠有过冲现象。表现 : 移动1mm/0.1mm时，等动作停了，过了1秒钟，还会往回走一点距离。增加刚度参数优化转动惯量将刚度调整为合适值后，过冲有了明显改善。现在，在看官方手册 19010215-SC_C05《IS620P系列伺服设计维护使用手册》.pdf，看看如何在线调整增益和转动惯量。

设备到手后，X轴一直有齿隙。看官方文档的说明，齿隙就是当给了轴步进控制，但是轴没有动的现象。e.g. 轴向右走100mm, 再向左走0.01mm, 可是此时轴并没有运动，再向左走0.01mm， 轴才开始动。为了解决这个问题，我将丝杠周边的东西(丝杠，一体化电机座，丝杠安装底板)都换过了，还是没解决这个问题，这就是明显影响运动精度的地方，真是如鲠在喉。前几天，看官方wiki, 看到齿隙的对应方法。看到方法只有一个，一定要将丝杠固定端的锁紧螺母拧紧。

设备上的当前主次基准点设置都是固定的，如下：基准点用黑色亚光塑料打印的1mm的白色圆点，贴在和PCB基本同高的PCB夹具的固定边上。PCB夹具槽深2.0mm, 一般PCB都采用1.6mm的.黑色亚光塑料也有0.5的厚度.当采用1.6mm厚度的PCB时，基准点和PCB的Z高度差大概不到1mm。左边的白点是视觉归位用的home点，因为发现启动视觉归位会影响已经捕获的关键点坐标，已经废弃不用。中间的白点作为主基准点，贴在3块1.6mm的PCB上，3块小PCB用螺丝拧在PCB夹具固定边上。

当设备标定完，开始正常使用后。当设备机械归零后，如果吸嘴连杆(N1,N2)上已经安装了吸嘴。会自动校验吸嘴。发现会偶发的校验吸嘴失败。参数根本就没有动，光照情况也一样。此时，要是单独校验失败的吸嘴，有时也能校验成功，有时会校验失败。其实，如果开机机械归零后的自动校验吸嘴会偶发失败，在校验参数没改的情况下，以后还可能吸嘴校验失败。所以，在吸嘴校验失败后，如果不微调参数，是没有意义的。像偶发的吸嘴校验失败，应该是opencv对参数敏感，要微调参数才靠谱。

想测试自动换刀，想确认一下openpnp的坐标系统。本来想将顶部相机移动到吸嘴库中的吸嘴上部中心，然后用openpnp提供的"将吸嘴移动到相机中心"的功能，将N1/N2自动移动到顶部相机看到的位置，但是发现，顶部相机并没有这种功能。只有底部相机才有这种功能。那只能确认一下，是否N1/N2的坐标和顶部相机中看到的坐标是否一致?

自从用手头这台设备后，每次标定设备，都启用"Enable Visual Homing"但是发现，只要启动了"Enable Visual Homing"，主次基准点的坐标就变了。标动完的设备进行贴片时坐标也不是很准。因为"Enable Visual Homing"是官方向导中的流程，既然官方推荐这么搞，也就每次都开启这个选项。

在试用OpenPnP-windows-x64-main-2.4_2025-07-31_07-09-12.4743a54发现有个bug, 如果只按照向导走，到了用NT2拾取测试目标时，会因为NT2没有安装，导致使用未标定的NT2拾取失败。也没有标定NT2的向导提示。

在用OpenPnP-windows-x64-main-2.4_2025-07-31_07-09-12.4743a54做实验，出事故了，记录一下。

openpnp主页上不同版本下载后的名字都叫OpenPnP-windows-x64-test.exe文件属性中有版本信息，但是无法复制。如果去找专门的工具，不方便。看了手头装了BC4, 有版本比较功能。如果比较这个文件本身，虽然没有区别(本来就一样)，但是可以将文件信息拷贝下来。

编译一个openocd的发布分支的代码，观摩一下。先将代码切到v0.12.0-rc3分支再从迁出的v0.12.0-rc3分支建立新分支my_v0.12.0-rc3。

开源工程如果是用IDE建立的工程，跟着人家走就行。但是如果开源工程是用arm-gcc + makefile工程来实现的，这时，为了单步调试方便，就不能跟着作者的调试思路走。想当然的就会想将开源工程迁移到可以图形化调试的IDE中。前面做了实验，已经可以将arm-gcc + makefile的工程导入MCUXpresso来单步调试。不过，好像MCUXpresso有bug, 导致有些开源工程(arm-gcc + makefile)工程导入MCUXpresso后，无法单步调试。

默认安装完的MCUXpresso, 一打开，就狂去刷远程的SDK库。得等1~2分钟才消停。整的心里发慌。特别是做实验时，如果程序编译选项不对，会导致arm-none-eabi-gdb卡死，此时要再去更新远程库，耽误事啊。一般安装到本地的SDK库，没啥特殊需求要求最新版啊。软件本身应该有SDK库管理的选项吧？

为了预研如何在mbed的工程上单步调试，买了一块mbed-NXP-LPC1768.这个板子就是mbed官方做实验的板子。接上这块板子后，会在电脑中模拟出一个U盘，将编好的.bin丢进去，就可以由bootloader自动升级然后跑起来。但是我不想这么玩。看mbed官方文档，还有一种玩法，用uv4可以单步调试工程。不过，大部分开源工程都是arm-gcc的makefile工程。今天再看一个大神的mbed教程, 看readme, 他用的也是这个板子。

前面做了笔记(debug - MCUXpresso - 导入arm-gcc工具链编译的makefile工程并单步调试), 已经解决了如何在MCUXpresso引入arm-gcc工具链的makefile工程并调试的问题。现在如果不能单步调试，已经排除了硬件调试器和MCUXpresso配置的问题，如果不能单步调试，一定是工程本身的问题。工程本身只有2个问题会一起不能单步调试。ld文件和实际的板子MCU不对应(工程的实现文件(.s, .c, .cpp)编译时，没加调试选项。

已经将最普通的arm-gcc工具链编译的makefile工程，导入MCUXpresso, 并单步调试。到此，我最初的实验目的已经达到，花了我3周的时间。实验已经成功后，看着步骤也不复杂，甚至可以说是简单。但是最开始是小白时，好多不确定的细节，都需要通过实验来确定调试想法。一个一个想法的验证，实验时间也是用的哗哗的。

想研究一个开源工程(基于arm-gcc工具链的makefile工程)，想试试能不能导入MCUXpresso进行单步调试。实验分2步，现在第一步完成了一半，准备完成第一步的另一半。现在已经从NXP向导做的工程中，抠出了一个makefile工程(debug - MCUXpresso - 从NXP工程做一个makefile工程出来), 现在就将这个nxp工具链的makefile工程导入MCUXpresso, 看看能不能单步调试。如果能单步调试，实验的第一步就完成了。

前面实验(debug - MCUXpresso - 从NXP工程做一个makefile工程出来), 在makefile中居然不能调用clear命令，好惊讶。刚才搞明白了，在busybox环境下，clear命令都是busybox的内建命令，并不是一个外部命令(没法找到clear.exe)。必须用busybox来调用clear命令。

前面做了实验(debug - MCUXpresso - 将NXP工程编译过程的所有命令行参数找出来), 已经将具体的arm-gcc编译用的命令行参数找出来了。做makefile的模板，参考了笔记(debug - MDK - arm-none-eabi - 从MDK工程做一个makefile工程出来现在搞一个简单的makefile, 将程序编译过程复现出来。# 用于隐藏和简化调试时的源码路径的指示 -fmacro-prefix-map = .. /src/ =

调试方法和上次的笔记一样。debug - MDK - arm-none-eabi - 将MDK工程编译过程的所有命令行参数找出来。

同样的源码(*.cpp, *.s, *.ld), 都是用arm-gcc工具链(同一个位置的arm-gcc)进行编译。不同的是，用2种IDE进行编译。用MDK5建立的工程，采用arm-gcc工具链将MDK5工程的工具链参数抠出来，做了一个makefile工程来编译。相当于，虽然是在2个IDE中编译，但是用的工具链都是同一个(位置都一样)，编译的命令和参数都一摸一样。用BC4比较2个elf, 有点区别。但是不知道含义。

想从一个基于arm-gcc工具链编译的MDK工程，做一个makefile工程出来。达到和MDK工程编译一摸一样的效果。前面做了实验(debug - MDK - arm-none-eabi - 将MDK工程编译过程的所有命令行参数找出来), 已经将MDK工程编译时的全部命令行编译参数找出来了。现在整理一个makefile出来。

前面做了一个实验NXP - MDK - 解决因为1768.ld规则写错导致不能单步调试的问题已经可以在MDK中切到arm-none-eabi工具链，编译出来的elf是可以在CMSIS-DAP中单步调试的。现在想直接做一个小的makefile工程，用arm-none-eabi工具链，将elf编译出来。实现文件(.s, .ld, .cpp)在MDK工程中都是有的，但是为了编译效果和MDK一摸一样，就需要知道MDK工程的编译过程的全部命令行参数。但是，MDK是不提供这些的。

在MDK中查看帮助，会弹出一个chm的窗口。当我看到一个有用的帮助时，非常想知道这个chm的具体位置，想直接打开看，而不是在MDK应用中看帮助。

昨天做了单步调试的实验(NXP - 用MDK建立基于arm-none-eabi工具链的工程框架 - 解决单步调试问题同样的工程，根本没有动，今天就不能单步调试了，在MDK4中显示无法访问内存。只在开发机上保留了MDK4, 还是如此。那应该就是程序实现本身的问题。且这个停下来的点，继续单步也进不了starup_x.s和main.cpp。莫非还是.ld写的不对？先查一下elf, 看看这个地址是哪个变量？为啥要读这个地址？

前面做了一个实验(NXP - 用MDK建立基于arm-none-eabi工具链的工程框架),用来解决如何在MDK下做一个基于arm-none-eabi工具链的工程框架，但是不能单步调试。不能单步调试后面隐含的问题，可能是不能正常运行。自己又琢磨了一条，冒出了几个调试思路。一个一个的落地，终于有个思路是可以的，单步调试问题搞定了。果真啊，前面那个实验虽然编译过了，经过这个实验验证，确实是不能运行的。现在这个版本，解决了调试问题，可以单步调试，就是一个可以正常运行的程序:-P。

想单步调试Smoothieware固件工程，如果用Smoothieware工程提供的方法，就得用MRI + GDB去调试。效率太低了，不想这么搞。经过权衡后，准备使用MDK(MDK4和MDK5都可)来建立一个基于arm-none-eabi工具链的工程框架，然后将Smoothieware移植过来。这样就能舒服高效的单步调试。现在关于工程本身如何建立已经知道了，还有些其他的问题，后续再研究。已经知道问题在哪里了。先记录一下，如何用MDK建立基于arm-none-eabi工具链的工程框架。

在实验使用mbed库的固件，进行单步调试的预研任务。看了官方文档, 可以知道，调试方式有2种。将程序.bin丢到mbed的U盘中，让板载的bootloader程序自动更新程序。reset之后，用串口控制台的调试信息来猜测判断程序的bug. 这种方式对于稍微复杂点的程序调试，不实用。只是理论上可行，且效率低下。用MDK来单步调试。官方建议的版本为MDK460.这种就是正常调试的方法了，喜欢这种正规的单步调试。但是，默认安装完的MDK460, 并不能正常单步调试。还需要设置一下才行。

在编译Smoothieware工程时，看到工程为了能稳定编译过，下载了特定版本的arm-gcc到工程目录中。尝试在工程外部建立工具链，以后不管哪个工程，都用自己的工具链，直接编译就行。将工程内部的工具链删掉。