打卡签到

抛开参数，从“做产品”的角度看C5，有几个层面值得深挖：

一、外设组合的“场景化陷阱”

以太网 + 144MHz：看似为IoT网关准备，但需确认MAC是否支持TSN（时间敏感网络）哪怕是最基础的802.1AS。没有硬件TSN支持的工业以太网，在运动控制场景下仍需外挂芯片，成本优势减半。

双FDCAN + 125℃：明显针对汽车BMS或域控，但汽车应用要求功能安全等级。C5是否计划提供ASIL-B以上的安全手册？没有故障注入检测和锁步核，很难进入主流车规供应链。

I3C的实用性：I3C的优势是动态地址和带内中断，但现有传感器驱动库（如BMI260、BME688）几乎全为I2C/SPI设计。ST是否提供传感器厂商的I3C适配清单？否则工程师仍需用GPIO模拟时序，失去升级意义。

二、软件生态的“真实生产力”

HAL2的“轻量化”陷阱：需实测对比HAL1和HAL2在相同功能（如USB CDC传输）下的中断延迟和Flash占用。轻量化若以牺牲外设fault恢复为代价，在工业现场可能引发宕机。

中间件的“版本锁”：FreeRTOS、LwIP等中间件是否强制绑定Cube库版本？历史教训是，一旦中间件升级（如FreeRTOS v11），旧版Cube库可能不兼容，导致整个项目无法安全更新。

调试链的缺失环节：VSCode插件是否支持RTOS线程感知调试（如FreeRTOS的线程状态可视化）？对量产阶段的固件批量烧录，ST是否提供脱机烧录器的配置文件（.obz）直接支持？