I have program that is reading and writing mat files using the Matlab API.
Therefore my only dependency ist on libmat.dll
Can i ship libmat.dll only (instead of requiring ~600mb MCR) or is that prohibited by a license?
As long as you write MAT files out your code, you can...
Here are the terms from Matlab's license.txt (located in Matlab installation folder) under which you can deploy and share your libmat.dll linked application.
Excerpt from "Deployment Addendum" license section:
OTHER SOURCE CODE AND SHARED OBJECT CODE LIBRARIES.
6.1. Programs may include selected Source Code and shared Object Code
library files that implement various documented application
programming interface capabilities of the Programs for which the
Source Code or shared library file is part.
6.1.1. Licensed User may use and modify the selected Source Code files
solely for creation of Licensee's own Applications. Licensee may
copy and distribute Object Code compiled from this Source Code,
but only as either standalone Object Code file (regardless
whether a Derivative Form) or Object Code Linked to the
Application, and only for use with and deployment of Licensee's
own Application.
6.1.2. Licensee may use, copy and distribute shared Object Code library
files (regardless whether a Derivative Form) for deployment of
Licensee's own Application, but only if a header file exists in
the Program for the shared library file. Licensee may not copy or
distribute header files themselves.
6.1.3. Licensee may not transfer Source Code, development rights, or
development capabilities for any Source Code or Object Code to
any Third Party.
6.2. MAT-files. Licensed User may create and distribute Applications that
read MAT-files using the MAT-file API, however, if such Applications
are distributed to Third Parties, they must also implement MAT-file
write capability.
Be aware that libmat.dll has its own further MATLAB library dependencies - so you'll need to ship also other Matlab DLLs in order to use libmat.dll.
Related
Is there a way to make a user created class/package to be read only in Modelica preferably through annotations? Make Modelica class read-only in Dymola gives a Dymola option, I am using OpenModelica and is required to verify a package across its two different versions, since both these versions are editable I am unknowingly making modifications in the older version. Thanks in advance.
I tried to search OpenModelica documentation to see if any OM specific annotations are available. But I couldn't spot them. I am pretty much sure that I have missed it in them, probably used a bad keyword.
In OMEdit there are two ways to open a library: either use "File->System Libraries" or "File->Open Modelica/Library File(s)".
The system libraries only shows packages installed at $HOME/.openmodelica/libraries (on Linux; other path in Windows). These are installed by the package manager or installed there manually. When loading libraries through "File->System Libraries", they are always read-only.
If you load the same library by pointing out the package.mo file, it is opened writable.
You can mark a class read-only in the filesystem by not making the file writable (and if you use a hierarchical file structure instead of the whole library in one file, you can restrict editing to only certain parts in this way).
When loading an encrypted library, it is possible to prevent certain operations on the package using annotations, but editing is always restricted.
This question already has answers here:
CMSIS & STM32, How to begin? [closed]
(2 answers)
Closed 1 year ago.
As I want to write an efficient program to use minimal RAM & Flash, I want to remove HAL library completely from my project & program only in registers.
I want to use cubeIDE for compiling & Debugging but I do not know how to remove HAL library from my project(It seems that HAL library created and attached to project by default when generating project).
Is there any practical way?
Best!
There is an option in STM32CubeIDE project generation which allows you to create empty projects.
The empty project comes with the following:
main.c : Mostly empty
syscalls.c : I don't know what it is for but probably useless.
sysmem.c : Implements _sbrk() function, which is used by malloc() & new()
startup_stm32[xxxxxxxx].s : Startup file in assembly. You can leave it as it is
[xxxxxx]_FLASH.ld : Linker script file. Most of the time, this can be left unchanged.
But you need some additional libraries & files.
CMSIS Library : This includes some core functions common to all Cortex M devices. The core library is header only, and it's the only one you need to get started. There are some additional CMSIS libraries, like the DSP library which you may need depending on your project requirements. I suggest downloading it from its official repository.
Official STM32 headers from ST : This is actually called STM32Cube[xx] (STM32CubeF4 for example) and includes the Cube & HAL framework you want to get rid off. But we're interested in CMSIS compliant device headers. You can delete the rest. It also includes a version of CMSIS which lags behind the official one. Since you can download the latest CMSIS from its official repository, you don't need the one included in Cube package. You can download the relevant package from ST. For example, this one is for F4 series.
Once you have the needed packages, you need to configure STM32CubeIDE such that your project uses the newly obtained libraries. Basically, you need to add some additional include directories and symbol definitions. And there is an additional system_stm32[xxxxx].c file, which can be found in STM32Cube package and needs to be included in your project.
Here you can find a somewhat related answer.
Here is an example STM32CubeIDE blinky project I've created for the Blue Pill board (STM32F103C8). It may be somewhat outdated but it's probably still useful.
The method I've described probably isn't very practical. Some people suggest creating a normal Cube & HAL project and than pruning the unused parts.
I know this has been posted before but none of the answers work for me.
I'm using VISSIM v10 and made a DLL File to make an external driver model. This is working well.
But what I want is to implement the algorithms in MATLAB instead and make the DLL File send data to Matlab, then Matlab computes the updates the values and sends them back to DLL. The DLL then sends the value back to VISSIM.
So along with .vcproj, .h and .cpp files provided by VISSIM to create the DLL File (im using Microsoft Visual Studio 19), I've added engine.h file in the same project file to be able to use engine routines but it gives 'unresolved external symbol' error for engOpen and engEvalString. I try the same thing in a new .cpp file and it works but how can I link that to VISSIM..
I've added all the libraries and include directories in the properties and configuration type as .dll.
Tettamanti and Varga (2012) mentions that this is the way to be able to do it. But it isn't working for me for now. Help ?
To call MATLAB algorithms from INSIDE your Vissim External Driver Module Dll, you have the following options:
Use MATLAB Compiler SDK for C/C++ - this SDK can help wrapping the MATLAB algorithms into a separate royalty-free DLL, which you can LINK with your Vissim External Driver Module DLL.
This would provide your the most computationally efficient and minimal overhead interoperability with MATLAB runtime.
A good command of C/C++ is a must because you will have to figure out a lot of things yourself;
You would need a MATLAB add-on license for this feature;
You can distribute your MATLAB DLL royalty free (together with MATLAB runtime libs) to a third-party who does not have an MATLAB license;
Use MATLAB directly as a COM automation server inside your Vissim External Driver Module DLL - you would just have to manage MATLAB as out-of-process COM automation server yourself, and do the house-keeping carefully;
This does not require a MATLAB add-on license;
It requires a local, licensed MATLAB installed on the same computer as Vissim;
You need to figure out a lot of things yourself, too.
Use MATLAB External Engine API in C/C++, which is essentially a convoluted wrapper of MATLAB out-process COM object, but in a modern C++ flavor;
This saves you the hassle managing MATLAB COM object yourself, but it demands you, again, to have a mastery of MODERN C++ (i.e., C++11/C++14/C++17) features.
No additional MATLAB add-on license is required;
It requires a local, licensed MATLAB installed in the same computer as Vissim.
I don't see there existing an easy, and straightforward way of integrating Vissim External Driver Module DLL DIRECTLY with MATLAB. All requires non-trivia C++ and COM knowledge and skills.
If you are good with modern C++, I would suggest you go with Option 1 - it provides the best performance.
I am working with STM32 B-L072Z-LRWAN1 discovery kit. How can I add I-CUBE-LRWAN libraries externally, after i have created a project on CubeMX for B-L072Z-LRWAN1 discovery kit. Because project which i have created have not radio libraries. I am coding with System Workbench.
Before this project, i used Ping-Pong example. It was divergent for create a fresh project. So i am trying to make a new project for Lora.
Thanks for answers.
I'm going to answer it from te point of view of a Keil project because that is the program wherein I've done it but these steps should be interchangeable with the IDE. It mostly involves copying the code and adding the right linker and source paths.
The I-CUBE-LRWAN project has been setup such as that the parts of the project have been separated. The root directory of the project consists of three folders: Middlewares, Projects and Drivers. These folders contain both .h and .c files inside their tree structure.
Drivers
The Drivers folder contains all the files related to the specific board you are using, the HAL (Hardware Abstraction Layer), CMSIS and the BSP (Board Support Package). The HAL and CMSIS provide a generalized interface towards the device and when using these creates code that can be ported to other STM32 platforms by changing out the CMSIS board specific definitions. I would recommend that when you create a project you tick the box to include all library files in your project. This will make compilation take longer and your project bigger but will also prevent you from fussing about with missing libraries. The BSP contains Board Specific interfaces for interfaces present on your platform. This includes LEDs and buttons on the L072Z-LRWAN1 and in case of the STM32l4 nucleo the joystick/LCD.
I would recommend that you copy your board specific BSP (.h and .c) into your project and use them as a standardized interface to board specific features. You should create a new BSP .h/.c pair when you are using a custom board.
Projects
The Projects contains your project specific code and contains the business end of your application. A bit of a bump in the road comes up here as ST has chosen to implement all their LoRaWAN code inside the main.c file. I would recommend that you take out all the LoRaWAN related initialization and transmission code (generally anything related to LoRaMainCallback_t) and put it inside a separate file with a defined interface. This is a bit of work but will pay dividend in the fact that your normal code has been separated from your LoRaWAN handling. I've stored my LoRaWAN code inside the file lorawan.<h|c>. With regard to the rest of the files: move the contents to a separate folders in your project called LoRaWAN/App/inc/ and LoRaWAN/App/src/. This pertains to the files: debug.c, hw_gpio.c, hw_rtc.c, hw_rtc.c, vcom.c, debug.h, hw.h, hw_conf.h, hw_gpio.h, hw_msp.h, hw_rtc.h, hw_spi.h, utilities_conf.h and vcom.h. Add the inc folder to your include path (the -I option) and the source files to your project.
Middlewares
The Middlewares folder needs to be copied from the source project to your target project and every inc folder or folder with .h files needs to be added to your include path and every source file needs to be added to your project. I would recommend that the folder structure is kept inside your IDE as to make your navigation between project and folder structure easier.
Another postive effect of keeping the folder structures similar is that upgrading your code with a newer stack should be easier as the files can be found in a somewhat same place in both projects.
Preprocessor defines
And a most important step. You need to take the DEFINE parameters defined inside the project and copy the into your own project. This can be found inside the Keil project (and the other projects also but in other places) under: options for target x->C/C++->define. It contains something akin to these values: STM32L072xx,USE_B_<board name>,USE_HAL_DRIVER,REGION_EU868,DEBUG,TRACE. As you can see I'm using: a Murata radio with integrated STM32, the EU 868 region and debugging and tracing options.
It should be possible to include "hw.h" and compile your program when you've done everything right.
I understand that plug-ins are components that are tasked with a specific function and loaded for use by an application.
Shared object libraries (.so) in linux and .dlls in windows are libraries that are loaded at run-time by an application.
I want to understand what if .dll / .so are always plug-ins. Are all plug-ins .dll / .sos?
Actually, .dll's and .so's are dynamic libraries. There are also other type libraries named static libraries. In Linux, their extension is .a.
Programmers tend to use libraries for maintaining their code easily. Also, if the library will be shared more than one application, shared library is chosen because of main memory usage.
You can apply this logic for a structure which contains plug-ins. If the code piece will be used only by your application's single process, you can use static library as your plug-in. However, if the code will be shared by multiple processes, you should use shared libraries, even if these process are instances of the same application.
When you use shared libraries as plug-ins, you must not include library as known methods and you must not link your executable directly to the library. Instead you must use libdl. Have a look at here and look for the dynamic loading.