rtthread套娃移植
和大家分享下將基于rtthread的項目移植到其他平臺的經驗。
背景
最近做了一個物聯網項目移植。原先的項目使用的硬件平臺為stm32f401+sim800c(mcu + 2G modem),軟件平臺為rtthread 4.0.1。移植到的新平臺為BC25(nb modem),軟件平臺為BC25 opencpu sdk,也跑了個RTOS,具體不詳。BC25不支持rtthread,筆者也無法移植rtthread到BC25,因為BC25只提供了一套SDK接口,無源碼,無芯片手冊。
opencpu簡介
可能有些同學不了解opencpu,這里簡單解釋下。傳統的單片機聯網平臺是mcu+modem,mcu通過AT命令與modem交互。modem也是有cpu的,而且由于其要運行網絡協議棧,RAM和FLASH資源比普通單片機豐富。因此有些modem提供了opencpu功能,讓客戶的業務代碼能跑在modem中,這樣就省去了mcu及周邊遠器件。
BC25 sdk提供了線程、線程間通信、驅動等接口。不過和rtthread的接口相比,其操作系統接口很不完備。比如:
- 獲取信號量的接口,只支持兩種方式:無堵塞(獲取不到,立刻返回失敗),死等(獲取不到就一直等)。缺少折中方案:設置等待的時間,超時則返回失敗。
- 最多可創建5個互斥量。。。
- 用戶程序最多可使用8個線程,而且是在代碼中通過宏列表寫死。不支持動態創建線程。
直接使用BC25的SDK的話,就需要對原來的業務代碼做很多改動。比如用到信號量的地方,不僅僅是將rt_sem_take換成Ql_OS_TakeSemaphore。對于用到超時返回特性的rt_sem_take,得做特殊的修改。再說寫死的線程,筆者在原項目中寫了一個通用的狀態機模塊,其內部動態創建線程以維護狀態機的流轉。并且多處使用了該狀態機模塊,因為是通用的嘛。而現在不能動態創建線程,就很麻煩。
假移植決定
經過一番權衡,筆者決定實現rtthread的內核接口,這樣做有三大好處:
- 解決了BC25 SDK接口不完備的問題。
- 業務層還是使用rtthread接口,所以業務代碼改動量非常之少(主要改的是驅動代碼)。
- 這樣的方案靈活機動,如果下次又用另一家的opencpu了,還是不用動業務層。
所謂實現rtthread接口而不是移植rtthread,是筆者基于現有的SDK接口來實現rtthread接口,即心是BC25 SDK,殼是rtthread。因此標題為:rtthread套娃移植。
筆者認為這種另類的移植不算常見,有很多細節要處理,因此寫此篇文章和大家分享交流。請注意,本篇文章是分享些移植經驗,并不是完整的移植指南。
移植的內容分為三大類:內核接口,非常常用的驅動(pin,i2c),finsh。
內核接口細分如下:
- 基本類型(如rt_uint32_t)
- rtt的內核庫(如rt_memset,rt_vsprintf,rt_malloc)
- 線程接口(如rt_thread_create)
- 線程間同步與通信、中斷管理(rt_mutex_t,rt_sem_t,rt_event_t,rt_mq_t,rt_enter_critical,rt_hw_interrupt_disable)
- 定時器(rt_timer_t)
內核接口移植
接實現方法,分為三類:
- 直接復制
- 簡單替換
- 邏輯適配
直接復制
基本類型(rt_uint32_t),錯誤碼(RT_EOK)以及基本宏(RT_ALIGN)定義在rtdef.h這中,可直接把該文件復制過來,刪除不需要的東西(如rt_device_ops,rt_device)。rtdef.h中還定義了線程、線程間通信、定時器這些模塊的相關結構體,這些也刪掉,具體原因會在后面說。
簡單替換
這個主要是針對rtt的內核庫,比如rt_memset,其聲明為:
void *rt_memset(void *s, int c, rt_ubase_t count)BC25也提供了自己的C庫,其聲明為:
void* Ql_memset(void* dest, u8 value, u32 size)這就可以通過宏來一對一替換:
#define rt_memset(dst, value, size) Ql_memset(dst, value, size)能簡單替換的內容不多,也就這么些:
#define rt_memset(dst, value, size) Ql_memset(dst, value, size) #define rt_memcpy(dst, src, size) Ql_memcpy(dst, src, size) #define rt_memcmp(dst, src, size) Ql_memcmp(dst, src, size) #define rt_memmove(dst, src, size) Ql_memmove(dst, src, size) #define rt_strcpy(dst, src) Ql_strcpy(dst, src) #define rt_strncpy(dst, src, size) Ql_strncpy(dst, src, size) #define rt_strcmp(s1, s2) Ql_strcmp(s1, s2) #define rt_strncmp(s1, s2, size) Ql_strncmp(s1, s2, size) #define rt_strchr(src, ch) Ql_strchr(src, ch) #define rt_strlen(str) Ql_strlen(str) #define rt_strstr(s1, s2) Ql_strstr(s1, s2)#define rt_vsprintf(s, fmt, arg) Ql_vsprintf(s, fmt, arg) #define rt_sprintf(s, fmt, ...) Ql_sprintf(s, fmt, ##__VA_ARGS__) #define rt_snprintf(s, size, fmt, ...) Ql_snprintf(s, size, fmt, ##__VA_ARGS__) #define rt_sscanf(s, fmt, ...) Ql_sscanf(s, fmt, ##__VA_ARGS__)除了用宏的方式,也可以用函數來封裝。
void *rt_malloc(rt_size_t size) {return Ql_MEM_Alloc(size); }起初筆者也是用宏來替換rt_malloc的,但是這樣一來cJSON軟件包的代碼編譯不過,因為其用函數指針來指向rt_malloc。而筆者定義的是帶參數的宏,此處就不會替換,從而提示rt_malloc未被定義。
int cJSON_hook_init(void) {cJSON_Hooks cJSON_hook;cJSON_hook.malloc_fn = (void *(*)(size_t sz))rt_malloc;cJSON_hook.free_fn = rt_free;cJSON_InitHooks(&cJSON_hook);return RT_EOK; }邏輯適配
邏輯適配才是本次移植的主要工作,所以另起一章進行說明。
關于線程接口、線程間同步與通信、中斷管理、定時器等模塊,BC25 SDK也提供了相關接口,不過在功能、參數列表和返回值方面與rtthread接口肯定是不一致的,需要做一些適配工作。
rtthread中rt_mutex_t之類的內核結構體使用了面向對象的概念,繼承關系如下:
不過本次移植,是使用BC25的接口來填充rtthread接口,用不到這層關系,只要在功能上保持一致即可。所以關于rt_mutex_t之類的類型定義,由筆者自行定義。這就是之前復制rtdef.h時要刪掉它們的原因。
rtthread中的定義
筆者的定義
struct rt_mutex {char name[RT_NAME_MAX];rt_sem_t sem;rt_thread_t owner;rt_uint32_t hold; };有些BC25的接口與rtthread比較相似,如定時器接口,適配起來很容易。有些BC25接口不完備,比如線程間同步的接口不能設置超時時間,不能動態創建線程,這些就需要費些工夫。下面筆者挑一些有代表性的來介紹適配方法。
定時器
BC25創建定時器和啟動定時器的接口如下:
typedef void(*Callback_Timer_OnTimer)(u32 timerId, void* param); s32 Ql_Timer_Register(u32 timerId, Callback_Timer_OnTimer callback_onTimer, void* param); s32 Ql_Timer_Start(u32 timerId, u32 interval, bool autoRepeat);rttthread相關接口為:
rt_timer_t rt_timer_create(const char *name,void (*entry)(void *parameter),void *parameter,rt_tick_t timeout,rt_uint8_t flag); rt_err_t rt_timer_start(rt_timer_t timer);大體上是相似的,都是創建定時器傳入回調函數和額外參數。哈哈,其實定時器接口肯定要這兩個參數啦。不同之處為:
- BC25通過ID來操作相關定時器,rtthread由模塊創建并返回定時器對象,之后由該對象來操作相關定時器。這點上,rtthread接口更為易用,因為BC25需要防止ID沖突。
- BC25是在啟動定時器是指定定時間隔和模式(周期還是單次),rtthread是在創建定時器時指定,不過之后也可以修改。這點上,筆者還是覺得rtthread好用,嗯,筆者真不是馬屁精。
適配方法很簡單,在rt_timer_create函數中,動態獲取id(自增即可),創建rt_timer_t對象,并將timeout和flag保存在對象中。也要保存entry和parameter,因為BC25的回調函數形式與rtthread不一致,由timer_callback中轉。
static uint32_t timer_id_alloc(void) {static uint32_t id = 0x100;uint32_t ret;rt_enter_critical();ret = id++;rt_exit_critical();return ret; }static void timer_callback(u32 id, void* param) {rt_timer_t timer = (rt_timer_t)param;RT_ASSERT(timer->handle == id);timer->entry(timer->parameter); }rt_timer_t rt_timer_create(const char *name,void (*entry)(void *parameter),void *parameter,rt_tick_t timeout,rt_uint8_t flag) {int ret;rt_timer_t timer = (rt_timer_t)rt_malloc(sizeof(struct rt_timer));RT_ASSERT(timer);rt_memset(timer, 0, sizeof(*timer));rt_snprintf(timer->name, sizeof(timer->name), "%s", name);timer->handle = timer_id_alloc();ret = Ql_Timer_Register(timer->handle, timer_callback, timer);if(ret != QL_RET_OK){rt_free(timer);return RT_NULL;}timer->entry = entry;timer->parameter = parameter;timer->flag = flag;timer->timeout = timeout;return timer; }rt_err_t rt_timer_start(rt_timer_t timer) {int ret;ret = Ql_Timer_Start(timer->handle, rt_tick_to_millisecond(timer->timeout), (timer->flag & RT_TIMER_FLAG_PERIODIC) != 0);timer->flag |= RT_TIMER_FLAG_ACTIVATED;return ret == QL_RET_OK ? RT_EOK : -RT_ERROR; }順便說下rt_enter_critical和rt_hw_interrupt_disable。前者是關調度器,后者是關中斷。還記得BC25的線程都不能動態創建嗎,更是不可能提供這些功能接口。巧婦難為無米之炊啊,筆者只能用BC25的互斥量(對,就是之前說的,最多可創建5個互斥量)來實現。
void rt_enter_critical(void) {Ql_OS_TakeMutex(rtt_mutex); }void rt_exit_critical(void) {Ql_OS_GiveMutex(rtt_mutex); }rt_base_t rt_hw_interrupt_disable(void) {rt_enter_critical();return 0; }void rt_hw_interrupt_enable(rt_base_t level) {rt_exit_critical(); }可能有的同學會不解,人家明明是要關調度器,你用互斥量有什么用。確實,這有一定的使用限制,那就是所有訪問相關資源的地方,都要關調度器。比如說:
寫ringbuffer時關調度器。
讀ringbuffer時也關調度器。
rt_enter_critical(); ret = rt_ringbuffer_getchar(&stream->recv_rb, &data); rt_exit_critical();這樣一來,調度器就是一個全局互斥量。關中斷也是一樣的原理。至于上述示例代碼為什么不直接用rt_mutex,筆者說下自己關于何時用互斥量、何時關調度器的理解。如果是在訪問資源的時間極短,關調度器比較合適;相反,比如通過i2c總線進行數據傳輸,尤其是硬件i2c,則應該用互斥量。因為在操作i2c的過程中,完全可以釋放cpu資源給別的線程用。而且,訪問不同的資源得使用不同的互斥量,因為操作i2c時不應該讓spi資源也被鎖定。
可能又有同學質疑:在中斷函數里面怎么能使用互斥量呢。慶幸的是,業務代碼就沒用到真正的中斷場景。BC25提供的大部分回調接口,比如串口、GPIO、定時器,都是在線程中進行回調,數據的緩存由BC25實現(比如串口)。這樣也是合理的,享受不到相應的權力(底層的控制權限),不應該也無法履行相應的義務。最后再次聲明,這是權宜之計,無奈之舉啊。
信號量
BC25的信號量接口與rtthread比較相似,唯獨缺少超時功能,只能選擇不等或者死等。
u32 Ql_OS_TakeSemaphore(u32 semId, bool wait); rt_err_t rt_sem_take(rt_sem_t sem, rt_int32_t timeout);rt_sem_trytake的實現很簡單,就是不等。
rt_err_t rt_sem_trytake(rt_sem_t sem) {rt_uint32_t ret = Ql_OS_TakeSemaphore(sem->handle, false);return ret == OS_SUCCESS ? RT_EOK : -RT_ERROR; }至于rt_sem_take,分三種情況。若是死等或者不等,直接通過rt_sem_trytake來調用BC25接口。若是帶超時的等待,只能搞個循環嘗試了,犧牲實時性。
rt_err_t rt_sem_take(rt_sem_t sem, rt_int32_t timeout) {if((rt_tick_t)timeout == RT_WAITING_FOREVER){rt_uint32_t ret = Ql_OS_TakeSemaphore(sem->handle, true);return ret == OS_SUCCESS ? RT_EOK : -RT_ERROR;}else if(timeout == 0){return rt_sem_trytake(sem);}else{timeout = rt_tick_get() + timeout;rt_err_t err;do{err = rt_sem_trytake(sem);if(err == RT_EOK){return RT_EOK;}rt_thread_delay(1);} while(rt_tick_get() < timeout);return -RT_ETIMEOUT;} }互斥量
BC25最多創建5個互斥量,這顯然不夠用。對了,它也沒有超時版本。PS:BC25所有進程間同步與通信接口均無超時版本。所以這里打算重新設計互斥量模塊,而不使用BC25的接口。之所以rt_enter_critical使用BC25的互斥量,是因為rt_enter_critical不存在超時場景,并且筆者設計的互斥量接口中還使用到了rt_enter_critical。
如何憑空創造互斥量呢,哈哈,顯然不可能。筆者使用已實現的rt_sem來實現rt_mutex。互斥量與信號量本是用于兩種不同的場景,不過信號量可以替代互斥量,而互斥量無法替代信號量。信號量常用的場景是用于發送通知,初始信號值為0,生產者調用rt_sem_release以讓信號值加1,消費者調用rt_sem_take等待信號并減1。如果將初始信號值設置為1的話,那就可以用于互斥場景了。在訪問資源前調用rt_sem_take,若此時信號值為1,則獲取信號量,此后信號值為0。此時其他線程調用rt_sem_take將被堵塞。當訪問完畢后,調用rt_sem_release恢復信號量值為1。
筆者最初的實現如下:
簡單測試下是沒問題的,不過跑業務代碼時發生了卡死。最終發現,這種實現不可重入。比如,函數A調用rt_mutex_take后調用函數B,函數B又調用了rt_mutex_take。處理方案:在獲取互斥量時,若其已被上鎖且持有者為當前線程,則直接放行。PS:此方案借(抄)鑒(襲)rtthread原接口的實現。
rt_err_t rt_mutex_take(rt_mutex_t mutex, rt_int32_t timeout) {rt_err_t err = -RT_ERROR;rt_thread_t cur_thread = rt_thread_self();RT_ASSERT(cur_thread);rt_enter_critical();if(mutex->owner == cur_thread){mutex->hold++;rt_exit_critical();return RT_EOK;}rt_exit_critical();err = rt_sem_take(mutex->sem, timeout);if(err != RT_EOK){return err;}rt_enter_critical();mutex->owner = cur_thread;mutex->hold = 1;rt_exit_critical();return RT_EOK;}rt_err_t rt_mutex_release(rt_mutex_t mutex) {rt_thread_t cur_thread = rt_thread_self();RT_ASSERT(cur_thread && mutex->owner == cur_thread);rt_enter_critical();mutex->hold--;if(mutex->hold == 0){mutex->owner = RT_NULL;rt_sem_release(mutex->sem);}rt_exit_critical();return RT_EOK; }線程
筆者已吐槽多次,BC25的線程是在代碼中寫死的,像下面這樣,proc_main_task、proc_ril_task是線程入口函數,第二個參數是線程ID。
TASK_ITEM(proc_main_task, MAIN_THREAD_ID, 10*1024, DEFAULT_VALUE1, DEFAULT_VALUE2) //main task TASK_ITEM(proc_ril_task, ril_task_id, 5*1024, DEFAULT_VALUE1, DEFAULT_VALUE2) //RIL task TASK_ITEM(proc_urc_task, urc_task_id, 5*1024, DEFAULT_VALUE1, DEFAULT_VALUE2) //URC task不過BC25提供了一個非常重要的線程接口,也僅僅提供了這一個接口:返回當前線程的ID。
s32 Ql_OS_GetActiveTaskId(void);可以用此實現rt_thread_self。真是萬幸啊,這不之前的rt_mutex_take的重入功能還用到它的嘛。
rt_thread_t rt_thread_self(void)至于如何實現動態創建,待我慢慢道來。
BC25允許用戶最多創建8個線程,筆者將它們納入線程池。
線程對象的定義:
struct rt_thread {char name[RT_NAME_MAX];int ql_id;void (*entry)(void *parameter);void *parameter;rt_uint32_t stack_size;rt_uint8_t priority;rt_bool_t in_use;rt_sem_t sem; };線程池定義:
static struct rt_thread thread_lst[THREAD_NUM];死寫的線程列表:
TASK_ITEM(thread_entry, THREAD1_ID, 5*1024, DEFAULT_VALUE1, DEFAULT_VALUE2) TASK_ITEM(thread_entry, THREAD2_ID, 5*1024, DEFAULT_VALUE1, DEFAULT_VALUE2) TASK_ITEM(thread_entry, THREAD3_ID, 5*1024, DEFAULT_VALUE1, DEFAULT_VALUE2) TASK_ITEM(thread_entry, THREAD4_ID, 5*1024, DEFAULT_VALUE1, DEFAULT_VALUE2) TASK_ITEM(thread_entry, THREAD5_ID, 5*1024, DEFAULT_VALUE1, DEFAULT_VALUE2) TASK_ITEM(thread_entry, THREAD6_ID, 5*1024, DEFAULT_VALUE1, DEFAULT_VALUE2) TASK_ITEM(thread_entry, THREAD7_ID, 5*1024, DEFAULT_VALUE1, DEFAULT_VALUE2) TASK_ITEM(thread_entry, THREAD8_ID, 5*1024, DEFAULT_VALUE1, DEFAULT_VALUE2)這8個線程的入口函數都指向同一個thread_entry。該函數通過id找到線程池中自己的對象,等待對象被激活。激活后,運行真正的線程入口函數。
void thread_entry(int id) {rt_thread_t thread;/** 等待本模塊初始化,因為線程是寫死的,* 可能在系統加載時就開始運行了。*/wait_thread_init();thread = get_thread(id);RT_ASSERT(thread);/** 等待線程被激活。* 即用戶rt_thread_create并rt_thread_create。*/RT_ASSERT(rt_sem_take(thread->sem, RT_WAITING_FOREVER) == RT_EOK);RT_ASSERT(thread->entry);thread->entry(thread->parameter);/** 其實這里還可以做回收的,不過筆者沒用到這個場景。*/ }rt_thread_create從線程池中獲取空閑的線程對象,標記為使用中(in_use),記錄相關參數(主要是入口函數,入參),返回該對象。
/** stack_size和priority是預留參數,可用于后期優化。*/ static rt_thread_t alloc_thread(rt_uint32_t stack_size, rt_uint8_t priority) {rt_thread_t thread = RT_NULL;rt_enter_critical();for(int i = 0; i < THREAD_NUM; i++){rt_thread_t tmp = thread_lst + i;if(!tmp->in_use){tmp->in_use = RT_TRUE;thread = tmp;break;}}rt_exit_critical();return thread; }rt_thread_t rt_thread_create(const char *name,void (*entry)(void *parameter),void *parameter,rt_uint32_t stack_size,rt_uint8_t priority,rt_uint32_t tick) {rt_thread_t thread = alloc_thread(stack_size, priority);if(!thread){rt_kprintf("No available thread for app_thread(name:%s, stack_size:%d, priority:%d)\r\n",name, stack_size, priority);return RT_NULL;}rt_snprintf(thread->name, sizeof(thread->name), "%s", name);thread->entry = entry;thread->parameter = parameter;return thread; }上述是最關鍵的實現。未實現的功能有:
- 線程的釋放與回收。這個筆者的項目中用不到,也就沒做嘿嘿。
- 線程棧空間大小及優先級的設定。棧空間大小是在線程列表里面列寫的,這倒可以視使用場景優化一下:在列表中設定不同空間大小的線程,alloc_thread選擇剛剛滿足需求的空閑線程。至于優先級,BC25不支持:(。
再次說明,本篇文章是分享些移植經驗,并不是完整的移植指南。做這種系統級移植,得對系統有深刻的了解,至少得明白各接口的功能、使用場景,以及自己需要哪些接口(畢竟工具有限,也不是所有接口都能實現,比如真正的關中斷)。所以,這種移植工作,因人而異,因項目而異。
先寫這么多,關于rt_event_t,rt_mq_t,pin,i2c,請待下回分解。
轉載請注明出處:https://blog.csdn.net/wenbodong/article/details/109056606
未經允許請勿用于商業用途。
總結
以上是生活随笔為你收集整理的rtthread套娃移植的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 用java实现五子棋三手交换_什么是五子
- 下一篇: 前端学习之vue+element-ui电