I want to measure these four signals in simultaneous mode. Two of them on ADCA and two of them on ADCB.
After finishing the measurement there is a ADC "End of Scan interrupt".
The triggered subsystem contains a simple stateflow model:
Each time a ADC "End of Scan interrupt" occurs, the out_signal toggles, which you can see at the green signal in the picture below.
Obviously the measurement of four signals in simultaneous mode required two PWM cycles.
Is there a possibility to make it faster, so that the measurement of the four signals are complete after each PWM cyle ?So in this example there should occure a ADC "End of Scan interrupt" two times faster.
If I configure three simultaneous measurements it requires three PWM cycles.
So the problem gets bigger with increasing number of measurements...
Hello lethuer2,
As far as I remember, we are talking about a KV4x controller. For this controller, the ADC consists of two separate ADC converters, each with eight analog inputs and its own sample and hold circuit. An ADC cannot convert more than one channel in the same time, because those eight channels are multiplexed. This means that for ADCA, at an ADC cycle moment only one channel from ADCA_CH[0,7] will be physically connected as input on the Scaling and Cyclic Converter A (like in the image attached below). The reason for which two channels can be convertd is that on this controller there are two different converters. So only one channel from ADCA and another one channel from ADCB can be converted in the same time.
Best regards,
Marius
Hello lethuer2,
Please explain which color is A and B(for C I understand that is the End of Conversion). Please try to modify the value on to off (drom "Delay sample until a new sync input occurs" to "Perform sample immediately after the completion of the current sample") like in the following image but only for the sample with Index 1 and Index 9 and not for the Index 0 or 8, to see if this solves your problem.
Hoe this helps,
Marius
Hallo mariuslucianandrei
now I have tried your configuration hint like this:
The option "Delay sample until new sync Input occurs" is only activated for the first Samples of ADCA (Index 0) and ADCB (Index 8)
The fastes configuration I could found was to set the "Scan Halted Interrupt" option on for all Samples.
Now in an empty model the End of Scan Interrupt occurs every PWM cycle with all six cofigured samples.
So for this example in the triggered Subsystem only the ADC values are read.
The trigger for ADC conversation is set to VAL0 (the middle of PWMA), so the complete conversation requires about 18us (see cursor value dx).
The ADC Interrupt occurs each 1/16000Hz = 62,5us (no cursors).
But if I havn't got an empty Subsystem with only the read adc values the End of scan Interrupt doesn't occure every PWM cycle, like in the Picture below.
Here the ADC Interrupt requires something about 90us instead of 1/16000Hz = 62,5us.
So now not the config of the adc isn't the problem any more, but the calculation of the triggered Subsystem.
Do you have any further recommendation to optimize the triggered Subsystem so that the calculation gets faster ?
Best regards
Hi lethuer2,
Since our last discussion on your real model, the Simulink project looked like this:
So the main part of your application was computed during the ADC ISR which was looking like this:
Assuming that the model looks similar now, I can suggest two things:
For reading the GPIO (red squares) you can start using interrupts and store the pins states into global variables. This way, any changing pin state will also change the variable value so you will have the pin current state stored in the variable at any time.
For the blue parts you can take the code out from the interrupt and put it in the main model in an sFunction. The ADC values will be passed to the newly created sFunction through global variables. In order to trigger that sFunction after the new conversion was done, you have to declare a flag variable. When the program starts the flag will be "0". The ADC ISR stores the conversion results into variables and changes the flag value to "1". The step checks if the flag is "1" and if so, it triggers the sFunction. Don't forget to unset the flag when you exit the sFunction! But before building this, take a look to see the Fixed-step size sample time.
Regards,
Marius.
Hallo mariuslucianandrei
the structure of the model is the same, but the content of the triggered Subsystem is different. Now it is more complex.
I could try your suggestion for the reading of GPI but this wouldn't solve the problem because it works without the additional content of the triggered subsystem.
So I think the problem is the complex content of the subsystem.
With another platform by Texas Instruments the model runs like I excpect.
So there should be a possibility to let it run with NXP.
The code Generation objectives I've already set to "Execution Efficiency".
In the IAR Compile Options I've configure the optimization level to "high, favoring speed"
If I choose a PWM frequency of 8 kHz then it works and the Subsystem is triggered every 1/8000Hz = 125 us.
But with 16 kHz it isn't faster.
Now I've also toggle a testpin every time a Trigger VAL0 occures with the "eFlex PWM Interrupt Block".
You can see with f = 8Khz in the middle of the Center aligned PWM (red) the black Signal Switch the state.
This is the Input for the ADC conversation and the End of Scan Interrupt (green) Switches the state before a new PWM cycle Begins.
In the case of 16 kHz the Trigger VAL0 (black) does not occure every time in the middle of PWM cycle (red).
So the ADC conversation is not triggered every PWM cycle, too.
Best regards
Hi, mariuslucianandrei
I still need help, so I've another idea.
For testing if there are any improvements for execution time I've now installed the Embedded Coder for ARM-M Support package.
But the build procedure is aborted due to an error.
### Build procedure for model: 'Motorregelung_mit_KV46F150M_Stand_090118' aborted due to an error.
Error make_rtw: exception id CoderFoundation:tfl:langConstraintNotSatisfied message Code replacement library "ARM Cortex-M (Optimized)" requires a compiler supporting any of "C89/C90 (ANSI)". Consider changing the TargetLang/ TargetLangStandard parameter if applicable, or choosing a code replacement library that complies with the current configuration.
After the Installation in Code Generation-->Interface I already tried the following:
"ARM Cortex-M (Optimized)"
"ARM Cortex-M (CMSIS)"
"GCC ARM Cortex-M3"
Is it correct that GCC ARM Cortex-M3 is only for using the GCC Compiler ?
In the reference Manual I've found this:
The Cortex M4 processor is based on the ARMv7 Architecture and ThumbR-2 ISA and is upward compatible with the Cortex M3, Cortex M1, and Cortex M0 architectures.
Which one I have to choose for IAR Compiler ?
Or is it needed to set anything else in the Compiler Options ?
Best regards
Hello lethuer2,
In order to generate code using Embedded Coder for ARM Cortex-M Support Package, you need to open the "All Parameters" Tab, search the "Standard math library" field and select the C89/C90 (ANSI) like in the following image. This will generate code and compile it just like before.
However, on the model we tested if this works, we've seen no differences between using or not this Cortex-M support package. Probably you will see a notable difference if you use some functions from Standard math library.
Regards,
Marius
Hi Leon,
By default the toolbox is using the ANSI-C code generation for Simulink models. This type of code-gen is generic and might not take full advantage of Cortex M4 arhitecture.
That is why - Mathworks has released the Embedded Coder for ARM Support Package. The philosophy behind such toolbox is that instead of ANSI-C generic code it will generate an improved version of code-gen that take benefit of the ARM architecture (registers and data types). This could potentially generate a more suitable ANSI-C code from Simulink models that could be better used by the GCC cross compiler to generate ELF.
Marius is going to check if additional settings are required to enable the Embedded Coder for ARM-M Support Package but since that is a standard Simulink toolbox it should not interfere with the settings we do to NXP toolbox.
Anyhow - there are a lot of tricks you could do in order to improve the code-gen even for the standard ANSI-C. In this topic we have made a short investigation over the possibilities: https://community.nxp.com/message/903112?commentID=903112#comment-902849
Here is a snapshot with code-gen before and after Simulink model optimizations.
Best regards,
Daniel
