ZHCUB85 August   2023 TMS320F28075 , TMS320F28075-Q1 , TMS320F28076 , TMS320F28374D , TMS320F28374S , TMS320F28375D , TMS320F28375S , TMS320F28375S-Q1 , TMS320F28376D , TMS320F28376S , TMS320F28377D , TMS320F28377D-EP , TMS320F28377D-Q1 , TMS320F28377S , TMS320F28377S-Q1 , TMS320F28378D , TMS320F28378S , TMS320F28379D , TMS320F28379D-Q1 , TMS320F28379S , TMS320F28P650DH , TMS320F28P650DK , TMS320F28P650SH , TMS320F28P650SK , TMS320F28P659DH-Q1 , TMS320F28P659DK-Q1 , TMS320F28P659SH-Q1

 

  1.   1
  2.   摘要
  3.   商标
  4. 1F2837x 和 F28P65x 的特性差异
    1. 1.1 F2837x 和 F28P65x 特性比较
  5. 2PCB 硬件更改
    1. 2.1 176 引脚 PTP 和 100 引脚 PZP 封装的 PCB 硬件更改
    2. 2.2 使用现有 176 引脚 F2837x PCB 设计
      1.      9
      2. 2.2.1 JTAG TRSTn 无连接
      3. 2.2.2 GPIO 输入缓冲器控制寄存器
      4. 2.2.3 176 引脚 GPIO 引脚/多路复用和 ADCD 注意事项
        1. 2.2.3.1 具有不同 GPIO 分配的 176 引脚 PTP 引脚
        2. 2.2.3.2 ADCD 通道迁移
    3. 2.3 176 引脚 PTP 新型 PCB 设计
    4. 2.4 100 引脚 PZP 新型 PCB 设计
    5. 2.5 将 337-BGA ZWT 应用于 256-BGA ZEJ 或 169-BGA NMR
  6. 3系统特性差异注意事项
    1. 3.1 F28P65x 的新特性
      1. 3.1.1 锁步比较模块 (LCM)
      2. 3.1.2 扩展的模拟通道
      3. 3.1.3 固件更新 (FWU)
      4. 3.1.4 灵活的 GPIO 和数字输入引脚
      5. 3.1.5 ADC 硬件冗余安全校验器
      6. 3.1.6 在 CPU 子系统之间灵活地共享存储器
      7. 3.1.7 增加了 CLA 上的 RAM 程序存储器
    2. 3.2 通信模块更改
    3. 3.3 控制模块更改”中重点介绍了这一新特性。
    4. 3.4 模拟模块差异
    5. 3.5 其他器件更改
      1. 3.5.1 Pie 通道映射
        1. 3.5.1.1 F2837x 与 F28P65x PIE 通道映射比较
      2. 3.5.2 Bootrom
      3. 3.5.3 AGPIO 滤波器
    6. 3.6 电源管理
      1. 3.6.1 VREGENZ
      2. 3.6.2 POR/BOR
      3. 3.6.3 功耗
    7. 3.7 内存模块更改
    8. 3.8 GPIO 多路复用更改
      1. 3.8.1 F2837x 与 F28P65x GPIO 多路复用器比较
    9. 3.9 模拟多路复用更改
      1. 3.9.1 F2837x_176PTP 与 F28P65x_176PTP 模拟连接比较
  7. 4从 F2837x 到 F28P65x 的应用程序代码迁移
    1. 4.1 C2000Ware 头文件
    2. 4.2 链接器命令文件
    3. 4.3 C2000Ware 示例
  8. 5EABI 支持
    1. 5.1 NoINIT 结构修复（链接器命令）
    2. 5.2 预编译的库
  9.   参考文献

5 EABI 支持

过去，F2837x 应用程序始终支持通用目标文件格式 (COFF) 二进制可执行文件输出。COFF 具有多项限制，其中一项便是符号调试信息不支持 C/C++。除此之外，对段的最大数量、段名的长度和源文件也存在限制。COFF 也不是业界通用的。由于这些原因，C2000 现在正在迁移到嵌入式应用程序二进制接口 (EABI) 格式。EABI 与 COFF 不兼容，因此，两种格式之间无法相互转换。这部分对 COFF 和 EABI 之间的差异进行了总结，并提供了一些有用的链接，这些链接提供了关于将应用程序从 COFF 迁移至 EABI 的指南。

  • EABI 与 COFF 的主要差异：
    • 直接初始化
      • 在 EABI 中，未初始化的数据默认为 0。
      • 在 EABI 中，原始数据初始化是通过链接器生成的压缩副本表完成的。
    • C++ 语言支持
      • C++ 内联函数语义：在 COFF 中，会将内联函数视为静态内联函数，这会导致无法内联的函数或含有静态数据的函数出现问题。在 EABI 中，没有静态”限定符的内联函数具有外部链接。
      • 更好的模板实例化：COFF 使用一种名为晚期模板实例化的方法，而 EABI 使用早期模板实例化方法。晚期模板实例化可能会出现库代码问题，从而导致链接时间较长。早期实例化使用 ELF COMDAT 来保证模板始终得到正确实例化，并且在最终可执行文件中最多存在每个实例化的一个版本。
      • 表驱动的异常处理（TDEH）：相比于 COFF，TDEH 对代码性能的影响几乎为零。COFF 使用 setjmp/longjmp 来实现由 EABI 实现的 C++ 异常特性。
    • 由 EABI 实现的特性
      • Location 属性：指定符号在 C 源代码中的运行时地址。
      • Noinit/persistent 属性：指定是否应在 C 自动初始化期间初始化符号。
      • Weak 属性：弱符号定义被强定义取代。在链接时，不需要解析弱符号引用。未解析的弱符号解析为 0。
      • 外部别名：在 COFF 中，如果对 A 的所有调用都可由 B 替代，编译器会使 A 成为 B 的别名。必须在同一个文件中定义 A 和 B。在 EABI 中，编译器会使 A 成为 B 的别名，即使 B 是外部属性。
    • 调用约定
      • COFF 和 EABI 之间的标量调用约定相同。
      • 结构调用约定 (EABI)
        • 单字段结构由对应于基础标量类型的值传递/返回。
        • 对于 FPU32，小于 128 位的同质浮点结构将由值传递。
        • 在 R0H-R3H 中传递，然后由值在堆栈上传递。
        • 由值传递的结构也是寄存器分配的候选项。
        • 对于 FPU64，相同的原理适用于 64 位双精度值 (R0-R3)。
    • 双精度内存大小
      • 在 EABI 中，双精度是 64 位大小，而在 COFF 中，双精度仍表示为 32 位大小。
      • C/C++ 要求双精度能够表示整数类型，并具有至少 10 个十进制数字，这就需要 64 位双精度值。
  • 段概述：

    表 5-1 对 COFF 和 EABI 的段名进行了总结。以下各段由编译器生成。

    表 5-1 段名
    说明COFFEABI
    只读段
    常量数据.econst.const
    22 位以上的常量数据.farconst.farconst
    代码.text.text
    预主构造函数.pinit.init_array
    异常处理不适用.c28xabi.exidx/.c28xabi.extab
    读写段
    未初始化数据.ebss.bss
    初始化数据不适用.data
    22 位以上的未初始化数据.farbss.farbss
    22 位以上的初始化数据不适用.fardata
    堆.esysmem.sysmem
    栈.stack.stack
    CIO 缓冲器.cio.bss:cio
  • 资源：
    有关 EABI 和迁移过程的更多信息，请参阅以下链接中提供的资源：