eLua 體繫結構概述

文章目錄

• 移植相關結構

eLua體繫結構

整體概述了eLua的體繫結構

eLua使用平台的概念表示一組具有相同核心結構的CPU，儘管這些CPU針對不同的具體外設，記憶體和其他一些屬性分別有特定的實現。一個eLua實現給定平台的一個或多個CPU。比如，eLua的lm3s移植可以運行LMSS8962,LM3S6965,LM3S6918處理器，它們都是lm3s平台下的一部分。從可以看出，eLua試著儘可能在不同平台之間使用一些簡單的設計規則。

• 所有代碼跟具體平台無關的是通用代碼，而且它應該儘可能使用標準C語言書寫。這樣就可以使它在不同的體繫結構和編譯器間有高度的可移植性，就像Lua本身一樣。
• 所有那些不可能通用的代碼（幾乎都是外設和具體CPU相關）應該儘可能的使之可移植，通過使用通用介面，這種通用介面要能讓eLua能在所有的平台上都能運行。這種介面稱為平台介面。
• 所有平台（和它們的外設）不能同等的建立，因為在功能上有巨大的變化。如前所述，平台介面試著組合不同平台的共同特性。如果想在一個給定平台上實現具體的一個功能的話，可以通過使用一個平台模組。這些平台模組是資料特定平台的，它們的目的就是填補平台介面和一個具體平台所提供的所有具體特性之間的缺口。

通用代碼

下面給出了不完整的一些項可以被歸類於通用代碼。

• Lua代碼（很明顯是）加上LTR補丁
• 所有在eLua的組件（比如ROM檔案系統，XMODEM接收代碼，eLua shell，TCP/IP棧等等）
• 所有通用模組，這些模組是lua的模組，展示了Lua平台的不同功能。
• 通用外設支援代碼，比如ADC支援代碼（src/common/elua_adc.c），此代碼獨立於真實的ADC硬體。
• libc代碼（比如allocators和Newlib）

上述的描述應該會給你一個好的關於通用代碼的印象。注意通用代碼所佔據的層應該儘可能的多，也就是說，應該儘可能的有更多的通用代碼。比如如下例子：

• 如果你想給eLua添加一個新的檔案系統，這很清楚應該是通用代碼。這就好像代碼產生的檔案系統與具體依賴相關的物理媒介的處理。如果你幸運的話，你可以使用在平台介面的一些函數解決這種依賴關係。比如通過SPI控制SD卡，因為這個平台擁有SPI層。如果不是那樣的話，你必須在一個獨立的介面中組合與特定的平台相關的函數，然後實現它讓其在所有平台上都能使用這種檔案系統。這給了代碼最大的移植性。
• 如果你想為特定的ADC外設（此ADC通過SPI工作）添加驅動，那麼可以使用如前所述的同樣理論，盡你可能的把它寫成通用代碼，並且使用平台介面中的函數實現你需要的特定的SPI。

當設計和實現一個新的組件時，記住另外一個eLua的設計目標：靈活性。使用者應該可以選擇在二進位檔案裡麵包含哪些組件，實現的時候就要把這些考慮進去。同樣的理論也適用於通用模組：使用者能根據需要選擇相應的模組。為了移植性的最大化，儘可能讓你的代碼工作在各種可能遇到的情景中。這樣的例子就如在stdio/stdout/stderr中代碼的處理。代碼（src/Newlib/genstd.c），此中代碼就承認了這樣一個事實，終端可以通過可以多種我物理傳輸介面實現(RS232,SPI控制的液晶/鍵盤等等)。所以代碼使用指標來處理收和發的函數。這樣在速度和資源的消耗上是最小的，但是它關係到重要的移植部分。平台介面運用得當的話，平台介面能允許在不同的平台上書寫具有可移植性的代碼，包括C和Lua.平台介面的一個重要特性就是它試著組合不同平台下共同特性。比如，一個eLua所支援的平台的串口能工作在迴路模式，但是其它平台不能，那麼關於迴路模式的支援就不能被包括進平台介面裡面。關於平台介面使用的特別的一點是：記住它不但可以用C，還可以用Lua.平台介面主要通過通用模組允許Lua控制平台的外設，但這不是它唯一的用法。如果可能的話也可以用C語言實現一個通用模組而且也能用C控制外設。這個例子就是上面所述的打造一個新的檔案系統。平台介面的定義總是在inc/platform.h標頭檔裡。平台和移植所有運行eLua的平台（和i平台介面的實現）都是在它的概念層上實現的。移植就是eLua能在一個給定的平台下運行。移植應當包括特定的外設驅動，很多時候這都是來自CPU所在平台的支援包。這些驅動用於實現平台介面。注意下面幾點：

