1. 项目概述嵌入式软件商店的“驱动”革命最近在嵌入式开发圈里一个消息引起了我的注意Beningo Engineering 和 USA Firmware 这两家业内知名的嵌入式软件工程服务公司宣布合作共同为“嵌入式软件商店”提供驱动框架。这听起来可能有点技术化但简单来说它就像是为嵌入式硬件开发者们开了一个“官方应用商店”只不过里面卖的不是手机APP而是各种芯片、传感器、显示屏的“驱动程序包”。对于常年挣扎在底层驱动开发、移植和调试泥潭中的工程师来说这无疑是一个值得深入探讨的行业新动向。嵌入式开发尤其是涉及不同微控制器MCU和外设如Wi-Fi模块、传感器、电机驱动器时最耗时、最易出错的环节往往就是底层驱动。每个芯片厂商的SDK风格迥异寄存器配置如同天书移植一个驱动动辄花费数周调试起来更是让人头大。Beningo Engineering 和 USA Firmware 的这次合作瞄准的正是这个长期存在的痛点。他们计划将经过实战检验、高度模块化、可移植性强的驱动框架以标准化的形式放入一个集中的“软件商店”让开发者可以像下载库一样快速获取可靠、即用的驱动代码从而将精力聚焦于应用逻辑和创新本身。这不仅仅是两家公司的商业合作更可能预示着嵌入式软件开发模式向更高效、更标准化方向的一次重要演进。2. 合作背景与核心价值解析2.1 为何是Beningo Engineering与USA Firmware要理解这次合作的意义首先得看看这两家公司是谁以及他们各自带来了什么。Beningo Engineering在嵌入式系统设计、软件架构和实时操作系统RTOS应用领域深耕多年。他们的强项在于构建健壮、可维护且高性能的嵌入式软件系统尤其擅长将复杂的硬件抽象为清晰的软件接口。你可以把他们看作是“嵌入式系统的架构师”专注于设计蓝图和核心框架。USA Firmware则以其在固件Firmware开发、底层驱动编写以及跨平台BSP板级支持包开发方面的深厚积累而闻名。他们更贴近硬件精通各种MCU架构如ARM Cortex-M, RISC-V和外围设备协议如I2C, SPI, UART, USB。他们是“嵌入式系统的泥瓦匠”擅长将架构师的蓝图用扎实的代码在具体的硬件上实现。两者的结合恰好覆盖了从高层软件架构设计到底层硬件驱动实现的完整链条。Beningo提供顶层的框架设计、接口定义和集成方法论而USA Firmware则贡献经过千锤百炼的、针对具体芯片和模块的驱动实现。这种“框架设计驱动实现”的强强联合确保了最终交付到“嵌入式软件商店”的产品不仅结构优良、易于集成而且稳定可靠、经过充分测试。2.2 “嵌入式软件商店”与驱动框架解决了什么根本问题传统的嵌入式驱动开发模式存在几个显著的痛点重复造轮子与碎片化每个项目、每个团队甚至每个工程师都可能为同一款传感器或通信模块编写相似的驱动代码。这些代码质量参差不齐风格各异造成了巨大的资源浪费和技术债务。移植成本高昂当硬件平台升级比如从STM32F4换到STM32H7或者更换供应商比如从TI的传感器换到NXP的同类产品时原有的驱动往往需要大量修改甚至重写项目周期和风险随之增加。验证与测试门槛高一个稳定的驱动不仅要求功能正确还要考虑中断处理、DMA使用、电源管理、错误恢复等复杂场景。自行开发并充分测试一个工业级驱动需要深厚的经验和大量的时间。知识壁垒新手工程师面对复杂的芯片手册和时序图往往无从下手而资深工程师的经验又难以有效沉淀和复用。“嵌入式软件商店”引入驱动框架正是为了系统性地解决这些问题标准化与复用通过提供标准化的驱动框架如基于CMSIS-Driver或类似抽象层将硬件差异封装起来。开发者面对的不再是具体的寄存器而是统一的API如sensor_read(),display_draw()。即插即用与加速开发开发者可以从商店中直接选购针对其硬件平台的、预编译或源码形式的驱动包快速集成到项目中将开发时间从数周缩短到数天甚至数小时。质量保证由Beningo和USA Firmware这样的专业团队开发和维护的驱动经过了严格的测试和实际项目验证其稳定性和可靠性远高于临时编写的代码降低了项目的整体风险。知识沉淀与生态构建商店成为一个高质量驱动代码的集散地促进了最佳实践的分享和嵌入式开发生态的繁荣。3. 驱动框架的技术架构与核心特性3.1 可能的框架设计思路虽然合作方未公开具体的技术细节但基于行业最佳实践我们可以推测其驱动框架很可能包含以下层次和特性硬件抽象层HAL这是框架的基石。它会定义一套完全独立于具体MCU厂商的接口用于操作GPIO、时钟、中断控制器、DMA等核心外设。理想情况下这一层会紧密对齐或扩展类似ARM CMSISCortex Microcontroller Software Interface Standard这样的行业标准。外设驱动层在HAL之上是针对特定功能模块如I2C、SPI、UART、ADC、PWM的通用驱动。这些驱动使用HAL接口因此可以在不同MCU间移植。例如一个I2C驱动会提供i2c_init(),i2c_master_transmit()等函数其内部通过HAL来配置具体的I2C外设寄存器。设备驱动层这是最上层面向具体的终端设备如某型号的温湿度传感器、OLED显示屏、电机驱动芯片等。设备驱动调用底层的外设驱动如通过I2C驱动去读写传感器并提供高级的、语义清晰的API如BME280_read_temperature_humidity()。中间件与集成接口框架可能还会提供与主流RTOS如FreeRTOS, Zephyr, Azure RTOS的集成接口确保驱动可以在多任务环境中安全使用。同时也可能包含电源管理、错误日志、配置管理等功能模块。注意一个设计良好的驱动框架其各层之间应该是松耦合的。这意味着你可以替换底层的HAL实现比如从STM32换到NXP平台而无需修改上层的设备和外设驱动代码这是实现可移植性的关键。3.2 框架的核心技术特性基于Beningo和USA Firmware的专业背景我们可以预期他们的驱动框架将突出以下特性可配置性与模块化通过头文件配置或编译时选项允许开发者只包含项目所需的驱动模块最大限度地减少代码体积ROM/RAM占用这对于资源受限的嵌入式设备至关重要。实时性保证驱动代码会精心设计确保中断服务程序ISR尽可能短小避免在关键路径上使用动态内存分配以满足硬实时系统的要求。线程安全对于可能在多任务环境中被调用的驱动API会提供互斥锁等同步机制或者明确标注其使用约束。完备的错误处理API会返回明确的错误代码而不是简单地崩溃或陷入死循环。框架可能包含断言Assert机制在开发阶段帮助快速定位问题。详细的文档与示例除了代码注释还应提供完整的API手册、移植指南和丰富的示例工程降低开发者的学习成本。测试套件提供单元测试和集成测试用例方便开发者验证驱动在新平台上的功能也便于后续的回归测试。4. 对开发者工作流的实际影响与集成实操4.1 开发流程的变革假设“嵌入式软件商店”已经上线并提供了所需的驱动框架包一个典型的开发流程可能会变成这样硬件选型与清单确认确定项目使用的MCU型号、传感器、通信模块等。访问软件商店在商店中搜索对应的MCU平台支持包BSP和所需的具体设备驱动包如BME280驱动、SSD1306OLED驱动。获取与安装以源码包或库文件的形式下载驱动包。商店可能提供类似git submodule或包管理器如CMake的FetchContent, 或专用的嵌入式包管理工具的一键集成方式。项目集成将驱动包添加到项目目录或依赖管理中。在项目的配置文件中使能所需的驱动模块并设置正确的参数如I2C引脚号、 SPI速率等。在应用代码中包含相应的头文件调用设备驱动提供的API。编译与调试像往常一样编译项目。由于驱动是预适配和测试过的大部分低级错误如寄存器配置错误、时序问题将被避免调试工作将更多地集中在应用逻辑和系统集成层面。4.2 一个简化的集成示例以下是一个概念性的代码示例展示如何使用商店提供的驱动框架来读取一个传感器// 1. 包含商店提供的驱动头文件 #include “embedded_store/bsp_stm32h7xx.h” // MCU BSP #include “embedded_store/drv_i2c.h” // 通用I2C驱动 #include “embedded_store/dev_bme280.h” // BME280传感器设备驱动 // 2. 初始化通常在main函数开始处 void hardware_init(void) { // 初始化MCU系统时钟等BSP提供 bsp_system_init(); // 初始化I2C1外设使用驱动框架的配置结构体 i2c_config_t i2c1_cfg { .instance I2C1, .speed I2C_SPEED_STANDARD, // 100kHz .scl_pin {GPIOB, GPIO_PIN_8}, .sda_pin {GPIOB, GPIO_PIN_9}, }; i2c_init(i2c1_cfg); // 初始化BME280传感器传入其连接的I2C总线句柄 bme280_config_t sensor_cfg { .i2c_bus i2c1_cfg, // 关联到I2C1 .i2c_addr BME280_I2C_ADDR_PRIM, }; bme280_init(sensor_cfg); } // 3. 应用中使用 float read_temperature(void) { float temperature, humidity, pressure; // 直接调用设备驱动提供的简洁API bme280_read_data(temperature, humidity, pressure); return temperature; }从这个例子可以看出开发者完全不需要关心STM32H7的I2C寄存器如何配置也不需要去解读BME280传感器数据手册中的复杂补偿算法。所有底层细节都被框架封装了。实操心得在集成这类驱动框架时最关键的一步是仔细阅读其提供的配置指南。错误的总线速率、引脚映射或中断优先级设置仍然是导致驱动无法工作的常见原因。建议先运行驱动包自带的示例工程确保在标准硬件上能跑通再将其移植到自己的目标板上。5. 潜在挑战与开发者注意事项尽管前景美好但这种新模式也带来一些新的挑战和需要适应的地方。5.1 许可与成本模型这是最实际的问题。驱动框架是开源如MIT Apache 2.0还是商业许可如果是商业许可是“一次购买永久使用”的授权费模式还是按项目、按芯片数量收费的订阅模式不同的模式直接影响项目的成本和长期维护的灵活性。开发者需要仔细评估许可条款特别是关于修改、分发和产品化方面的限制。5.2 长期维护与更新驱动框架的维护者即Beningo和USA Firmware能否跟上芯片厂商的更新节奏当MCU厂商发布新的芯片型号或修复SDK中的bug时对应的BSP和驱动能否及时更新开发者需要考虑对特定版本框架的依赖风险以及未来升级的成本。5.3 深度定制与调试标准化框架在带来便利的同时也可能在一定程度上限制深度优化。如果项目有极致的性能如超低延迟中断处理或功耗要求可能需要修改框架底层代码。这时框架代码的可读性、结构清晰度以及是否允许修改就变得非常重要。此外当出现复杂bug时调试的深度会深入到框架内部要求开发者具备一定的框架理解能力。5.4 生态锁定风险一旦项目大量依赖某个特定的“嵌入式软件商店”及其驱动框架未来切换技术路线或服务提供商可能会产生较高的迁移成本。因此在架构设计上建议在自身应用逻辑与驱动框架之间增加一个薄薄的适配层将框架的API转换为项目内部统一的设备接口。这样未来更换底层驱动提供商时只需重写这个适配层而不必改动大量应用代码。6. 行业影响与未来展望Beningo Engineering与USA Firmware的这次合作可以看作是嵌入式软件行业向“软件定义硬件”和“开发即服务”模式迈进的一小步但却是非常扎实的一步。对中小企业和初创公司尤其有利它们往往缺乏足够的资源去深入打磨每一个底层驱动。通过采购高质量的驱动框架它们可以快速搭建产品原型将有限的人力投入到核心算法和差异化功能的开发上加速产品上市时间。促进硬件选型的标准化当驱动变得易于获取和集成时工程师在选择硬件时可能会更倾向于那些在“软件商店”中有良好驱动支持的芯片和模块从而间接推动硬件供应链的标准化。可能催生新的商业模式除了驱动框架本身围绕其进行的培训、技术支持、定制化开发、系统集成等服务也可能成为合作双方乃至整个生态的新增长点。从我个人的经验来看嵌入式开发的复杂性正在从“硬件驱动开发”向“系统集成与智能应用开发”转移。像这样的驱动框架商店如果能成功运营将像当年的开源操作系统和库一样极大地降低行业门槛让开发者能更专注于创造价值。当然其成功与否最终取决于框架本身的质量、易用性、性价比以及构建的社区生态。对于广大嵌入式开发者而言这无疑是一个值得关注和尝试的新工具。在下一个项目中如果遇到熟悉的传感器或模块或许可以先去看看“商店”里有没有现成的轮子这可能会为你节省下大量宝贵的时间。
嵌入式软件商店驱动框架：标准化开发，加速硬件创新
1. 项目概述嵌入式软件商店的“驱动”革命最近在嵌入式开发圈里一个消息引起了我的注意Beningo Engineering 和 USA Firmware 这两家业内知名的嵌入式软件工程服务公司宣布合作共同为“嵌入式软件商店”提供驱动框架。这听起来可能有点技术化但简单来说它就像是为嵌入式硬件开发者们开了一个“官方应用商店”只不过里面卖的不是手机APP而是各种芯片、传感器、显示屏的“驱动程序包”。对于常年挣扎在底层驱动开发、移植和调试泥潭中的工程师来说这无疑是一个值得深入探讨的行业新动向。嵌入式开发尤其是涉及不同微控制器MCU和外设如Wi-Fi模块、传感器、电机驱动器时最耗时、最易出错的环节往往就是底层驱动。每个芯片厂商的SDK风格迥异寄存器配置如同天书移植一个驱动动辄花费数周调试起来更是让人头大。Beningo Engineering 和 USA Firmware 的这次合作瞄准的正是这个长期存在的痛点。他们计划将经过实战检验、高度模块化、可移植性强的驱动框架以标准化的形式放入一个集中的“软件商店”让开发者可以像下载库一样快速获取可靠、即用的驱动代码从而将精力聚焦于应用逻辑和创新本身。这不仅仅是两家公司的商业合作更可能预示着嵌入式软件开发模式向更高效、更标准化方向的一次重要演进。2. 合作背景与核心价值解析2.1 为何是Beningo Engineering与USA Firmware要理解这次合作的意义首先得看看这两家公司是谁以及他们各自带来了什么。Beningo Engineering在嵌入式系统设计、软件架构和实时操作系统RTOS应用领域深耕多年。他们的强项在于构建健壮、可维护且高性能的嵌入式软件系统尤其擅长将复杂的硬件抽象为清晰的软件接口。你可以把他们看作是“嵌入式系统的架构师”专注于设计蓝图和核心框架。USA Firmware则以其在固件Firmware开发、底层驱动编写以及跨平台BSP板级支持包开发方面的深厚积累而闻名。他们更贴近硬件精通各种MCU架构如ARM Cortex-M, RISC-V和外围设备协议如I2C, SPI, UART, USB。他们是“嵌入式系统的泥瓦匠”擅长将架构师的蓝图用扎实的代码在具体的硬件上实现。两者的结合恰好覆盖了从高层软件架构设计到底层硬件驱动实现的完整链条。Beningo提供顶层的框架设计、接口定义和集成方法论而USA Firmware则贡献经过千锤百炼的、针对具体芯片和模块的驱动实现。这种“框架设计驱动实现”的强强联合确保了最终交付到“嵌入式软件商店”的产品不仅结构优良、易于集成而且稳定可靠、经过充分测试。2.2 “嵌入式软件商店”与驱动框架解决了什么根本问题传统的嵌入式驱动开发模式存在几个显著的痛点重复造轮子与碎片化每个项目、每个团队甚至每个工程师都可能为同一款传感器或通信模块编写相似的驱动代码。这些代码质量参差不齐风格各异造成了巨大的资源浪费和技术债务。移植成本高昂当硬件平台升级比如从STM32F4换到STM32H7或者更换供应商比如从TI的传感器换到NXP的同类产品时原有的驱动往往需要大量修改甚至重写项目周期和风险随之增加。验证与测试门槛高一个稳定的驱动不仅要求功能正确还要考虑中断处理、DMA使用、电源管理、错误恢复等复杂场景。自行开发并充分测试一个工业级驱动需要深厚的经验和大量的时间。知识壁垒新手工程师面对复杂的芯片手册和时序图往往无从下手而资深工程师的经验又难以有效沉淀和复用。“嵌入式软件商店”引入驱动框架正是为了系统性地解决这些问题标准化与复用通过提供标准化的驱动框架如基于CMSIS-Driver或类似抽象层将硬件差异封装起来。开发者面对的不再是具体的寄存器而是统一的API如sensor_read(),display_draw()。即插即用与加速开发开发者可以从商店中直接选购针对其硬件平台的、预编译或源码形式的驱动包快速集成到项目中将开发时间从数周缩短到数天甚至数小时。质量保证由Beningo和USA Firmware这样的专业团队开发和维护的驱动经过了严格的测试和实际项目验证其稳定性和可靠性远高于临时编写的代码降低了项目的整体风险。知识沉淀与生态构建商店成为一个高质量驱动代码的集散地促进了最佳实践的分享和嵌入式开发生态的繁荣。3. 驱动框架的技术架构与核心特性3.1 可能的框架设计思路虽然合作方未公开具体的技术细节但基于行业最佳实践我们可以推测其驱动框架很可能包含以下层次和特性硬件抽象层HAL这是框架的基石。它会定义一套完全独立于具体MCU厂商的接口用于操作GPIO、时钟、中断控制器、DMA等核心外设。理想情况下这一层会紧密对齐或扩展类似ARM CMSISCortex Microcontroller Software Interface Standard这样的行业标准。外设驱动层在HAL之上是针对特定功能模块如I2C、SPI、UART、ADC、PWM的通用驱动。这些驱动使用HAL接口因此可以在不同MCU间移植。例如一个I2C驱动会提供i2c_init(),i2c_master_transmit()等函数其内部通过HAL来配置具体的I2C外设寄存器。设备驱动层这是最上层面向具体的终端设备如某型号的温湿度传感器、OLED显示屏、电机驱动芯片等。设备驱动调用底层的外设驱动如通过I2C驱动去读写传感器并提供高级的、语义清晰的API如BME280_read_temperature_humidity()。中间件与集成接口框架可能还会提供与主流RTOS如FreeRTOS, Zephyr, Azure RTOS的集成接口确保驱动可以在多任务环境中安全使用。同时也可能包含电源管理、错误日志、配置管理等功能模块。注意一个设计良好的驱动框架其各层之间应该是松耦合的。这意味着你可以替换底层的HAL实现比如从STM32换到NXP平台而无需修改上层的设备和外设驱动代码这是实现可移植性的关键。3.2 框架的核心技术特性基于Beningo和USA Firmware的专业背景我们可以预期他们的驱动框架将突出以下特性可配置性与模块化通过头文件配置或编译时选项允许开发者只包含项目所需的驱动模块最大限度地减少代码体积ROM/RAM占用这对于资源受限的嵌入式设备至关重要。实时性保证驱动代码会精心设计确保中断服务程序ISR尽可能短小避免在关键路径上使用动态内存分配以满足硬实时系统的要求。线程安全对于可能在多任务环境中被调用的驱动API会提供互斥锁等同步机制或者明确标注其使用约束。完备的错误处理API会返回明确的错误代码而不是简单地崩溃或陷入死循环。框架可能包含断言Assert机制在开发阶段帮助快速定位问题。详细的文档与示例除了代码注释还应提供完整的API手册、移植指南和丰富的示例工程降低开发者的学习成本。测试套件提供单元测试和集成测试用例方便开发者验证驱动在新平台上的功能也便于后续的回归测试。4. 对开发者工作流的实际影响与集成实操4.1 开发流程的变革假设“嵌入式软件商店”已经上线并提供了所需的驱动框架包一个典型的开发流程可能会变成这样硬件选型与清单确认确定项目使用的MCU型号、传感器、通信模块等。访问软件商店在商店中搜索对应的MCU平台支持包BSP和所需的具体设备驱动包如BME280驱动、SSD1306OLED驱动。获取与安装以源码包或库文件的形式下载驱动包。商店可能提供类似git submodule或包管理器如CMake的FetchContent, 或专用的嵌入式包管理工具的一键集成方式。项目集成将驱动包添加到项目目录或依赖管理中。在项目的配置文件中使能所需的驱动模块并设置正确的参数如I2C引脚号、 SPI速率等。在应用代码中包含相应的头文件调用设备驱动提供的API。编译与调试像往常一样编译项目。由于驱动是预适配和测试过的大部分低级错误如寄存器配置错误、时序问题将被避免调试工作将更多地集中在应用逻辑和系统集成层面。4.2 一个简化的集成示例以下是一个概念性的代码示例展示如何使用商店提供的驱动框架来读取一个传感器// 1. 包含商店提供的驱动头文件 #include “embedded_store/bsp_stm32h7xx.h” // MCU BSP #include “embedded_store/drv_i2c.h” // 通用I2C驱动 #include “embedded_store/dev_bme280.h” // BME280传感器设备驱动 // 2. 初始化通常在main函数开始处 void hardware_init(void) { // 初始化MCU系统时钟等BSP提供 bsp_system_init(); // 初始化I2C1外设使用驱动框架的配置结构体 i2c_config_t i2c1_cfg { .instance I2C1, .speed I2C_SPEED_STANDARD, // 100kHz .scl_pin {GPIOB, GPIO_PIN_8}, .sda_pin {GPIOB, GPIO_PIN_9}, }; i2c_init(i2c1_cfg); // 初始化BME280传感器传入其连接的I2C总线句柄 bme280_config_t sensor_cfg { .i2c_bus i2c1_cfg, // 关联到I2C1 .i2c_addr BME280_I2C_ADDR_PRIM, }; bme280_init(sensor_cfg); } // 3. 应用中使用 float read_temperature(void) { float temperature, humidity, pressure; // 直接调用设备驱动提供的简洁API bme280_read_data(temperature, humidity, pressure); return temperature; }从这个例子可以看出开发者完全不需要关心STM32H7的I2C寄存器如何配置也不需要去解读BME280传感器数据手册中的复杂补偿算法。所有底层细节都被框架封装了。实操心得在集成这类驱动框架时最关键的一步是仔细阅读其提供的配置指南。错误的总线速率、引脚映射或中断优先级设置仍然是导致驱动无法工作的常见原因。建议先运行驱动包自带的示例工程确保在标准硬件上能跑通再将其移植到自己的目标板上。5. 潜在挑战与开发者注意事项尽管前景美好但这种新模式也带来一些新的挑战和需要适应的地方。5.1 许可与成本模型这是最实际的问题。驱动框架是开源如MIT Apache 2.0还是商业许可如果是商业许可是“一次购买永久使用”的授权费模式还是按项目、按芯片数量收费的订阅模式不同的模式直接影响项目的成本和长期维护的灵活性。开发者需要仔细评估许可条款特别是关于修改、分发和产品化方面的限制。5.2 长期维护与更新驱动框架的维护者即Beningo和USA Firmware能否跟上芯片厂商的更新节奏当MCU厂商发布新的芯片型号或修复SDK中的bug时对应的BSP和驱动能否及时更新开发者需要考虑对特定版本框架的依赖风险以及未来升级的成本。5.3 深度定制与调试标准化框架在带来便利的同时也可能在一定程度上限制深度优化。如果项目有极致的性能如超低延迟中断处理或功耗要求可能需要修改框架底层代码。这时框架代码的可读性、结构清晰度以及是否允许修改就变得非常重要。此外当出现复杂bug时调试的深度会深入到框架内部要求开发者具备一定的框架理解能力。5.4 生态锁定风险一旦项目大量依赖某个特定的“嵌入式软件商店”及其驱动框架未来切换技术路线或服务提供商可能会产生较高的迁移成本。因此在架构设计上建议在自身应用逻辑与驱动框架之间增加一个薄薄的适配层将框架的API转换为项目内部统一的设备接口。这样未来更换底层驱动提供商时只需重写这个适配层而不必改动大量应用代码。6. 行业影响与未来展望Beningo Engineering与USA Firmware的这次合作可以看作是嵌入式软件行业向“软件定义硬件”和“开发即服务”模式迈进的一小步但却是非常扎实的一步。对中小企业和初创公司尤其有利它们往往缺乏足够的资源去深入打磨每一个底层驱动。通过采购高质量的驱动框架它们可以快速搭建产品原型将有限的人力投入到核心算法和差异化功能的开发上加速产品上市时间。促进硬件选型的标准化当驱动变得易于获取和集成时工程师在选择硬件时可能会更倾向于那些在“软件商店”中有良好驱动支持的芯片和模块从而间接推动硬件供应链的标准化。可能催生新的商业模式除了驱动框架本身围绕其进行的培训、技术支持、定制化开发、系统集成等服务也可能成为合作双方乃至整个生态的新增长点。从我个人的经验来看嵌入式开发的复杂性正在从“硬件驱动开发”向“系统集成与智能应用开发”转移。像这样的驱动框架商店如果能成功运营将像当年的开源操作系统和库一样极大地降低行业门槛让开发者能更专注于创造价值。当然其成功与否最终取决于框架本身的质量、易用性、性价比以及构建的社区生态。对于广大嵌入式开发者而言这无疑是一个值得关注和尝试的新工具。在下一个项目中如果遇到熟悉的传感器或模块或许可以先去看看“商店”里有没有现成的轮子这可能会为你节省下大量宝贵的时间。
