【讨论】“嵌入式裸奔”、“嵌入式OS”、“OS”各适合什么场合？

农民讲习所

【讨论】“嵌入式裸奔”、“嵌入式OS”、“OS”各适合什么场合？ [复制链接]

如果你只能用的心： A)如果你手上是4位MCU？ B)如果你手上是8位MCU？ C)如果你手上是16位MCU？ D)如果你手上是外设不多的32位MCU？ E)如果你手上是外设丰富的32位MCU？ F)如果你手上是外设极其丰富的64位MCU？ 你要做什么产品： a)如果你想做的是民用小产品？ b)如果你想做的是简单控制的工业产品？ c)如果你想做的是复杂控制的工业产品？ d)如果你想做的是高科技产品？ e)如果你想做的是PC？ 你将怎么选择： 1）如果你只会“嵌入式裸奔”？ 2）如果你只会“嵌入式OS”？ 3）如果你只会“OS”？ 4）如果你精通其中一种或两种？ 5）如果你什么都会？ 6）如果你什么都不会？

dld2

穿衣服的时候希望能冷了加件毛衣，热了脱掉外套。这样才能适应或简单或复杂、或资源紧缺或吃穿不愁的应用环境。

农民讲习所

毕竟“嵌入式黑奔”太难学很多，学好了什么OS都能做出来。但反对“嵌入式黑奔”就是俺要坚决抵制的，“嵌入式黑奔”包含的基础设计理论太多。基础设计理论学不好，用OS也只是站在巨人脚板上的一只蚂蚁，可千万别认为自己站到了巨人的肩膀上了。

圆圈

我倒是很感兴趣~~~ 因为在我经历里，只有普通单片机程序+中断===〉单线程状态机+中断====〉多线程+中断 学习学习

dai_weis

4Bit的就不要想OS了 基本上连使用C编程都被禁止了，哪有那么多的地方？ 8Bit的要看FLASH和RAM的大小，太小的话，想不裸奔都难，撑爆了可就飞程序了

圆圈

我把ucos代码可是基本都读懂了的，对于如何实现任务调度，内存管理我也可是比较清楚实现细节的，所以我也说过，不是你写不了普通得os，而问题是有没必要，而且你得os稳定吗？ 真不想说这些没实质性的东西~~

农民讲习所

“嵌入式裸奔”相对于“裸奔”，多了可以大幅度提高了程序的健壮性的许多规则和约束，多了可以高度复用代码的模块标准化、可以最小代码化的可裁剪化，有OS特点，无OS讲究的通用性。

农民讲习所

俺做的比LINUX和WINCE还稳定，何况ucos

农民讲习所

俺的“嵌入式裸奔”一个程序 #include "libRain_M128.h" #include "MyLib.h" #include "Driver\UmIo.h" #include "Protocol\Protocol.h" #include "Task\Task.h" #include "Task\ImportKey.h" #include "Task\PWM_Wkv.h" #include "Triggle\Triggle.h" #include "Task\XPower.h" #include "Task\WaterLoop.h" #include "WorkLed\WorkLed.h" //-------------------------------------------------------- //5ms中断回调函数 //-------------------------------------------------------- void CallBack_5msInterrupt( void ) { } //-------------------------------------------------------- //20ms中断回调函数 //-------------------------------------------------------- void CallBack_20msInterrupt( void ) { } //-------------------------------------------------------- //析构 //-------------------------------------------------------- void Main_Destory( void ) { WatchDog_Destory(); //--------------------------user--------------------- Triggle_Destory(); PWM_Wkv_Destory(); ImportKey_Destory(); Task_Destory(); Protocol_Destory(); UmIo_Destory(); //--------------------------System--------------------- WorkLed_Destory(); Package_Destory(); VirtualUart80_Destory(); Uart80_Destory(); Uart81_Destory(); EDataBase_Destory(); CPU_Eeprom_Destory(); MyLib_Destory(); } //-------------------------------------------------------- //初始化 //-------------------------------------------------------- void Main_Init( void ) { //--------------------------System--------------------- MyLib_Init(); CPU_Eeprom_Init(); EDataBase_Init( 4, 1, 500, CPU_Eeprom_Cmd ); Uart80_Setup( OSC_7p3728MHz_4800, (eUart80_NoneChk | eUart80_Stop1Bit), 250, 250 ); Uart81_Setup( OSC_7p3728MHz_4800, (eUart80_NoneChk | eUart80_Stop1Bit), 250, 250 ); VirtualUart80_Setup( 200, 200 ); //配置信息在VirtualUart80_IO.c中 Package_Init( 3 ); //三个协议转换任务 //--------------------------user--------------------- UmIo_Init(); Protocol_Init(); Task_Init(); ImportKey_Init(); PWM_Wkv_Init(); Triggle_Init(); XPower_Init(); WaterLoop_Init(); WorkLed_Init(); } //-------------------------------------------------------- //主程序 //-------------------------------------------------------- int main( void ) { Main_Init(); Msg_RunInit(); //执行完全部初始化消息 WatchDog_Init(); //看门狗初始化 sei(); Package_Send( psUart_Import, eProto_RequAllState ); //开始主循环 while(1){ //--------------------------System--------------------- MyLib_MainLoop(); CPU_Eeprom_MainLoop(); EDataBase_MainLoop(); VirtualUart80_MainLoop(); Uart80_MainLoop(); Uart81_MainLoop(); Package_MainLoop(); //--------------------------user--------------------- UmIo_MainLoop(); Protocol_MainLoop(); PWM_Wkv_MainLoop(); Task_MainLoop(); ImportKey_MainLoop(); Triggle_MainLoop(); XPower_MainLoop(); WaterLoop_MainLoop(); WatchDog_MainLoop(); WorkLed_MainLoop(); } } 只要任意再添加一百个任务，即使TCP/IP也可以（当然要改造下），只要MCU能处理过来，同样也可以user下面任何一个任务去掉，而其它任务工作正常。这就是规则和约束的好处。

athlon64fx

不排斥OS，也不是所有的情况下OS都比裸奔好.. 如果裸奔是徒步,那么OS就好比驾车..而车也要分自行车,摩托车,汽车,火车等.. 个人以为这个比喻比较恰当。

athlon64fx

我以前是这样的， uint8_t s = wait_signal(TIMEOUT | ADC | KEY, timeout); if(s & TIMEOUT) // ... if(s & ADC) // ... if(s & KEY) { switch(get_key()) { case KEY_UP: // ... default: // ... } }

圆圈

也就是你现在将系统划分为三条线|任务，对吧。两条中断任务（你将他设计成任务了），另外一条主循环任务，主循环放非实时处理任务，两个中断任务满足更强的实时性需求。应该是这样吧~~ 没错，这个程序基本算是个通用的模式了~ 一般情况下确实能满足需求了。不过并不是所有需求都能满足的，因为你的中断处理能力毕竟是受限制的，而且你的任务只有这么几个，你不可能再多开个八个10个任务吧，如果你认为将这些任务放到其中某个任务内串接就算解决问题的话，那对我来说，不管如何加，实质上这都还只是3个任务（线程）。这个我想也是赞同的吧~ 不过呢，你的框架结构确实通用，可移植性也强。但是你把刀玩神了之余可也不能忘记外面还有飞机大炮坦克的啊~~ 赫赫~~ 我这么说不要生气，没有恶意的实话~~

huchuan987

呵呵,要OS也要学会裸奔~~~~~