• 移植不要實現平台下的所有功能，只是它需要的就夠了。也就是說，通過所構建的eLua二進位檔案使用者能夠取得相應的需要控制的部分。如果你不需要SPI模組，你就不需要實現關於它的平台介面。
• 平台介面中的一部分可以在一個檔案中實現，讓其夠工作在所有平台上(src/common.c)，這簡化了一些模組的設計（比如定時器模組），這樣也實現了所綁定平台的通用特性，但在所有平台上也有共同的表現（比如虛擬定時器）。如果你正在寫特定平台下代碼的話，儘可能不要去修改它，但是最好記住它是幹什麼的。

一個平台的也許包括一個或多個獨立平台的模組。正如已經解釋的那樣，這樣做的目的是讓Lua能發揮所有平台相關外設的潛能，而不只是被平台介面覆蓋到的外設功能。當然外設具有特定的功能時也不會被歸類到平台介面。按照慣例，所有平台的獨立模組應該被組合進一個單獨的模組，此模組的名字與它本身的平台是一樣的。如果一個平台的獨立模組增加的功能是平台介面所擁有的，它應該也是相同的名字。否則，應該給它一個不一樣的名字。比如:

• 如果在LM3S平台實現了一個新的功能關於UART模組，那麼響應的模組應該被稱作lms3s.uart。
• 如果實現了一個特定外設驅動在LPC2888平台下，比如雙通道DAC，給它一個特別的名字，比如lpc288x.audiodac.

移植相關結構所有關於平台名字的代碼（包括外設驅動）必須集中在一個叫做src/platform/<name>的檔案裡（比如src/platform/lm3s就是針對lm3s平台的）。每一個這樣的特定於平台的子目錄必須包含至少這些檔案：type.h：其中定義的特定的資料類型。是關於i386平台下一些資料類型。

typedef unsigned char u8;typedef signed char s8;typedef unsigned short u16;typedef signed short s16;typedef unsigned long u32;typedef signed long s32;typedef unsigned long long u64;typedef signed long long s64;

conf.py:這是特定平台的構建檔案。構建系統會使用此檔案，此檔案有以下目的：獲得特定平台下將被編譯成eLua二進位檔案的檔案清單。它們通過specific_files字串載入，空格隔開。而且必須給出相關檔案的路徑。下面的例子是關於i386平台的：

specific_files = "boot.s common.c descriptor_tables.c gdt.s interrupt.s isr.c kb.c  monitor.c timer.c platform.c"# Prepend with pathspecific_files = " ".join( [ "src/platform/%s/%s" % ( platform, f ) for f in specific_files.split() ] )

為了獲得不同工具鏈單元的所有需要的命令來編譯eLua。它們需要被聲明在tools變數裡。每個獨立的字典裡的關鍵字是相應平台的名字，linkcom代碼linker,ascom代表assember，比如下面就是關於i386平台工具變數的設定：

# Toolset data tools[ 'i386' ] = {} tools[ 'i386' ][ 'cccom' ] = "%s %s %s -march=i386 -mfpmath=387 -m32 -ffunction-sections -fdata-sections -fno-builtin -fno-stack-protector %s -Wall -c $SOURCE -o $TARGET" % ( toolset[ 'compile' ], opt, local_include, cdefs ) tools[ 'i386' ][ 'linkcom' ] = "%s -nostartfiles -nostdlib -march=i386 -mfpmath=387 -m32 -T %s -Wl,--gc-sections -Wl,-e,start -Wl,--allow-multiple-definition -o $TARGET $SOURCES -lc -lgcc -lm %s" % ( toolset[ 'compile' ], ldscript, local_libs )

