We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hello,
Can anyone clearify what the difference are in Keil MDK and Arm realview dev.suite?
Kasper
**** This is not an authoritative answer ****
It is *much* easier to get a standard MCU up and running using MDK!
RVDS is a bare-bones tool chain. In a way comparable to GCC being a bare-bones tool chain. Both are focussed on target architecture, not on actual devices. In RVDS you have to write your own device/board support package. RVDS cleary targets vendor specific SoCs, not so much off-the-shelf MCUs. It is, of course, possible to use RVDS for MCU development.
Both, MDK and RVDS sue the same underlying compiler technology. Generated code is very similar[1] for the same CPU if the same compiler version is used.
RVDS supports high end ARM architectures, such as v6 and v7-A/R. This is turned off for MDK at this point. I am sure that when deemed strategically useful, that it will be merely a compiler switch to enable this when rebuilding MDK's version of armcc.
The RealView Debugger supports multi-core debugging. I provides a well documented system for adding new device/board descriptions. None of these features are required by most MCU customers.
RVDS uses an IDE based on Eclipse. A nice gimmick is the scatter file editor with syntax highlighting and a graphical view!
MDK simulates the actual device, RVD only the core itself[2].
RVDS Pro includes an incredible profiling tool.
RVDS is available for Linux. The Windows version of RVDS comes with a "make" utility.
Building Linux applications with RVDS is a supported flow.
Did I mention this: It is *much* easier to get a standard MCU up and running using MDK!
Regards Marcus http://www.doulos.com/arm/
Footnotes: [1] The only reason I don't say "identical" is that I don't have hard evidence to back this up.
[2] Well, not quite: The simulators in RVDS do include some commodity peripherals (UART, timer) but are not modelling a standard MCU.