First Cortex-M3 MCUs available

Jim Granville wrote:
> 
>  One example, of the half dozen deviations/deltas mentioned :
> "Memory Protection Unit (MPU)
> The LM3S101 controller does not include the memory protection unit (MPU) 
> of the ARM Cortex-M3."

    It is not a "deviation" or "delta" it is just that ARMv7-M
does not mandate an MPU, it is optional.  See Section B2.6
of ARMv7-M Architecture Application Level Reference Manual.

>  However, if Luminary can pick what to remove and change
> ( see their section 2.2 ), presumably other Cortex-M3 licencees will
> be doing the same ?

    Cortex M3 makes the MPU optional.  See Section 1.2.8 of
Cortex M3 Technical Reference Manual.


			Laurent

On Sun, 02 Apr 2006 15:38:11 GMT, "Wilco Dijkstra"
<Wilco_dot_Dijkstra@ntlworld.com> wrote:

>Cortex-M3 allows all code (startup, interrupt etc) to be written in C - on

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 <same-name>@monlynx.de instead !

"42Bastian Schick" <bastian42@yahoo.com> wrote in message
news:4431360e.301479124@news.individual.de...
> On Sun, 02 Apr 2006 15:38:11 GMT, "Wilco Dijkstra"
> <Wilco_dot_Dijkstra@ntlworld.com> wrote:
>
> >Cortex-M3 allows all code (startup, interrupt etc) to be written in C -
on
>
> 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 ??


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.

> 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 ?

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

Peter

"Eric" <englere.geo@yahoo.com> wrote in message 
news:1144039132.359850.19860@v46g2000cwv.googlegroups.com...
> >it's &#4294967295;99 for the board, a tethered CrossWorks for ARM license, and the
> >integrated CrossConnect, so you don't need anything else to evaluate the 
> >LM3S102.

> Wow, that's great! I love Embedded Artists, and I've wanted CrossWorks
> for a long time but I couldn't get my company to spring for it. This
> price point for your new dev board is so attractive that I can just buy
> it for myself.

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.  :-)

> By the way, how does the MIPS/milliwat compare with the MSP430? I know
> they'll probably use more current than the MSP, but maybe they're
> similar if you throttle the speed down? I hope these LM3S102 chips use
> a small amount of current so they can be battery powered.

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.

"Peter Dickerson" <first{dot}surname@ukonline.co.uk> wrote in message 
news:%YaYf.51544$zr.45052@newsfe7-gui.ntli.net...
> "42Bastian Schick" <bastian42@yahoo.com> wrote in message
> news:4431360e.301479124@news.individual.de...
>> On Sun, 02 Apr 2006 15:38:11 GMT, "Wilco Dijkstra"
>> <Wilco_dot_Dijkstra@ntlworld.com> wrote:
>>
>> >Cortex-M3 allows all code (startup, interrupt etc) to be written in C -
> on
>>
>> I really doubt this. At least it is not portable even between ARM
>> compilers.

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).

>> How would you setup a new stackpointer in plain ANSI C ??
>
>
> 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.

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.

>> 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 ?
>
> I don't think 'portable' was mentioned. However, M3 interrupts entry and
> exit is compatible with C ABI.

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 

"Jim Granville" <no.spam@designtools.co.nz> wrote in message 
news:44302f02@clear.net.nz...
> Wilco Dijkstra wrote:
>> "Jim Granville" <no.spam@designtools.co.nz> wrote in message
> <snip>
>>
>>> And no, those 8/16 bit users are not used to this. Try asking some,
>>>or look at the typical Microchip/Freescale/Infineon/Atmel data sheets
>>
>> Wrong again. None of the above suppliers combine the instruction set in
>> the datasheets for their devices (at best you get a cycle time summary in 
>> a
>> few pages). In most cases I couldn't find an architectural document 
>> nearby -
>
> but that IS information on the instruction set, and they DO publish
> wider Opcode documents themselves.  [ie not committee camels]
>
> If you want a good example, of a well written data sheet that
> has pretty much all the info, try this 8 bit vendor:
>
> http://www.coreriver.co.kr/product-lines/top_corerivermcu.html

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 ]

>>> Also, can anyone from Luminary explain why the ARM documents that were 
>>> on their web site are now removed ?

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

>> Indeed. So with Cortex-M3 you don't need to learn ARM and Thumb-1,
>> how/when to choose between them, or how to write the necessary
>> assembler code - you can do everything in C and thus get going faster.
>> Apart from that there is always a learning cost when switching between
>> architectures (or even cores from the same architecture - peripherals
>> are always different). It's up to you to decide whether the gain 
>> outweighs
>> the cost of the switch. But with ARM you never have the risk of single
>> source cores like you have with many non-ARM MCUs.
>
> True of ARM7tdmi and ARM9, but in April 2006, sadly not true of Luminary's 
> variants. Might be true in 2007.
> They have a long road ahead of them.

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.

> I also see the first data sheet for AVR32, and Freescale showing signs of 
> waking up. Interesting times.

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 

Wilco Dijkstra wrote:

> "Jim Granville" <no.spam@designtools.co.nz> wrote in message 
>>If you want a good example, of a well written data sheet that
>>has pretty much all the info, try this 8 bit vendor:
>>
>>http://www.coreriver.co.kr/product-lines/top_corerivermcu.html
> 
> 
> 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.

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

> 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.

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.

> However I agree that it would be useful if Luminary added a detailed M3
> and instruction summary to their specs. 

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

>>>>Also, can anyone from Luminary explain why the ARM documents that were 
>>>>on their web site are now removed ?
> 
> 
> Oh, they have reappeared already. Tthe Cortex-M3 TRM and v7
> architecture spec now available on both the Luminary and ARM sites.

:)

..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

>Embedded Artists designed the board, and we're very happy with the quality
>and whole experience working with them.

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

On Mon, 03 Apr 2006 15:14:03 GMT, "Peter Dickerson"
<first{dot}surname@ukonline.co.uk> wrote:

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

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 <same-name>@monlynx.de instead !

"42Bastian Schick" <bastian42@yahoo.com> wrote in message
news:4432042f.354248222@news.individual.de...
> On Mon, 03 Apr 2006 15:14:03 GMT, "Peter Dickerson"
> <first{dot}surname@ukonline.co.uk> wrote:
>
> >
> >I don't think 'portable' was mentioned. However, M3 interrupts entry and
> >exit is compatible with C ABI.
>
> Must have overseen this. But the documents and the discussion in this
> thread aren't really clearing things :(

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

> I have seen better docs from ARM before. But hands-on real hardware
> will clear all this :-(

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