Time is very slow in external mode

[TGIRA.1]

I have a little problem with external mode and I didn't know if it's nortmal or just a lack of setting from myself. I use F429 with 5.4 version and R2018b

When I run my soft on STM32, the time is passing good (I see it with my CAN_message coming from my MCU with the good frequency).

But as soon as I connect the external mode in Simulink the time become so slow (it take 20 secondes to some minutes to pass 1 second on the soft, dependind the sample time).

When I cut the external mode the time become instantly good again.

I tried with VCP on the STlink on nucleo board and with TTL232 on a custom board. The problem is the same exceep it's about 10 times quicker with ST link than with TTL232 cable.

When I increase the soft sample time it become more slower.

It's not a real problem for me if time is a little slower than I should be in external mode. But here the difference is so big and my controlled system can't work with a speed so slow.

Maybe I need to change the sample time of the uart function because it can't work at the sample time of the soft, but I see no setting for that...

Is someone have the same probem? And maybe have a solution?

Thank you

[Amigo]

By saying that you 'run the soft on STM32' I assume that you mean that you are generating the code to be run entirely on the target, I/O drivers and all. In that case the software will run in real-time, hopefully as you expect it to.

When using external mode, the Simulink environment prepares the data to be passed to whatever part of the model runs on the target, and then, for each sample, sends the data via UART to the target, where the autogenerated UART receiver will pass that data to the software on the target, which will use it when executing the code as inputs, generate the outputs, and then pass the outputs back to the UART driver on the target, which will then send it back to Simulink over UART. In such a scenario the software does not run in real-time, and this mode is not designed to be used with I/O drivers, but rather to profile the execution of the generated code, in terms of execution time, and maybe accuracy.

As you can imagine, in the case of External Mode there is a significant overhead. This is caused by the fact that Simulink does not run in real-time (long story). As you can also probably imagine, the speed of the UART link has a significant impact on the speed of simulation. Are the UART speeds the same in both cases you used, i.e. ST-LINK and UART cable? Which UART channel on the STM32 board where you using in each case?

[TGIRA.1]

Thank you for your response Amigo!

Yes I generate the code and send it to STM32 to run entirely on the target.

To connect with Simulink I use USART2 on my custom card, on the nucléo board it was USART3

The speed of Uart are the same in the two case, and I tried to change it up to 460200bauds but nothing have changed...

What I see is that it is the trigger to have values on simulnik wich slow the software.

If I connect external mode withour arm trigger, the speed is good.

My soft run at 5000hz, and when I connect external mode with arm trigger it totaly change and it take about 1 seconde to run 0.02seconds on the soft. (I see it on the time on simulink). I can't use it at this speed.

So I connect without arm trigger, and sometime I do it manualy just 1 second to update the data.

I would like to have a return of the value I want to log on simulnik, but the return couldn't be at 10hz for exemple. But I really don't know how to do it.

But what is good is I can use external mode to change parameter in real time, just no data acquisition

I hope my english is not too bad!

[Amigo]

I must start by saying that I confused External Mode with PIL, my apologies. What follows is a few updated suggestions.

For External Mode, the amount of data that has to be exchanged between the target and the host has a direct and significant impact on the real-time behaviour of the target. The file "STM32_MAT-TARGET_HandsOn.pdf" from the STM32-MATLAB installation should give some pointers in that direction. I must admit I have not used the External Mode in about 15 years, but I will have a go.

You are saying that your software runs at 5000Hz rate, i.e. a sample time of 200us. That is extremely tight, and External Mode will give you a lot of grief. If we assume a single float variable (4 byte) monitoring, sending it over the UART at 460200baud will take roughly 80us for the data only, let alone any other other control data, two such variables will take double that, etc. I have not checked the implementation, but it might be that the UART comms are done in blocking mode, meaning that while sending or receiving takes place nothing else gets executed on the target. If this is the case, all sorts of dubious things will happen in the software.

As a first step I would try to remove all the sinks in your model and see if that makes a difference, while not changing any parameters. If that works, then it is clearly an issue with the data load.

At this stage, I think that this is all I can offer, I am afraid.

[TGIRA.1]

Thank you Amigo.

I will try it to see if there is a change.

But what I wanted to do if it's possible, is to change the sample rate of the link between simulink and STM32 in external mode.

For exemple with my woftware, a link with simulink in external mode at a frequency of 50hz would be enougth for my devlopment

I don't know if it's possible.

No one has the same issue as me?

[Amigo]

I could not find any option that would allow you to do that, although I agree it would be very useful. Maybe there is a way, but I can't find it. Nonetheless, even if that were possible, it relies on the communication with the host over UART to be in non-blocking mode. If it is in blocking mode, any communication with the host will upset your control strategy, as the time it takes to send the smalles amount of data will block your control algorithm from executing. I will take a look at the generated code over the next few days and come back to you on that.

[TGIRA.1]

Thank you!

I'm not so good in C so i'm not able to see that on the generated code.

Do you want I send you a generated code to have a look?