This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320F28388D: Legacy Bit-field approach vs. Driver API's direct register access model. Which approach is more efficient in terms of code processing speed?

Part Number: TMS320F28388D

Hi,

I wonder which one is more advantageous in terms of code processing speed between the legacy bit-field approach and the direct register access model of the Driver API.

In the example below, GPIO port 12 of the F28388D is individually manipulated with the GPASET register. (Legacy bit field approach and driver API's direct register access model were applied respectively.)

[Bit-field approach]
Clock profile result: 4 cycles

Bit-field approach

[Driver API's direct register access model]
Clock profile result: 2 cycles

Direct register access model

According to the Clock Profile results, the direct register access model of the Driver API seems to be more efficient in terms of processing speed when independently manipulating specific bits of registers.

I wonder if this result is correct.
Based on code processing speed, which approach is more efficient?

Thanks and regards,
Sang-il

  • Hi Sang-il,

    Yes, this result is expected for the code snippet you shared.

    In the bitfield based code, you are writing to a particular bit in the register. The compiler will perform a read-modify-write operation.

    This register is in fact a R-0/W-0 register, meaning, it always reads as 0 and writes of 0s are ignored. Driverlib takes advantage of this and does a write to the complete 32 bit register, and not a read-modify-write

    HWREG(addr) = 0x100; and not HWREG(addr) |= 0x100;

    To perform a 32 bit write using bitfield code, you can rewrite your code as follows:

    GpioDataRegs.GPASET.all =  1<<bitNo;

    Regards,

    Veena

  • Hi Veena,

    I understand that legacy bit-field approach (from bit-wise accesses) generates atomic instructions(read-modify-write).

    Conversely, the Driver API's direct register access model applies logical operations based on the address of a register(MMR), so I thought it would be interpreted as a non-atomic instructions by C2000 compiler.

    So, I expected it(legacy bit-field approach) to be more advantageous in terms of code processing speed compared to the Driver API's direct register access model. I wonder if my predictions are correct.

    If the direct register access model of the Driver API also generates atomic instructions from bit-wise accesses, there will be no need to use the old bit-field approach to optimize code throughput speed.

    I understand that the Driver API's direct register access model has macros that manipulate registers bit by bit, such as HWREGBITW( ) or HWREGBITW( ).

    If I use those macros, does the C2000 compiler interpret them as atomic instructions the same as the legacy bit-field approach?

    Thanks and regards,
    Sang-il

  • Hi Sang-il,

    The fundamental difference here is you are comparing a read-modify-write instruction with a write instruction. The former inherently has a latency whether you  use bitfields or HWREG macro.

    If you were comparing the following code snippets, both should take similar cycles

    GpioDataRegs.GPASET.bit.GPIO0 = 1;

    HWREG(addr) |= 1;

    OR

    GpioDataRegs.GPASET.all = 1;

    HWREG(addr) = 1; 

    The bitfields approach uses the Data Page addressing whereas the HWREG approach uses direct addressing. The first one is more efficient when there are back to back accesses to the same data page.

    Regards,

    Veena

  • I understand what you mean.
    Thank you for your kind reply. have a nice day.