常见的汽车氛围灯驱动方案介绍

• 1.前言
• 2.需求概述
• 3.静态氛围灯
  • 3.1 需求
  • 3.2 当前方案主要厂家
  • 3.3 当前方案对比
  • 3.4 新方案
• 4.动态氛围灯
  • 4.1 需求
  • 4.2 当前方案主要厂家
  • 4.3 当前方案对比
  • 4.4 新方案
• 5.总结

1.前言

之前的文章系统性的介绍了汽车前灯和尾灯的方案，也简单提及了氛围灯方案，今天系统性的介绍下汽车氛围灯的驱动方案。

2.需求概述

汽车氛围灯按照架构和功能分为静态氛围灯和动态氛围灯，静态氛围灯指的是一个LED驱动芯片控制一颗RGB灯珠或者一个PCB上放一颗RGB灯珠，通过导光条实现简单线条照明。动态氛围灯指的是一个LED驱动芯片控制多颗RGB灯珠或者一个PCB上放多颗RGB灯珠，可以实现分区照明。

• 氛围灯的功能需求如下思维导图所示：

• 氛围灯驱动芯片的资源需求如下思维导图所示：

下面对这些需求进行详细描述。

3.静态氛围灯

静态氛围灯主要指一个LED驱动芯片控制一颗RGB灯珠或者一个PCB上放一颗RGB灯珠，通过导光条实现简单线条照明。静态氛围灯主流的方案为一颗集成LIN和恒流源驱动的MCU加上RGB灯珠，整个PCB的尺寸非常小，嵌在门板框里。

3.1 需求

静态氛围灯的需求主要从整个方案的功能需求和驱动芯片的资源需求进行描述。

3.1.1 功能需求

静态氛围灯的功能需求如下：

LIN

• 常规的LIN通信，用于和主机通信。需要提供基于LIN的bootloader，因为PCB尺寸很小，不一定会留出调试接口。有些客户（特别是海外车厂）还需要LIN自动寻址功能，减少组装的难度。

• 有时车厂放了方便氛围灯节点的软件升级，不希望拆卸零部件，造成器件损伤，会要求氛围灯节点支持LIN UDS Bootloader，该功能需要MCU的Flash最少64KB，如果还需要A/B分区，那MCU的Flash就需要128KB，同时RAM也需要相应增大。

调光

• 因为不同的RGB灯珠，色域顶点会有偏差，单纯的按颜色的RGB混合比例调整占空比方式不适用，需要先标定每个RGB灯珠的色坐标三个顶点，再根据所需点亮颜色的色坐标使用相关的混光算法得到RGB三个通道的占空比，最后进行输出。

• 因为温度会影响RGB灯珠的发光强度，所以还需要通过检测PN结电压来计算当前灯珠的温度，再使用温度补偿算法，修改RGB三个通道的占空比。芯片自带的温度传感器精度较差，一般不使用。有些海外客户对于成本要求没那么高，会在PCB放放置一个NTC电阻用于计算温度。

• 部分客户对于氛围灯的效果有更进一步的需求，需要无极调光。当整车ZCU通过LIN给了无极调光的命令之后，需要氛围灯节点根据LIN报文传输的sRGB坐标信息，进行温和的颜色变换。

诊断和保护

一般车厂提供的LIN报文列表里会预留LED开短路的信号，有些高端的车型需要氛围灯节点上报诊断信息。同时氛围灯驱动芯片的硬件一般也会提供供电电压的过欠压保护和过温关断功能。

3.1.2 芯片资源需求

静态氛围灯对于驱动芯片的资源需求如下：

主系统

• 主频：需要最少16MHz的主频，当前主流厂商的驱动芯片主频都在48MHz

• 存储：Flash需要64KB，如果本身自带SysROM并且内部集成LIN协议栈、Bootloader等功能，32KB的Flash也能满足需求。RAM需要2-8KB，主要看客户的代码功能。EEPROM一般需要0.5KB左右，主要用来存放RGB灯珠的标定数据。

