一、需求分析
當前項目狀態較多，總線指令也持續較多，bug定位不是難事，難在主動發現bug，且原模塊之間關聯性較複雜，排查和改動都比較麻煩。所以決定在RTOS上重構代碼。
RTOS方案選擇有uCOS, Keil RTX, Free RTOS, RT-Thread。
二、方案選擇
uCOS有穩定的主要優勢，Keil RTX有開發上手簡單順暢的優勢，Free RTOS是相對於uCOS有商業免費的優勢，RT-Thread有完全開源免費，中文文檔，更新支持活躍，以及組件豐富的優勢。僅就目前需求來看，Keil RTX是最佳的選擇，時間不多，它可以在最短時間內用起來，難度也最低，但是考慮到異常時方便排查，後續融合功能平臺需求，也因爲前期主要了解的是它，同時也看重其組件豐富，更新速度可觀，先以RT-Thread作爲初步方案。
選用RT-Thread的劣勢不可忽視，現有MCU爲F103C8，ROM大小是第一個難點。其可靠Flash爲64k，最多可用128k。現有項目已劃分16k(BootLoader)+4k(Config)，則Application只有44k可靠容量，最多108k。原有APP工程大小爲20k，所以首先要嘗試將rtt kernel + shell的大小控制在20k以內，接下來是IAP功能和軟復位(boot與app互相跳轉而保持io狀態)的移植。
三、過程
計劃步驟：
1.kernel + shell ROM大小控制在20k以內；
2.iap+軟復位功能實現；
3.功能移植；
4.穩定性評估；
5.平臺與業務功能分離：通用基礎框架，編譯成庫便於獨立維護以及作爲通用工程模板；
6.平臺獨立維護：細化爲3個方向版本，體積小，適中，功能全；
1.方案初試
使用Keil Pack ,rtt 3.1.1，kernel + shell，額外增加串口驅動。
a. 實現console輸出接口可在最小體積下實現調試信息輸出，但還無法完成 rtt 強大的msh terminal.
void rt_hw_console_output(const char *str);
b. 實現串口驅動接口，註冊驅動
uart_ops =
{
uart.init,
uart.open,
uart.close,
uart.read,
uart.write,
uart.control, //非必須
uart.user_date; //非必須
};
register：
INIT_BOARD_EXPORT(rt_hw_usart_init); //板級初始化
(other options)
INIT_PREV_EXPORT(comp_soft_init_fun); //純參數、軟件一類的初始化
INIT_DEVICE_EXPORT(dev_init_fun); //設備初始化
INIT_COMPONENT_EXPORT(comp_init_fun); //組件初始化
INIT_ENV_EXPORT(env_init_fun); //環境初始化
INIT_APP_EXPORT(app_init_fun); //應用初始化
c. 測試msh功能。
四、結果
五、總結