dsh-luxar-stm32

STM32/CubeMX 平台适配器。M0 已冻结公共 core、单平台约束和生命周期；M1 已完成零配置工具链发现、无副作用项目识别、模型工具以及独立 Web/CLI 状态入口。M2 已完成全新 CubeMX CMake 工程创建和不隐式再生成的 CMake 构建链路；既有 .ioc 的安全再生成仍在实施。

首版只支持传统 STM32CubeMX，不支持 CubeMX 2。工具链按覆盖、环境/安装记录、注册表、文件关联、PATH、可选 CubeCLT/传统 CubeIDE 工具组、STM32CubeIDE for Visual Studio Code 的 %LOCALAPPDATA%/stm32cube/bundles 及有界常见目录自动发现；这些发行方式都不是插件依赖，独立 GCC、CMake、Ninja/Make 和 Programmer 通过探针后同样可以使用。同一 STM32 工程同时存在 CMake 与 Keil 文件时，默认构建后端固定为 CMake。

工具链快照使用插件实例内 15 秒短时缓存。重复读取会校验选中工具和受控搜索根的大小/修改时间；发生变化时立即重探测，未被现有候选覆盖的新安装最迟在 TTL 后发现。模型工具使用 refresh=true、CLI 使用 toolchain --refresh、Web 使用“重新探测”可跳过缓存。只有完整的成组工具或独立/混合组件通过临时目录中的最小 CMake/GCC 编译探针， cmakeBuild 才会为 true；探针不会修改全局 PATH 或目标工程。 VS Code Bundles 会按各组件版本目录选择最新有效版本，并监听 Bundle 元数据、版本目录和已选可执行文件；扩展升级、删除或回退工具后会自动使短时缓存失效。

Keil 自动发现会验证候选为真实 UV4.exe，并从安装根 TOOLS.INI 的 RTEPATH 定位外置 Pack 仓库；只有 Arm 编译器和至少一个已安装的 STM32 Device Pack 同时存在时， keilBuild 才会为 true。驱动安装程序不会被当作 µVision。

当前模型工具：

luxar_stm32_toolchain
luxar_stm32_project_inspect
luxar_stm32_project_create
luxar_stm32_build

luxar_stm32_project_create 只创建全新工程：默认 CMake + GCC + copy-only，在目标父目录的同级临时目录执行 CubeMX，回验 .ioc、CMake preset、启动文件、链接脚本及 HAL/CMSIS 后再原子发布。目标目录已存在时拒绝覆盖；该工具不执行编译、烧录、固件包下载或既有 .ioc 再生成。CLI 等价入口为 create --mcu [--parent ]。

CubeMX 6.x 的 -q 只关闭 UI。插件不会在脚本中调用 swmgr refresh/install，并在启动前要求目标 MCU 的固件包已存在；但 CubeMX 进程仍可能遵循其全局“自动检查更新”首选项访问 ST 更新服务。需要严格离线时，应先在 CubeMX 的 Updater Settings 中关闭自动检查；插件不会替用户改写这一全局设置。

luxar_stm32_build 只读取并编译现有工程：CMake 与 Keil 并存时固定走 CMake，优先使用 CMakePresets.json 的 Debug preset，configure/build 都设置 FetchContent 离线开关，且不会调用 CubeMX。结果盘点 ELF/AXF/HEX/BIN/Map，并为每个产物返回新鲜度和 SHA-256。CLI 等价入口为 build [path] [--preset ]。Keil 和 Make 构建仍属于后续里程碑。

CLI 行 dsh-luxar-stm32/cli 和 Web 行 dsh-luxar-stm32/web 在 bundle 中默认禁用，由各自的 STM32 profile 显式启用；不得与 ESP adapter 放在同一 profile。

test/fixtures 固化 CubeMX+CMake、CubeMX+Keil、无 .ioc CMake/Make/Keil、 CMake+Keil、平台冲突和未知工程，供 M1 项目识别实现直接使用。

dsh-luxar-stm32

インストール

ドキュメント

dsh-luxar-stm32