協議 freemodbus的分層結構分析

freemodbus的相容性非常好，可以方便的在很多的平台進行移植，這與它的**架構有很大的關係。

這裡我們不考慮**的移植過程，僅僅分析它的層次結構。

我認為，freemodbus協議實際上是分了三個層次的

1. 應用層（或者說暴露給應用層的介面）：

介面定義全部在標頭檔案mb.h中包含，在mb.c中實現。

包括了移植時不需要改動的部分（一些初始化，使能，poll等），還有需要修改或者說實現的部分（註冊給定功能碼對應的**處理程式,暫存器相關操作等）。

而且在初始化中通過**函式指向了第二層的函式介面，相當於為整個程式提供了統一的介面去訪問第二層的函式，而不用考慮第二層的改變。

2. 協議（移植）層：

這一層體現了freemodbus的型別多樣（rtu模式，ascii模式，tcp模式等）

介面定義型別.h（mbrtu.h/mbascii.h）中包含，在對應的.c中實現。

目前看到的函式全部不用改動，可以直接呼叫。實現了具體的(rtu)初始化、開始、停止、接收處理、傳送處理等部分功能。

此層函式直接呼叫物理層介面。

3. 物理層：

介面定義在mbport.h中定義，使用者只需要根據平台的不同具體實現（初始化串列埠、初始化最小單位為50us的定時器、使能串列埠和定時器等）其定義的相關介面。具體位置的話，串列埠相關的基本操作在portserial.c中，定時器相關的在porttimer.c中，狀態機在portevent.h中

4. 特殊點：

這裡有乙個地方比較特殊，就是接受和傳送中斷函式。實際上的接受和處理是在協議（移植）層定義並實現好的，但是清中斷必須要下放到物理層來適配不同的平台。

所以freemodbus規定了接受中斷和傳送中斷必須分別包括兩個函式，這兩個函式通過**的形式最終指向的是協議移植層的接收處理和傳送處理函式。接受中斷處理函式和傳送中斷處理函式需要註冊在本層（物理層）的串列埠初始化部分。

所以我認為可以說freemodbus協議規定了中斷處理函式的流程。

也可以說是freemodbus做好了中斷處理函式，只是讓使用者在物理層幫忙清一下中斷標誌，如果需要其他操作也可以同時加入。

5. 總結：這個架構明顯的分了三個層次，對應著使用者移植的三種情況：

（1）業務：串列埠接收資料與業務完全分離，業務只需要呼叫介面，而不對串列埠的架構做任何的修改即可。

（2）切換協議：假設從rtu切換到ascii，那麼只需要在應用層介面中註冊ascii的**即可完成，底層與業務無需修改。

（3）切換平台：以微控制器為例，切換的時候僅需要把物理層的硬體實現重新適配，而不需要對上層做任何的改動。

那麼其呼叫流程為：

應用->（呼叫）應用層的介面 -> (**) 協議（移植）層函式->（呼叫）物理層介面

當然，這個協議遠比我分析的複雜和具體，以後有時間和機會我還會繼續學習和分析整理。