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.

ecan byte order bitfield definitions

byte definitions in the union/struct definitions seem backwards from the ecan sprueu0 discussion of CANMC.DBO.  As we know, the order of a bitfield struct definition is platform dependent, but it is not consistent in dsp280xECan.h.  The whole definition is arbitrary until it comes to the union with HI_WORD, LO_WORD. 

I have an application accessing the same MDL half of the mailbox using a combination of bytes and words.  Altering the header file works as expected, but  I can't find anything about this in the forums, and all the framework headers I have are the same like this.

Here is a snip of the TI header:  You can see the inconsistency, and it seems the correct method is to define bitfields as lsb-first.

Am I missing something???

 

/* eCAN Message Control Field (MSGCTRL) bit definitions */

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

struct

 

 

CANMSGCTRL_BITS {

// bits description

Uint16 DLC:4;

 

// 0:3

Uint16 RTR:1;

 

// 4

Uint16 rsvd1:3;

 

// 7:5 reserved

Uint16 TPL:5;

 

// 12:8

Uint16 rsvd2:3;

 

// 15:13 reserved

Uint16 rsvd3:16;

 

// 31:16 reserved

};

 

/* Allow access to the bit fields or entire register */

 

 

union

 

 

CANMSGCTRL_REG {

Uint32 all;

 

 

struct

CANMSGCTRL_BITS bit;

};

 

/* eCAN Message Data Register low (MDR_L) word definitions */

struct

 

 

CANMDL_WORDS {

// bits description

Uint16 LOW_WORD:16;

 

// 0:15

Uint16 HI_WORD:16;

 

// 31:16

};

 

/* eCAN Message Data Register low (MDR_L) byte definitions */

struct

 

 

CANMDL_BYTES {

// bits description

Uint16 BYTE3:8;

 

// 31:24

Uint16 BYTE2:8;

 

// 23:16

Uint16 BYTE1:8;

 

// 15:8

Uint16 BYTE0:8;

 

// 7:0

};

 

 

/* Allow access to the bit fields or entire register */

 

 

 

union

 

 

CANMDL_REG {

Uint32 all;

 

 

struct

CANMDL_WORDS word;

 

 

struct

CANMDL_BYTES byte;

  • Did you ever get any resolution on this? 

    It does seem strange.

  • Curtis and Jason,

    You are right, there is some inconsistency here in the comments, but the register definitions are indeed correct (assuming DBO = 0).

    With our compiler, bitfield definitions do start from bit 0, so the comments for the CAN_MDx register byte definitions are indeed incorrect.  Instead these should be something like:

    /* eCAN Message Data Register low (MDR_L) byte definitions */
    struct  CANMDL_BYTES {      // bits   description
       Uint16      BYTE3:8;     // 7:0
       Uint16      BYTE2:8;     // 15:8
       Uint16      BYTE1:8;     // 23:16
       Uint16      BYTE0:8;     // 31:24
    };

    Keep in mind though the byte order can be flipped by changing the DBO bit in the CANMC register.

    I'll file a bug to get these comments fixed.

    Regards,

    Trey

  • The header file needs to change when setting DBO=1. The byte order is reversed.

    I am using DBO=1 which is not the default setting. However I'm finding it(DBO=1) is a better fit to little-endian processors (like the C2000) and CANOpen;

    I am able to write to words or Dwords and the data gets transmitted in the correct byte order without having to manually swap bytes every time.

  • Jason,

    You're absolutely correct. When DBO=1 byte order is indeed reversed.

    For your purposes, it shouldn't be hard to modify the header files to align with the byte ordering you are using.

    Trey