表及其在固件层中的位置

通常，需要有一种方法来更改参数值，而无需重新编译源代码。

由于人力短缺，我们最近决定分包一个简单的电子设计，包括硬件和软件。我写了一个规范，但事实证明，我所期望的常识被设计师完全忽略了，因为他不知道我想要什么。他本可以问的，但那是另一回事了。“如果一个年轻的工程师没有这方面的知识，也许还有其他人，”我想，此时我感觉博客要上线了（我应该去躺下）。

当您编写一个软件时，大多数时候您使用常量来确定诸如执行循环的次数、激活输出之前等待的时间等等。在一个简单的 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 文件。

由于缺乏一个像样的程序员界面，也许这个整个表格的概念在未来不会起作用。或者也许我们应该投资一个具有合适用户界面的第三方程序员（如果这样的野兽仍然存在的话）。

审核编辑：汤梓红