---基於TI CC254X OSAL的分析

當工具鏈配置完成後，Source Insight向你展示一份原始碼工程，不借助百度和開發文件，能否在一兩個小時內理解原始碼的組成框架和介面，進行快速開發？

在筆者過往撰寫的博文中，一直在倡導兩個嵌入式學習和開發理念：提高嵌入式系統架構和軟體層次形成大局觀；掌握從需求的角度去理解新系統和技術這個方法論。在軟體大局觀作為學習新系統的背景知識的基礎上，從軟體需求的角度入手就能快速理解和掌握一個全新的系統。本文以TI藍芽BLE CC254x的原始碼庫和工程為例進行分析研究。

一、作業系統相關概念

1. 作業系統

最常見的通用作業系統是Windows和Linux。作業系統給應用層提供程序排程、程序間通訊、記憶體管理、驅動管理、檔案管理、中斷管理、時間管理等相關介面。在嵌入式領域，除了通用的嵌入式Linux作業系統，更多的是定製型的作業系統。定製型作業系統一般都是閉源且高度裁剪移植的系統，根據應用的需求提供必要的功能和管理模組。資源豐富型系統的應用層和核心層會使用不同的CPU執行模式，只有核心層能夠訪問硬體資源，而資源緊缺型系統的應用層和核心都是運行同一模式，都能夠訪問硬體資源。

嵌入式系統中有單任務作業系統和多工作業系統。單任務作業系統一般用於簡單的電子控制和處理產品中，如玩具、工業控制、家電等等。而多工作業系統則用於較為複雜且功能豐富的電子產品中，如手機、視訊監控等等。

在一般的簡單的電子產品中，作業系統只是一種層次概念，其管理的功能顯得比較弱，有時甚至為了效果和記憶體而進一步削減它的存在，但是軟體層次能夠讓軟體工程顯得更加有序和易於維護和管理。只要中斷管理、GPIO和驅動、時間管理單獨成模組，我們都可以認為它形成作業系統。

2. 核心

核心是多工作業系統的核心，最基本的功能就是任務排程和任務間通訊。既然是多工併發執行，而CPU只有一個（假設是單核CPU），就必須做好任務的排程和任務間的同步和通訊。Linux是一個作業系統（OS），其核心（kernel）除了任務排程、任務間通訊，還有記憶體管理、網路介面等；UCOS是常見的多工核心，多用於資源有限型嵌入式系統，它提供了優先順序搶佔的任務排程和訊號量、郵箱、訊息佇列等任務間通訊，儘管UCOS也提供了記憶體管理，但完全可以裁剪掉這個功能。

3. 併發

一個系統可能有多個獨立的任務，但是否是多工作業系統，是以這些任務是否併發為標準。所謂併發，是指各個獨立的任務是否能夠得到公平的執行機會。如果一個任務必須要等待另一個任務完成才能執行，那兩者是序列執行；如果一個任務能夠在另一個任務執行過程中搶佔CPU，才算是併發執行。併發執行跟任務上下文密切相關，單任務作業系統只有一個使用者上下文，而多工作業系統的每個任務都有一個上下文，任務切換就是對上下文的切換。

4. TI CC254x需求分析

TI CC254x是在8051核上整合藍芽BLE4.0低功耗的單晶片，可以預想它是一個資源緊缺型的嵌入式系統；同時CC254x是為了完成藍芽連線和簡單的控制功能（即GAP profile和GATT profile），因此TI提供的庫也重點圍繞藍芽連線和控制傳輸設計，而沒有通用作業系統所支援的檔案、驅動管理等功能；另外藍芽協議是分層協議棧，各層都有獨立的的業務和處理流程，它會是多工應用嗎？

TI向用戶提供了一個叫做OSAL（作業系統抽象層）的程式設計框架，除了藍芽相關的底層協議不透明，OS相關的任務排程和通訊、藍芽高層協議都是使用者透明的。誠如以上對單任務作業系統的分析，OASL也是一個較弱的作業系統，只包含了排程和通訊的核心，和一個硬體抽象層。但不妨礙我們把它當成一個作業系統去理解。

5. 如何快速開發

理解工程的架構、任務排程、任務通訊、使用者訊息的輸入和輸出之後，就能進入快速開發階段了。基於以上分析，要在OASL上進行快速開發，我們需要重點關注OSAL的任務編排程、任務間通訊、使用者訊息輸入和處理。對於藍芽協議棧相關的內容（GAP、GATT等應用profile），不是本文的重點，以後再另外撰文闡述。

二、OSAL的任務排程

1. 背景知識

嵌入式系統中每個任務都是while（1）的大迴圈。在單任務中可能還會有不同的場景，例如每個功能選單都可以認為是一個場景，每個場景都有自己的訊息大迴圈，但本質上還是一個while（1）的迴圈。而在多工作業系統中，每個任務都有自己的訊息迴圈。任務間的協同執行依賴任務的主動釋放控制權（主動休眠）和被動的掛起（如等待另一個任務的訊號量）。每個任務都必須要在就緒狀態才可能得到執行的機會。

