TMS320F28379D: SCI UART communication - Distinguishing data Frames

Hi Radha,

Thanks for your question. As you mentioned, the packets should not be lost in transmission, unless there is collision happening between data packets, or there is insufficient differentiation between idle time and bits.

The best way to handle this will indeed be use of the address-bit mode, but depending on how high-speed the baud rate is, a 10 bit idle may still be unavoidable in the transmission stream.

While there are currently no examples directly utilizing this, the description in section 19.9.1 (Sending an Address) of the TRM should provide an excellent starting place for utilizing address-bit mode.

Regards,

Vince

----------------------------------------------------------------------------------------------------------------------------

If I was able to answer your question, please press the green "Verified" button below, thanks!

Hello Vince,

Appreciate your prompt response. 

I am targeting baud rates closer to 4 ~ 6.25 Mbps. With this baud rate, do we still need to have idle bits in the transmission stream in address bit mode. My understanding is if we operate in address bit mode, the idle period is of no significance.

Also, I am only thinking of the address packet as a means to distinguish between the data frames and give a definite structure to the frame. Is there a possibility of collision or corruption of data despite using the address bit mode.

Thanks & Regards,

Radha

Hi Radha,

Thanks for the follow up questions! Please see responses below:

Q1

I am targeting baud rates closer to 4 ~ 6.25 Mbps. With this baud rate, do we still need to have idle bits in the transmission stream in address bit mode. My understanding is if we operate in address bit mode, the idle period is of no significance.

While the idle period is of no significance, in address-bit mode specifically at high speeds, the program itself has issues keeping up with the frames (see below quote from the "Recognizing the Address Byte" section of the TRM):

The address-bit mode (Section 19.9) adds an extra bit (that is, an address bit) into every byte to distinguish addresses from data. This mode is more efficient in handling many small blocks of data because, unlike the idle mode, it does not have to wait between blocks of data. However, at a high transmit speed, the program is not fast enough to avoid a 10-bit idle in the transmission stream.

Q2

Also, I am only thinking of the address packet as a means to distinguish between the data frames and give a definite structure to the frame. Is there a possibility of collision or corruption of data despite using the address bit mode.

There is still possibility of collision/corruption -if- the data received is actually unreadable according to the receiver signal format of a frame. Basically stated, if the C2000 receives byte/frames that do not have proper timing for the bits to be determined as 1/0, then corruption of the frame can occur. The image below from section 19.10 of the TRM shows how our device strobes each bit and determines the 1/0 state, as well as the start bit detection:

So unfortunately, considering the application mentioned here is approaching the upper baud-rate limits of the device, the speed of the program will likely require an idle-time of 10 bits as mentioned in the TRM.

Let me know if you have any additional questions regarding this, or if we can help debug further!

Regards,

Vince

----------------------------------------------------------------------------------------------------------------------------

If I was able to answer your question, please press the green "Verified" button below, thanks!

Hello Vince,

Thank you so much for the reply. I will enable the address bit mode and get back to you in case I have more questions.

I have a follow up question on SCI though. I am working with three SCI peripherals at any instant. Can SCI A-D operate in parallel. For instance, can I transmit/receive through both SCI A and B at any instant without any issues ?

Thanks & Regards,

Radha

Hello Vince,

Thank you Vince.

Regards,

Radha