Cortex M0 vs. M3

Here is how NXP explains it.

I hate to be ungrateful, but if there's a print version of that it would be helpful. Multimedia presentations just go in one ear and out the other for me.

I like that video as it shows the instruction sets for the different processor versions.

The M0 is a mini M3 which is a mini M4.

So a binary for an M0 will run on a M4. But not the other way around.

So the bottom line for you is; No the M3 compiler will not work with the M0 as not all the registers will be available.

hamilton

Thanks. I knew that the M0 instruction set was a subset of the M3's, which was why I was concerned.

Your link didn't help me by itself, but it did lead me down a path that ended with me finding the right options for the compiler I have, which certainly seem to be generating correct code.

My Google-fu just needed jumper cables this morning.

Tim Wescott schreef op 08-Feb-14 6:33 PM: > I just noticed that the tool chain I'm using (arm-none-eabi from > Codesourcery, version 4.6.3), does not seem to know what to do if I > specify the M0 core to the compiler.

Funny, I have been using the CodeSourcery compiler for M0 for over a year with -mcpu=cortex-m0

There was a problem with the aeabi library (long long arithemetic etc.), which used M3 instructions. Maybe that has been solved by now.

Wouter

We used the Keil tool chain. You can setup the compiler to use the M0 instruction set exclusively, assuring portability

Cheers

Klaus

For my own records.

Please post the links you found.

Thanks

hamilton

I had been misinterpreting the correct behavior that I saw reflected in the map file as a problem.

It was my own paranoia coupled with ignorance. The ignorance has been solved, which has allowed me to suppress the paranoia.

Tim Wescott schreef op 09-Feb-14 1:05 AM:

Does 64-bit (long long) arithemetic work OK?

Wouter

Well, it was really a "me" problem, not an "out there" problem.

The page that resolved it for me was this:

But the tid-bit on that page that made things clear was simply that the M0 core is ARMv6-M architecture, while the M3 and M4 cores are ARMv7-M.

However, the CodeSourcery tool chain pulls M3 library objects (which I know to work) from a "thumb2" directory, while it pulls M0 library stuff from armv6. This marked difference in naming, and a subconscious urge to think that armv-anything is highfalutin convinced me that the tool chain had it's little digital head up its little digital butt, where in truth it wasn't the tool chain that was suffering from this malady.

I don't know. I'm still waiting on parts, which is probably why I'm examining map files and freaking out on what I find therein, rather than just programming chips and seeing if they work.

Tim Wescott schreef op 10-Feb-14 8:21 PM:

It does for me now, when I use the correct switches: -mcpu=cortex-m0 -mthumb -march=armv6-m

Wouter

Do you need to use all three? According to the gnu manual (and assuming I'm reading it right, which is always a big assumption), the -arch=armv6- m and the -mcpu=cortex-m0 are synonyms.

I suppose you could build it with an without each of those three and compare hex files.

Comparing hex files may not be the best idea: in Cortex code, you can express the same resulting code with different encodings, and the compiler is free to choose.

I'd compare the generated assembly codes. To generate a listing, add

-Wa,-ahlms=myfile.lst

to the compiler switches.

It is sufficient to use the -mcpu and -mthumb switches. It is a good question to the GNU compiler team if the Cortex architecture should be sufficient to turn the -mthumb switch also on.

If your GCC is new enough to support the Cortex-M0+, they're not automatically synonymous anymore. (The CM0+ has a shorter pipeline than the CM0, so while they should be otherwise compatible it makes sense to have a separate compiler switch for it.)

-a

Sigh, shouldn't post without a full night's sleep.

To give the answer to what you were really asking, if you give the CPU type with -mcpu, you don't have to separately specify the architecture. You do still have to provide the -mthumb parameter even when compiling for CPUs that only support Thumb.

-a