探索IoT應用中對于8位、32位MCU的選擇

　　延時

　　兩種架構的中斷和函數調用延時存在很大差異，8051比ARM Cortex-M內核更快。此外，高級外設總線(APB)配備的外設也會影響延時，這是因為數據必須通過APB和AMBA高性能總線(AHB)傳輸。最后，當使用高頻內核時鐘時，許多基于Cortex-M的MCU需要分配APB時鐘，這也增加了外設延時。

　　我做了個簡單的實驗，實驗中的中斷是通過I/O引腳觸發的。該中斷對引腳發出一些信號，并根據引發中斷的引腳更新標志。然后我測量了一些參數，如下表所示。這里的列表顯示了32位的實現。

　　8051內核在中斷服務程序(ISR)進入和退出時顯示出優勢。但是，隨著中斷服務程序(ISR)越來越大和執行時間的增加，這些延遲將變得微不足道。和已有原則一致，系統越大，8051的優勢越小。此外，如果中斷服務程序(ISR)涉及到大量數據遷移或大于8位的整數數據運算，中斷服務程序(ISR)執行時間的優勢將轉向ARM內核。例如，一個采用新樣本更新16位或32位移動平均的ADC ISR可能在ARM設備上執行的更快。

　　控制vs.處理

　　8051內核的基本功能是控制代碼，其中對于變量的訪問是分散的，并且使用了許多控制邏輯(if、case等)。8051內核在處理8位數據時也是非常有效的，而ARM Cortex-M內核擅長數據處理和32位運算。此外，32位數據通道使得ARM MCU復制大包的數據更加有效，因為它每次可以移動4個字節，而8051每次僅能夠移動1個字節。因此，那些主要把數據從一個地方移動到另一個地方(例如UART到CRC或者到USB)的流數據處理的應用更適合選擇基于ARM處理器的系統。

　　來做個簡單的實驗。我們編譯以下兩種架構的函數，變量大小為uint8_t、uint16_t和uint32_t。

　　uint32_t funcB(uint32_t testA, uint32_t testB){

　　return (testA * testB)/(testA—testB)

　　}

　　|data type | 32bit(-o3) | 8bit |

　　| uint8_t | 20 | 13 | bytes

　　| uint16_t | 20 | 20 | bytes

　　| uint32_t | 16 | 52 | bytes

　　隨著數據量的增加，8051內核需要越來越多的代碼來完成這項工作，最終超過了ARM函數的大小。16位的情況下在代碼大小上幾乎類似，在執行速度上稍好于32位內核，因為相同代碼通常需要更少周期。還有一點很重要，那就是要注意到，只有采用優化的ARM編譯代碼時，這種比較才有效。未優化的代碼需要花費幾倍長的時間。

　　這并不意味著有大量數據移動或32位運算的應用不應該選擇8051內核完成。在許多情況下，其它方面的考慮將超過ARM內核的效率優勢，或者說這種優勢是不相關的。考慮使用UART到SPI橋接器。該應用花費大部分時間在外設之間復制數據，而ARM內核會更高效地完成該任務。然而，這也是一個非常小的應用，可能小到足以放入一個僅有2KB存儲容量的器件就足夠合適。

　　盡管8051內核效率較低，但它仍然有足夠的處理能力去處理該應用中的高數據速率。對于ARM設備來說，可用的額外周期可能處于空閑循環或“WFI”(等待中斷)，等待下一個可用的數據片到來。在這種情況下，8051內核仍然最有意義，因為額外的CPU周期是微不足道的，而較小的flash封裝會節約成本。如果我們要利用額外的周期去做些有意義的工作，那么額外的效率將是至關重要的，且效率越高越可能越有利于ARM內核。這個例子說明，清楚被開發系統所關注的環境中的各種架構優勢是何等重要。作出這個最佳的決定是簡單但卻重要的一步。

　　指針

　　8051設備沒有像ARM設備那樣的統一的存儲映射，而是對訪問代碼(Flash)、IDATA(內部RAM)和XDATA(外部RAM)有不同的指令。為了生成高效的代碼，8051代碼的指針會說明它指向什么空間。然而，在某些情況下，我們使用通用指針，可以指向任何空間，但是這種類型的指針是低效的訪問。例如，將指針指向緩沖區并將該緩沖區數據輸出到UART的函數。如果指針是XDATA指針，那么XDATA數組能被發送到UART，但在代碼空間中的數組首先需要被復制到XDATA。通用指針能同時指向代碼和XDATA空間，但速度較慢，并且需要更多的代碼來訪問。

　　專用區域指針在大多情況下能發揮作用，但是通用指針在編寫使用情況未知的可重用代碼時非常靈活。如果這種情況在應用中很常見，那么8051就失去了其效率優勢。

