I am playing around a bit bit with Microsofts ELL library/compiler to deploy a simple learning algorithm to a micro controller. But my knowledge regarding embedded development has been better in the past. The Problem is the following:
ELL creates an LLVM IR file and a C Header file from a CNTK machine learning model (There are no pure c/c++ files). So far so good. Now I can use the IR to tell llc to make an assembler or object file for the desired target from it (ARM Cortex M4 in my case).
So I end up with a header file model.h and an assembler file model.s or an object file model.o.
Now I want to include this model with the header and the precompiled model in my embedded project.
For developing, I use the Bosch XDK, the IDE is basically Eclipse.
So, is there a way, that I can include the precompiled model in my code? When yes, how? And how do I correctly include it in Eclipse? Or do I have to do further steps? I also thought about making a static library out of the object file, but I do not have any experience on this and my tries did not end successfully so far. Thanks for your kind help.
If you make a static library from the object file, the linker will simply extract the object file and link it. That is an unnecessary step, you can add the object file to the linker command line directly. Alternatively add the .s source file to your project - the default build rules should identify it as an assembly language file and invoke the assembler rather then the compiler.
Related
I have created a small Modelica library of my own. The way I have created it is in a single file. But I would like to make it a proper Modelica Library, as in the one with multiple directories for each subpackages.
So this is what i followed. File > New Modelica Class > Specialization - Package > Unchecked Save contents in one file. I copied the entire package code from the single file library, pasted it here and saved it. while doing so, I've noticed that the library lost most of its extends clauses, few models went missing.
Have I followed the correct procedure to create the library or did I do something wrong?
Can anyone point me towards the right direction?
#MSK, I cannot help you with OpenModelica as I work with Dymola. I did however recently split a single-file library (called package in Modelica) into several files manually. I did this so that the library hierarchy is represented in the file system hierarchy (i.e. several subfolders and .mo files in a library folder). For 35,000 lines of code this took roughly 10 hours. Just follow these steps:
create folder with same name as library
in this folder, create a text file "package.mo"
"package.mo" has to start with the statement
within ;
package [name of your package, i.e. the folder name...without the brackets];
now you want to create a subclass within this package. To do this create another folder containing a text file called "package.mo"
start this "package.mo" with
within [name of your package];
and declare the model as usual.
continue all the way down your library hierarchy
at the lowest hierarchy level you no longer need to create folders. You can simply create a .mo with the name of the lowest level class. As usual, start this file with
within [name of your package].[subclass1].[subclass2];
For an example of implementation please refer to the Physiolibrary found at https://www.modelica.org/libraries or the Modelica Standard Library which also uses this structure.
I have been trying to find out how to deploy a Simulink model. There are possibilities and problems as well.
If I use Simulink Coder how can I find the generated code on my computer? Where is it saved as a file or package of files?
Can we deploy Simulink as .NET Assembly? If we can, where can I find a detailed documentation about it.
Is there any other way to use my Simulink model standalone?
Thank you for any effort.
By default all the code gets placed into a folder, in the current directory, called ModelName_CodeTarget, where ModelName is the name of your model and CodeTarget is the particular type of code you are generating. (This folder is created during the build process if it doesn't already exist.)
There is no mechanism for automatically generating a .Net assembly. Simulink Coder generates C code; what you do with it is then up to you (just as it would be with hand written code). Note that the process is fully customizable, so you could create your own build process to autmatically wrap the C code into an assembly (but it would be a very advanced maneuvre to do this).
There are a couple of Simulink Coder "targets" that generate standalone executable files. For instance, the GRT (Generic Real-Time) target generates a simple .exe file; the RSIM target (the Rapid Simulation Target) generates an exe where you can specify different .mat files that can be used to specify different model parameters for different simulation runs, and have the results of the different runs stored to different output .mat files.
Most of these questions are answered by looking at the early chapters of the Simulink Coder documentation.
It would be worth you taking some time to look at it to get a feel for how the code generation process works.
I have a simple model from simulink and I would like to generate code using the code generator in the simulink and then compile it using gcc into a .ELF object file. How can I proceed?
Thanks
You need the product called Simulink Coder (around matlab 2011b) or Real-time Workshop (for older matlab versions). Typing ver at the matlab command window will show what products and licences you have installed.
If Simulink Coder or RTW are installed, you use the menu Simulation->Configuration Parameters to set up the model for code generation.
If you have Embedded Coder you can set System Target File to ert.tlc, and this will produce a very concise main() routine to call your model code. Otherwise, use grt.tlc which produces a lot more bloat then ert, but is the only useful one available for on Windows.
There are a lot of options to go through and check - it really needs someone with a bit of experience to be present!
As you are requesting an ELF file, is this for an embedded system? If so, there is a lot more work to be done. If the target is not one of the already supported targets, then you need a target package, which will take either a lot of time and experience, or money to buy one.
Custom target development - a world of it's own:
http://www.mathworks.co.uk/help/toolbox/rtw/ug/bse3b2z.html
This is probably a totally noob question but I have missing links in my mind when thinking about linking libraries in iOS. I usually just add a new library that's been cross compiled and set the build and linker paths without really know what I'm doing. I'm hoping someone can help me fill in some gaps.
Let's take the OpenCV library for instance. I have this totally working btw because of a really well written tutorial( http://niw.at/articles/2009/03/14/using-opencv-on-iphone/en ), but I'm just wanting to know what is exactly going on.
What I'm thinking is happening is that when I build OpenCV for iOS is that your creating object code that gets placed in the .a files. This object code is just the implementation files( .m ) compiled. One reason you would want to do this is to make it hard to see the source code and so that you don't have to compile that source code every time.
The .h files won't be put in the library ( .a ). You include the .h in your source files and these header files communicate with the object code library ( .a ) in some way.
You also have to include the header files for your library in the Build Path and the Library itself in the Linker Path.
So, is the way I view linking libraries correct? If , not can someone correct me on this ?
Basically, you are correct.
Compiling the source code of a library produces one object file for each of the source files (in more than one, if compiled multiply times against different architectures). Then all the object files are archived (or packaged) into one .a file (or .lib on Windows). The code is not yet linked at this stage.
The .h files provide an interface for the functionality exposed by the library. They contain constants, function prototypes, possibly global declarations (e.g. extern int bad_global;), etc. -- basically, everything that is required to compile the code which is using the library.
.h files do not 'communicate' with object code in any way. They simply provide clues for the compiler. Consider this header file:
// library.h
extern int bad_global;
int public_func(int, const void*);
By including this file in your own code, you're simply telling the compiler to copy and paste these declarations into your source file. You could have written declarations for OpenCV library and not use the headers provided with it. In other words, you're asking the compiler to not issue errors about undefined symbols, saying "I have those symbols elsewhere, ok? Here are their declarations, now leave me alone!".
The header files need to be included in the search path in order for compiler to find them. You could simply include them via the full path, e.g. #include "path/to/file.h", or supply an -I option for your compiler, telling him where to look for additional headers, and use #include <file.h> instead.
When your code is compiled, the declarations in header files serve as an indication that symbols your code is using are defined somewhere. Note the difference between the words declaration and definition. Header files contain only declarations most of the time.
Now, when your code is compiled, it must be linked in order to produce the final executable. This is where the actual object code stored in the library comes into play. The linker will look at each symbol, function call, etc. in your object code and then try to find the corresponding definition for each such symbol. If it doesn't find one in the object code of your program, it will look the standard library and any other library you've provided it with.
Thus, it is important to understand that compilation and linkage are two separate stages. You could write any function prototypes at all and use them in your code, it will compile cleanly. However, when it comes to the linking stage, you have to provide implementation for symbols used in your code, or you won't get your executable.
Hope that makes sense!
The .a is the compiled version of the code.
The header files provided with a library are its public interface. They show what classes, methods, properties are available. They do not "communicate" with the binary code.
The compiler needs the headers to know that a symbol (a method name for example) is defined somewhere else. They are associated with the right "piece of code" in the library binary later during the "link" step.
I am writing a reusable static library for the iPhone, following the directions provided here.
I want to use minizip in my library internally, but don't want to expose it to the user.
It should be possible for the user to include minizip themselves, possibly a different version, and not cause clashes with my "inner" minizip version.
Is this possible?
Edit:
I've tried adding -fvisibility=hidden to additional compiler flags for minizip files and changing functions to be __private_extern__ and __attribute__((visibility("hidden"))), but it still seems to produce defined external symbols:
00000918 T _unzOpen
0000058e T _unzOpen2
00001d06 T _unzOpenCurrentFile
00001d6b T _unzOpenCurrentFile2
...
Edit #2:
Apparently the symbols marked with these annotations are only made private by the linker, which never happens when Xcode builds the sources, since it adds the -c parameter ("Compile or assemble the source files, but do not link.")
You could rename all exported symbol from minizip with objcopy.
something like
objcopy -redefine-sym=minizip.syms yourstaticlibray.a
and minizip.syms
_unzOpen _yourownprefix_unzOpen
_unzOpen2 _yourownprefix_unzOpen2
... ...
No clash if an executable is linked with an other minizip.a and yourstaticlibray.a, and because you renamed all the symbol in yourstaticlibray.a your call inside yourstaticlibray.a to minizip will use the prefixed symbol, and not the unzOpen one.
Since static library is nothing more than a set of .o files (which are not linked yet, as you have mentioned), the only way to completely hide presence of minizip from the outside world is to somehow compile minizip and your library together as a single compilation unit and make minizip functions/variables static.
You could have a look at how does SQLite do the "amalgamation" process which turns library source code into single .c file for further compilation: The SQLite Amalgamation.
As a bonus you'll get better optimization (really recent GCC and Binutils are able to make link-time optimizations, but this functionality is not released yet).