2. OAL應用需求

OSAL支援藍芽協議棧，包括鏈路層、適配層、GAP連線管理、ATT屬性管理、GAP profile應用、GATT profile應用，此外還要支援使用者的按鍵訊息輸入處理等。各層均有獨立的分工和職責。到底是以多工來支援這種模型，還是單任務的多場景呢。拭目以待！

3. OSAL程式碼分析（以SimplePeripheral為例）

1）從main開始，main->osal_init_system-> osalInitTasks，如下圖：

tasksCnt是系統的任務個數，如下圖：

陣列中每個成員都是一個任務處理過程。先給tasksEvents申請空間，tasksEvents是做什麼的，先不管它。

osalInitTasks接著就是進行各個任務的初始化，這時還沒有進入訊息迴圈。我們注意到taskID在每個任務初始化後，taskID都會加1，而在每個任務初始化的開始都會記錄傳入的taskID並儲存，作為任務的標記。

2）main-> osal_start_system,如下圖：

我們看到大迴圈了。繼續看：

可見，taskID除了任務標識，還有優先順序的含義。tasksEvents陣列的每個元素即對應每個任務的就緒狀態，0為沒有事件需要處理，非0代表有事件需要處理。

跟蹤一個任務處理流程，我們發現裡面並沒有while（1）迴圈，都是等到某個任務執行完才返回，返回之後回到osal_start_system大迴圈。因此該系統本質上是一個單任務操作，只有一個上下文。但是OASL的程式設計模型看起來確實蠻想多工系統的，或者其借鑑了很多多工程式設計的思維，如在OASL看到了很多UCOS的影子。

為什麼要將返回值設定到tasksEvents中，就是因為其本質是一個單任務迴圈，如果某個子任務時間執行過長，會影響更高優先順序的任務的響應變慢，影響整體效能。因此如果一個任務執行比較長，宜進行分割，在返回值那裡設定繼續處理事件，然後返回大迴圈，看看有沒有更高優先順序的任務需要執行。

三、OASL的任務間通訊

1. 背景知識

Linux的任務間通訊包括訊息佇列、共享變數，有訊號量來同步；UCOS也有訊息佇列、郵箱和條件變數、訊號量等手段來進行通訊和同步。OSAL是單任務作業系統，需要由使用者層的各個任務處理過程自己約束保證同步。

訊息一般包括按鍵訊息、時間訊息、繪圖訊息等等，訊號量用於任務間的同步，並不屬於訊息傳遞。

2. OSAL的程式碼分析

tasksEvents的元素除了作為就緒狀態，還有另外一個作用就是作為引數傳入該應用處理過程。我們跟蹤一個處理過程：

可以看到，event可能是使用者自定義的事件，如這個任務要做的週期性的事情和啟動連線的事件。另外，event還可能是系統訊息事件（SYS_EVENT_MSG），它是什麼？訊息和事件在OSAL中是怎麼理解的。

其實把事件作為訊息的型別更容易理解，事件用一個16位的整型來表示，從程式碼來看，是每個位元表示一種事件，其最多隻能表示16種事件。對於按鍵訊息，由於其可能有多個不同的鍵值，因此不宜通過多個事件來表示，而是用一個按鍵事件來表示，然後按鍵的鍵值通過訊息佇列來傳遞。

通過跟蹤訊息傳送osal_msg_send( uint8 destination_task, uint8 *msg_ptr )和訊息接收osal_msg_receive( uint8 task_id )介面，可以發現，所有的任務共用一個連結串列型的訊息佇列，每個結點記錄訊息的事件型別/值和接收任務的taskID。

那麼事件的傳送介面呢？如下圖

即往tasksEvents的taskID下標成員寫入對應的事件值。這樣在之後的大迴圈中目標task就會得到執行的機會。訊息傳送osal_msg_send不僅將訊息插入到全域性訊息佇列連結串列，而且最後也會呼叫osal_set_event介面填入SYS_EVENT_MSG事件。

此外，還有一個定時傳送事件的介面osal_start_timerEx，其在規定的時間到達後才會傳送該事件，以讓目標taskID得到執行事件的機會。

四、OSAL訊息處理

OSAL提供了一個HAL硬體抽象層，咱們主要分析按鍵輸入和串列埠輸出就好了。

利用TI CC2540進行藍芽方案開發還是幾個前，當時一個小時就理解了OSAL，但現在把當時的理解思路還原整理出來花了差不多四個小時，主要是因為在撰寫過程中不斷地考慮如何讓讀者更好地理解本文的學習思路，即總結軟體架構方面的知識，和如何從需求的角度去理解新的系統。嗚嗚，還是把OSAL的訊息處理流程留到下一篇好了。

接下來將會陸續推出物聯網-微信藍芽和wifi接入相關的技術分享。敬請關注！

更多原創分享請關注微信公眾號：嵌入式企鵝圈！