这是一个创建于 57 天前的主题，其中的信息可能已经有所发展或是发生改变。
背景
在一个不小的大厂里面拧螺丝，发现很多部门都在重复造轮子。没有引入好用的开源组件，自己造的轮子也没有复用，公司内部相同的轮子都有好几种。编译体系简陋，加个文件也要改编译脚本。也没有单元测试和其他的工具。
目标
我觉得这可能是很多嵌入式软件开发的普遍痛点吧。
于是业余时间参考esp32的idf框架esp-idf，搞了个 linux 应用开发框架RibbonBuild和RibbonDF，核心思想也是组件化,前者是组件化编译最小单元，后者是基于组件化编译搭建的工程，采用cmake+kconfig作为编译配置框架。目前已支持Linux交叉编译环境，RibbonDF已引入一部分嵌入式常用的开源组件，并在树莓派环境验证。
对比了一下 github 上的其他框架，RibbonBuild与c_cpp_project_framework比较相似，但采用了更camke原生的编译方式。并且在RibbonDF实现了工程化的组件搭建，以及引入gtest，gcov等工具，在工程化上更友好一点。
cmake-kconfig比较简单，需要进行一定程度适配。
end
有兴趣的朋友可以试试看。人生苦短，希望能让大家的工作轻松一点、高效一点。 第一次搞开源，很多地方不成熟，希望和大家友好交流，共同进步。
27 条回复 • 2024-10-09 15:56:12 +08:00
 |
1
loading 57 天前  6
你不做个带屏幕的小玩具是火不起来的，多学学电子网红。
|
 |
2
haikea 57 天前
厉害了，点赞
|
 |
3
electronic 57 天前
支持一下，点赞
|
 |
6
rotcar OP @electronic 感谢支持
|
 |
7
muooOOO 57 天前 via Android
点赞支持，感觉大部分的嵌入式开发人员的技能树都比较杂，有这样一个工具确实不错，希望越来越好
|
 |
8
NessajCN 57 天前 via Android
确实有这样的痛点，不过我的解决方法是全迁移到 embedded rust 。cargo 把所有问题都解决了
|
 |
9
Licsber 57 天前
其实我也一直在思考 嵌入式框架到底是要做啥工作
ESP-IDF 干的 对我来说就是硬件的一层 API 抽象 开发者要做的也就是写一下 所谓的 main 逻辑 上电 -> Wi-Fi 联网 -> 外设交互 -> 序列化、服务器交互 这些我都封装好了各种功能函数 感觉称作框架不太适合 更像脚手架、工具包 框架听起来像是“模板” 使用的方式像是“克隆” 可谁会天天起新项目呢 况且 起一个新项目的成本可能远没这么高？只有 cpp 比较乱而已？ 我现在用 micropython 要做的就是把写过的功能复制粘贴下 稍微改下逻辑 就又好了一个需求 感觉再进化下 我已经在研究拖拽式编程了（好多需求就是这么简单 最近就在学 esp-rs 体会到了传统 cpp 式的麻烦 make 来 make 去 也可能我一直路子比较野 没有过底层详细定制的经验 哈哈 |
 |
10
glcolof 57 天前
其实 arduino 那种框架就可以满足大部分需求了。
|
 |
11
FightPig 57 天前
挺厉害的，我自己对嵌入式一直不是很懂
|
 |
12
nooneanyone 57 天前
老哥, 纯软 cpplinux 方向的, 转嵌入式难么, 感觉 linux 后端岗位比较少, 想看看嵌入式会不会好点.
|
 |
13
villivateur 56 天前
支持一下，我现在的工作也遇到类似的问题
|
 |
14
afxcn 56 天前
嵌入式开发的代码量好像都很少，很多人都直接透传到服务器处理了。
|
 |
15
chenxuuu 56 天前
嵌入式开发的痛点主要是每家厂商提供的开发环境 sdk 都不一样，各种稀奇古怪的环境
如果再加上一些特殊架构，厂家闭源了一些库（比如蜂窝/蓝牙/wifi 芯片），那更复杂，编译器都不好换 总不可能自己手动把上千上万个文件的 sdk 手动改一遍格式，就算整理改好了，后续 sdk 升级还要再来一遍 |
|
18
rotcar OP @NessajCN rust 是未来的发展方向。c/cpp 的开发，缺少包管理工具也一直是吐槽的点。另外目前嵌入式商业化的场景下，芯片平台是否支持 rust 编译链，flash/内存资源都是重要考虑因素，c/cpp 在这方面还是有不小优势。
|
|
20
rotcar OP @nooneanyone 我认为不难的。嵌入式以 C 为主流，cpp 更少一些。你会 cpp ，c 应该也没啥问题。嵌入式主要还是要了解交叉编译开发环境、操作系统、计算机组成原理、计算机网络等相关知识，这些在工作中补也没啥问题。
|
|
21
rotcar OP @villivateur 你可以试用一下，还是上面的那句话，人生苦短，让工作轻松一点、高效一点。
|
|
23
rotcar OP @chenxuuu 你说的这个要区分驱动开发和应用开发。应用开发的标准化更好一点，基本采用编译链的形式做跨平台。驱动开发和平台联系更紧密，跨平台更困难一些。我这个框架主要是解决应用开发中的问题。
|
|
26
Licsber 55 天前
@rotcar #19 对的 算是单平台 两款产品分别基于 ESP32S3 和 RK3568
后者感觉都不怎么算嵌入式的范畴 跑个 openwrt 在上面跑应用 ESP32S3 是从 ESP32 升级来的 代码几乎不动 能接的外设就多了 |
 |
27
UIXX 55 天前
有点言过其实了，其实把“嵌入式”三个字去掉，描述为 Linux 应用编译框架也没什么问题。
一个嵌入式框架不明确服务架构对象、不提供跨芯片兼容方案的核心实现、不讲究内核驱动...，光统一开发代码资源规则和提供可有可无的边缘工具解决不了嵌入式开发的痛点。如 15L 所说，嵌入式最麻烦的地方不是软件工程的实施上，而是上游不同厂商提供的多层次异构资源带来一系列管理问题，可能是沟通的错位、厂商的私有架构/代码、闭源的库、非标代码资源与文档... 在使用中，针对某一系列芯片/系统的 Build System/SDK 已经非常工程化了，可以打驱动补丁、可以装新应用、可以增加测试方案，对于新增的代码，配置修改更少，集成程度更好。再把内部的子功能挖出来重做一个框架不是不行，只是必要性不大，project create 和 copy paste 只是雅与俗的区别。 --------------------------------------------------------------------------------------- 最好的嵌入式工具肯定要具有“蓝图”功能（不知道是不是有人做了），如果把 make 那一套东西迁移成蓝图模式，功德无量。 |
Select Language