安裝了64位linux版的arduino IDE　1.8.1用于在arduino_due平臺上做開發(fā)，總體上給我的感覺用arduio IDE編譯，upload 程序，比之前在due上跑zephyr內核要直觀，方便很多，　只需要點擊幾個按鈕就能搞定一切.　但是IDE背后隱藏了很多重要的啟動機制，則是用這種開發(fā)模式看不到的．

　最簡單的例子，　打開一個arduion ide的一個工程，可以看到開發(fā)出來的接口只有setup和loop兩個:

　系統(tǒng)會主動鏈接和調用這兩個接口，　用戶只要在這兩個函數(shù)中寫好自己的邏輯．不需要知道背后的啟動細節(jié)，　但這個流程是怎樣的呢？

進入到arduino的安裝目錄，找到arduion sdk所在路徑　/home/user/.arduino15/packages/arduino/hardware/sam/1.6.11/cores/arduino/main.cpp，打開main.cpp文件: 上圖清楚的表明了setup, loop的調用機制，　由此揭開了arduino ide sdk的神秘面紗．為了更好用，sdk屏蔽了 cpu底層的啟動細節(jié)以及必要的底層硬件初始化機制，　同時，sdk還提供了很多的庫文件類供用戶調用．

另一個問題來了，　main函數(shù)是誰調用的呢？　要完整描述整個啟動流程，必須了解一些cortex-m系列處理器的細節(jié)．　 我們知道，cortex-m系列是從復位向量處開始啟動的，cortex_m有２５５個啟動向量，這些向量大部分是給外部ＩＯ中斷使用的，根據(jù)外部IO的連接可選配置，　但前１６個是必不可少的，必須要設置，　以zephyr內核為例，在zephyr/arch/arm/core/cortex_m/vector_table.S文件中: 向量第二個slot __reset就是啟動入口． 處理器的實現(xiàn)不依賴os的邏輯，所以arduino也應該有同樣一張啟動向量表，我們要找到它，然后跟據(jù)第二個slot的定義去尋徐追蹤，直到找到調用main函數(shù)，邏輯鏈條閉合．

幾經(jīng)周折，找到.arduino15/packages/arduino/hardware/sam/1.6.11/system/CMSIS/Device/ATMEL/sam3xa/source/gcc_atmel/startup_sam3xa.c 　文件，異常向量表在這里: 　

得知啟動入口是Reset_Handler, 同樣定義在本文件中:

可以看到，在啟動線程里過來調用了前面提到的main函數(shù)，整個邏輯鏈條打通了．

關于中斷處理，　以PIOD中斷為例，　在異常表中: PIOD_Handler定義在中斷表里面，找到他的定義, 在文件 ~/.arduino15/packages/arduino/hardware/sam/1.6.11/cores/arduino/WInterrupts.c中:

看到函數(shù)中調用 callback指針表． 函數(shù)指針數(shù)組中記錄有每個終端發(fā)生時的終端處理程序入口，在同一個文件中被初始化: 所以，用戶程序只需要調用attachInterrupt函數(shù)注冊中斷入口即可．

從嵌入式os的角度看，arduino ide提供的sdk僅僅是一個前后臺系統(tǒng)，　是一個順序執(zhí)行的系統(tǒng)，其程序進程中只有一個main線＞程，程序功能的實現(xiàn)是依靠死循環(huán)實現(xiàn)；實時性主要是靠外部中斷信號，或者檢測IO口得信號實現(xiàn)的，中斷的運行的速度還＞是比較快的，這是因為它完全是基于硬件機制的。至于實時性，如果是在簡單的系統(tǒng)中，即任務數(shù)少的情況，那前后臺還是＞很迅速的．實時性收到線程數(shù)量的限制．

或者說arduino ide提供的sdk僅僅是一個單線程的裸機bootflow，　根本沒有os, 整個過程僅僅是不斷的執(zhí)行l(wèi)oop函數(shù)，這讓我想起了西門子ＰＬＣ的OB1 大循環(huán)，所有的事件處理都要安排在一個循環(huán)內進行，對于一個系統(tǒng)來講，實時性肯定是不夠的．