深度解读汽车域控制器

BlackCoffee 2023-03-28 原文

什么是域控制器

过去十多年的汽车智能化和信息化发展产生了一个显著结果就是ECU芯片使用量越来越多。从传统的引擎控制系统、安全气囊、防抱死系统、电动助力转向、车身电子稳定系统；再到智能仪表、娱乐影音系统、辅助驾驶系统；还有电动汽车上的电驱控制、电池管理系统、车载充电系统，以及蓬勃发展的车载网关、T-BOX和自动驾驶系统等等。

传统的汽车电子电气架构都是分布式的（如下图2-1），汽车里的各个ECU都是通过CAN和LIN总线连接在一起，现代汽车里的ECU总数已经迅速增加到了几十个甚至上百个之多，整个系统复杂度越来越大，几近上限。在今天软件定义汽车和汽车智能化、网联化的发展趋势下，这种基于ECU的分布式EEA也日益暴露诸多问题和挑战。

汽车分布式EEA

为了解决分布式EEA的这些问题，人们开始逐渐把很多功能相似、分离的ECU功能集成整合到一个比ECU性能更强的处理器硬件平台上，这就是汽车“域控制器（Domain Control Unit，DCU）”。域控制器的出现是汽车EE架构从ECU分布式EE架构演进到域集中式EE架构（如图2-2所示）的一个重要标志。

域控制器是汽车每一个功能域的核心，它主要由域主控处理器、操作系统和应用软件及算法等三部分组成。平台化、高集成度、高性能和良好的兼容性是域控制器的主要核心设计思想。依托高性能的域主控处理器、丰富的硬件接口资源以及强大的软件功能特性，域控制器能将原本需要很多颗ECU实现的核心功能集成到进来，极大提高系统功能集成度，再加上数据交互的标准化接口，因此能极大降低这部分的开发和制造成本。

对于功能域的具体划分，各汽车主机厂家会根据自身的设计理念差异而划分成几个不同的域。比如BOSCH划分为5个域：动力域（Power Train）、底盘域（Chassis）、车身域（Body/Comfort）、座舱域（Cockpit/Infotainment）、自动驾驶域（ADAS）。这也就是最经典的五域集中式EEA，如下图2-2所示。也有的厂家则在五域集中式架构基础上进一步融合，把原本的动力域、底盘域和车身域融合为整车控制域，从而形成了三域集中式EEA，也即：车控域控制器（VDC，Vehicle Domain Controller）、智能驾驶域控制器（ADC，ADAS\AD Domain Controller）、智能座舱域控制器（CDC，Cockpit Domain Controller）。大众的MEB平台以及华为的CC架构都属于这种三域集中式EEA。

域集中式EE架构

域控制器市场概述

2018年，基于德尔福提供的域控制器技术，奥地利TTTech公司开发的zFAS控制器率先应用在奥迪A8当中。伟世通公司则推出了SmartCore域控制器，集成信息娱乐、仪表板、信息显示、HUD、ADAS等功能。这些产品开创了商用功能域控制器产品之先河，全球各大Tier 1供应商纷纷跟进，整个域控制器市场逐渐发展起来。

在国内市场，华为、德赛西威、航盛电子、东软等企业也推出了DCU解决方案，并得到了国内车企的采用。比如，2020年小鹏汽车推出的智能轿跑P7就采用了德赛西威基于英伟达Xavier打造的自动驾驶域控制器产品——IPU03。

当前，整个业界对DCU市场都有非常乐观的预期。据佐思产研的预测，2025年全球汽车DCU（座舱+自动驾驶）出货量将超过1400万套，2019-2025期间年平均增长高达50.7%。

全球域控制器市场预测

整个汽车行业普遍认为，域控制器是汽车电子行业未来竞争门槛最高的部分，因此利润也最高，芯片厂商和核心算法供应商将会受益。

（一）域控制器市场快速增长背后的驱动因素

更多更好的ADAS功能和智能座舱与信息娱乐功能一直是推动域控制器市场快速增长的主要因素，这些新功能能明显提高整车的科技感和用户体验，因此也是主机厂开发新车型时的投入重点。L1到L2+级别之间的ADAS应用是这几年发展非常快，很多功能都正在快速普及，比如：停车辅助、车道偏离预警、自适应巡航、碰撞避免、盲点侦测、驾驶员疲劳探测等。

