皓月光兮非自明

1、不少厂家的性能选型表做的较差，不便于工程师快速评估选型；

2、芯片功能同质化严重，各家别无太大差异点，降低更换意愿；

3、芯片手册不全，部分功能表达描述不清晰；

4、样例提供不够丰富，不利于工程师熟悉程序封装库用法，拉长开发时间；

 

吾妻思萌

很有友人都说了，诸如硬件，代码，EMC的问题。补充一个，架构的问题，MCU通常有ARM，RISC-V和MIPS等主流的架构，ARM需要授权，对于初创团队和小公司来说，这笔钱不小，智能家电和小产品的市场已经是红海，差异化的小物件还要买授权的MCU划不来啊。

而RISC-V作为开源的却还不是很主流，资料有但不多，像是ADI 超低功耗 MCU MAX32675C 这类高精度、带ADC、大闪存的芯片，低成本的开源内核和生态起来才是王道。

水汤姆

MCU选型针对物联网平台的应用不好选择，首先是存储RAM和ROM在某些场景内置不够，外置会增加成本。ADC采样位数太少只能12位居多。芯片性能，像ESD的抗干扰能力不一样。加密国内简单产品应用不多，但芯片基本都支持。GPIO的接口电平参差不齐，有的做成默认高或低，没有高组态。

韵湖葱白

（1）芯片是否有成熟的应用？

（2）官方的API是否合理？这很体现厂商的实力。

（3）低功耗是否易用？

（4）FAE支持是否即时准确。

（5）是否有针对特殊场景的优化

lidonglei1

MCU的资源（如RAM、Flash）通常比较有限，如何高效地管理存储器成为很多开发人员面临的难题。资源不足可能导致系统崩溃或性能下降。

解决方案:

代码优化: 使用优化编译器选项，精简代码体积。通过代码查重、减少函数调用堆栈深度等方法提升代码效率。

内存管理优化: 使用动态内存管理策略，如垃圾回收、内存池等。定期检查和优化内存泄漏问题。

外部存储扩展: 如果可能，使用外部存储器（如EEPROM、SD卡）存储一些非关键数据，减少对内部存储器的依赖。

模块化设计: 将程序划分为多个模块，确保每个模块独立，减少交叉依赖，并且可以单独调试和优化。

fangkaixin

痛点问题1：芯片选型难，mcu更新速度越来越快，想要选一款供货稳定，价格坚挺，且能完美完成产品目标，有着超高性价比的“最终选项”太难了

解决方案1：根据需求初步筛选，从ram和rom的容量，到io口的数量，封装形式，再到到通信方式，功能扩展，功耗，层层筛选，选择几款性价比高的大品牌，再详细比较这几款芯片的使用者数量，潜在的bug，最终选择出符合要求的芯片来进行实测。

痛点2：不同芯片软件平台的使用，往往不同的芯片会有特定的开发环境，电脑里各种环境装了一堆，有些正版软件还要付费

解决方案2：使用eclipse或者vscode这类开放性高的工具，配合拓展包和开源的工具链，一套环境走天下

痛点3：整机功耗优化难，往往难以快速达到规格书上的功耗，不是io配置有问题，就是哪个传感器配置有问题

解决方案3：有低功耗的需求时，选择官方有低功耗例程的，便于快速排查问题，缩短任务周期，针对复杂的问题，可以先断开外设，从内向外逐步检查问题

aramy

痛点问题 :

1、SDK庞大，文档、例程更新都在国外服务器上，安装、更新极其困难。

2、例程写的功能超多，想找到关注点困难重重。

3、社区支持不足，问题挂很久无应答。

 