• 需要硬件乘除法器，因为调光里面涉及到很多矩阵运算，纯粹靠软件运算的话，需要MCU主频比较高。

驱动

• 输出通道一般使用恒流源，20-60mA的驱动能力就足够使用。恒流源相比恒压源，对于RGB灯珠的控制更精确，当前主流的方案都是低边恒流源。国内需要3路的输出通道，海外客户因为更多使用RGBW灯珠，所以需要4路输出通道。

• 输出通道同时也需要PWM发生器，频率700Hz，分辨率16-bit，用于实时调整输出通道的电流。有些场景下，车主会听到输出旁路电容的啸叫，导致有些高端车会要求PWM频率提高到20KHz，但是这会增加EMC实验的难度，具体看和车厂沟通的最终要求。

通信

当前静态氛围灯基本都是LIN通信，需要满足LIN 2.2规范。有时为了自带的bootloader升级速度加快，会需要支持100K波特率的高速LIN，但是高速LIN只局限于升级场景使用，正常整车运行时不会用到。

测量

• 氛围灯的ADC分辨率一般要求12-bit，采样和转换速率也尽量在400KSAS以上。同时需要支持差分采样，主要目的是采集RGB灯珠的PN结电压，和使用bus shunt方式的LIN自动寻址工作时采集电阻两端电压。

• 另外氛围灯需要采集的通道比较多，需要配合PWM模块和定时器模块进行采样任务的合理调度。

3.2 当前方案主要厂家

当前静态氛围灯的驱动芯片的主要厂家有英迪芯、迈来芯、艾尔默斯、泰矽微、纳芯微等。各家的产品介绍下。

3.2.1 英迪芯

笔者认为，英迪芯是当前国内静态氛围灯驱动芯片的市场领导者，第一颗产品IND83209应该是第一颗使用ARM内核的静态氛围灯驱动芯片，解决了之前其他家产品调试工具贵、调试不方便的问题。同时，英迪芯也是第一家提供混光算法和温补算法（以库的形式提供，看不到源码，提供接口函数）的LIN RGB集成芯片厂商，并和光色科技进行合作，提供客户从设计到生产全贯通的解决方案，降低了静态氛围灯方案的开发难度。

英迪芯针对静态氛围灯的驱动产品列表如下，也称Realplum系列：

• IND83212是当前客户端使用最多的产品，英迪芯正在推动客户逐步向性价比更高的IND83216转移。

• IND23224（属于Rugby系列）是英迪芯在DVN展会重点介绍的产品，主要针对0.5W的氛围灯，该功率的氛围灯主要应对高端车上白天开启氛围灯的应用场景。

3.2.2 迈来芯

在英迪芯崛起之前，国内静态氛围灯的市场份额主要由迈来芯和艾尔默斯占据。迈来芯的静态氛围灯驱动产品非常丰富，覆盖各种资源需求。

如下是迈来芯的静态氛围灯驱动产品列表，也称LIN lighting系列：

• MLX81124是迈来芯主推的静态氛围灯驱动产品，增加了一些实用的特色。比如支持小于1mA，微秒级脉宽的诊断电流，不会造成微光，可以更加精确得测量LED的PN结电压；以及提供了如何分辨LED开路和低边输出通道对GND短路的方法。

3.2.3 艾尔默斯

艾尔默斯的静态氛围灯驱动产品系列相比前面两家有点少，但是深受海外客户的青睐，欧洲份额依然非常高，但是国内份额这几年下降较多。为了更贴近国内客户的需求，做了E521.39的国内版本D168.20，也可以基于库的方式提供提供调光算法。另外，除了SysROM自带的基于$BB服务的LIN Bootloader，也可以提供符合国内客户需求的LIN UDS Bootloader例程。

艾尔默斯针对静态氛围灯的驱动产品列表如下：

• E521.31和E521.36是比较老的产品，目前仍有少量客户在使用。E21.36使用OTP存储代码，相比Flash成本更低，但是一旦烧写代码，后续就无法更改。

