I have a running a board with FreeRTOS. What do I need to do if I want to link an application written in Ada language?
Does the SDK source code of FreeRTOS need to be recompiled with GNAT?
How to realize static link and dynamic link an Ada application?
Your question reads as though you already have an application written in Ada and you want to run it on a board already running FreeRTOS; in that case, Trashgod’s link directly applies.
Ada code relies on a runtime system (RTS), which is (usually) almost entirely written in Ada. Your application will very likely have been written in full (unrestricted) Ada, using exceptions and, possibly, tasking. The GNAT folk (AdaCore) have produced one bare-board RTS that supports exceptions, but only the Ravenscar (and now Jorvik) tasking subset.
FreeRTOS itself shouldn’t need recompiling. If your other code is written in C++, it should be OK if your compiler is GCC.
FreeRTOS doesn’t support dynamic linking.
Related
I have a running ARM CortexA9 board with FreeRTOS and I need to add a old and large library written in ADA. I have successfully generated the library and implemented it in the code but I'm struggling with some problems;
First off, what RTS profile are permitted with FreeRTOS between the following ?
zfp
Ravenscar_sfp
Ravenscar_full
You’re proposing to use the GNAT CE 2019 arm-elf compiler to compile the Ada source (-mcpu=cortex-a9 is OK) & link the result with your non-ada code.
I don’t think you could use the AdaCore Ravenscar runtimes that come with that compiler, because they assume they are in charge of the board and run their own tasking/interrupt handling code, not FreeRTOS.
I’ve been maintaining a FreeRTOS-based runtime for some lower-end Cortex-M boards, which does support the Ravenscar profile, quite like the AdaCore sfp runtimes. I don’t think it’d be a huge amount of work to adapt it for your use case.
On the other hand, if your Ada code (and the Ada code it depends on) don’t involve tasking or rely on finalization or exceptions, you may well not need much in the way of runtime support; the zfp runtimes would act as a basis.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I'm still a newbie programmer and I am looking at some garbage collected languages that are suited for writing desktop GUI applications. The language must be available on Windows, OSX and Linux. I say "garbage collected" instead of high level since a language like D isn't quite high level (imo) but is garbage collected, compiles to native code and gives near C++ performance. However the most developed GUI toolkit for D is DWT, wich is a port of SWT. The few SWT apps I have used look ugly on every platform. If D had a Qt binding that would be great, but the only thing I could find was QtD which seems to be a dead project.
Languages I am aware of:
Java
Python
D
I'd rather not use C# with Mono and syntax-wise I prefer languages similar to C/C++.
Are there any others, and what would you suggest?
EDIT: The language doesn't have to compile to native code, compiling to bytecode and running in a VM is just fine.
Every programming language that I know, that has a compiler to the native code, uses some C or C++ GUI toolkit for GUI. SWT/DWT uses GTK on Linux/Unix for an example. If SWT applications look ugly to you, then either you did not configure the GTK theme or you did something with the look&feel initialisation. SWT applications look exactly the same as any "native" GUI application.
Even though I am a former C++ programmer, and no matter how I dislike it now, I would still recommend C++ to you because you asked for programming language with compiler that compiles to native binary. Additional requirement you specified is the garbage collector. Use the libgc in your C++ applications, and that is all you need. More about it here: http://developers.sun.com/solaris/articles/libgc.html .
In the field of programming languages with native compilers I am more/less settled with D, but unfortunately, D has no actively-developed GUI ToolKit as we speak. That will be solved soon, but until then, use C++.
What about vala?
Vala is an object-oriented programming language with a self-hosting
compiler that generates C code and uses the GObject system. Vala is
syntactically similar to C# and includes useful language features like
anonymous functions, signals, properties, generics, assisted memory
management, exception handling, type inference, and foreach
statements.2 It is being developed by Jürg Billeter and Raffaele
Sandrini. It aims to bring modern language features to C[clarification
needed][peacock term], with no added runtime needs and with little
overhead, by targeting the GObject object system. Rather than being
compiled directly to assembly or to another intermediate language,
Vala is source-to-source compiled to C which is then compiled with a
platform's standard C compiler, such as gcc.
Go there is as well some bindings for GTK, FLTK and WALK. Check out this thread.
On Java you can still modify the Look and Feel of your UI. Java gets also a port of Qt called Qt Jambi.
And then there are very stable languages like Free Pascal/Lazarus and PureBasic that work well (same source code compiles on all platforms) on Win, OS X and Linux
Real Studio uses reference counting for automated memory management. It's not garbage collection, but better in many ways.
And of course Real Studio runs on Windows, OS X and Linux and can create apps for Windows, OS X, Linux and the web.
You could use Qt Quick. It has a declarative UI language called QML and it's scriptable with javascript.
I need to create a simple application that is multi-platform that will send data over serial connections without much fuss for me or end users. The sole purpose is to be able to read and write tables of data to an Arduino over a USB interface (that presents itself as a serial interface).
I have some experience with python, perl, and php for what it's worth.
Thanks,
Luke
As the Languages you noted are all interpreted you need an Interpreter on the Platforms. If you don't dare installing a pee-family interpreter on a windows machine which is the most difficult platform i think then you can use it.
If you want real multi-platform you should consider using a compiled Language like C, which you compile for the different versions, or use Java and run it on top of the JRE which is available on most platforms.
With Google Native Client, can the source code be protected so that, unlike JavaScript, it is not visible in the client?
If so, how? Thanks!
As the name says, Google Native Client uses native code.
That means, your code is compiled, just like with your average executable binary on the desktop. It can be disassembled, but the source code can't be recovered.
Native client means that you are running native code on the client. In most cases, you'll be running i386 or amd64 machine language on your client. If you're using a compiled language, then your users cannot directly recover it. Users could disassemble your software to recover some information about your code, but they cannot recover the original source code (unless it is assembly language). Rewriting a piece of software from the disassembled binary is difficult, but given enough time, it can usually be done. It really depends on how paranoid you are about the people using your code.
Native Client's structural requirements to enable reliable disassembly so that it can perform static analysis can make some techniques for code obfuscation unusable. These are often the same techniques used by malware to make malware analysis difficult, i.e., have two valid interpretations of the instruction stream if decoded by different offsets. Native Client does, however, permit a form of self-modifying code since it has JIT support. Mono uses just-in-time code generation, for example, and the same interfaces can be used to create obfuscated code, as long as the JIT'ted code continue to conform to the NaCl security requirements.
Using the JIT interface would of course make your code non-portable to other CPU architectures.
I would want to compile existing software into presentation that can later be run on different architectures (and OS).
For that I need a (byte)code that can be easily run/emulated on another arch/OS (LLVM IR? Some RISC assemby?)
Some random ideas:
Compiling into JVM bytecode and running with java. Too restricting? C-compilers available?
MS CIL. C-Compilers available?
LLVM? Can Intermediate representation be run later?
Compiling into RISC arch such as MMIX. What about system calls?
Then there is the system call mapping thing, but e.g. BSD have system call translation layers.
Are there any already working systems that compile C/C++ into something that can later be run with an interpreter on another architecture?
Edit
Could I compile existing unix software into not-so-lowlevel binary, which could be "emulated" more easily than running full x86 emulator? Something more like JVM than XEN HVM.
There are several C to JVM compilers listed on Wikipedia's JVM page. I've never tried any of them, but they sound like an interesting exercise to build.
Because of its close association with the Java language, the JVM performs the strict runtime checks mandated by the Java specification. That requires C to bytecode compilers to provide their own "lax machine abstraction", for instance producing compiled code that uses a Java array to represent main memory (so pointers can be compiled to integers), and linking the C library to a centralized Java class that emulates system calls. Most or all of the compilers listed below use a similar approach.
C compiled to LLVM bit code is not platform independent. Have a look at Google portable native client, they are trying to address that.
Adobe has alchemy which will let you compile C to flash.
There are C to Java or even JavaScript compilers. However, due to differences in memory management, they aren't very usable.
Web Assembly is trying to address that now by creating a standard bytecode format for the web, but unlike the JVM bytecode, Web Assembly is more low level, working at the abstraction level of C/C++, and not Java, so it's more like what's typically called an "assembly language", which is what C/C++ code is normally compiled to.
LLVM is not a good solution for this problem. As beautiful as LLVM IR is, it is by no means machine independent, nor was it intended to be. It is very easy, and indeed necessary in some languages, to generate target dependent LLVM IR: sizeof(void*), for example, will be 4 or 8 or whatever when compiled into IR.
LLVM also does nothing to provide OS independence.
One interesting possibility might be QEMU. You could compile a program for a particular architecture and then use QEMU user space emulation to run it on different architectures. Unfortunately, this might solve the target machine problem, but doesn't solve the OS problem: QEMU Linux user mode emulation only works on Linux systems.
JVM is probably your best bet for both target and OS independence if you want to distribute binaries.
As Ankur mentions, C++/CLI may be a solution. You can use Mono to run it on Linux, as long as it has no native bits. But unless you already have a code base you are trying to port at minimal cost, maybe using it would be counter productive. If it makes sense in your situation, you should go with Java or C#.
Most people who go with C++ do it for performance reasons, but unless you play with very low level stuff, you'll be done coding earlier in a higher level language. This in turn gives you the time to optimize so that by the time you would have been done in C++, you'll have an even faster version in whatever higher level language you choose to use.
The real problem is that C and C++ are not architecture independent languages. You can write things that are reasonably portable in them, but the compiler also hardcodes aspects of the machine via your code. Think about, for example, sizeof(long). Also, as Richard mentions, there's no OS independence. So unless the libraries you use happen to have the same conventions and exist on multiple platforms then it you wouldn't be able to run the application.
Your best bet would be to write your code in a more portable language, or provide binaries for the platforms you care about.