qditz

        我在汽车MCU和VCU的软硬件开发、调试和测试过程中，遇到过各种挑战和困难，同时也在这些过程中积累宝贵的经验和成长。以下是一些成功经验分享如下：

        设计原则：在软硬件设计时，遵循模块化、低耦合的设计原则，不仅能提高系统的可维护性和扩展性，还能在后期调试和测试中大大降低复杂度。

        代码质量：编写清晰、可读且易于维护的代码是非常重要的。实施代码审查、遵守编码规范和使用静态代码分析工具可以帮助提高代码质量。

        调试技巧：在软硬件调试过程中，使用有效的调试工具和方法，如逻辑分析仪、示波器等，可以帮助快速定位问题。学会如何解读硬件信号和软件日志对于问题诊断至关重要。

        测试策略：制定全面的测试计划，包括单元测试、集成测试和系统测试，确保覆盖所有功能点和边界条件。自动化测试可以大大提高测试效率和可靠性。

 

        在设计中如果遇到的困难，心态最重要，但也要讲究应对策略。分享一些给大家：
        技术挑战：在开发过程中，经常会遇到技术难题。通过持续学习最新技术、参加专业培训和技术交流，可以提升解决问题的能力。

        时间管理：项目时间管理是一个普遍的挑战。采用敏捷开发方法，如Scrum或Kanban，可以帮助团队更灵活地应对变化，有效管理时间。

        团队协作：强化团队内部的沟通和协作是关键。定期的团队会议、有效的沟通工具和明确的任务分工可以促进团队合作。

        压力管理：开发过程中的压力是不可避免的。学会时间管理、设置合理的期望和休息放松，可以帮助减轻压力。

        经过多年的工作，让我感觉从工作中汲取经验，到实践中不断成长，对自己和团队都有了一些或多或少的成长。主要如下3点：
        持续学习：汽车电子行业快速发展，技术不断更新，就是在不断工作中，持续学习新技术、新工具，以不断提升自己的专业能力。

        分享与交流：定期组织技术分享和经验交流会，不仅能促进团队成员的技术成长，还能增强团队凝聚力。

        鼓励创新：鼓励团队成员提出新想法和创新方案，即使这些想法最终未被采纳，也是团队成长和学习的宝贵过程。

         最后，感谢EEworld给我们有这个机会，可以分享技术人员的点点滴滴，互相学习，共同进步，希望大家在这一行业可以有更好的发展，加油吧！

asimilar

1、配套的开发软件是否易上手，是否免费；

2、是否兼容目前绝大多少MCU的烧录方式；

3、MCU芯片包含的功能，如多种通信方式，PWM输出精度等；

4、平台方对芯片开发案例的分享，以便于开发者更好的应用于产品设计。

许慧清

关于产品设计定型MCU的一些使用问题： 1）资料没有中文版、英译版本还有错的地方。 2） 开源源码注释不全，不能上手快速调用驱动代码。 3）开发环境不同，换MCU还需要学习新的SDK。 4）厂家提供选型手册繁琐不直接，没有针对性的产品和方案推荐。 5）虽然MCU大同小异但与主流MCU引脚不兼容。 6）烧录代码不方便，需要冷启动。下载引脚过多。

 

bigbat

对于我遇到的MCU问题如下：
1、外设引脚冲突，这类问题最为麻烦，升级过程中有可能原有MCU产品的外设引脚冲突，明明MCU的外设够用，结果外设引脚冲突导致外设无法使用或需要大量的工作调整PCB。我开发的一款产品由于需要增加一路PWM输出结果引脚全部被占用，不得不更换更多引脚的MCU信号。这方面做的最好的是NXP的LPC8xx系列的产品，数字引脚可以随意更换。
2、集成的ADC外设位数不足，我的一款产品的MCU中集成有12位的ADC，但是由于产品的精度需要只能外置16位的ADC芯片
3、厂家的MCU成本定价阶梯过于陡直，例如：我的一款产品初始使用NXP的LPC17XX系列的LPC1758产品，后来由于产品功能升级的问题flash和sram都不足，计划更换同系列的产品，但是由于价格过高而放弃改为ST的产品。甚至配置资源少的产品价格反而较高。
4、产品系列资源不足且不够丰富，例如：ESP32的产品GPIO的引脚过于少和产线不够丰富，导致有些设计不得不使用多MCU方案，
5、MCU资料不完善，例如：某公司的MCU产品出现BUG，但是其数据手册中的勘误表不予警示，造成设计出现严重问题。甚至有些厂家的产品对于一些外设的资料不开放。
6、产品性能过低，例如：某公司的MCU产品的ADC性能极差，其产品的ADC宣称12位，但是测试时同样的电路原理ST公司MCU可以做到较稳定的温度读数，该公司产品确无法稳定读数。