域控制器需要一颗性能更强、集成度越高的主控处理器来作为其大脑，更多原本通过分离ECU实现的功能现在可以放到域主控处理器上来实现，也因此就能更加节省功能域里所需的ECU用量和其它硬件资源。更高的集成度可以更主机厂供应链管理实现ADAS域控和相关零部件平台化和标准化的要求。

（二）对域控制器供应链的影响

汽车E/E架构的演进和发展，也深刻影响了主机厂和汽车电子供应商的供应关系。主机厂的核心竞争力从以前的机械制造为主，全面转向软件和算法为重点。预计未来整车厂与Tier 1供应商之间将可能有两种合作模式：

其一，Tier 1负责域控制器硬件设计和生产，以及中间层Middleware软件部分。整车厂负责自动驾驶软件部分。Tier 1的优势在于以合理的成本将产品生产出来并且加速产品落地，因此整车厂和Tier 1进行合作生产方式是必然，前者负责自动驾驶软件部分，后者负责硬件生产、中间层以及芯片方案整合。这种模式下，在项目立项时，整车厂又可能跨过Tier 1直接与芯片厂商确定方案的芯片选型。
其二，Tier 1自己与芯片商合作，做方案整合后研发中央域控制器并向整车厂销售，例如大陆ADCU、采埃孚ProAI、麦格纳MAX4等。

智能座舱域控制器

座舱智能化的实质是基于汽车驾驶舱中的人机交互场景，将驾驶信息与娱乐信息两个模块进行集成，为用户提供高效的、直观的、充满未来科技感的驾驶体验。智能座舱的设计诉求主要是用于提升用户的驾乘体验，同时还要保证用户驾乘的安全性和舒适性，最终实现汽车作为人们工作和家庭场景以外的第三生活空间这一终极目标。

智能座舱域包括HUD、仪表盘（Cockpit）和车载娱乐信息系统（In-Vehicle Infotainment，简称IVI）三个最主要的组成部分。

HUD是非常实用的功能，将ADAS和部分导航功能投射到挡风玻璃上，诸如ACC、行人识别、LDW、路线提示、路口转弯提示、变道提示、剩余电量、可行驶里程等。HUD将很快会演变为AR HUD，在L3和L4时代成为标配。

进入L3时代，驾驶员状态监测（Driver Status Monitor，DMS）将成为必备的功能，包括：面部识别、眼球追踪、眨眼次数跟踪等将引入机器视觉和深度学习算法。而L4时代则必备V2X（Vehicle to everything）。

另外，多模态交互技术的蓬勃发展将会极大改变用户与汽车的交互模式。基于语音识别功能的语音交互技术越来越普及，常用于跟IVI系统的交互操作。进一步还能通过语音来对驾驶员进行情绪状态分析。当DMS系统检测到驾驶员昏昏欲睡时，系统可以通过播放音乐或者释放香味来唤醒驾驶员；基于多场景下的汽车座舱多模态交互技术未来一定会重新定义人机交互技术的发展。

所有这些智能座舱新技术的发展，都将推动对座舱域计算资源需求的暴增。

智能座舱域控制器领域，全球Tier 1厂商主要包括：博世、大陆汽车、哈曼、伟世通和Aptiv（安波福）等。中国本土企业主要有德赛西威、航盛和东软睿驰等。

全球主要座舱域控制器厂商信息

ADAS域控制器

ADAS域控制器通常需要连接多个摄像头、毫米波雷达、激光雷达等传感器设备，要具备多传感器融合、定位、路径规划、决策控制、无线通讯、高速通讯的能力，要完成包含图像识别、传感器数据处理等诸多功能，因此要完成大量运算，域控制器一般都要匹配一个核心运算力强的处理器，能够提供自动驾驶不同级别算力的支持，目前业内有NVIDIA、华为、瑞萨、NXP、TI、Mobileye、赛灵思、地平线等多个方案。

自动驾驶技术目前是全球科技行业最前沿的方向。L1到L2+级别的辅助驾驶技术和功能已经日趋成熟，搭载ADAS功能和应用的很多车型开始进入大规模量产。可以遇见L1/L2级别ADAS功能的市场渗透率将快速提升，而L3/L4级别自动驾驶系统仍处于小规模原型测试阶段。

