首先，您是否考虑从Bootloader中删除USB主机代码。我不知道你的设计细节，但在我们的设计中，我们有一个SPI闪存，用于下载新的代码。应用程序从USB、Internet、SD卡或任何地方获得新代码，并在SPI闪存中写入代码的新版本。Bootloader将代码从SPI Flash传输到程序存储器，这意味着很容易放弃一次失败的下载，因为只有SPI被写入，所以在SPI闪存中携带一个固件图像和在发生故障时重载和旧图像更容易携带。3）自举器是简单的，因为它只是传输数据，所以不太可能有BUGS4），引导加载程序非常小。如果你想用USB驱动程序保持引导加载程序。在Bootloader和主应用程序之间重用代码是可能的，1）保留一个程序存储器的一部分，它可以从APP和Bootloader访问，这意味着存储器的物理地址必须从两个固件中得知。2）在应用端，构造当您想在应用程序侧使用一个函数时，要在Bootloader端上写入所有函数的函数指针表，并将其写入Bootloader端。转到共享内存，并根据其在共享结构上的位置查找函数指针的地址，然后调用函数。
以上来自于百度翻译
以下为原文
First, did you consider removing the USB host code from the bootloader. I do not know the details of your design, but in our designs we have a SPI flash reserved for downloading new code. the application gets the new code form the USB, Internet, SD card or wherever, and writes the new version of the code in the SPI flash. The bootloader transfers the code from SPI flash to program memory.
This means
1) It is easy to abandon a failed download, since only the SPI was written
2) Its easy to carry more that one firmware image in SPI flash and reload and older image when failures occur.
3) The bootloader is simple, since it just transfers data, so is less likely to have bugs
4) The bootloader is very small.
If you want to keep the bootloader with the USB driver. It is possible to re-use code between the bootloader and the main application,
1) Reserve a section of program memory that can be accesses from both app and bootloader, this means that the physical address of the memory must be known from both pieces of firmware.
2) On the application side, construct a table of function pointers for all the functions you wish to share, and write the structure into the shared memory
3) On the bootloader side, when you want to use a function on the application side. go to the shared memory and look up the address of function pointer by its position on the shared structure, then call the function.
首先，您是否考虑从Bootloader中删除USB主机代码。我不知道你的设计细节，但在我们的设计中，我们有一个SPI闪存，用于下载新的代码。应用程序从USB、Internet、SD卡或任何地方获得新代码，并在SPI闪存中写入代码的新版本。Bootloader将代码从SPI Flash传输到程序存储器，这意味着很容易放弃一次失败的下载，因为只有SPI被写入，所以在SPI闪存中携带一个固件图像和在发生故障时重载和旧图像更容易携带。3）自举器是简单的，因为它只是传输数据，所以不太可能有BUGS4），引导加载程序非常小。如果你想用USB驱动程序保持引导加载程序。在Bootloader和主应用程序之间重用代码是可能的，1）保留一个程序存储器的一部分，它可以从APP和Bootloader访问，这意味着存储器的物理地址必须从两个固件中得知。2）在应用端，构造当您想在应用程序侧使用一个函数时，要在Bootloader端上写入所有函数的函数指针表，并将其写入Bootloader端。转到共享内存，并根据其在共享结构上的位置查找函数指针的地址，然后调用函数。
以上来自于百度翻译
以下为原文
First, did you consider removing the USB host code from the bootloader. I do not know the details of your design, but in our designs we have a SPI flash reserved for downloading new code. the application gets the new code form the USB, Internet, SD card or wherever, and writes the new version of the code in the SPI flash. The bootloader transfers the code from SPI flash to program memory.
This means
1) It is easy to abandon a failed download, since only the SPI was written
2) Its easy to carry more that one firmware image in SPI flash and reload and older image when failures occur.
3) The bootloader is simple, since it just transfers data, so is less likely to have bugs
4) The bootloader is very small.
If you want to keep the bootloader with the USB driver. It is possible to re-use code between the bootloader and the main application,
1) Reserve a section of program memory that can be accesses from both app and bootloader, this means that the physical address of the memory must be known from both pieces of firmware.
2) On the application side, construct a table of function pointers for all the functions you wish to share, and write the structure into the shared memory
3) On the bootloader side, when you want to use a function on the application side. go to the shared memory and look up the address of function pointer by its position on the shared structure, then call the function.
举报
