纠结裸机与os之间的切换

会飞的猪_2020

之前一直在裸机下写代码，积累了一堆可复用的代码库。例如串口、can、eeprom等等外设。


现在开始用os了。代码库迁移很纠结。

裸机代码都是非阻塞的，以串口、CAN等通讯接口为例子，read这个API抽象出去之后，一般都是在一个轮询里面读它。

OS代码里面的read，按照我目前的思路应该是阻塞的。例如while(1)里面调用read之后，由于有os，是可以阻塞在这里的。
直到有数据了才执行下一步，不依靠轮询。

我就纠结是裸机代码，放到一个轮询里按照裸机方式继续调用它好。
这种方式兼容最简单，坏处是放弃了部分OS的特性。


还是说加OSAL， 根据OS重写一套代码。

这种方式兼容复杂，不同OS可能无法抽象成一致的OSAL。并且要重写代码。
好处是可能也许会比上一种的性能好一点点？（不确定到底有无优化。）

eric2013

如果这些驱动代码在裸机下已经稳定了，什么都不用改，在OS下继续这么使用。
唯一要注意的是优先级问题，如果任务优先级高，空闲的地方注意释放CPU权限，方便低优先级的任务得到执行。

死不低头

不阻塞的任务，如果实时性没太高要求，直接把OS当裸机用也没问题吧，直接放在一个任务里

反正我是不太喜欢OS的，感觉没那么自由，我搞东西经常带几十甚至几百K的中断，我不知道OS里怎么处理这高频中断

sumji

OS也是能不阻塞就不阻塞的，实在没办法了才阻塞

lovesong1992

已有的接口放到soft timer中一直轮询，新开发的再按照OS的特性开发

egoistaw

哈哈我刚好相反，刚入行就是接管ucosii freertos项目，自己做项目选threadx，导致现在很不习惯裸机，稍微阻塞一下就要套层状态机

会飞的猪_2020

sumji 发表于 2026-6-15 09:07
OS也是能不阻塞就不阻塞的，实在没办法了才阻塞

这样吗？我的理解是OS要能阻塞就阻塞，因为它能多线程，会自己切换。
轮询是就当裸机在使用了。阻塞才用到了OS的特性...

上面这个是我的理解。

小梁呐

工作后反而没有一个项目用到了RTOS