当今的自动驾驶行业，中国市场绝对是主力。今年中国L2的搭载量预计突破80万，中国品牌占据绝大部分份额。未来中国市场ADAS功能的渗透率还将持续快速提高，中低端汽车所配置的ADAS功能将逐步增多。根据艾瑞咨询研究报告显示，预计2025年ADAS功能在乘用车市场可以达到65%左右的渗透率。L3级别的高速自动领航HWP功能和L4级别的AVP自动泊车功能，目前车型渗透率较低，未来提升空间较大。

中国ADAS功能市场渗透率预测

ADAS域控制器正在从过去的分布式系统架构演变到域集中式架构。过去一套ADAS系统，要有好几个独立的ECU才能实现，比如车道偏移和交通识别ECU、前向碰撞预警ECU、泊车辅助ECU等。现在有了功能强大的集中式ADAS域控制器后，一个域控制器就实现了所有功能。系统的软硬件复杂度大大降低，可靠性也得到了提高。

目前业内提供ADAS域控芯片平台的有NVIDIA、华为、瑞萨、NXP、TI、Mobileye，以及国内本土的地平线和黑芝麻等多个方案。下表2-2总结了全球主要ADAS域控制器厂商及其客户和伙伴信息。

全球主要ADAS域控制器厂商信息

域控制器发展趋势

域控制器的兴起对传统的汽车MCU厂商造成了极大的挑战，“因为MCU使用量将大大减少，传统的MCU产品其演进路线将不复存在”。

在分布式ECU时代，计算和控制的核心是MCU芯片，传输的基础核心是基于传统的CAN、LIN和FlexRay等低速总线。但在域控制器时代，高性能、高集成度的异构SoC芯片作为域的主控处理器，将成为域控制器的计算与控制的核心芯片。而汽车TSN（Time-Sensitive Network）以太网因为具有高带宽、实时和可靠的数据通信能力等特点，必将成为整车通信的核心基础设施，尤其是域主控处理器之间的通信主干网。

下面我们来简单分析一下域控制器以及核心的主控处理器的一些关键技术和趋势。

高性能

总的来说，对算力的需求提升一直是域控制器核心芯片发展的主要推动力。一方面原本由多个ECU完成的功能，现在需要依靠单一的域主控处理器来完成，并且还需要管理和控制所连接的各种传感器与执行器等。比如：底盘、动力传动系统和车身舒适电子系统的域主控处理器，其算力需求大约在10000DMIPS-15000DMIPS左右。

汽车域控制器对CPU DMIPS算力的需求预测

新的智能汽车，除了要更多的与人交互外，更需要大量的对环境进行感知，这就需要计算和处理海量的非结构化数据，因此座舱域和自动驾驶域都要求高性能的CPU，比如就座舱仪表的CPU算力而言，它其实跟一部高端智能手机的CPU算力差不多，约为50000DMIPS左右。此外，为了支持L2辅助驾驶功能或者更高级别的自动驾驶功能，需要运行很多视觉DNN模型算法，这就又额外需要上百TOPS的AI算力。

所以，各芯片厂商总是会尽量使用更先进的制程工艺、更先进的CPU核于与NPU核来尽量提高域主控芯片的CPU核心性能与NPU性能。

高异构性

伴随着AI技术在视觉领域的应用，基于视觉的自动驾驶方案逐渐兴起，这就需要在CPU的基础上加装擅长视觉算法的GPU芯片，从而形成“CPU+GPU”的解决方案。

不过，“CPU+GPU”组合也并非最优解决方案，因为 GPU 虽然具备较强的计算能力，但成本高、功耗大，由此又逐步引入了FPGA和 ASIC 芯片。

总体来看，单一类型的微处理器，无论是 CPU、GPU、FPGA还是ASIC，都无法满足更高阶的自动驾驶需求，域控制器中的主控芯片会走向集成“CPU+xPU”的异构式 SoC（xPU 包括 GPU/FPGA/ASIC等），从而能较好的支撑各种场景的硬件加速需求。

高集成度

从功能层面上，域控制器会整合集成越来越多的功能。比如动力系统域可能把发动机的控制、电机控制、BMS、车载充电机的控制组合在一起。有些主机厂甚至直接一步到位，将底盘、动力传动以及车身三大功能域直接整合成一个“整车控制域（Vehicle Domain Controller，VDC）”。