这里说一下我用过的ST和NXP公司的产品，大部分的问题是因为自身的原因造成，而不是公司的产品品质造成地，例如：我没有深入的理解ST公司的MCU供电设计，按照自己的经验设计产品，导致在矿山的大功率环境下使用造成的EMC问题，后来了解ST推荐设计后产品稳定产品

zjk103

 

1. 技术复杂性与开发难度

• 内部架构复杂性增加：随着MCU的发展，其内部架构变得越来越复杂，包括更大的内存、更快的CPU和多种外设。这要求开发者具备更高的技术水平，以应对复杂的硬件和软件接口。
• 编码挑战：现代MCU的软件开发面临诸多挑战，如平台锁定、可移植性有限、碎片化、缺乏开源支持等。这些挑战增加了开发的难度和成本。

2. 测试与验证

• 手动测试繁琐：传统的MCU测试方法往往依赖手动搭建测试环境，数据记录也多为人工完成，这既耗时又容易出错。
• 复杂测试业务逻辑：一些复杂的测试业务逻辑难以通过手动方式完成，需要自动化的测试流程和工具来支持。
• 长时间可靠性测试：MCU的长时间可靠性测试及环境相关测试无法仅通过手动方式完成，需要自动化的测试系统来模拟各种环境条件。

3. 数据管理与协同

• 数据分散：在分散的自动化测试环境中，测试数据往往分散在不同的系统和地点，难以实现统一管理和分析。
• 数据关联分析缺乏专业工具：从研发到中试到生产，各阶段的数据关联分析需要专业的工具来支持，但许多企业在这方面存在不足。
• 数据协同分析困难：分散在各地的研发部门在数据协同分析方面存在困难，需要更高效的数据共享和协同机制。

4. 供应链依赖与技术差距

• 供应链依赖：国内MCU企业对国外供应商的依赖程度较高，全球芯片短缺等问题对供应链的安全性和稳定性造成了影响。
• 技术差距：在高端市场，如汽车电子和工业自动化领域，中国MCU厂商与国际巨头相比仍存在显著的技术差距。

5. 特定应用领域的挑战

• 特定需求满足不足：在新能源汽车、智能穿戴设备等特定应用领域，MCU需要满足特定的性能、功耗和可靠性要求，这对MCU的设计和制造提出了更高的挑战。

解决方案与建议

• 采用先进的测试设备和工具：使用高精度的测试设备和工具，如高精度的电压表、频率计、时间计数器等，以及专门的测试程序进行自动化的测试流程。
• 加强数据管理与协同：开发统一的数据管理平台，实现测试数据的集中管理和分析；加强研发部门之间的数据共享和协同机制。
• 加大研发投入：提升自主创新能力，加强在高性能、高可靠性产品开发方面的技术积累。
• 政策支持与产业链协同：政府应出台更多扶持政策鼓励企业进行技术创新和产业升级；构建完善的产业链生态，加强上下游企业的合作形成协同效应。

我心安联

主要论述物联网端侧设备的MCU产品的痛点：

一是低功耗方面。传统的低功耗MCU主要关注低静态待机功耗（可降低至10uA及其以下）。而物联网技术的发展和应用场景的多元化，对物联网端侧设备的MCU提出了新的需求，其中非常重要的一点便是动态运行功耗和平均运行功耗的优化。

二是封装尺寸方面。在工业及传统应用领域，客户端普遍采用的通用MCU多采用LQFP等大尺寸封装。然而，物联网端侧设备的紧凑结构设计，要求主控MCU必须采用较小尺寸的封装方案。

