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-F28379D: Simulink - Fast serial communication to host (PC)

Part Number: LAUNCHXL-F28379D
Other Parts Discussed in Thread: TMS320F28379D

Hello TI Forum,

I have a question concerning the serial communication in Simulink with the LAUNCHXL-F28379D and a host (PC): The data transfer rate is much less, then possible by the FTDI chip!

Basically I just want to

1: Run a current controller of a PMSM on CPU 1 (Code "FOCControllerTuningIPC")

2: Send the measurement data via IPC to CPU 2 (Code "CPU2SerialCommunication")

3: Send the data from CPU 2 to Host PC via Serial communication

4: Receive the data from CPU 2 on Host PC (Code "host_read_F28379")

Instead of receiving 200.000*2 data points per second, I just receive around 40.000*2.

I would be very thankfull, if somebody could look over my code.

SerialCommunicationTI2000.zip

Yours,

David

  • Hi David,

    While we take a look at this, are you able to receive the correct data when you send data from CPU1 to host directly via serial?

  • Thank you for the fast reply, but no it wasnt possible.

    I already tested the current loop AND the serial sending to host on CPU1. The transfer rate was even slower. I thought, this is due to the limited CPU1 capability and the delay, the serial sending causes on the control loop on CPU 1.
    Thats why I wanted to shift the sending to CPU2.

    Right now, I made following test: I created a minimal example for sending data over serial communication and I could reach the desired transfer rate of 2*200000 Hz.

    So, to me it seems, that the TMS320F28379D is too slow, to run just the current loop with 200kHz. This would be even worse, as I still have to run much more complex algorithms.

    Update 1:

    I made following code:

    1: Send data (a constant, run with the sampling frequency) from CPU 1 to CPU 2 via IPC

    2: Send data from CPU 2 to Host via serial (SCI A)

    I can observe, that now the data transfer rate is limited to 100 kHz * 2!

    So, right now it seems, that IPC could be the bottleneck.

    I would be thankfull for any tips. For the code, see attachment.

    Yours,

    DavidTestSerialCommunication.zip

  • As I haven't got a clue regarding Simulink issues, I can say that designed properly (separate process for control code and communication code, where communication code can be preempted by control code, use of FIFO buffers) MCU has no problems running communication via SCI interface at 1 Mbps continuously on one core. 1.5 Mbps is doable but you'll have to run the MCU at less then 200 MHz (I don't remeber the exact speed) in order to be able to generate precise baudrate. More than 1.5 Mbps is probably not doable due to FTDI limitations.

    If you want to achieve high through output and you want to send more data wider than one byte, COBS is the best framing scheme.

    With 1 Mbps you can send only 5 bits in one control period (at 200 kHz). With start and stop bit this leaves 3 bit payload.

    So I am not sure if Simulink or MCU are actually the source of your issues. But the precise definition of "transfer rate of 2*200000 Hz." would be helpful

  • Sorry for the unprecise definition. I want a transfer rate of 0.9 MBd (2*18 Bit(2 unsigned integer with start and stob bit)*200000 Hz / 8).
    I will restructure the code and keep you up to date.
  • Hi David,

    I quickly got the 'f28377S_DCDC_Buck' demo model setup for F28379D and used the host read model 'c2000_host_read_F28379D' model to receive.

    Running out of CPU1 this model runs the control loop at 200KHz and send 2 uint16's at every 5usec. Which is like 2*200000 uint16's values every second.

    Serial communication usually sends 10 bits per data byte (1 start bit and 1 stop bit + 8 bits of data). At 200kHz, 2 uint16 data points mean 2x2x10x200000 = 8Mbps needed. We need make sure the target serial baudrate is set above this value.

    I have attached the models(both target and host) that worked for me, please can you try this at your end and see if you are successful?ti_forum.zip

  • Here is the image of scope that shows 2 uint16 captured every 5usec.

  • Thank you for the example code, but no with your code i can transfer 2 unsigned integer with a rate of just 100 kHz instead of 200 kHz.
    How I measure the transfer rate (roughly):
    1: Instead of the scope, I use the simout on the host PC to be sure to be capable of keeping up with the MCU
    2: I start and stop the host and measure the time
    3: I check Matlab for amount of data saved in workspace and I get 2*1000000 in 10 seconds (makes half of the desired transfer rate)
  • Hello Venkatesh,

    if I measure the transfer rate with the scope, I get the same transfer rate as you. But scope time is different from real world time, thats why I measure the transfer rate with the procedure described above and I get half of the transfer rate.

  • Hi,

    Even with simout block I get the same result.

    In the attached image I have tout captured which is like I ran the simulation for 2.22 sec equal to 444001 number of 5usec.

    And for 5usec I have 2 samples of data. Please refer the attached image.

  • Thank you for the reply, but tout is simulation time.

    So, I get the same results as you, but as already mentioned before, simulation time is not equal to real world time.

    Thats why I check the data transfered over a specific time, measured with a stopwatch.

  • I am sorry, in this case simulink is able to get the data from target realtime as we have large buffer to collect the data on host side. Simulink reads the buffer only at 60ms rate hence the host machine pools data in buffer(12000 data points) and simulink reads this data 60ms rate. So there is no room for data drop there.
  • Actually I can transfer two unsigned integer with a rate of 200 kHz, but not with the DCDC Buck Converter Example from Mathworks.
    As my host PC is fast enough to acquire data that fast, I think that the TMS320F28379D is too slow to run the DCDC control with 200 kHz and transfer the data with the same rate.

    The example code for the DCDC buck converter runs just on one CPU. So there is still room for optimization by using more processing units of the TMS320F28379D.

    In my current project, I run the current loop of a BLDC machine on the FPU (CLA) and the communication with the host is performed in parallel by the CPU.
    This way, I can achieve the desired transfer rate.

    Thank you for the help!

    Best regards,

    David