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

3.3.1.3 Migrating C28 and CLA to the Same C29 CPU

  1. 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.
  2. To implement this in this scenario, for software task triggers, a software interrupt would be triggered through PIPE to run the desired ISR.
  3. For hardware task triggers, the C29 CPU's PIPE would be setup to trigger from the desired peripheral.
  4. For task completion interrupts, a software interrupt is triggered through PIPE (user code needs to write to PIPE registers) to run the desired ISR.
  5. 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).
  6. One key challenge in this scenario is interrupt priority assignment, since both C28 ISRs and CLA tasks are now mapped to C29 ISRs and need interrupt priority assignment. Whereas, on the C28+CLA, they run independently on independent cores, here they run on the same C29 CPU. CLA tasks run to completion without being preempted by other tasks, and as mentioned above, this can be achieved by grouping them into the same C29 PIPE interrupt group. However, there is no way to ensure C28 ISRs do not preempt CLA tasks. Likewise, there is no way to ensure CLA tasks do not preempt C28 ISRs. Therefore, in this case, the user must necessarily perform analysis of C28 ISRs + CLA tasks as a whole and determine the interrupt priorities that suit the application.
  7. Similarly, if a C28 ISR was software triggering a CLA task, with them now resident on the same C29 CPU, this presents a problem of relative interrupt priorities of each. If the CLA task is made higher priority, it can preempt the C28 ISR and run and deliver the expected functionality from a CLA side. However, this means the C28 ISR is halted and this may not be expected functionality from the C28 perspective.
  8. Also, if the same exact event (for example, peripheral) triggers a C28 ISR as well as a CLA task, now with them running on the same C29 CPU, the user could merge them into a single ISR.
  9. 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.
Note: Not all corner case scenarios may have been identified here.