SPRUIY8 October   2024 F29H850TU , F29H859TU-Q1 , TMS320C28341 , TMS320C28342 , TMS320C28343 , TMS320C28343-Q1 , TMS320C28344 , TMS320C28345 , TMS320C28346 , TMS320C28346-Q1

 

  1.   1
  2.   Abstract
  3.   Trademarks
  4. 1Introduction
  5. 2C28 to C29 CPU Migration
    1. 2.1 Use Cases
    2. 2.2 Key Differences
    3. 2.3 Source Code Migration
      1. 2.3.1 C/C++ Source Code
        1. 2.3.1.1 Pragmas and Attributes
        2. 2.3.1.2 Macros
        3. 2.3.1.3 Intrinsics
        4. 2.3.1.4 Inline assembly
        5. 2.3.1.5 Keywords
        6. 2.3.1.6 Data Type Differences
        7. 2.3.1.7 Tooling support for Migration
      2. 2.3.2 Assembly Language Source Code
    4. 2.4 Toolchain Migration
      1. 2.4.1 Compiler
      2. 2.4.2 Linker
      3. 2.4.3 CCS Project Migration
  6. 3CLA to C29 CPU Migration
    1. 3.1 Use Cases
    2. 3.2 Key Differences
    3. 3.3 Source Code Migration
      1. 3.3.1 C/C++ Source Code
        1. 3.3.1.1 Data Type Differences
        2. 3.3.1.2 Migrating CLAmath.h Functions and Intrinsics
        3. 3.3.1.3 Migrating C28 and CLA to the Same C29 CPU
        4. 3.3.1.4 Migrating C28 and CLA to Different C29 CPUs
      2. 3.3.2 Assembly Language Source Code
    4. 3.4 Toolchain Migration
  7. 4References

Migrating C28 and CLA to Different C29 CPUs

  1. A different CCS project is needed.
  2. In the C28+CLA implementation, CLA tasks could be triggered by hardware or software, and on task completion, an interrupt may be sent to the C28.
  3. To implement this in this scenario, you would need IPC between two C29 CPUs. IPC, however, has a maximum of four interrupts in either direction, whereas, there could be eight CLA tasks. Hence, it would make sense to use one IPC interrupt in either direction, along with a command specifier to indicate the task that needs to be run or the task that completed. This requires additional code that parses the IPC interrupt and triggers the ISR.
  4. So, for software task triggers, you would map them to an IPC interrupt , then the receiving C29 CPU would run the IPC ISR, and trigger a software interrupt through its PIPE (by writing to PIPE registers) to run the desired ISR.
  5. For hardware task triggers, the C29 CPU's PIPE would be setup to trigger from the desired peripheral.
  6. For task completion interrupts, you would map it to an IPC interrupt, then the receiving C29 CPU would run the IPC ISR, and trigger a software interrupt through its PIPE to run the desired ISR.
  7. If a background task was present in the C28+CLA implementation, it can be easily implemented in the C29 CPU as a background loop (idle loop).
  8. CLA registers offer a lot of functionality to users, like being able to know which task is running, and being able to stop a task by writing to a specific bit in a register. When migrating, suitable source code updates may be needed given the absence of these registers and corresponding functionality.