业余时间弄了一个 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

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

[loading]

你不做个带屏幕的小玩具是火不起来的，多学学电子网红。

[haikea]

厉害了，点赞

[electronic]

支持一下，点赞

[rotcar]

@loading 下一步有在考虑做一个智能音箱

[rotcar]

@haikea 谢谢

[rotcar]

@electronic 感谢支持

[muooOOO]

点赞支持，感觉大部分的嵌入式开发人员的技能树都比较杂，有这样一个工具确实不错，希望越来越好

[NessajCN]

确实有这样的痛点，不过我的解决方法是全迁移到 embedded rust 。cargo 把所有问题都解决了

[Licsber]

其实我也一直在思考 嵌入式框架到底是要做啥工作
ESP-IDF 干的 对我来说就是硬件的一层 API 抽象
开发者要做的也就是写一下 所谓的 main 逻辑
上电 -> Wi-Fi 联网 -> 外设交互 -> 序列化、服务器交互
这些我都封装好了各种功能函数 感觉称作框架不太适合 更像脚手架、工具包
框架听起来像是“模板” 使用的方式像是“克隆” 可谁会天天起新项目呢

况且 起一个新项目的成本可能远没这么高？只有 cpp 比较乱而已？
我现在用 micropython 要做的就是把写过的功能复制粘贴下
稍微改下逻辑 就又好了一个需求
感觉再进化下 我已经在研究拖拽式编程了（好多需求就是这么简单

最近就在学 esp-rs 体会到了传统 cpp 式的麻烦 make 来 make 去
也可能我一直路子比较野 没有过底层详细定制的经验 哈哈

[glcolof]

其实 arduino 那种框架就可以满足大部分需求了。

[FightPig]

挺厉害的，我自己对嵌入式一直不是很懂

[nooneanyone]

老哥, 纯软 cpplinux 方向的, 转嵌入式难么, 感觉 linux 后端岗位比较少, 想看看嵌入式会不会好点.

[villivateur]

支持一下，我现在的工作也遇到类似的问题

[afxcn]

嵌入式开发的代码量好像都很少，很多人都直接透传到服务器处理了。

[chenxuuu]

嵌入式开发的痛点主要是每家厂商提供的开发环境 sdk 都不一样，各种稀奇古怪的环境
如果再加上一些特殊架构，厂家闭源了一些库（比如蜂窝/蓝牙/wifi 芯片），那更复杂，编译器都不好换

总不可能自己手动把上千上万个文件的 sdk 手动改一遍格式，就算整理改好了，后续 sdk 升级还要再来一遍

[qiyilai]

@FightPig 可以理解为更加古早时期的软件开发，硬件不统一，也没有一个大一统的框架和统一的库，要自己实现的东西比较多

[rotcar]

@muooOOO 是的，所以从工程的角度，开发人员某些领域知识的欠缺需要这种框架性的东西来解决，提升开发的速度、效率和质量。这也是我做这个框架的原因。

[rotcar]

@NessajCN rust 是未来的发展方向。c/cpp 的开发，缺少包管理工具也一直是吐槽的点。另外目前嵌入式商业化的场景下，芯片平台是否支持 rust 编译链，flash/内存资源都是重要考虑因素，c/cpp 在这方面还是有不小优势。

[rotcar]

@Licsber 你目前还是在单平台、单产品上做开发吧。如果涉及跨平台、多产品的话，你就会体会到组件化，统一编译，代码复用的必要了。

[rotcar]

@nooneanyone 我认为不难的。嵌入式以 C 为主流，cpp 更少一些。你会 cpp ，c 应该也没啥问题。嵌入式主要还是要了解交叉编译开发环境、操作系统、计算机组成原理、计算机网络等相关知识，这些在工作中补也没啥问题。

[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 那一套东西迁移成蓝图模式，功德无量。