三是安全性方面。相较于通用领域，物联网端侧设备的安全问题受到了更多重视。除了加强网络层面的安全措施，端侧设备自身的安全设计同样不可或缺，这便要求MCU需要具备硬件加解密能力。

四是无线连接能力方面。网络连接能力对物联网端侧设备而言是实现智能化、自动化以及与用户及其他设备和服务进行互动的基础，这一关键功能可通过外接无线网卡模块或者采用内置Wi-Fi功能的MCU来实现。

kit7828

MCU使用过程，最头疼的问题，应该是下列这些问题了：

1. 时钟配置异常，如配置超出芯片主频工作范围，导致MCU无法正常工作或性能下降。
2. 电源质量差、纹波过大、供电芯片质量差或系统供电能力不足等，导致MCU供电不稳定。
3. BOOT配置脚焊接或接触不良，导致MCU启动失败或进入错误的工作模式。
4. 选错启动文件，导致程序无法正常运行或调试时出现问题。
5. 中断请求位没有及时清除，导致中断重复进入，影响系统性能。
6. 程序中的堆或栈使用不当，导致数据越界或溢出。
7. 某些MCU芯片有VCAP脚，需要接上适当的电容，如果忽略这一点，可能导致芯片功能异常。
8. 由于电源上电或下电时序不符合MCU的要求，导致MCU启动失败或工作异常。

王阳阳阳

MCU行业的痛点主要包括供应链紧张、‌技术挑战、‌认证壁垒高、‌供应周期长、‌以及市场需求激增与产能不足的问题。‌

（1）供应链紧张：‌全球疫情导致晶圆厂产能下降，‌加上新能源车辆的崛起，‌造成了MCU供需失衡，‌导致缺芯问题严重。‌这影响了汽车的生产和供应链的稳定性。‌

（2）技术挑战：‌随着自动驾驶技术的发展，‌MCU需要处理海量数据、‌制定驾驶决策、‌协调各系统间工作，‌这对MCU的性能提出了更高的要求。‌同时，‌高可靠性和稳定性也是必不可少的特点。‌

（3）认证壁垒高：‌车规级MCU的认证过程严格，‌一旦完成认证后，‌车厂不会轻易更换供应商，‌这使得新进入者难以打破垄断格局3。‌

（4）供应周期长：‌车规级MCU的供应周期长，‌需要较长的检测和实验时间，‌以及较高的投入，‌才能实现上车和量产。‌

（5）市场需求激增与产能不足：‌随着汽车电动化和智能化的发展，‌车用MCU的需求急剧增加，‌而产能不足导致了供应短缺。‌这要求厂商加大投资，‌提高产能以满足市场需求。

kjsm

在使用（MCU）进行项目开发时，以下是一些我总结令人头疼的问题：

      1/硬件兼容性和稳定性问题：

• 不同批次的MCU之间可能存在微小的差异，这可能导致在某些硬件上工作正常的代码在另一批次的MCU上无法正常工作。
• MCU的稳定性问题；MCU产品的成熟性；样品没问题到量产时出现偏差过大，能否量产问题

2/电源管理：

• 低功耗设计是许多嵌入式应用的关键，但正确管理MCU的电源状态（如睡眠、唤醒、低功耗模式等）往往很复杂，并且容易出错。
• 供电电压的波动和噪声也可能对MCU的稳定性和性能产生负面影响。
• 抗干扰能力不够担心MCU突然失效，程序跑飞。

3/调试困难：

• 由于MCU的运行环境和PC机截然不同，调试过程可能相当复杂，特别是在没有适当的调试工具或调试接口的情况下。
• 实时系统的问题可能难以复现，增加了调试的难度。
• 能有好的调试工具就能快速找到软件问题

4/电磁兼容性（EMC）和电磁干扰（EMI）： 

