TMS320F28379D: byte-access, byte-packing

Marcel Kummer

Part Number: TMS320F28379D

Hello everyone,

to easily access an external device, the manufacturer of this device told me it is highly recommendet, that the used MCU (here the TMS320F28379D) supports byte-wise access (and supporting uint8_t datatypes) to internal data (byte-packing).

They told me, that some (he mentioned no name) TI-MCUs are only able to perform 16bit-wide data-access and no byte-packing/8bit-wide access.
If so, many bitshift operations would be necessary to get the interface to the external device running.

Is the TMS320F28379D able to access data byte-wise and perform byte-packing?
(I don't know where to search for that info inside the datasheet)

PS:
Since 8bit-Datatypes aren't supported I assume not.

Thanks and regards,

Marcel.

over 7 years ago

0 Marcel Kummer over 7 years ago

Expert 1015 points

Well I did some reading and found what I was looking for.
For the future visitors:

The C2000 MCUs are not able to do byte-packing.
And don't support the datatype uint8_t/int8_t.
Even char ist a 16bit-value.
See this post:
e2e.ti.com/.../262328

0 Whitney Dewey over 7 years ago in reply to Marcel Kummer

TI__Guru 54195 points

Thanks for sharing your answer. We do have a MOVB instruction that can move 8 bits at a time and a couple compiler intrinsics (see __byte() and __mov_byte() in the C28 compiler's user guide) that you can use in your C code to generate it. But yes, you are correct that we don't actually have an 8-bit data type.

Whitney

0 Marcel Kummer over 7 years ago in reply to Whitney Dewey

Expert 1015 points

Those intrinsics don't really help me with my problem.

I will describe the problem in more detail and ask 2 questions:

The Manufacturer of the device is giving us some header-files with typedefs of the Data of the device.
e.g.

typedef struct NETX_COMMUNICATION_CHANNEL_INFOtag
{
  uint8_t   bChannelType;                                        /*!< 0x00 Type of this channel */
  uint8_t   bChannelId;                                          /*!< 0x01 Channel / Port ID */
  uint8_t   bSizePositionOfHandshake;                            /*!< 0x02 Size and position of the handshake cells */
  uint8_t   bNumberOfBlocks;                                     /*!< 0x03 Number of blocks in this channel */
  uint32_t  ulSizeOfChannel;                                     /*!< 0x04 Size of channel in bytes */
  uint16_t  usCommunicationClass;                                /*!< 0x08 Communication Class (Master, Slave...) */
  uint16_t  usProtocolClass;                                     /*!< 0x0A Protocol Class (PROFIBUS, PROFINET....) */
  uint16_t  usProtocolConformanceClass;                          /*!< 0x0C Protocol Conformance Class (DPV1, DPV2...) */
  uint8_t   abReserved[2];                                       /*!< 0x0E:0x0F Reserved area */
} NETX_COMMUNICATION_CHANNEL_INFO;

If we get data via SPI from the device, this data has exactly this structure.
Since there is no uint8_t in our MCU we can't just copy the SPI-Data into the structure, because the SPI-data is byte-packet and the struct ist not.
To get the device connected, we need to do many 8-bit shifts depending on the structure of each incoming paket.
This is very annoying, time-consuming and wasting performance, is there a way arround this?

I had the idea to pack all the uint8_t data into a bitfield like so:

typedef struct NETX_COMMUNICATION_CHANNEL_INFOtag
{
  struct packet_data{
    uint32_t  bChannelType              :8;                           /*!< 0x00 Type of this channel */
    uint32_t  bChannelId                :8;                           /*!< 0x01 Channel / Port ID */
    uint32_t  bSizePositionOfHandshake  :8;                           /*!< 0x02 Size and position of the handshake cells */
    uint32_t  bNumberOfBlocks           :8;                           /*!< 0x03 Number of blocks in this channel */
  }packet_data;
  uint32_t  ulSizeOfChannel;                                     /*!< 0x04 Size of channel in bytes */
  uint16_t  usCommunicationClass;                                /*!< 0x08 Communication Class (Master, Slave...) */
  uint16_t  usProtocolClass;                                     /*!< 0x0A Protocol Class (PROFIBUS, PROFINET....) */
  uint16_t  usProtocolConformanceClass;                          /*!< 0x0C Protocol Conformance Class (DPV1, DPV2...) */
  uint16_t  abReserved;                                          /*!< 0x0E:0x0F Reserved area */
} NETX_COMMUNICATION_CHANNEL_INFO;

BUT:
The order of the bits inside the bitfield depends on the used compiler, what is the behaviour of the C2000-compiler in that situation.

0 Whitney Dewey over 7 years ago in reply to Marcel Kummer

TI__Guru 54195 points

As long as you're okay with the potential lack of portability to another compiler, the bit-field option should work. As you may have noticed, we rely on the C2000 compiler's implementation of bit-fields for all of our device support header files:

struct SPICCR_BITS {                    // bits description
    Uint16 SPICHAR:4;                   // 3:0 Character Length Control
    Uint16 SPILBK:1;                    // 4 SPI Loopback
    Uint16 HS_MODE:1;                   // 5 High Speed mode control
    Uint16 CLKPOLARITY:1;               // 6 Shift Clock Polarity
    Uint16 SPISWRESET:1;                // 7 SPI Software Reset
    Uint16 rsvd1:8;                     // 15:8 Reserved
};

Whitney

0 Marcel Kummer over 7 years ago in reply to Whitney Dewey

Expert 1015 points

Yeah I think it will be okay to have that possible compiler-dependency in our case.
If we will port everything to another platform I think there will be an uint8_t datatype anyway.

Thanks.

C2000™︎ microcontrollers

C2000 microcontrollers forum

TMS320F28379D: byte-access, byte-packing