进行嵌入式软件更新时，您应该擦除整个应用程序代码，还是仅部分更新应用程序？
当公司更新产品的嵌入式C代码应用程序固件（通过MicroController上的引导加载程序或JTAG等）时，它们通常是否通常会刷新一个全新的.hex/.bin文件，其中包含新功能 +旧软件？因此，完全消除了旧程序？ 还是通过单独的.hex/.bin文件进行部分应用程序更新是标准的？
我之所以问这个问题，是因为我想知道发布不同嵌入式软件包的最佳行业实践。理想情况下，能够在不更新整个程序内存的情况下为项目的功能进行特定更新会很高兴。
例如： 假设您的项目的嵌入式C软件具有3个功能：
- 用户输入处理
- 如果您有每个功能的许多软件版本，并且想测试不同版本的组合，则显示输出
- 电源管理的
，可以为每个功能提供单独的.hex/.bin那被闪烁到MCU上了吗？
When a company updates a product's embedded C code application firmware (via a bootloader on the microcontroller, or JTAG, etc.), do they normally flash a whole new .hex/.bin file that contains the new features + old software? Therefore, wiping out the old program entirely?
Or is it standard to make partial application updates via separate .hex/.bin files?
I am asking this question because I want to know the best industry practice for releasing different embedded software packages. Ideally it would be nice to be able to flash specific updates for a feature of a project without updating the entire program memory.
For example:
Lets say your project's embedded C software has 3 features:
- user input handling
- displaying an output
- Power supply management
If you had many software versions of each feature and wanted to test combinations of different versions, can you have separate .hex/.bin for each feature that gets flashed onto the MCU?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
除非您将其某些部分设计为独立于位置的代码，否则您将无法真正更新程序，然后将这些部分从固定地址开始链接。可以做到，但在设计过程中增加了额外的复杂性。
否则，如果您没有像这样设计程序，那么机器代码将充满绝对地址并跳到错误的位置。
正常的方法是一次更新整个程序（也许减去存在的任何引导加载器零件）。并可选地分别更新数据闪存/EEPROM。
You can't really update the program partially unless you have designed certain parts of it as position-independent code and then linked those parts starting at fixed addresses. It can be done, but adds extra complexity during design.
Otherwise if you haven't designed your program like this, the machine code will be full of absolute addresses and jump to the wrong places.
The normal way is to update the whole program at once (perhaps minus any bootloader parts present). And optionally update data flash/eeprom separately.
这取决于操作系统，体系结构和系统的需求。
It depend on the OS, architecture and the need of your system.
部分更新非常常用，但与您描述的更新不同。
最常用的情况是您拥有Bootloade+应用程序的位置，并且仅更新了应用程序。
当应用程序彼此完全分开时，此方法是合适的。
您描述的情况意味着每个功能都需要相互通信或与主应用程序进行通信。在这种情况下，尝试将功能分离为单独的闪光区域将是太多麻烦。
您必须为每个“功能”提供一个单独的闪存段，从而导致空白（浪费空间），同时希望您的功能不会超越分配的空间。此外，您必须担心如何在不同功能之间实施通信，保持兼容性等...
只需将所有内容链接在一起并立即更新所有内容。
Partial update is used very commonly, but in a different way than the one you have described.
The most common used case is where you have a bootloade+application and only the application is updated.
This approach is suitable when the applications are completely separate from each other.
The case that you are describing implies that each feature need to communicate with each other or with the main application. In this case, it would be way too much trouble to try and separate the features into separate flash regions.
You'd have to give a separate flash segment for each "feature", resulting in gaps (wasted space), while hoping that your feature does not outgrow the allocated space. Additionally, you'd have to worry about how to implement communication between different features, maintaining compatibility etc...
Just link everything together and update everything at once.