要支持这些功能的整合，作为域控制器的大脑，域主控处理器SoC就需要集成尽可能多的接口类型，比如：USB、Ethernet、I2C、SPI、CAN、LIN以及FlexRay等等，从而能连接和管理各种各样的ECU、传感器和执行器。

硬件虚拟化

对硬件虚拟化技术的需要主要来自两方面：（1）硬件资源的分区与隔离；（2）支持混合安全等级。

原本需要多个ECU实现的多个功能都整合到域控制器上后，势必会导致域控制器的软件更为复杂，这势必会导致整个软件系统的出错概率增加、可靠性下降。而且多个应用混合运行在同一个操作系统上，经常会出现故障传播（Failure Propagation），也就是一个应用出现问题后，会使得整个系统底层软件和硬件都处于紊乱状态，从而导致其它原本正常的应用也会开始出现故障。因此通过硬件虚拟化技术对硬件资源进行分区（Partition），使得各个功能对应的软硬件之间互相隔离（Isolation），以此保证整个系统的可靠性。

另一方面，在汽车电子系统中，通常不同的应用其对实时性要求和功能安全等级要求都不同。例如，根据ISO 26262标准，汽车仪表系统与娱乐信息系统属于不同的安全等级，具有不同的处理优先级。汽车仪表系统与动力系统密切相关，要求具有高实时性、高可靠性和强安全性，要求运行在底层实时操作系统上（比如QNX）。而信息娱乐系统主要为车内人机交互提供控制平台，追求多样化的应用与服务，以Linux和Android为主。为了实现混合安全等级的应用，实现不同的操作系统运行在同一个系统上，这就需要虚拟化技术的支持。

车载硬件虚拟化技术的核心是Hypervisor，它是一种运行在物理服务器和操作系统之间的中间层软件，可以允许多个不同虚机上的操作系统和应用共享一套基础物理硬件。当系统启动时，首先运行Hypervisor，由它来负责给每一台虚拟机分配适量的内存、CPU、网络、存储以及其它硬件资源等等（也就是对硬件资源进行分区），最后加载并启动所有虚拟机的客户操作系统。

一句话总结一下基于Hypervisor的优点：它提供了在同一硬件平台上承载异构操作系统的灵活性，同时实现了良好的高可靠性和故障控制机制, 以保证关键任务、硬实时应用程序和一般用途、不受信任的应用程序之间的安全隔离，实现了车载计算单元整合与算力共享。

ISO 26262功能安全

功能安全是汽车研发流程中非常关键的要素之一。随着系统复杂性的提高，来自系统失效和随机硬件失效的风险日益增加。ISO 26262标准制定的目的就是更好的规范和标准化汽车全生命周期中的功能安全管理和要求，包括：概念阶段、系统研发、硬件研发、软件研发、生产和操作过程、售后等环节，尤其重点在产品设计阶段如何定义和实现功能安全的目标。

载汽车功能安全标准ISO26262-5 2018 “产品开发：硬件层面附录D”中对处理器单元的诊断覆盖率推荐的安全技术措施中，双核锁步(dual-core lockstep)、非对称冗余和编码计算是三种典型的硬件冗余技术措施。除此之外，硬件BIST、软硬件Self-Test技术、ECC等也是常见的提高处理器安全特性的设计措施。

ISO26262标准中的功能安全芯片设计技术

双核锁步CPU是一种CPU冗余技术，在一个芯片中包含两个相同的处理器，一个作为master core，一个作为slave core，它们执行相同的代码并严格同步，master可以访问系统内存并输出指令，而slave不断执行在总线上的指令（即由主处理器获取的指令）。slave产生的输出，包括地址位和数据位，发送到比较逻辑模块，由master和slave总线接口的比较器电路组成，检查它们之间的数据、地址和控制线的一致性。检测到任何总线的值不一致时，就会发现其中一个CPU 上存在故障，但不会确定是哪个CPU故障。

这种CPU架构使得CPU自检独立于应用软件，不需要执行专门的指令集自检，实际运行的软件指令在每个时钟都进行比较，只需要测试软件用到的CPU资源，但这种架构不会对内存和总线进行检测，需要增加单独的检测方法以避免两个CPU的共模故障。

网络卸载引擎