注意到tools的定義使用到了toolset的定義，toolset是一個包含當前所使用工具名的字典。這也是eLua構建系統的一部分。
為了實現一個可以接收eLua可執行檔的函數（構建步驟的結果），並且產生一個在相應平台上合適的編程檔案，這個函數的名字應該被設定進tools字典中，如下所示（關於str7平台的例子代碼）：

# Programming function for STR7 def progfunc_str7( target, source, env ):   outname = output + ".elf"   os.system( "%s %s" % ( toolset[ 'size' ], outname ) )   print "Generating binary image..."   os.system( "%s -O binary %s %s.bin" % ( toolset[ 'bin' ], outname, output ) )              tools[ 'str7' ][ 'progfunc' ] = progfunc_str7

再一次提醒這個函數使用相同的toolset變數跟上面的一樣。stacks.h:按照慣例，系統所使用的棧空間被聲明在這裡。下面給出的例子是來自at91sam7x平台下的一段代碼：

#define  STACK_SIZE_USR   2048#define  STACK_SIZE_IRQ   64#define  STACK_SIZE_TOTAL ( STACK_SIZE_USR + STACK_SIZE_IRQ )

platform.c：按照慣例，平台介面的實現就在這個檔案裡。它也包含一些與平台無關的初始化函數。platform_conf.h：這是關於平台配置的標頭檔，其中給出了平台本身和構建相關平台的配置資訊。從這個檔案中，你將看到下列內容：

• 將要被構建的組件列表
• 將要被構建的模組列表
• 靜態配置資料
• CPU的各種外設的數目，下面的例子代碼展示了來自同一平台（lm3s）下不同CPU的外設情況。宏FORXXX被定義在conf.py檔案中

// Number of resources (0 if not available/not implemented)#define NUM_PIO               7#define NUM_SPI               1#ifdef FORLM3S6965  #define NUM_UART            3#else  #define NUM_UART            2#endif#define NUM_TIMER             4#ifndef FORLM3S6918  #define NUM_PWM             6#else  #define NUM_PWM             0#endif  #define NUM_ADC               4

• 特定的外設配置：包括UART使能緩衝，使能和開啟虛擬定時器，設定PIO配置等等。
• 記憶體配置：描述了記憶體分布地區。此地區將被標準系統分配。兩個宏MEM_START_ADDRESS 和MEM_END_ADDRESS定義了空閑RAM的起始地址和結束位址。如果你的板子有外部RAM空間，你也應該在這裡定義。如果沒有的話，你將只能使用內部記憶體，並且一般你需要使用連結定義標誌end找出你空閑記憶體從哪裡開始，下面的例子來自ATEVK1100（AVR32）開發板，它擁有內部和外部RAM

// Allocator data: define your free memory zones here in two arrays// (start address and end address)#define MEM_START_ADDRESS     { ( void* )end, ( void* )SDRAM }#define MEM_END_ADDRESS       { ( void* )( 0x10000 - STACK_SIZE_TOTAL - 1 ), ( void* )( SDRAM + SDRAM_SIZE - 1 ) }

• 網路設定：如果需要TCP/IP在你的開發板上，你需要向eLua添加網路支援。你也需要另一個叫做uip_conf.h檔案用來配置uip以用於你特定的處理器架構。

除了上述那些被要求的檔案外，常見的情況是在移植中需要添加跟特定平台相關的檔案：

• 開機檔案：一般用彙編書寫，做一些低檔次的初始化，設定堆棧指標，歸零BSS地區，將ROM中DATA地區移動到RAM中，然後跳轉到main函數。
• 連結命令檔案
• CPU支援包：一般來自裝置製造商，包括的代碼有控制外設，配置核心，開啟中斷等等。

水平有限，如有錯誤，給出指正。