armcortex-m3embedded
Generic Linux can't be run on Cortex M3 because Cortex M3 has no MMU. Okay, there're special versions of Linux that can run there.
The problem is I don't quite get how this affects application software.
Suppose I have some application – any user application, let it be ZIP unpacker as an example. I have it in source form and can compile it for ARM.
Will it run on Cortex M3 that has no MMU? How do I know if lack of MMU will affect any given program?
For professional type use, your major options are IAR, Keil or Rowley CrossWorks. Keil is owned by ARM, which may or may not give them a slight advantage. I'd say the performance between IAR and Keil is nearly identical. Rowley is bargain of the 3. Rowley also let's you use cheaper debuggers, such as the J-link. You might be able to use the J-link with IAR as well, but I think Keil forces you to use their Ulink products, which can be a bit more expensive. As far as support, I believe Rowley is purely through their website. IAR and Keil offer 1 year or so of phone support. From what I've been told, Keil seems to offer better support in the US, while IAR is more focused on Europe. I've used Keil without any issues and support was good. That being said, any of these 3 will probably perform just as well.
At the risk of sounding like a broken record...
PSoC5 is your answer! (It's amazing how many times PSoC is the answer)
The PSoC5 MCU has an ARM Cortex M3 core, and a bunch of other brilliant features that practically no other MCU has. Unlike other MCUs, setting up the peripherals is as fun as eating ice cream, and you can even create your own in Verilog! The IDE is pretty good, and totally free.
The Development Kit is great, and full of features and comes with the programmer, which you can use for your future projects. It's not too expensive.
Best Answer
There are several things that an MMU gives you:
Memory Protection: In a multitasking environment this prevents one buggy program from affecting another program. For example, if the buggy program tries to write to a memory location using an uninitialized pointer it might overwrite code or data for the good program. Memory protection prevents this by putting restrictions on what memory each program can access.
Memory Translation: The MMU does a "logical to physical memory address translation". Memory is normally split up into blocks or pages. Sometimes, especially after a multitasking system has been running for a while, the physical memory pages can get all mixed up into discontinuous chunks. The MMU can rearrange these pages to create virtual memory chunks that are contiguous. Think of this like defragmenting a hard drive, but with memory and without the time-comsuming copying/moving of data around.
Virtual Memory: More sophisticated OS's allow for virtual memory, where the apparent amount of RAM in a system is larger than what is physically installed. The extra memory is usually located on the hard drive. When a program tries to access a page of memory that is not physically located in main memory the MMU informs the OS. The OS then loads that page of "memory" into main memory. If main memory is full, another page of main memory is transferred to the hard drive to make room. The MMU and OS do this fairly quickly, and in a way that the program doing the memory accessing does not even know it is happening. This was more important back in the days when memory was small and expensive, but it is still used to day for almost all major OS's.
MMUs are most important for multitasking systems. For single tasking systems and many embedded applications, the value of an MMU is questionable.