• E521.39是最新的静态氛围灯驱动产品，在欧洲市场深受欢迎，国内版本的是D168.20，因为价格相比国产差距不大，也有一些客户在选用。

3.2.4 泰矽微

泰矽微的静态氛围灯驱动产品目前在很多国内车厂的推荐名单种，市场份额在快速增长。

如下是泰矽微针对静态氛围灯的驱动产品列表：

• TCPL010已导入多个国内车厂，ADC分辨率相比其他几家有点较低。

• TCPL03x是目前主推的产品，价格和性能相比上一代有挺大优势。

3.2.5 其他

除了上述几个主要的静态氛围灯驱动产品厂家，也有一些新的玩家在进入该市场，目前产品种类相对单一，笔者遇到的几家产品如下。

• 纳芯微的NSUC1500相比上述芯片厂商的产品有两个比较特出的特点，一个是SysROM支持LIN UDS Bootloader，另一个是硬件上支持LED开短路阈值的设置。

• 英飞凌的TLD4020风格和其他海外厂商类似，都是32KB Flash加上SysROM的配置，如果客户需要做LIN UDS Bootloader，32K Flash空间有点勉强。TLD4020只有3个输出通道，能够满足国内的静态氛围灯市场需求，海外客户更多需要4个输出通道（驱动RGBW灯珠）。和其他厂商不同的是，TLD4020有图形化配置工具，可以集成到Keil和IAR中，能够减少部分软件工作量。如果TLD4020跟随电机SOC（TLE9954）在国内市场的激进价格策略，后续也能占据一部分市场份额。

• 帝奥微和艾为的静态氛围灯驱动产品暂时还没有遇到量产的客户，并且网上资料较少，这里就不赘述了。

3.3 当前方案对比

笔者挑选了厂家的几颗静态氛围灯驱动产品，做了简单的对比表，如下所示（因为各家的规格书参数指标并非完全一致，有不当之处欢迎在评论区指出）：

3.4 新方案

静态氛围灯除了上述集成LIN和恒流通道的集成MCU之外，还有一些新方向。

3.4.1 code-free

迈来芯近期推出了code-free的MLX80124，官方公众号介绍资料如下链接：

• 新品发布 | Melexis以无代码LIN LED驱动器重塑汽车照明设计规则

code-free相比当前方案，能够极大压缩客户的软件开发工作量，对芯片内置的固件功能丰富度有非常高的要求，有可能会成为以后的趋势。

3.4.2 all in one

弘凯近期推出了集成LIN、恒流驱动以及RGB灯珠的all in one方案，该方案因为需要将驱动和RGB灯珠合封在一起，所以工艺难度较大，相比之前的ISELED方案和欧司朗的RGBi方案，通信速率太低，但是对于静态氛围灯的应用来说应该足够。

弘凯官方公众号发布的介绍资料如下链接：

• LIN-Lite智能LED：车企“新宠”，打造高效智能车内光环境！

4.动态氛围灯

动态氛围灯指的是一个LED驱动芯片控制多颗RGB灯珠或者一个PCB上放多颗RGB灯珠，可以实现分区照明以及复杂绚丽的动画效果。动态氛围灯的主流方案为一颗驱动芯片驱动几十至一百颗的RGB灯珠，或者使用RGBi这种通信速率极高的all in one芯片，一般用在面光源、格栅灯等场合，

4.1 需求

动态氛围灯的需求主要从整个方案的功能需求和驱动芯片的资源需求进行描述。

4.1.1 功能需求

动态氛围灯的功能需求如下：

通信

• 对于可以支持驱动多路RGB的集成芯片，需要LIN或者UART Over CAN通信

• 对于smartLED或者欧司朗的RGBi等all in one方案，需要高速率的ISELED协议或者OSP协议

调光

• 如果需要精确的颜色控制，需要使用混光算法（sRGB坐标）；温度补偿的需求不多，因为一个PCB上RGB灯珠特别多的时候，想要每个RGB灯珠都做精确的温补比较困难。

