I've seen that it's already implemented in Matlab R2013 in the form of Variant Subsystems, but budget and convenience don't show the upgrade necessary yet:
I am seeking a subsystem in which a concrete implementation can be selected prior to running the simulation, in Matlab R2007a.
A bunch of enabled subsystems along with a switch block connected to a masked variable would do the trick, however the whole family of selectable implementations must coexist inside the "container" subsystem.
Any workaround, other than upgrading to R2013?
Thank you.
I have come up with the following workaround.
1- Include all the possible implementations in a Library
2- Create a Configurable Subsystem block in the Library and edit it to include all the desired implementations
3- Right clicking in a Configurable Subsystem instance will show the "Block Choice" option where the desired implementation can be chosen.
Regardless of differences that may exist with respect to the Variant Subsystem solution when it comes to code generation, RT targets etc..., this solution works for me.
Related
I'm new to Autosar.
I was asked to implement Autosar interface for hand written code, create RTE and ARXML files, and send Arxml file to other group.
I have two runnables in my code.
Let's say for example interface variables (inputs) X and Y, and we have output as Z:
here my code:
global X;
global Y;
global Z;
Runnable_Step()
{
Z = X + Y;
}
Runnable_Init()
{
X =0 ;
Y =0;
Z =0;
}
I guess, my question where and how to start?
we have Autosar DaVinci Developer and Autosar DaVinci configurator.
Your question is quite general in nature and can not be answered in a few lines. However, I try to give a general answer which may help other people to orient themselves in AUTOSAR development with Vector DaVinci.
Generally in DaVinci you have the following work split between tools:
DaVinci Developer is used for modeling Application Component(s), Interfaces, Data Types etc. You also can run the RTE generator for generating "Contract Phase" artifacts.
DaVinci Configurator is used for integrating/configuring the ECU (Electronic Controll Unit). In an Application Developer's scenario it is typically used for generating the RTE that will actually be built into the final image.
In practice, the transition between these two tools often is fluid: You enter some information in Configurator (for example signals in the CAN Stack), then switch over to Developer for mapping the signals to your component instance's ports, then switch back to Configurator in order to configure and generate the production RTE.
You should start with thinking about how the AUTOSAR model for your task will look like. This includes the following aspects:
Which Data Types will be used?
Which Interfaces will be used (SenderReceiverInterface, ClientServerInterface)
Which Software Components do you need? Add the required Port Prototypes, using the Port Interfaces you defined in the previous step
Which resources does you SW Component need from the RTE? You add these to the "Internal Behavior" of the Component. In particular, these are Runnable Entities, but there are also Read/Write dependencies to the ports that need to be considered.
Integrate your new Software Component into a top-level composition.
Creation/Editing of these elements is done in Developer. Based on the work done so far you should be able to generate the "contract phase" RTE header files and C-language implementation stubs. You then can proceed to implement your runnable entities by adding code to the provided stubs.
Next, you will probably need to switch over to Configurator in order to configure the ECU your application should run in. If your work is based on an existing ECU, you will just add to the existing model. If you do not have an ECU project yet, you need to create one and typically populate it with the communication aspects of the model. This can be done either by importing a communciation extract or a CANdb file (Vector's proprietary CAN configuration format).
Switching back to Developer, you may deploy your Software Component onto the ECU, and also map its ports to the signals known by the ECU.
Finally, return to Configurator, optionally configure Basic Software and generate the RTE. It may be a lengthy process to get all BSW modules and parameters right in order to pass the RTE generator's validation process.
Once you managed to generate the RTE, you start the build process, and off you go!
Be sure to consult the AUTOSAR documents at https://www.autosar.org/
Using Dymola, I'm looking for a way to automatically execute a script when loading a library. The intention is to define additional displayUnits using the defineUnitConversion() command, which are specific to the library that is loaded. Still I think there are quite some other cases where this could be helpful.
What I figured out in this regard:
I know that it is possible to add conversions to the file in DymolaInstallDir/insert/displayUnits.mos but this comes with the disadvantage that is has to be done again on every new computer or after an update of Dymola. I would like to avoid this.
Other than that I only found the libraryinfo.mos file, which seems to be read during the start-up of Dymola. Therefore I assume it is not the right place to put the conversions, as it contains general information about the library and should only contain the respective functions.
Dymola 2022 has a new (tool-specific) feature that covers exactly this use-case. It is mentioned in the Dymola 2022 release notes in the section "Library startup script" on page 24.
It basically introduces the a new annotation, which allows to specify a path to a .mos script, which is executed, when the respective library is loaded. Here is the example from the release notes:
package ThisPack
annotation(__Dymola_startup =
"modelica://ThisPack/Resources/Scripts/Dymola/startup.mos");
end ThisPack;
The annotation can also be set via the UI...
I have a question related to V4L-DVB drivers. Following the
Building/Compiling the Latest V4L-DVB Source Code link, there are 3 ways to
compile. I am curious about the last approach (More "Manually
Intensive" Approach). It allows me to choose the components that I
wish to build and install using the "make menuconfig". Some of these components (i.e. "CONFIG_MEDIA_ATTACH") are used in pre-processor directives that define a function in one shape if defined, and a function in another if not defined (i.e.
dvb_attach, dvb_detach) in the resulting modules (i.e. dvb_core.ko)
that will be loaded by most of the DVB drivers. What happens if there are two
drivers (*.ko modules) on the same host machine, one that needs dvb_core.ko with
CONFIG_MEDIA_ATTACH defined and another that needs dvb_core.ko with
CONFIG_MEDIA_ATTACH undefined, is there a clean way to handle this?
What is also not clear to me is: Since the V4L compilation environment seems very customizable (by setting the .config file), if I develop a driver using V4L-DVB structures, there is a big chance that it has conflicts with other drivers since each driver has its own custom settings. Is my understanding correct?
Thanks!
Dave
I want to use scripting to create and define a variant subsystem in simulink.
I am able to create the variant subsystem and add subsystems within it using the add_block but cannot find the appropriate property that defines the variant subsystem by using the get_param command.
The way I graphically configure a variant subsystem is by right clicking the block and going to Block Parameters and then adding the variant control conditions for each subsystem.
I want to do the same thing but from an m-file so that I can create multiple blocks programmatically.
I checked the documentation and google search but couldn't find anything.
Thanks in advance.
Based on a comment by #Praetorian, I opened the model in a text editor and found the parameter line where the variant condition was defined.
I found that the variant conditions are stored in the subsystems within the variant subsystem and not within the top-level variant subsystem.
So you store the condition within each subsystem's "VariantControl" parameter.
Example:
set_param([variantSys '/' sys],'VariantControl','a==1') where sys is a subsystem within the variant subsystem variantSys.
The variant control should be written on the Callbacks of the Model. In order to put the simulink variant controls available to the model, the variables should be created in the workspace. For this to happen you need to put your Sys = Simulink.Variant(Mode== value) etc on the PreLoadFcn.
Check access PreLoadFcn and put the formulas in there then your table will be automatically filled.
If you do not mind can you tell me how you created the variant subsystem?
Good luck
os i figured out how to use the -mthumb and -mno-thumb compiler flag and more or less understand what it's doing.
But what is the -mthumb-interlinking flag doing? when is it needed, and is it set for the whole project if i set 'compile for thumb' in my project settings?
thanks for the info!
Open a terminal and type man gcc
Do you mean -mthumb-interwork ?
-mthumb-interwork
Generate code which supports calling between the ARM and Thumb
instruction sets. Without this option the two instruction sets
cannot be reliably used inside one program. The default is
-mno-thumb-interwork, since slightly larger code is generated when
-mthumb-interwork is specified.
If this is related to a build configuration, you should be able to set it separately for each configuration "such as Release or Debug".
Why do you want to change these settings? I know using thumb instructions save some memory but will it save enough to matter in this case?
my application uses both, thumb and vfp code but i never specifically
set -thumb-interwork flag.. how is that possible?
According to man page, without that flag the two instructions sets
cannot be reliably used inside one program.
It says "reliably"; so without that option, it seems they still can be mixed within a single program but it might be "unreliably". I think normally mixing both instructions sets works, the compiler is smart enough to figure out when it has to switch from one set to another one. However, there might be border cases the compiler just doesn't understand correctly and it might fail to see that it should switch instruction sets here, causing the application to fail (most likely it will crash). This option generates special code, so that no matter what your code does, the switching always happens correctly and reliably; the downside is that this extra code is needed for every global visible function and thus increases the binary side (I have no idea if it also might slow down function calls a little bit, I personally would expect that).
Please also note the following two settings:
-mcallee-super-interworking
Gives all externally visible functions in the file being
compiled an ARM instruction set header
which switches to Thumb mode before executing the rest of
the function. This allows these
functions to be called from non-interworking code.
-mcaller-super-interworking
Allows calls via function pointers (including virtual
functions) to execute correctly regardless
of whether the target code has been compiled for
interworking or not. There is a small overhead
in the cost of executing a function pointer if this option
is enabled.
Though I think you only need those, when building libraries to be used with other projects; but I don't know for sure. The GCC thumb handling is definitely "underdocumented".