First Cortex-M3 MCUs available

I really doubt this. At least it is not portable even between ARM compilers. How would you setup a new stackpointer in plain ANSI C ?? A lot of code I have seen relies on the cstartup, which relies on a CS and memory beeing setup already. Now what if the memory-setup relies on the C startup code ?

And: How would you save to context of one task/thread/process in (portable) C ?

--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
Use @monlynx.de instead !

on

M3 load stack-pointer and PC at reset. So basically it is a linker facility. A bit of pass-the-buck. the C code still has to init RAM data.

I don't think 'portable' was mentioned. However, M3 interrupts entry and exit is compatible with C ABI.

Peter

The idea of the CrossFire boards is that they are cheap to evaluate target silicon and CrossWorks as a package. We've had lots of people purchase CrossConnects just to evaluate how well CrossWorks performs on real hardware. Not only that, we've had lots of requests from the hobby lobby to produce a version of CrossWorks under a hobbyist license and we think that this product is a good idea for hobbyists, educationalists, CrossWorks evaluators and silicon evaluators. We expect to introduce more CrossFire boards for silicon we think is interesting and has merit. The Embedded CrossConnect on the CrossFire LM3S102 board is an LPC2142. :-)

Dunno, that didn't really concern me when I put the board into production. Embedded Artists designed the board, and we're very happy with the quality and whole experience working with them. They are also manufacturing the board and taking care of all the details so this is also great for us, we just concentrate on software. They get a nice plug on the reverse of the board too...

-- Paul.

We're talking 100% standard C here, no extensions required...

However if you'd use intrinsics it would be easy to port between different ARM compilers and even different architectures - that is one of the key benefits of intrinsics (compared to say inline assembler).

Indeed. As long as the init code is careful to avoid using (zero) initialised data before it has intialised it, it can do everything necessary to intialise the chip.

For a full process switch I'd use a few lines of assembler. People have suggested using setjmp or intrinsics, but I think that is a step too far.

However for a really simple "RTOS" you don't need a full task switch. If tasks are primarily interrupt driven then interrupts simply preempt lower priority tasks and all task switching is done by the hardware. You can change priorities of interrupts on the fly as well.

Wilco

These parts only have an instruction set description. That is not the same as an architecture document. So you still need a second document describing the architecture, the register set, how interrupts are handled etc.

My point is that most if not all CPUs require at least 2 documents: one for the chip, and one for the architecture. It's how things work.

However I agree that it would be useful if Luminary added a detailed M3 and instruction summary to their specs. Combining the documents (quite apart from legal issues) would not be useful given they total over 1000 pages...

[ I take it that the difference between architecture and implementation has been cleared up between you and Paul ]

Oh, they have reappeared already. Tthe Cortex-M3 TRM and v7 architecture spec now available on both the Luminary and ARM sites.

It's likely there will be another M3 core this year. 2007, definitely, probably

3, maybe 4. Note that existing MCU manufacturers could get an M3 to market faster than Luminary did as they have a large set of existing peripherals.

You mean the AVR32 at a disappointing 166Mhz? It's funny, they appear right next to ARM1020/1026 on the EEMBC site, and you can see the certified scores are worse than 4+ year old ARM cores... Interesting times indeed :-)

Wilco

Not in the ones I've looked at - they have all of that info.

At ARM, probably yes - however the rest of the microcontroller space are widely used to getting all their data solely from the company that makes the devices. Keeps things simple.

Then we all agree, you, me and Paul. :)

:)

..and I note you now have to register to get this info, and also see in their Errata section, an ARM errata on the Cortex M3.

Will the next Cortex M3 releases also have this errata, or have they got a cleaner design ?

-jg

Agreed. Their lpc2148 Educational board is an incredible value, and they're developing a lot of extender boards for it. They also have some great software (like their RTOS).

This company is going places, and so is yours (Rowley).

After a couple years of boredom things are starting to happen again, and that's exciting!

Eric

Must have overseen this. But the documents and the discussion in this thread aren't really clearing things :( I have seen better docs from ARM before. But hands-on real hardware will clear all this :-(

--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
Use @monlynx.de instead !

The docs are beta :-( and only describe the 'application' view :-( Perhaps holding back the 'system' view documentation is adding to the problems.

Hardware may clarify what the core actually does but not what it is supposed to do. You might discover that a register is cleared by some instruction (say) but that doesn't stop the architecture docs from saying the value is undefined or implementation dependent...

Peter

Thanks for that tip to look at errata. Sometimes I don't pay attention to it, and I really should, of course.

I see 35 ma as typical full speed operating current in the spec sheet (3.3v @ 20Mhz), and 1.7 ma in deep sleep.

This is definitely not a candidate for battery power. The lpc2103 has better numbers than these, and the new lpc2888 is supposed to be able to operate from a single 1.5v battery.

This is still an interesting device and I'll likely get the new dev board from Rowley and check it out. But it lacks the main advantage I was looking for.

Eric

If you are looking for better maths, and low power, the metering market has some focused devices - and they need reasonable maths to get accurate powers.

Companies like TDK have a C51 + CoPro, and Maxim has their MAXQ, they claim is lowest power 16 bit CPU - but the mA/MHz need to be watched on some models.

If you want real speed, in a new 32 bit core see

( the SH2A, like Cortex, claims better code size (25% smaller), but unlike the first Cortex-M3, hits ~160MHz and also claims "(Upward instruction compatibility is maintained with the SH-2 core.)"

-jg

want real speed, in a new 32 bit core see

It's important to note that the core mA/MHz figure is almost irrelevant for low power, low on-cycle applications. Sure, the MSP430 has a low mA/MHz figure but the clock ramp-up and flexibility, smart peripherals, low pin leakage are more important.

To chase low mA/MHz figures is naive for real applications unless the device spends a lot of time at full power. The MSP430 is still very hard to beat for low on-cycle, low power applications.

-Andrew M

A few new instructions (they mention bitfield and division) isn't going to give 25% average codesize improvement. Few instructions improve codesize by more than 1% (bitfield instructions give far less), so you do need to do something drastic to get to 25%.

It's interesting to note that Renesas recently licensed some ARM cores.

A similar MCU was announced by Philips (208Mhz ARM926EJ-S with floating point hardware and Java acceleration):

It looks like everybody is going after the high-end MCU (100+Mhz) segment.

Wilco

True.

What sets the SH2A appart a little from the others (AVR32, LPC3180 Fujitsu, Freescale etc), is the SH2A claims 160MHz/320 MIPS from internal flash(512KF). Most other internal flash specs are 50/60/80MHz region.

Flash has always been a weakspot, and flash has been getting faster slower than the cores.

Analog Devices dumped their FLASH DSPs, and went for RAM cores instead.

-jg