大部分代码都是那个命令行界面，无论.text还是.econst代码都很多。
Arduino的bootloader只有512字节。

【 在 tom6bj (tom) 的大作中提到: 】
: 嗯, 我学你那个, 把命令行界面去掉之后可以降到2-3k
: 我的bootloader，自带的命令解释器，固件总体积7kB
--
FROM 36.45.174.*

久仰久仰...我工作里也经常用armink的库，节约了不少时间精力和人力...

暂时没在正式项目里用rt-thread，主要是考虑rt-thread的生态定位更偏向IoT领域，我们目前的产品面向工业控制和数据中心，对于很多rt-thread自带的功能，用kconfig直接配置启用确实非常方便，但是为了保证产品的可维护性，我们得把代码都通读过 了解原理 保证有问题自己接得住 才敢上生产环境。现在暂时没有精力去做这项工作，所以生产环境里还在用我们团队自己更熟悉的freertos和一些自己写的库。
最近也在考虑先在不太重要的场合下试试切换到rt-thread上去，磨合一段时间看看效果，比较麻烦的就是我们一些既有的库挪过去怕跟rtt的组件有冲突

【 在 ffxz 的大作中提到: 】
: 楼主哪里高就？换工作否
: rt-thread/finsh，把finsh本身砍掉，精简下只预msh，挺小巧的了
: rt-thread上类似的几个小东西挺顺手的，msh、ulog。armink的sfud、cmbacktrace。现在armink也在rt-thread，所以在rt-thread上整合得也更好了
: ...................
--
FROM 114.253.87.*

这个问题，作为总工，我的办法是，多花点钱换大容量的芯片，或者外置nor，留足够的空间余量让代码尽量通用化，代码功能上也尽量多做冗余，这样不光方便移植，方便后期维护，还能一处暴露问题 多处同步升级...

当然我们设备不是消费类电子跑量的，多十几块钱成本毛毛雨...≥kk量级的产品压缩成本到小数点后2位这个也完全理解，只能说还好我现在不用考虑这个
( o ω o )?

【 在 spadger 的大作中提到: 】
: 这个确实是使用rtos的最大障碍，不出问题还好，出了问题，定位起来太麻烦。
: 另外小容量器件确实用不起，flash根本存不下那么多通用代码。
: SFUD我试过最后还是放弃了，一般产品兼容三四种芯片就够了，代码可以很简化，不需要兼容那么多型号。
: ...................
--
FROM 114.253.87.*