　　通過選擇完成工作

　　我已經注意到多次，運算傾向于選擇ARM，而控制傾向于選擇8051，但沒有應用僅僅著眼于計算或控制。我們怎樣才能表征廣義上的應用，并計算出它的合適范圍呢?

　　讓我們考慮一個由10%的32位計算、25%的控制代碼和65%的一般代碼構成的假定的應用時，它不能明確的歸于8或32位類別。這個應用也更注重代碼空間而不是執行速度，因為它并不需要所有可用MIPS，并且必須為成本進行優化。成本比應用速度更為重要的事實在一般代碼情形下將給8051內核帶來微弱優勢。此外，8051內核在控制代碼中有中間等級的優勢。ARM內核在32位計算上占上風，但是這并非是很多應用所考慮的。考慮到所有這些因素，這個特殊的應用選擇8051內核更加合適。

　　如果我們做一細微的改變，假設該應用更關心執行速度而非成本，那么通用代碼不會傾向于哪種架構，并且ARM內核在計算代碼中全面占優。在這種情況下，雖然有比計算更多的控制代碼，但是總的結果將相當均衡。

　　顯然，在這個過程中有很多的評估，但是分解應用然后評估每一組件的技術將幫助確保我們了解在哪種情況下哪種架構有更顯著的優勢。

　　功耗

　　當查閱數據手冊時，很容易根據功耗數據得出哪個MCU更優的結論。雖然睡眠模式和工作模式電流性能在某些類型MCU上確實更優，但是這一評估可能會非常具有誤導性。

　　占空比(在每個電源模式上分別占用多少時間)將始終占據能耗的主導地位。除非兩個器件的占空比相同，否則數據手冊中的電流規格幾乎是沒有意義的。最適合應用需求的核心架構通常具有更低的能耗。

　　假設有一個系統，在設備被喚醒后添加一個16位ADC樣本到移動平均，然后返回到休眠狀態，直到獲取下一個樣本時才又被喚醒。該任務涉及到大量16位和32位計算。ARM設備將能夠進行計算，并比8051設備更快返回到休眠狀態，這會讓系統功耗更低，即使8051具有更好的睡眠和工作模式電流。當然，如果進行的任務更適合8051設備，那么MCU能耗由于相同的原因而對系統有利。

　　外設特性也能夠以這樣或那樣的方式影響功耗。例如，大多數Silicon Labs的EFM32 32位MCU具有低功耗的UART(LEUART)，能夠在低功耗模式下接收數據，而卻只有兩個EFM8 MCU具有此功能。這一外設影響電源的占空比，且在任何需要等待UART通信的應用中都比缺乏LEUART的EFM8在很大程度上有利于EFM32 MCU。遺憾的是，除了讓MCU供應商的本地應用工程師利用EFM8來解決問題，沒有簡單的指南來評估這些外設因素。系統設計人員還應了解各種MCU能耗模式下可完成的處理任務。

　　8位或32位?我仍然不能決定!

　　如果考慮到所有這些變量后，仍然不清楚哪些MCU架構是最好的選擇，會怎樣?那好吧!這說明，它們都是很好的選擇，你使用哪種體系結構并不是緊要的事情。如果沒有明確的技術優勢，那么過去的經驗和個人喜好在你的MCU架構決定中也起到了很大的作用。此外，你也可以利用這個機會去評估可能的未來項目。如果大多數未來項目更適合ARM設備，那么選擇ARM，如果未來項目更側重于降低成本和尺寸，那么就選擇8051。

　　這到底意味著什么呢?

　　8位MCU仍然可以為嵌入式開發人員提供許多功能，并且越來越關注物聯網。當開發人員開始設計時，重要的是確保從工具箱中獲得合適的工具。雖然我還是很樂意把8051出售給可能更適合選擇32位設備的客戶，但是我不禁要想象如果開發人員僅僅花費1個小時思考就作出決定，那么他們的工作將會如何更加容易、最終產品將會有多好。

　　實際上的難題是，不能僅僅依賴于PowerPoint演示文稿中的一兩個要點就得出選擇MCU架構的結論。然而，一旦你有正確的信息，并愿意花一點時間應用它，就不難作出最佳選擇。

　　關于作者

　　Josh Norem是Silicon Labs微控制器和無線產品系統工程師。他于2006年加入Silicon Labs公司，任職產品和測試工程師，擔任過包括測試和應用方面的多個技術職位，最近擔任系統工程師。在加入Silicon Labs公司之前，Josh就職于AMD公司，負責AMD的x86微處理器的系統級速度調試工作。此前，他就職于TI，負責TI的DSP產品的開發和存儲測試。Josh擁有伊利諾斯大學(University of Illinois)Urbana-Champaign分校電氣工程科學學士學位。