业余时间弄了一个 Linux 嵌入式应用开发框架，看看有没有其他人需要。

[rotcar]

背景

在一个不小的大厂里面拧螺丝，发现很多部门都在重复造轮子。没有引入好用的开源组件，自己造的轮子也没有复用，公司内部相同的轮子都有好几种。编译体系简陋，加个文件也要改编译脚本。也没有单元测试和其他的工具。

目标

我觉得这可能是很多嵌入式软件开发的普遍痛点吧。

于是业余时间参考esp32的idf框架esp-idf，搞了个 linux 应用开发框架RibbonBuild和RibbonDF，核心思想也是组件化,前者是组件化编译最小单元，后者是基于组件化编译搭建的工程，采用cmake+kconfig作为编译配置框架。目前已支持Linux交叉编译环境，RibbonDF已引入一部分嵌入式常用的开源组件，并在树莓派环境验证。

对比了一下 github 上的其他框架，RibbonBuild与c_cpp_project_framework比较相似，但采用了更camke原生的编译方式。并且在RibbonDF实现了工程化的组件搭建，以及引入gtest，gcov等工具，在工程化上更友好一点。 cmake-kconfig比较简单，需要进行一定程度适配。

end

有兴趣的朋友可以试试看。人生苦短，希望能让大家的工作轻松一点、高效一点。 第一次搞开源，很多地方不成熟，希望和大家友好交流，共同进步。

[rotcar]

@villivateur 你可以试用一下，还是上面的那句话，人生苦短，让工作轻松一点、高效一点。

[rotcar]

@afxcn 这个看业务形态。现在嵌入式很多时候也叫边缘计算。计算放在中心，和放在边缘各有优缺点，你说是吧。

[rotcar]

@chenxuuu 你说的这个要区分驱动开发和应用开发。应用开发的标准化更好一点，基本采用编译链的形式做跨平台。驱动开发和平台联系更紧密，跨平台更困难一些。我这个框架主要是解决应用开发中的问题。

[rotcar]

@FightPig 以后就懂了

[afxcn]

@rotcar 你说的确定是，我们也在这么做。

放在边缘的好处很多，就是维护升级麻烦。

#14 只是想表达一种现状而已，我看到的现状。

[Licsber]

@rotcar #19 对的 算是单平台 两款产品分别基于 ESP32S3 和 RK3568
后者感觉都不怎么算嵌入式的范畴 跑个 openwrt 在上面跑应用
ESP32S3 是从 ESP32 升级来的 代码几乎不动 能接的外设就多了

[UIXX]

有点言过其实了，其实把“嵌入式”三个字去掉，描述为 Linux 应用编译框架也没什么问题。

一个嵌入式框架不明确服务架构对象、不提供跨芯片兼容方案的核心实现、不讲究内核驱动...，光统一开发代码资源规则和提供可有可无的边缘工具解决不了嵌入式开发的痛点。如 15L 所说，嵌入式最麻烦的地方不是软件工程的实施上，而是上游不同厂商提供的多层次异构资源带来一系列管理问题，可能是沟通的错位、厂商的私有架构/代码、闭源的库、非标代码资源与文档...

在使用中，针对某一系列芯片/系统的 Build System/SDK 已经非常工程化了，可以打驱动补丁、可以装新应用、可以增加测试方案，对于新增的代码，配置修改更少，集成程度更好。再把内部的子功能挖出来重做一个框架不是不行，只是必要性不大，project create 和 copy paste 只是雅与俗的区别。

---------------------------------------------------------------------------------------

最好的嵌入式工具肯定要具有“蓝图”功能（不知道是不是有人做了），如果把 make 那一套东西迁移成蓝图模式，功德无量。