用于引导加载程序的向量 Table
Vector Table for Bootloader
大多数（如果不是全部）微控制器都有一个向量 table，用于程序 运行 时遇到的所有异常。我很困惑引导加载程序是否也有自己的向量 table 来执行重置处理程序？
引导加载程序只是一个程序，那里没有魔法，与任何其他程序一样，如果它需要向量 table，程序员会创建一个向量 table。当然，如果它需要 运行 从重置，那么它必须符合 hardware/processor 规则。处理器或任何其他逻辑都无法知道该位集合、该指令集合是否是引导加载程序。只是 运行 而已。
我假设您是在谈论许多（但不是全部）flavors/brands 具有在工厂编程的引导加载程序的微控制器？
在单片机中有一个带有内存总线的处理器核心。芯片、ram、闪存、gpio、spi、定时器、uart、adc 等中的许多项目都住在那辆公共汽车上，就像在一条特定街道上拥有不止一所房子一样。处理器总线上的这些项目中的每一个都有地址解码器在总线上寻找它们的地址，以知道何时获取或提供 data/information。 application flash 和 bootloader rom 没有区别，没有特别之处。就像在软件中一样容易，在硬件中也很容易有某种 if-then-else 允许应用程序闪存在向量 table 地址处回答处理器，该标志驱动 then否则外壳可以是零件的输入引脚。将引脚拉高并按下复位，部件从一个存储器启动，将引脚拉低按下复位，部件从另一个存储器启动。还有其他解决方案可能不是由部件的输入引脚驱动，而是由引导加载程序软件驱动。
有时处理器核心本身有一个信号，表明芯片供应商随心所欲地驱动，在处理器核心内它会执行 if-then else，也许 then 的情况是 0x00000000 是它寻找向量的地方 table, else case 0xFFFF0000.
归根结底，引导加载程序只是某人为该芯片编写的另一个程序，与您为芯片编写的程序没有什么不同，只是如果它是工厂编程的 rom 引导加载程序，那么该引导加载程序的程序员可能有额外的 information/documentation 用于我们没有的那部分。但是作为引导加载程序并不神奇，它只是一个程序，一组指令。我们的应用程序也可以是一个引导加载程序，根据我们的引导加载程序发现的内容，有几个可能的不同应用程序，他们的引导加载程序可以引导我们的引导加载程序，然后从多个应用程序中选择 运行s 其中之一。全部在一个部分内...
我编写了一个引导加载程序，它已在通信产品（MSP430、AVR32、DSP56300）中使用的许多不同嵌入式处理器之间移植。此加载程序的功能要求非常有限
- 硬件初始化。
- 使用校验和或加密签名验证主代码图像。
- 如果验证通过，将控制转移到主应用程序。
- 通过串行端口提供最小命令接口以允许固件更新。
- 允许主应用程序触发新固件加载的重新进入点。
同一处理器上保存在非易失性存储器中的两个程序之间的这种操作转移意味着我必须在两个完全独立的应用程序之间提供中断函数的重定向。 MSP430 的中断 table 保存在 FLASH 中，因此不容易修改。它还包含必须始终指向引导加载程序代码开头的复位向量，因此擦除和重写该区域存在完全使单元变砖的风险。
这种情况下的解决方案是在引导加载程序中有一个中断服务例程，该例程通过位于应用程序内存 space 内固定位置的向量 table 重定向。使用此方法向每个中断处理程序添加一个间接跳转指令，从而为处理的每个中断产生最小的额外处理器负载。引导加载程序被编写为不使用任何依赖轮询所有通信的串行端口状态的中断。如果引导加载程序需要使用中断，则可以将向量 table 移动到 RAM 并由引导加载程序或应用程序根据需要进行初始化。 （我的处理器没有足够的 RAM 来支持这个）
在主应用程序代码的固定位置有一个简单的数据结构，其中包含每个可能的条目 interrupt/exception 和应用程序代码的起始地址（您可以将其视为应用程序代码重置向量).只要应用程序在闪存中提供此数据结构并正确填充它，它就可以完全单独编译和构建，就好像它是处理器上唯一的应用程序一样。
大多数（如果不是全部）微控制器都有一个向量 table，用于程序 运行 时遇到的所有异常。我很困惑引导加载程序是否也有自己的向量 table 来执行重置处理程序？
引导加载程序只是一个程序，那里没有魔法，与任何其他程序一样，如果它需要向量 table，程序员会创建一个向量 table。当然，如果它需要 运行 从重置，那么它必须符合 hardware/processor 规则。处理器或任何其他逻辑都无法知道该位集合、该指令集合是否是引导加载程序。只是 运行 而已。
我假设您是在谈论许多（但不是全部）flavors/brands 具有在工厂编程的引导加载程序的微控制器？
在单片机中有一个带有内存总线的处理器核心。芯片、ram、闪存、gpio、spi、定时器、uart、adc 等中的许多项目都住在那辆公共汽车上，就像在一条特定街道上拥有不止一所房子一样。处理器总线上的这些项目中的每一个都有地址解码器在总线上寻找它们的地址，以知道何时获取或提供 data/information。 application flash 和 bootloader rom 没有区别，没有特别之处。就像在软件中一样容易，在硬件中也很容易有某种 if-then-else 允许应用程序闪存在向量 table 地址处回答处理器，该标志驱动 then否则外壳可以是零件的输入引脚。将引脚拉高并按下复位，部件从一个存储器启动，将引脚拉低按下复位，部件从另一个存储器启动。还有其他解决方案可能不是由部件的输入引脚驱动，而是由引导加载程序软件驱动。
有时处理器核心本身有一个信号，表明芯片供应商随心所欲地驱动，在处理器核心内它会执行 if-then else，也许 then 的情况是 0x00000000 是它寻找向量的地方 table, else case 0xFFFF0000.
归根结底，引导加载程序只是某人为该芯片编写的另一个程序，与您为芯片编写的程序没有什么不同，只是如果它是工厂编程的 rom 引导加载程序，那么该引导加载程序的程序员可能有额外的 information/documentation 用于我们没有的那部分。但是作为引导加载程序并不神奇，它只是一个程序，一组指令。我们的应用程序也可以是一个引导加载程序，根据我们的引导加载程序发现的内容，有几个可能的不同应用程序，他们的引导加载程序可以引导我们的引导加载程序，然后从多个应用程序中选择 运行s 其中之一。全部在一个部分内...
我编写了一个引导加载程序，它已在通信产品（MSP430、AVR32、DSP56300）中使用的许多不同嵌入式处理器之间移植。此加载程序的功能要求非常有限
- 硬件初始化。
- 使用校验和或加密签名验证主代码图像。
- 如果验证通过，将控制转移到主应用程序。
- 通过串行端口提供最小命令接口以允许固件更新。
- 允许主应用程序触发新固件加载的重新进入点。
同一处理器上保存在非易失性存储器中的两个程序之间的这种操作转移意味着我必须在两个完全独立的应用程序之间提供中断函数的重定向。 MSP430 的中断 table 保存在 FLASH 中，因此不容易修改。它还包含必须始终指向引导加载程序代码开头的复位向量，因此擦除和重写该区域存在完全使单元变砖的风险。
这种情况下的解决方案是在引导加载程序中有一个中断服务例程，该例程通过位于应用程序内存 space 内固定位置的向量 table 重定向。使用此方法向每个中断处理程序添加一个间接跳转指令，从而为处理的每个中断产生最小的额外处理器负载。引导加载程序被编写为不使用任何依赖轮询所有通信的串行端口状态的中断。如果引导加载程序需要使用中断，则可以将向量 table 移动到 RAM 并由引导加载程序或应用程序根据需要进行初始化。 （我的处理器没有足够的 RAM 来支持这个）
在主应用程序代码的固定位置有一个简单的数据结构，其中包含每个可能的条目 interrupt/exception 和应用程序代码的起始地址（您可以将其视为应用程序代码重置向量).只要应用程序在闪存中提供此数据结构并正确填充它，它就可以完全单独编译和构建，就好像它是处理器上唯一的应用程序一样。