• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 83 subscribers
  • Views 378 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Compiler/LAUNCHXL-F280049C: uin8_t support for serial communication

Sumit Ranjan Chakraborty
Prodigy 80 points
Part Number: LAUNCHXL-F280049C


Tool/software: TI C/C++ Compiler

We are trying to interface DSP and ESP32 via serial communication. The problem is DSP sending 16-bit data. ESP32 has a maximum width of 8-bit for serial communication. So, we are facing trouble to port ESP32 code to DSP.
Currently we are treating uint16_t as uint8_t data. Is there any better way to do it? 

  • 0
    TI__Mastermind 32655 points

    Hi Sumit,

    C28x does not have uint8_t data type. Please use uint16_t instead. Are you using SPI for serial communication? In that case you can configure SPI to send 8 bit instead.

    In case of SCI, the maximum data length is already 8 bits.

    Regards,

    Veena

  • 0 in reply to Veena Kamath
    Prodigy 80 points

    Hi Veena,

    Thanks for the reply and clearing out.

    We were using SCI.

    So,the high byte of data of SCI_writeCharBlockingFIFO(uint32_t base, uint16_t data) api is always eliminated right? 
    We are currently treating the high as 'don't care' and keeping it always blank? 

    We were implementing our custom data encoding/decoding protocol. We were converting our data type to uint8_t array in ESP32 and uint16_t type in F280049C. The problem is if we convert an int32_t type data in uint8_t type array, then it takes 4 spaces. But it's done for uint16_t type data and it takes 2 spaces. But we are currently using 4 spaces of uint16_t  type to keep things synchronized. Is this the right approach or there is any better way?

    Thanks