汽车网络会存在多种通信总线。骨干网未来势必会基于TSN以太网来构建，但是从域主控处理器到ECU或者传感器之间的通信则仍然是基于传统的车载低速总线，比如：CAN、FlexRay等。域主控处理器作为域控制器的核心，是所有ECU和传感器通信的汇聚中心。因此如果要依靠CPU的算力来完成不同总线间的协议转换，以及跨域通信的网络包处理的话，势必会占用宝贵的CPU算力资源。

因此基于硬件来实现网络协议转换处理的网络卸载引擎，对于各个域（包括中央网关）的域主控处理器是非常重要的技术。

Security引擎

连接性（Connectivity）是汽车智能化发展的一个很重要的趋势，未来的汽车一定会像今天的手机一样随时保持连接到互联网中。因此如何阻止未经授权的网络访问，以保护汽车免于受到黑客的攻击，对未来的智能汽车而言就会变得极为重要。下一代硬件安全模块（Hardware Security Module，HSM）正在成为下一代车载网络通信的重要基础设施之一。

HSM对于完全的安全车载通信（Secure Onboard Communication，SecOC）是必不可少的。HSM能确保所接收到的数据的真实性，防止攻击者绕过相关的安全接口，入侵车载网络。

基于硬件的安全模块主要解决两个问题：

密钥泄漏问题：如果密钥存储在应用程序的代码或数据中，很容易被泄漏。所以有必要增加一个硬件模块，专门存储密钥。
Crypto算法加速：通过内核来直接进行加密或解密运算会占用大量CPU算力资源。因此，有必要通过硬件模块来进行加密解密算法的加速。

SHE（Secure Hardware Extension）标准是由奥迪和宝马公司合作制定的、针对硬件安全模块HSM的规范，它主要包括密码模块的硬件、硬件软件接口。这个规范已被广泛接受，很多针对汽车行业的微处理器都支持这个规范。

面向服务的软件架构SOA

ECU原先运行的软件大多数是按照Classic AutoSAR规范开发的软件系统，其中的应用软件一般都是静态调度（Static Scheduling）模式的，也即在系统运行时，程序中不同功能的函数按照事先定义好的排序文件依次调用、逐个运行。静态调度的优点是资源分配问题都是事先安排好的，车辆量产后就不会再改变，每个功能对应的函数代码具体运行时间也被提前锁定，是确定性的。因此这种设计对于汽车上很多对功能安全要求苛刻的场景是非常适合的。比如：决定安全气囊是否打开的功能函数就是固定地每隔几毫秒运行一次，以便紧急情况下可以及时打开。

承载计算和控制的底层硬件从分散的多个ECU集中到多核、异构的高性能域主控处理器后，相应的软件也会从分散向集中、从简单向复杂、从静态向动态进化。下图2-7显示了以后汽车域控制器上的典型软件架构：

域控制器上基于空分虚拟化技术的典型软件架构

操作系统层：最底层利用Hypervisor虚拟化技术对硬件资源进行分区(partition)，从而可以在每个虚机运行不同的操作系统。比如在上图中，虚机VM1中运行兼容POSIX实时操作系统标准（比如PSE 52）的RTOS，RTOS上通常要承载功能安全相关的应用和服务；虚机VM2中运行Linux这种完全POSIX标准的分时操作系统，上面通常运行管理相关的功能和服务；虚机VM3中运行的可能是原来在ECU上运行的Legacy应用。
中间件层：操作系统是不做任何与“车”特定相关工作的。为了让域主控处理器在汽车场景下使用，需要有很多软件或者中间件用于让域控制器满足汽车的电源管理标准、网络管理标准以及诊断标准等；车载域控制器需要比一般工业嵌入式系统有更高的可靠性要求，这样就需要在计算机OS基础上再附加对存储和通讯等各方面的安全保护和容错机制；同时，位了让车载域控制器能够在整车EE架构下运行，还需要提供时钟同步、日志跟踪以及服务管理和发现等功能。Adaptive AutoSAR规范定义了运行在Linux或者完全兼容POSIX 1003.1标准RTOS上的这一层与“车”相关的中间件标准；而传统运行在POSIX子集的RTOS或者BareMetal模式的中间件规范则由Classic AutoSAR标准定义。
应用层：上层应用基于AutoSAR标准的中间件来进行开发。随着汽车智能化和网联化相关的功能越来多，上层应用软件也越来越复杂。位了降低单个应用的整体复杂性，我们可以借鉴互联网的面向服务架构（SOA）的软件设计思想，将一个复杂应用拆分多个服务。每个服务实现得尽可能小，尽量实现成无状态方式的服务，以利于整个系统的开发、测试和软件重用。服务与服务之间通过事件或者消息总线（发布/订阅工作模式）来进行通信，并降低互相之间的耦合度。通过服务配置来管理服务之间的依赖性、服务的部署和启动，以及服务的健康状态检测等。

