ARM Cortex-M7的內存：太大還是不夠？

　　毫無(wú)疑問(wèn)，ARM Cortex-M7 - 擁有強大的內存和處理能力 –以即使在幾年前都難以想象的方式擴展了微控制器的功能。該處理器被定位成為物聯(lián)網(wǎng)(IOT)的核心構建模塊的事實(shí)，更是奪人眼目。

　　事實(shí)上，意法半導體的STM32 F7系列在9月的ARM科技論壇上榮獲了最佳表現獎。這是第一款采用ARM的Cortex-M7內核的32位MCU家族，擁有320KB SRAM和1024KB閃存。愛(ài)特梅爾采用Cortex-M7內核的處理器還沒(méi)有公布，預計將有384KB SRAM和2MB閃存，這種內存規格高出典型的MCU 10倍以上。

　　但是，Cortex-M7是否擁有“完成任務(wù)”所需的必要資源基本上還是要取決于開(kāi)發(fā)者。本質(zhì)上：今天的嵌入式開(kāi)發(fā)人員，有時(shí)是在似乎幾乎不受約束的設計空間上，絞盡腦汁地在硬件、軟件和系統設計上做出如毛線(xiàn)團似的大量繁雜的決定和取舍。

?

　　“對于來(lái)自Windows，Linux，iOS，Web服務(wù)編程和商用邏輯編程領(lǐng)域的開(kāi)發(fā)人員，Cortex-M7有太多限制和性能上的扼殺。但是，對于曾在8051等任何8位微處理器上，或Cortex-M0到M3上的開(kāi)發(fā)者而言，他們眼中的Cortex-M7資源豐富、性能強大?！?Matt Liberty說(shuō)。他是Jetperch LLC的創(chuàng )始人，該公司提供DSP和嵌入式軟件咨詢(xún)服務(wù)。

　　一個(gè)實(shí)時(shí)I / O處理的強者

　　“這是一個(gè)實(shí)時(shí)I/ O處理的強者。事實(shí)上，像很多在8位單片機上編寫(xiě)的小型嵌入式程序那樣不帶操作系統裸機運行在目標硬件上的循環(huán)程序，它們高效、簡(jiǎn)單易懂且易于調試，可能很難使用這么多的性能配置和存儲器?！?/p>

　　Liberty強調，在物聯(lián)網(wǎng)的應用場(chǎng)景中，為了更有效地管理復雜的網(wǎng)絡(luò )和多個(gè)外圍設備，采用一個(gè)實(shí)時(shí)操作系統(RTOS)變得非常關(guān)鍵。但是，過(guò)去幾年來(lái)，隨著(zhù)開(kāi)發(fā)社區努力尋找更佳的方案，RTOS的數量也在激增，現在，選擇“最好”的RTOS已經(jīng)成為開(kāi)發(fā)人員的一大挑戰。

　　“快速瀏覽維基百科的“實(shí)時(shí)操作系統列表”就足以讓嵌入式軟件工程師頭大”，Liberty強調。 “雖然C和C ++仍然司空見(jiàn)慣，但在考慮多線(xiàn)程、安全性以及可靠性時(shí)，這兩種語(yǔ)言都顯得捉襟見(jiàn)肘。D和Rust語(yǔ)言具有填補這些空白的潛力，但它們今天都沒(méi)有做好用于嵌入式應用的準備?！?/p>

　　Frank Hunleth，一名專(zhuān)注于視頻處理和嵌入式Linux開(kāi)發(fā)的嵌入式軟件開(kāi)發(fā)人員，他也認為，實(shí)時(shí)操作系統行業(yè)需要證明在這些平臺上使用高級語(yǔ)言的可能性，并幫助定義它們的庫。

　　“我敢肯定，如果明年我在一個(gè)項目上使用M7，我還是會(huì )使用C或C ++，因為它們有大部分工具和庫的廣泛支持，”他說(shuō)。 “我希望這種情形保持下去嗎?不是的，因為如果這樣，我們將錯失可以從Rust語(yǔ)言得到的靜態(tài)檢查內存安全，從Python語(yǔ)言得到的易開(kāi)發(fā)特性，和來(lái)自Erlang和Elixir的容錯性和并發(fā)性?！?/p>

　　內存有點(diǎn)小

　　其他人覺(jué)得，對物聯(lián)網(wǎng)而言，即使有旨在最大限度地利用M7內存的功能特性，M7的內存依然稍顯不足。一個(gè)例子是ST針對內部嵌入式閃存和L1高速緩存的自適應實(shí)時(shí)加速器，它可以從內部和外部存儲器同時(shí)執行指令和訪(fǎng)問(wèn)數據。

　　“對一個(gè)微控制器而言，這是一個(gè)很大的內存和存儲空間。但是，哪怕是最小的Java虛擬機[即解釋Java字節碼，使處理器執行程序指令的環(huán)境]至少也需要2MB才能運行起來(lái)，一時(shí)半會(huì )我們還不太可能會(huì )看到Java或任何其他基于虛擬機的平臺上運行在這些小的CPU內核上?！?PTR集團的首席技術(shù)官和首席科學(xué)家Michael Anderson說(shuō)?！叭绻阍黾右粋€(gè)通信協(xié)議棧和一個(gè)可執行程序或諸如ARM的mbed、Micrium的μC/ OS-III或FreeRTOS之類(lèi)的實(shí)時(shí)操作系統，你的程序空間會(huì )顯得非常小?！?/p>

　　Anderson強調，內存使用率是很多這些物聯(lián)網(wǎng)新應用的命脈?！皟却媸菍氋F的。類(lèi)庫內部封裝的API會(huì )吃掉內存，盡管它在通用計算機上表現良好。這些年，在計算機行業(yè)，我們的代碼只有少數存在不知情內存膨脹的案例。如果我們不認真思考正在進(jìn)行的開(kāi)發(fā)任務(wù)，并繼續以我們在大容量?jì)却姝h(huán)境下已經(jīng)習慣的方式編寫(xiě)代碼，我們就永遠無(wú)法使用這些小內存的微控制器進(jìn)行物聯(lián)網(wǎng)應用開(kāi)發(fā)，并發(fā)掘出其令人驚艷的可能性?！?/p>