Electronic – Understanding ROM/RAM in ARM MCUs

Does anyone even care about what you're developing on?

Yes and no. I've been developing on the AVR32 for a particular project, and the development environment (in particular the compile/program/debug cycle) is horrendous compared to, for instance, PIC32.

The customers don't care, except for cost and maintenance, and in the case of an arduino-like system the programmers wouldn't care because the arduino environment and development cycle is leaps and bounds better than the current AVR32 setup.

I just wonder because there is such a strong contingent for AVRs in the Arduino family. I understand that they are the official processor but there isn't a reason the code couldn't be ported to an ARM or a Freescale architecture other than cost, right? As long as there is onboard memory, I figured there could be easy migration into those parts.

There's no reason another processor couldn't be used, but there's a very good reason they've chosen a low end 8 bit device rather than an ARM, MIPS, PowerPC, etc device: Ease of use.

If you've looked at the setup for the even the low end arms, it's an order of magnitude more complex (memory mapping, caching, etc) than an 8 bit processor. But even more importantly - at the time there were no DIP arm processors, and these were meant to be used and buildable by artists and hackers, not necessarily electronic technicians and engineers who feel comfortable with even a 48 pin TQFP.

The reason the AVR was chosen over the PIC is that the PIC doesn't really have a widely used, open source, free C compiler, among other things (the SDCC port isn't mature).

I see a lot of ARM in industry (seems like every vendor is pushing one into their designs) and was wondering why there wasn't more uptake in the Arduino developer world. Thoughts?

Mainly it's due to ease of use - complexity, easy to solder, cost, and the fact that there's not much need for it. Developers like the idea of having a lot of power, but at the end of the day when all you need to do is move some servos and flash some lights with a low-end FFT, an 8 bit processor is just fine.

Even the low end cortex ARMS coming out in 28 pin packages are still SOIC, not DIP.

So the AVR had all the right features:

• Easy to solder
• Easy to get via mail order all over the world
• Free GCC C compiler
• Easy to understand the processor and peripheral setup and usage
• Cheap
• Ubiquitous - lots of people and experience surrounding the AVR family

Largely this is still true - I don't know of an ARM in a dip format, and the adapters make it significantly more expensive than the AVR. For the most part, manufacturers don't think that a DIP packaged 32 bit processor is going to be very profitable.

1. There are many microcontrollers out there (a microprocessor is slightly different), and propably an ARM is the first choice if you want performance. Hook up RAM and processor is conceptually trivial, but the practice can be complicated if you are not expert.

2. RAM is probably embedded if you buy a microcontroller, so just load the software from the Flash; and wait for using operating systems, first try to play a little bit with the board.

3. If you don't have a specific requirement for multiprocessor systems (and you should have them in the same chip, I don't think is feasible with microcontrollers) then it makes no sense to get crazy with that kind of stuff. And if you have to learn, I would suggest again of starting with something simple, you can't think to build a computer without even have build a microcontroller board, at least once.

And probably you are expert in programming, but even if you have the PCB made, programming with microcontrollers requires the management of the hardware, and that's also a thing to learn before going further.