汽车以太网给车载系统通信带来一个革命性的变化，在中央计算式汽车EE架构下，整个车载系统可以被看作是一个分布式网络系统：中央计算平台是一个小型服务器集群，区域计算平台是边缘计算节点。在互联网或者大型分布式系统中，SOA架构设计理念已经被广泛使用了。因此当IP网络技术被广泛应用于汽车后，很多在互联网或者分布式计算中已经很成熟的软件技术，自然会被借鉴到新的汽车软件架构设计中来，比如：RPC技术、事件/消息总线、RESTful API设计等。

大型互联网数据中心中的服务器集群动辄几百、上千台服务器，每秒百万、千万级别的并发。车载系统尽管可以被看作是一个分布式网络系统，但是它却没有互联网大型服务器系统的高并发特征，相反，它更注重通信的实时性和可靠性。

车载系统在物理上是向集中式发展的，也就是原来通过多个分散ECU来实现的功能，渐渐集中到几个主要的高性能域控制器上。因此，尽管在软件设计上，我们会尽量按照SOA的思路拆分成一个一个小的服务，但是这些服务在部署上其实是集中式的。鉴于这种物理部署上的“集中”与运行时的“分布式”并存的特点，因此我们可以通过一系列技术手段来优化服务与服务之间的通信延迟（比如：通过共享内存技术）。这是车载分布式系统与互联网强调高并发特性的分布式系统之间另一个显著的差别。

域集中式EE架构会是未来相当长一段时间占主要地位的汽车EE架构，域控制器作为域集中式EE架构的核心，会在整个汽车产业链中占据越来越重要的地位。其相应的芯片和硬件方案、操作系统和算法等将会成为整个产业链各上下游厂家的争夺焦点。

深度汽车 span style 的智能汽车汽车软硬件 $汽车智能芯片

有关深度解读汽车域控制器的更多相关文章

