通常，需要有一種方法來更改參數值，而無需重新編譯源代碼。

由于人力短缺，我們最近決定分包一個簡單的電子設計，包括硬件和軟件。我寫了一個規范，但事實證明，我所期望的常識被設計師完全忽略了，因為他不知道我想要什么。他本可以問的，但那是另一回事了。“如果一個年輕的工程師沒有這方面的知識，也許還有其他人，”我想，此時我感覺博客要上線了（我應該去躺下）。

當您編寫一個軟件時，大多數時候您使用常量來確定諸如執行循環的次數、激活輸出之前等待的時間等等。在一個簡單的 C 程序中，這些常量是使用#define宏以如下形式建立的：

#define WAIT_TIME_BEFORE_ACTIVATING_SOLENOID 4000 //time in mS

可以有這些常量的完整列表。當您想修改某些內容時，您只需轉到宏定義，更改值，然后重新編譯。這一切都很好，但是很多時候用戶想要改變系統的性能并且沒有知識或資源來做到這一點，更不用說讓你的源代碼進入公共領域了。所需要的是一種無需重新編譯源代碼即可更改參數值的方法。

想想您可以在現代車輛中更改的參數——您可以對鎖車后燈保持亮起的時間進行編程；您可以啟用/禁用接近傳感器；并且——根據汽車的復雜程度——你可以改變幾十到幾百個。現代系統通常將允許使用用戶界面或通過通信通道進行某種下載來更改這些參數。顯然，這些參數必須駐留在可以重新配置的內存中——有時是 RAM，但主要是配置為像 EEPROM 一樣執行的 EEPROM 或閃存。

當您在 C 中聲明一個常量時，如下所示：

const uint16_t iVariable1 = 45;
const uint16_t iVariable2[4]= {45,46,47,48};

大多數編譯器會將這些組合在一起，并將結果數據放在閃存中的某個位置。我不相信有任何保證它們會相鄰。在沒有專用 EEPROM 的 micros 中，并不是所有的 flash 存儲器都可以當作 EEPROM 來處理，所以通常會有一條指令說服編譯器將一些內存空間當作 EEPROM 來處理。例如，在使用 Keil 編譯器的 Cypress PSoC4 上，指令如下所示：

const uint8_t EmEEPROM_em_EepromStorage[EmEEPROM_PHYSICAL_SIZE] __ALIGNED(CY_FLASH_SIZEOF_ROW) = {0u};

但是您的處理器和編譯器會有所不同。

為了確保 EEPROM 中的所有元素都是相鄰的（稍后我將解釋原因），我很想創建一個數組（或者可能是一個結構），就像我在 PSoC4 聲明中所做的那樣：

uint8_t eepromArray[48];

然后通過一個enum或一組#defines，確定數組的哪個元素與特定參數相關聯。

現在，讓我回到我們將微控制器嵌入恐龍跟蹤設備的時間。那時，還沒有 EEPROM。后來，EEPROM 以外部設備的形式提供。然而，客戶仍然希望在不重新編譯的情況下更改參數。

開發系統很笨重，獨立的（通常是便攜式的）PROM 編程器通常是必要設備的一部分。該技術是使用上述一些技術在 EPROM（外部或嵌入在微型計算機中）中創建一個表作為程序的一部分。客戶將能夠使用 EPROM 編程器從主 IC 甚至目標設備讀取二進制代碼，轉到表位置并修改存在的數字，然后將整個 shebang 編程回空白 EPROM。然后他/她將 EPROM 插回目標套接字——不需要程序匯編-鏈接-加載-編譯。

不同模塊的鏈接和位置是命令行的一部分（可以從批處理文件中輸入），并且有很多關于如何在不同位置定位內存的不同部分的文檔。如果您使用的是外部內存或內存分區設備，則可能會有很多這樣的分配。不管好壞，這個功能已經被升華了，并且作為現代用戶界面的一部分，細節并不容易獲得，盡管從我有時會在屏幕上看到閃爍的一閃而過的一瞥中，我認為那些命令行可能仍然存在。

在小型系統上，這種舊技術可能仍然是實現客戶可配置性的唯一方法。在引發此博客的項目中，我們的客戶要求重新配置表格，而我們的分包商將“表格”解釋為一堆#defines重新編譯。

使用const聲明很容易；問題在于桌子的位置。可以從編譯報告中提取內存中的確切位置（同樣，每個處理器/編譯器可能不同），但該位置可能因每次編譯迭代而異。使用固定位置的想法有很多值得推薦的地方。我對如何使用 PSoC 微控制器解決這個問題有一個相當好的想法，但上述項目中的處理器是 Microchip Atmega328，這意味著我有一個大問題——我根本不知道。

有一些關于在 Atmega 上實現此功能的在線討論。該設備實際上具有 EEPROM，因此將表格放在那里可能同樣容易，但這僅在開發工具允許您更改 EEPROM 值甚至程序存儲器時才有用。時間會證明一切。

兩個分開的想法：一些關鍵任務設備具有檢查內存校驗和以確保程序內存正常的例程。在這種情況下，校驗和計算應排除任何要調整的表。

調整影響軟件性能的參數實際上可能會突出或掩蓋程序中的缺陷。但不能保證僅僅因為您可以更改性能，您的軟件就沒有錯誤。我曾經有一個上司受此錯覺困擾——我在那份工作上只干了三個月。

后記

在重新設計之后，我們的分包商選擇將表格放置在 EEPROM 中。看來 Atmel Studio 7 確實允許您訪問 EEPROM，但它不會將內容顯示為屏幕上的表格。分包商采用的流程是使用 Atmel Studio 7（在 PC 上運行）將 EEPROM 內容讀入 hex 文件，編輯 hex 文件的內容，為已更改的每一行創建一個新的校驗和，重新保存文件，然后將文件寫回 EEPROM。您還必須來回更改一些微型的內部“開關”以訪問 EEPROM，然后返回標準操作。這似乎有點令人費解——我確實希望找到一種更優雅的方式。

后記

我剛剛嘗試了 PSoC Programmer，看看是否可以直接從用戶界面 (UI) 修改一個字節。雖然不需要切換微控制器的編程設置，但不幸的是，它仍然需要與上述相同的技術來編輯 hex 文件。

由于缺乏一個像樣的程序員界面，也許這個整個表格的概念在未來不會起作用。或者也許我們應該投資一個具有合適用戶界面的第三方程序員（如果這樣的野獸仍然存在的話）。

審核編輯：湯梓紅