• 在嵌入式系统中，EMC和EMI问题可能导致设备性能下降或完全失效。这些问题可能由多种因素引起，包括电路设计、PCB布局、电源质量等

5/资料例程是否完善

• 在嵌入式系统中，快速的上手也是MCU考虑的一方面；资料和例程的齐全，说明文档的存在，能够让工程师快速的熟悉一款新的MCU；加速产品的开发进度。
• 例程的注解能够更方便的了解例程的功能和外设的使用

eelw

       在MCU程序开发过程中我们常常遇到内存不足、编译工具过度优化程序、导致在线调试时，程序执行跳转到不可预期的地方，现针对以上提出的问题、提出以下解决方案、供后者使用：

       通过调整优化等级、解决内存不足的问题
      1、将优化等级调整到最高

      2、调整优化方式

      有时调整优化等级，仍发现flash 内存不足，那么调整优化方式。针对高等级优化，IAR还提供了更灵活的控制。在高等级编译优化时，可以选择项目的编译优化倾向，针对代码大小优化（Size）、针对代码运行速度优化（Speed）或平衡状态。其中，选择针对代码运行速度优化（Speed）时，若MCU剩余的资源空间足够，还可以勾选“No size constraints”选项，该选项将让编译器牺牲一部分的空间占用来换取最快的代码执行速度。这将导致编译的目标文件体积增大，但可以获得更快的代码运行速度。具体缩小的大小，可查看map文件分析。

     部分文件调整优化等级。有时优化等级过高，导致我们对程序进行在线调试时，程序跑不到断点处、甚至乱跑，这个主要原因是优化等级过高，但优化等级过低，导致内存不足，直接编译失败，这时我们调整要在线调试的文件优化等级，部分函数调整优化等级。
      以上两种方式都不能使用时，但我们还想在线调试、只能用最后一种方式，局部函数的优化等级调整,如果再不行那么可以考虑换芯片了。。。

孟珺

前期可能更需要技术支持以及推广，采购阶段则更关注价格，货期，以及商务，而最后则是质量和售后，或者说这个品牌、企业的发展，能否提供长期、可持续的更新换代。

qzc飘曳

芯片缺货与替代难题
        痛点：疫情期间，特定型号的MCU经常出现缺货情况，导致项目延期甚至停滞。替代芯片的选择不仅需要考虑性能参数匹配，还需考虑软件兼容性、封装尺寸、引脚排列等因素，这大大增加了设计复杂度。

解决方案：
        提前规划：建立多元化的供应商体系，减少对单一供应商的依赖。
        模块化设计：在设计初期就考虑使用模块化架构，便于在需要时快速更换MCU模块。
        软件抽象层：开发通用的软件抽象层（HAL），减少对特定MCU硬件的直接依赖，提高代码的可移植性。

衍生问题-软硬件适配问题
        痛点：不同MCU之间的寄存器配置、中断系统、外设接口等存在差异，导致软件迁移和适配工作量大。

解决方案：
        使用中间件：利用RTOS（实时操作系统）、文件系统、图形库等中间件，它们通常提供较好的跨平台支持。
        代码重构：采用面向对象或组件化的编程方法，将硬件相关的代码封装成独立的模块，降低耦合度。
        自动化测试：建立全面的自动化测试体系，确保每次更改后都能快速验证软硬件的适配性。

yinxx

1、比如说，有些基本模块的功能演示不能够保持一致性，也就是说在stm32f103系列芯片上能够实现的功能，不能简单直接的移植到stm32h533这样的情形。

2、手册里面的文字描述似乎给人一种静悄悄的感觉，既不能在出现问题的时候及时的咨询回应，只能通过不断的思考和质疑，参考其他案例，或者sdk中携带的例子进行初步的实现，对于一下功能比较复杂的方式，就不能快速的定位问题和实现

3、既然已经有芯片手册，为什么不配套出一下对应的芯片手册解读和对应功能的实现方面的视频

4、或者建立一个反馈机制，能够及时解决一下看不明白，或者实现逻辑方面的问题