背景
在一个不小的大厂里面拧螺丝，发现很多部门都在重复造轮子。没有引入好用的开源组件，自己造的轮子也没有复用，公司内部相同的轮子都有好几种。编译体系简陋，加个文件也要改编译脚本。也没有单元测试和其他的工具。
目标
我觉得这可能是很多嵌入式软件开发的普遍痛点吧。
于是业余时间参考esp32的idf框架esp-idf，搞了个 linux 应用开发框架RibbonBuild和RibbonDF，核心思想也是组件化,前者是组件化编译最小单元，后者是基于组件化编译搭建的工程，采用cmake+kconfig作为编译配置框架。目前已支持Linux交叉编译环境，RibbonDF已引入一部分嵌入式常用的开源组件，并在树莓派环境验证。
对比了一下 github 上的其他框架，RibbonBuild与c_cpp_project_framework比较相似，但采用了更camke原生的编译方式。并且在RibbonDF实现了工程化的组件搭建，以及引入gtest，gcov等工具，在工程化上更友好一点。
cmake-kconfig比较简单，需要进行一定程度适配。
end
有兴趣的朋友可以试试看。人生苦短，希望能让大家的工作轻松一点、高效一点。
第一次搞开源，很多地方不成熟，希望和大家友好交流，共同进步。

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

厉害了，点赞

支持一下，点赞

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

谢谢

感谢支持

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

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

其实我也一直在思考 嵌入式框架到底是要做啥工作ESP-IDF 干的 对我来说就是硬件的一层 API 抽象开发者要做的也就是写一下 所谓的 main 逻辑上电 -> Wi-Fi 联网 -> 外设交互 -> 序列化、服务器交互这些我都封装好了各种功能函数 感觉称作框架不太适合 更像脚手架、工具包框架听起来像是“模板” 使用的方式像是“克隆” 可谁会天天起新项目呢况且 起一个新项目的成本可能远没这么高？只有 cpp 比较乱而已？我现在用 micropython 要做的就是把写过的功能复制粘贴下稍微改下逻辑 就又好了一个需求感觉再进化下 我已经在研究拖拽式编程了（好多需求就是这么简单最近就在学 esp-rs 体会到了传统 cpp 式的麻烦 make 来 make 去也可能我一直路子比较野 没有过底层详细定制的经验 哈哈

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

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

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

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

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

嵌入式开发的痛点主要是每家厂商提供的开发环境 sdk 都不一样，各种稀奇古怪的环境如果再加上一些特殊架构，厂家闭源了一些库（比如蜂窝/蓝牙/wifi 芯片），那更复杂，编译器都不好换总不可能自己手动把上千上万个文件的 sdk 手动改一遍格式，就算整理改好了，后续 sdk 升级还要再来一遍

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

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

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

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

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

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

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

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

以后就懂了