• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 82 subscribers
  • Views 875 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.

LAUNCHXL-F28069M: Optimize SCI reception in C2000 series microcontroller

Andrea Polastri
Prodigy 10 points
Part Number: LAUNCHXL-F28069M
Other Parts Discussed in Thread: TMS320F28379D, TMS320F28069M, TMS320F28388D

Hi guys,

I'm new to TI microcontrollers, I found the microcontroller very advanced in feature as ADC and ePWM peripherals, but in SCI communication, I have some questions, since I still didn't find a way to optimize the communication (SCI) in order to unload the CPU.

Actually, on a different microcontroller, the communication is implemented in the following way:

- the reception of the RX bytes is managed entirely by the DMA which transfer the byte from the peripheral register to the memory as soon as a byte is receive, keeping the CPU unloaded.
- Once the UART peripheral detect an IDLE line detection (for example after 1.5 char of idle state on the RX line), an interrupt is generated from the UART peripheral.
Inside this interrupt, the buffer received is processed.
Using this configuration, the CPU is fully unloaded from the communication until the UART interrupt fire (at the same time, the IDLE line detection, and thus the detection of the end of the packet, is executed from the peripheral without software checks).

I would like to replicate this behaviour also on the TI microcontroller.

On the TI C2000 series (for example in TMS320F28069M and TMS320F28379D), from the BUS diagram, it seems the DMA is not connected to the SCI peripheral.
At the moment, the way I'm adopting for the reception is to fire an interrupt for each byte received (without exploiting the FIFO) and save the byte received in the memory.
In this way, exploiting also a cputimer (which its counter is reinitialized for each byte received) configured to fire an interrupt after a defined time (for example after 3.5 char of UART), I can also keep track of the time elapsed from the last byte received and detect an idle line for the end of the packet.
Obviously, this method is not very efficient, since all the work is done in software, interrupting continuously the CPU for each byte received (especially at higher baudrate and with big packet) from other works and at the same time, it is not exploiting the SCI RX FIFO to reduce the number of interrupt (otherwise with the FIFO enabled, I cannot keep track of the time elapsed from the last byte received).

I was wondering how to manage this communication in a more efficient way (obiously if it is possible), maybe exploiting the FIFO in a better way and at the same time, find a way to keep track of the time elapsed from the last byte received.
I also noticed that there is also an evolution of the microcontroller (TMS320F28388D) which embeds an ARM Cortex M4 which is entirely employed for communication purpose and its DMA can transfer the data form the peripherals (SCI included) in a shared memory with the two main CPUs.
The purpose of this new microcontroller (TMS320F28388D) maybe is to delegate the communication task to a different microcontroller to unload the two main CPUs?

Thanks

Andrea

  • 0
    TI__Mastermind 25800 points

    Hi Andrea,

    Thank you for your detailed question!

    Andrea Polastri said:
    I was wondering how to manage this communication in a more efficient way (obiously if it is possible), maybe exploiting the FIFO in a better way and at the same time, find a way to keep track of the time elapsed from the last byte received.

    The most efficient way to do the SCI communication (not taking up CPU bandwidth) is to use FIFOs and if you can the DMA. If you haven't already picked a C2000 device, then yes, something with a DMA would be the better choice so that the data transfer can happen automatically without CPU intervention. 

    If you want to capture the time that has been elapsed, the only way to do this would be through a CPU timer. Devices like F28388D do have two CPUs each with three timers. You could assign this communication to one of the CPUs along with a timer resource and still have the other CPU free for other tasks your application requires. Additionally, you also have the CM core which like you mentioned, can also be used for the UART communication. Overall, this device has the most capability to offload a CPU given your requirements.

    Best Regards,

    Marlyn

  • +1 in reply to Marlyn Rosales Castaneda20
    Prodigy 10 points

    Hi Marlyn,

    Thanks for your reply, since I need the information about the time elapsed to detect the end of the packet for my application (MODBUS RTU), in the F28379D, I will try to use a core only for the communication, using the SCI RX interrupt to save the byte received, and at the same time restart the cputimer every time I enter this interrupt. And as you suggested, use the other core to compute the control action.

    Edit 1:

    In the meantime, I found and tested another possible solution in order to unload the CPU and keep track of the time elapsed from the last byte received.
    In the f28379d there is a CLB, inside the CLB, it is possible to use a counter (with a fclk equivalent to 100MHz and a max counter value of 32bit).
    The CLB/counter can be interfaced with external input (such as GPIO or peripherals) furthermore, the counter inside the CLB can be reinitialized based on these external event or different match value.
    Exploiting the possibility to "route" inside the CLB the SCIARX gpio, I build a logic for the CLB counter such that it counts only when the RX line is high (idle state), and it reset the counter at every rising/falling edge of the RX line.
    In this way, the counter is reinitialize at each rising/falling edge for each bit received (during the communication it continuously reset), at the same time, I set a counter value for the match event equivalent to 3.5 char, once the counter match this value, an interrupt to the CLB is generated.
    In this way, without using the CPU timer to keep track of the timing requirements and exploiting the RX FIFO with a larger value (instead of an interrupt for each byte received), it is possible to receive an idle line interrupt useful to detect the end of the packet or for packet with unknown length.

    Thanks

    Andrea