Ruby Readline 在向上箭头上使控制台崩溃 - 2
当我在Rails控制台中按向上或向左箭头时，出现此错误:irb(main):001:0>/Users/me/.rvm/gems/ruby-2.0.0-p247/gems/rb-readline-0.4.2/lib/rbreadline.rb:4269:in`blockin_rl_dispatch_subseq':invalidbytesequenceinUTF-8(ArgumentError)我使用rvm来管理我的ruby安装。我正在使用=>ruby-2.0.0-p247[x86_64]我使用bundle来管理我的gem，并且我有rb-readline(0.4.2)(人们推荐的最少
ruby-on-rails - 带 Spring 锁的 Rails 4 控制台 - 2
我正在使用Ruby2.1.1和Rails4.1.0.rc1。当执行railsc时，它被锁定了。使用Ctrl-C停止，我得到以下错误日志:~/.rvm/gems/ruby-2.1.1/gems/spring-1.1.2/lib/spring/client/run.rb:47:in`gets':Interruptfrom~/.rvm/gems/ruby-2.1.1/gems/spring-1.1.2/lib/spring/client/run.rb:47:in`verify_server_version'from~/.rvm/gems/ruby-2.1.1/gems/spring-1.1.
ruby-on-rails - openshift 上的 rails 控制台 - 2
我将我的Rails应用程序部署到OpenShift，它运行良好，但我无法在生产服务器上运行“Rails控制台”。它给了我这个错误。我该如何解决这个问题？我尝试更新rubygems，但它也给出了权限被拒绝的错误，我也无法做到。railsc错误:Warning:You'reusingRubygems1.8.24withSpring.UpgradetoatleastRubygems2.1.0andrun`gempristine--all`forbetterstartupperformance./opt/rh/ruby193/root/usr/share/rubygems/rubygems
C51单片机——实现用独立按键控制LED亮灭（调用函数篇） - 2
说在前面这部分我本来是合为一篇来写的，因为目的是一样的，都是通过独立按键来控制LED闪灭本质上是起到开关的作用，即调用函数和中断函数。但是写一篇太累了，我还是决定分为两篇写，这篇是调用函数篇。在本篇中你主要看到这些东西！！！1.调用函数的方法（主要讲语法和格式）2.独立按键如何控制LED亮灭3.程序中的一些细节（软件消抖等）1.调用函数的方法思路还是比较清晰地，就是通过按下按键来控制LED闪灭，即每按下一次，LED取反一次。重要的是，把按键与LED联系在一起。我打算用K1来作为开关，看了一下开发板原理图，K1连接的是单片机的P31口，当按下K1时，P31是与GND相连的，也就是说，当我按下去时
深度学习部署：Windows安装pycocotools报错解决方法 - 2
深度学习部署：Windows安装pycocotools报错解决方法1.pycocotools库的简介2.pycocotools安装的坑3.解决办法更多Ai资讯：公主号AiCharm本系列是作者在跑一些深度学习实例时，遇到的各种各样的问题及解决办法，希望能够帮助到大家。ERROR:Commanderroredoutwithexitstatus1:'D:\Anaconda3\python.exe'-u-c'importsys,setuptools,tokenize;sys.argv[0]='"'"'C:\\Users\\46653\\AppData\\Local\\Temp\\pip-instal
ruby-on-rails - 在 Rails 控制台中使用 asset_path - 2
在我的Character模型中，我添加了:字符.rbbefore_savedoself.profile_picture_url=asset_path('icon.png')end但是，对于数据库中已存在的所有角色，它们的profile_picture_url为nil。因此，我想进入控制台并遍历所有这些并进行设置。在我试过的控制台中:Character.find_eachdo|c|c.profile_picture_url=asset_path('icon.png')end但这给出了错误:NoMethodError:undefinedmethod`asset_path'formain:O
ruby-on-rails - 带有 Pry 的 Rails 控制台 - 2
当我进入Rails控制台时，我已将pry设置为加载代替irb。我找不到该页面或不记得如何将其恢复为默认行为，因为它似乎干扰了我的Rubymine调试器。有什么建议吗？最佳答案我刚发现问题，pry-railsgem。忘记了它的目的是让“railsconsole”打开pry。关于ruby-on-rails-带有Pry的Rails控制台，我们在StackOverflow上找到一个类似的问题： https://stackoverflow.com/question
ruby - 将全局 $stdout 重新分配给控制台 - ruby - 2
我正在尝试将$stdout设置为临时写入一个文件，然后返回到一个文件。test.rb:old_stdout=$stdout$stdout.reopen("mytestfile.out",'w+')puts"thisgoesinmytestfile"$stdout=old_stdoutputs"thisshouldbeontheconsole"$stdout.reopen("mytestfile1.out",'w+')puts"thisgoesinmytestfile1:"$stdout=old_stdoutputs"thisshouldbebackontheconsole"这是输出。r
ruby-on-rails - Ruby 流量控制 : throw an exception, 返回 nil 还是让它失败？ - 2
我在思考流量控制的最佳实践。我应该走哪条路？1)不要检查任何东西并让程序失败(更清晰的代码，自然的错误消息):defself.fetch(feed_id)feed=Feed.find(feed_id)feed.fetchend2)通过返回nil静默失败(但是，“CleanCode”说，你永远不应该返回null):defself.fetch(feed_id)returnunlessfeed_idfeed=Feed.find(feed_id)returnunlessfeedfeed.fetchend3)抛出异常(因为不按id查找feed是异常的):defself.fetch(feed_id
ruby-on-rails - ruby 新手，有人可以帮我从控制台破译这个错误吗？ - 2
我真的只是不确定这意味着什么或我应该做什么才能让网页在我的本地主机上运行。现在它只是显示一个错误，上面写着“我们很抱歉，但出了点问题。”当我运行railsserver并在chrome中打开localhost:3000时。这是控制台输出:StartedGET"/users/sign_in"for127.0.0.1at2013-07-0512:07:07-0400ProcessingbyDevise::SessionsController#newasHTMLCompleted500InternalServerErrorin55msNoMethodError(undefinedmethod`