In Developer Studio, while starting a new project, most of you have already saw that project allow multiple compiler possibilities:
ADS: which is an old compiler that has been always supported by Open AT. ADS was only available from ARM Limited but it is no more commercially available. Open AT still support ADS to remain compatible with legacy platform, but Sierra Wireless has no intention to maintain it in the futur. In addition this compiler doesn’t support the EABI library format.
RVDS: It is the latest compiler available from ARM Limited. Firmwares and Open AT libraries are compiled with it, as it offers the most interresting performances for code size reduction and code execution speed. In addition RVDS support the EABI library format. So, it is recommanded for further project.
GCC ARM Elf: Old compiler generation that was included in the early age of Open AT. Open AT still support GCC ARM Elf, but we have no intention to maintain it. Remaining libraries that are still compiled with this compiler will be also compiled with RVDS or GCC ARM EABI (if not already done), or some of them won’t be maintained and disapear from next SDK.
GCC ARM EABI: Latest compilation mode that was recently added to Open AT. The interrest of this compiler is that it is compatible with RVDS EABI library format. GCC ARM EABI is part of the recommended compiler for further project.
But what is the EABI compilation mode?
Libraries compiled in EABI mode are interoperable. RVDS or GCC libraries that are compiled in EABI mode are compatible and can be used in the same project to build an end application.
Sierra Wireless plan to deliver all their next generation of libraries based on EABI compilation mode to ease interroperability and compatibility.
Then, any project relying on EABI compiler (RVDS or GCC) could support a libraries from any third party without knowing which compiler was used originally, preventing interworking issues.
Which compiler is the best?
From our experience, RVDS remain the most powerfull compiler in code size reduction and code speed execution. Anyway, GCC performances are reasonably good.
RVDS is not free of charge and available from ARM directly or their reseller, while GCC is already included with Developer Studio.
Sierra Wireless intends to deliver RVDS EABI library in order to let you benefits from their maximum of performances. Then, these libraries could be used in any projects relying on GCC EABI or RVDS.
It is a very good idea to change to EABI compilation mode, but not all the libraries are compiled (e.g. C-GPS-OPUS-III) in EABI mode and therefor I’m unable to use the RVDS compiler or GCC ARM EABI.
Can I get a EABI compiled version of C-GPS plugin? or when it will be available for download?
Is it possible to use Keil MDK compiler in DS? It is also owned by ARM company. Our company is working with MDK on other project so it would be great if we could use it in Dev Studio also.
Several things have to be verified…
1* Is this compiler able to produce ARM EABI code (as GCC or RVDS do)? If not, then it’s over, since you won’t be able to link your code against Open AT libraries (built for ARM EABI).
2* Then, the easy way would be that this MDK compiler uses options syntax similar to other ARM ones. If this is the case, you could give a try to customize - for example - ARM RVDS installation paths (in Windows > Preferences > Developer Studio > Tools Path > RVDS), and various compiler options to try to get it compile and link against our libs.
3* And if not (I mean if the options syntax is really completely different), I’m afraid that someone need to do some java and Eclipse code to develop a DS add-on able to integrate this particular toolchain. That’s the moment to remind that DS code is opened, and that it’s possible to develop (and even maybe contribute) add-ons: forum.sierrawireless.com/viewto … 108&t=5727
Note that Keil (an ARM company) do already have an Eclipse-based IDE: arm.com/products/tools/softw … /index.php - so, if necessary, it migh be possible to base something on that…
I will try configure DS as daav recomended in point 2.
awneil, you are referencing ARM Development Studio. There is a chance (even I don’t bet on it) that this version of compiler is more similar to MDK than RVDS so maybe info from this Eclipse plugin would be valuable.
Hello world project compilation and GDB debugging with Keil MDK worked like a charm!
For further ref - steps that worked for me (thank you daav):
Setup Tools Path (Window->Preferences->Developer Studio->Tools paths->RealView Development Suite preferences)
RVCT40BIN: C:\Keil\ARM\BIN40
RVCT40INC: C:\Keil\ARM\RV31\INC
RVCT40LIB: C:\Keil\ARM\RV31\LIB
Add Windows System Environment Variable ARMLIB -> C:\Keil\ARM\RV31\LIB (+restart Dev Studio)
Without this step I had wrong path during linking process. I have ADS1.2 toolchain installed which set ARMLIB variable to ADS linker. I’m not sure why DS used path from System Environment Variable instead configured path (from step 1.)
Project Properties->C/C++ Build->Settings->ToolSettings->RVDS C/C++ Linker->Linker options : unmark Elf format checkbox (I didn’t try with Elf so I’m not sure is this make any difference but I wanted EABI).
Good news!
Sure this will be helpful for other users.
Actually, DS exports environment variables with the exact names mentioned in the preferences pages (e.g. RVCT40LIB, etc…)
Note that if ARMLIB variable is required by your compiler, maybe it is closer to ADS configuration system (cf. ADS preference page in DS, where you can configure ARMLIB & other variables…)
Last option, instead of modifying your OS environment, you can configure DS/CDT to make it export environment variables at build time: cf Window > Preferences > C/C++ > Build > Environment. You can even overwrite these global settings at project level in each project properties.
Another question regarding this subject (using Keil MDK as a toolchain).
Setup: SL6087 module on development board
Dev Studio Build Version 2.1.1.201201180944-R8656
SL Module FW 7.47
I have some problems during GDB session. My test project contains following files:
src\generated.c
src\hello_world.c
src\SubFolderTest\SecondFile.c
src\SubFolderTest\SecondFile.h (marked as “Exclude resource from build”)
Compile/link Debug project and then Debug As Open AT Target application.
After I pause debug session I am able to place breakpoints inside hello_world.c file and debug as expected (step, continue,…). Problem is when I try to place breakpoint inside SecondFile.c. GDB says "No line 9 in file “…\src\SubFolderTest\SecondFile.c”. I can manually place breakpoint on that place but with following command: break “…\src\SubFolderTest/SecondFile.c”:9. Notice “/” before SecondFile.c.
Other observations:
When debugging and step from hello_world.c into function located in SecondFile.c everything works (SecondFile.c is being open and I can continue to stepping inside it but placing breakpoints directly in SecondFile.c still doesn’t work).
Same test with EABI GCC toolchain works.
When move SecondFile.h to inc\SecondFile.h, Refresh project, recompile and retry debugging then I am able to place breakpoints in both .c files (Keil toolchain).
GDB console shows following lines after starting debug session:
warning: Loadable segment “APP_DATA” outside of ELF segments
warning: Loadable segment “APP_BSS” outside of ELF segments
warning: Loadable segment “APP_UNINIT” outside of ELF segments
Can’t send signals to this remote system. SIGEMT not sent.
warning: RMT ERROR : failed to get remote thread list.
Does anyone have a suggestion what can be source of problem based on this “blurry” info that I gave?