• 动态氛围灯需要更绚丽的效果，所以分区显示，音乐律动等功能是比较常见的。

诊断和保护

• LED开短路的信息需要进行上报。

• 驱动芯片本身需要有过欠压保护和过温关断，有些还需要可配置的热降额功能。

4.1.2 芯片资源需求

动态氛围灯对于驱动芯片的资源需求如下（不包含smartLED）：

主系统

• 主频：48-72MHz

• 存储：64-128KB Flash，8-16KB RAM

• 最好有硬件乘除法器

驱动

• 恒流源在21-27路左右，每路驱动能力在30-100mA。为了满足更高的功率，需要内置buck提高效率。

• PWM发生器的频率在1KHz左右，分辨率16-bit，有些场景需要更高频率时，可以适当降低分辨率。

• 有时为了单个驱动芯片能够控制更多RGB，需要有额外的GPIO做行切换，配合恒流源做行列扫。

通信

• 通信接口推荐UART Over CAN，因为LIN的通信速率在需要控制非常多RGB灯珠时无法满足要求。

• 通信速率需要2-4Mbit/s

测量

• 12bit的ADC，最好支持差分测量。

• 需要定时器以及其他能够触发ADC的模块进行配合。

4.2 当前方案主要厂家

当前动态氛围灯的驱动芯片的主要厂家有迈来芯、欧司朗、英迪芯、泰矽微等。各家的产品介绍下。

4.2.1 迈来芯

目前动态氛围灯的应用场景中，笔者见到最多的还是迈来芯的方案，如MLX81116、MLX81142等。

迈来芯的动态氛围灯的产品列表如下，也称MeLiBu系列：

4.2.2 ISELED联盟/欧司朗

ISELED联盟和欧司朗都是做的all in one方案，因为通信接口速率比较高，也可以做动态氛围灯。笔者之前介绍过这两种方案，链接如下：

• ISELED---氛围灯方案的新选择

• 适合超多氛围灯节点应用的新选择

4.2.3 英迪芯

英迪芯的IND83220目前见到不少客户在使用，除了用于动态氛围灯，有些LED灯珠数较少的ISD方案也在使用。

英迪芯针对动态氛围灯的产品列表如下：

4.2.4 泰矽微

泰矽微的动态氛围灯驱动芯片称为TClux系列，主要针对RGB面光源和流水氛围灯等应用。

主要的产品系列和功能如下列表：

TClux系列更多信息参考如下官方发布的微信文章：

• 泰矽微发布TClux系列车规多通道LED驱动芯片

对于SmartLED这类all in one方案和驱动芯片的方案的对比，泰矽微的分析参考如下官方发布的微信文章：

• Smart LED or 专用驱动芯片，如何选择动态氛围灯芯片方案

4.3 当前方案对比

当前方案中未内置buck的驱动芯片对比如下（因为各家的规格书参数指标并非完全一致，有不当之处欢迎在评论区指出）：

因为smartLED的方案拓扑和驱动芯片不一样，所以没有放在一起对比。

4.4 新方案

随着动态氛围灯所需的RGB灯珠越来越多，除了传统的集成驱动的MCU方案之外，有些客户也会选择通用MCU加行列扫描式芯片，如TI的LP5860、LP5891等。

5.总结

当前静态氛围灯方案以集成LIN和恒流源驱动的MCU加上RGB灯珠的架构为主；动态氛围灯方案除了以专用驱动芯片加多颗RGB灯珠的架构之外，smartLED这种all in one也有不少客户选择。

随着10base-T1兴起，以及整车EE架构的演变，传统边缘节点的软件会逐步向ZCU集中，静态氛围灯和动态氛围灯也许会向code-free的思路转移，需要重点考虑如何完善code-free芯片和10base-T1 RCP芯片之间的通信方式和通信协议。

整理不易，如果觉得本文对你有用，帮忙点个三连！！！