First Cortex-M3 MCUs available

Richard wrote:
>>On Tue, 28 Mar 2006 23:28:43 GMT, "Wilco Dijkstra"
>><Wilco_dot_Dijkstra@ntlworld.com> wrote:
>>
>>
>>>change your favorite tool chain as several (4) already support Cortex-M3.
>>
>>Which ?
>>My RVCS 2.1 does neither list v7 nor cortex.
>>
>>GCC ?
>>
> 
> 
> I have used (ARM) Keil and GCC on the CORTEX M3.  A quick scan of the WEB 
> also shows from the IAR site: "IAR Systems announces support for new ARM 
> Cortex-M3 microcontrollers from Luminary Micro", and from the Rowley.co.uk 
> site "CrossWorks supports Cortex-M3".  I guess this is the 4 (?).
> 
> Out of interest the basic minimal FreeRTOS.org kernel build using IAR for 
> ARM7 is 3040 bytes, while using Keil for M3 is 2284bytes.  Different 
> compilers so not an apples for apples comparison, these figures just come 
> from the MAP file nothing more scientific, but interesting all the same. 
> One point to note is that the ARM7 requires more setup code in the port 
> layer, so maybe this is where the M3 saving comes from.  Full optimisation 
> being used.

Can you add the CortexM3 to the comparisons on http://www.FreeRTOS.org ?
I see the LPC2106 @ 60MHz is already there.

And a url to the map files for the two targets (ARM7 vs Cortex), ideally 
from the same compiler vendor, would make interesting reading.

-jg

Op Wed, 29 Mar 2006 09:59:45 +0200 schreef Richard <nospam@thanks.com>:

>> On Tue, 28 Mar 2006 23:28:43 GMT, "Wilco Dijkstra"
>> <Wilco_dot_Dijkstra@ntlworld.com> wrote:
>>
>>> change your favorite tool chain as several (4) already support  
>>> Cortex-M3.
>>
>> Which ?
>> My RVCS 2.1 does neither list v7 nor cortex.
>>
>> GCC ?
>>
>
> I have used (ARM) Keil and GCC on the CORTEX M3.  A quick scan of the WEB
> also shows from the IAR site: "IAR Systems announces support for new ARM
> Cortex-M3 microcontrollers from Luminary Micro", and from the  
> Rowley.co.uk
> site "CrossWorks supports Cortex-M3".  I guess this is the 4 (?).

CrossWorks is an IDE (and some other stuff) on top of GCC.



-- 
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/

Jim Granville <no.spam@designtools.co.nz> wrote:
> > Luminary parts are MCUs based around the Cortex-M3 core. It is hardly
> > surprising the architecture document doesn't say anything about
> > Cortex-M3.

> ?!

> > The Cortex-M3 TRM describes the core while the Luminary data sheets
> > describe the additional peripherals and physical characteristics.

> I trust everyone followed that ? :)

This is how ARM has worked as a vendor of synthesizeable IP for the last oh
15 years now. A partner produces a ASIC or standard part which contains an
ARM core (which implements a particular version of the ARM architecture) and
also contains other IP in order to make the core useful such as memory
controllers etc.

ARM provides the documentation for the architecture and the core, it is up
to the partner as to if they amalgamate that documentation with the
documentation for the IP that they have added to produce a unified
documentation set.

I will agree that for the micro-controller market it might be better to have
unified documentation however that is up to the partner.

The separate documentation approach has the benefit that it allows customers
to easily segment their code in to architecture, core and part specific
sections with abstract interfaces between them. This allows the customer to
more easily port their code to a different part based on the same core.

>   However, from what you say above : "It is hardly surprising the
> architecture document doesn't say anything about Cortex-M3" - perhaps that
> was a double error ?

>   As typical users will not be used to getting their data from two
> companies, perhaps you, (or better someone from Luminary actually involved
> in the silicon), could clarify just which available WEB documents DO refer
> to the Cortex M3, as shipped by Luminary ?

The ARMv7 Architecture Reference Manual is relevent to the Cortex M3 but
will not refer to the Cortex M3 as it is a specific implementation of
ARMv7M.

Having an architecture document refer to a specific implemenation would be
like having the ISO C++ standard refer to conforming C++ compilers by exact
name and version.

-p
-- 
 "What goes up must come down, ask any system administrator"
--------------------------------------------------------------------

"Boudewijn Dijkstra" <boudewijn@indes.com> wrote in message 
news:op.s658jeoxy6p7a2@ragnarok.lan...
> Op Wed, 29 Mar 2006 09:59:45 +0200 schreef Richard <nospam@thanks.com>:
>
>>> On Tue, 28 Mar 2006 23:28:43 GMT, "Wilco Dijkstra"
>>> <Wilco_dot_Dijkstra@ntlworld.com> wrote:
>>>
>>>> change your favorite tool chain as several (4) already support 
>>>> Cortex-M3.
>>>
>>> Which ?
>>> My RVCS 2.1 does neither list v7 nor cortex.

RVCT2.2 added Thumb-2 support and the latest tools support v7,
including Cortex-A8 and Cortex-M3.

>> I have used (ARM) Keil and GCC on the CORTEX M3.  A quick scan of the WEB
>> also shows from the IAR site: "IAR Systems announces support for new ARM
>> Cortex-M3 microcontrollers from Luminary Micro", and from the 
>> Rowley.co.uk
>> site "CrossWorks supports Cortex-M3".  I guess this is the 4 (?).
>
> CrossWorks is an IDE (and some other stuff) on top of GCC.

OK, so we have 3 Thumb-2 compilers in 5 toolkits already:

GCC
Crossworks (using GCC)
ARM
Keil (using ARM)
IAR

Wilco 

"Jim Granville" <no.spam@designtools.co.nz> wrote in message
news:442a0892@clear.net.nz...
> Wilco Dijkstra wrote:

>  As typical users will not be used to getting their data from two
> companies, perhaps you, (or better someone from Luminary actually involved
> in the silicon), could clarify just which available WEB documents DO refer
> to the Cortex M3, as shipped by Luminary ?

Let me quote you some text from a random LPC2000 User Manaul:

"The ARM7TDMI-S processor is described in detail in the ARM7TDMI-S
data sheet that can be found on official ARM website."

So people are not used to this? You must be the only one...


>>>## Remember: This IS a single sourced core, that needs new tool chains!
>>
>>
>> No it isn't. Anybody can license Cortex-M3 and produce their own MCUs.
>> Several companies have already done so, and it is just a matter of time
>> before they announce their Cortex-M3 based MCUs.
>
> Small detail here:
> I used the present tense, you used the future tense. Case proven.

Eh, future tense in which language? Not in English... I used present tense
and present perfect tense. Case dismissed.

>> Also you don't need to
>> change your favorite tool chain as several (4) already support Cortex-M3.
>
> .. and those would thus be _new_ tool chain compilers/libraries ? - or is
> a new version, somehow not really new ?

A new version is needed, just like you need a new version if you want
bug fixes, new features, or support for a new MCU. That is a lot simpler
and cheaper (upgrades are often for free) than having to switch to a
different unfamiliar toolchain. All the upgrade does is add an extra
option (eg --cpu=Cortex-M3) that selects all the right settings,
optimizations and libraries for that particular core. So it is pretty
trivial to rebuild an existing project for a new CPU.

>>>~~~~~ Quick scan of the data sheet ~~~~~~ :
>>>** Strange method to 'kludge around' BIT manipulation.
>>> Yes, you can set a single port bit, but need a lot of opcode, and
>>>memory space, to do so. - ie it is not a native opcode, but
>>>actually a memory-decode patch.
>>
>>
>> It is a nice trick to add bit operations without adding extra opcodes.
>> You can read or write a bit with a single load or store, just like some
>> CISCs.
>
> any examples of this in use, on more than one tool chain ?

With a set of trivial macros this can be done efficiently by any compiler
(1 load/store for a bit read/write). I wouldn't be surprised if some are
providing a header, but it's easy to write your own. Some compilers
may choose to support bit access natively in C, allowing normal bitfields
to use the bitbanding as well.

>>>** SFR space looks 'fat' - 32 bit's wide, and large offsets,
>>>suggests INIT of SFR values will consume CODE space.
>>> Not such an issue on larger devices, but this has only 8K Flash.
>>
>>
>> Actually because it is 32-bit rather than 8- or 16-bit, it means you
>> need fewer instructions and data for initialisation - think about it.
>
> You have read the datasheet ?
> Seen how much of that 32 bit word is wasted, on average ?

There is no actual wastage, not in hardware, not in software.

> Some real code examples could help show just how much it takes,
> because I cannot see 'fewer instructions' on their info...

That's because it is obvious that 32-bit CPUs need fewer instructions
to write 32-bit fields, even if not all bits are used. For example the
SysTick reload value register is 24 bits, so it takes a single 32-bit store
to set it to a particular value. If you use 8-bit stores it takes 3 times as
many instructions:

*p = 0x112233;  // store a 24-bit constant

// using a 32-bit constant, and 32-bit store: 2 instructions, 8 bytes
LDR r0,=0x112233  // load literal from literal pool
STR r0,[r1]

// using 3 8-bit constants and stores: 6 instructions, 12 bytes
MOVS r0,#0x33
STRB r0,[r1,#0]
MOVS r0,#0x22
STRB r0,[r1,#1]
MOVS r0,#0x11
STRB r0,[r1,#2]


> and those peripherals probably matter more, than 'which 32 bit core'
> to the typical designer.

If that was true only a few 32-bit cores would be available (Z80000 anyone?)
and ARM Ltd (and others) would be losing money big time. However in reality
most development time is spent on writing software. So if a particular core
can help you achieve small & fast code with less effort it is obviously
desirable.

Wilco

On Wed, 29 Mar 2006 19:09:07 GMT, "Wilco Dijkstra"
<Wilco_dot_Dijkstra@ntlworld.com> wrote:

>>>> My RVCS 2.1 does neither list v7 nor cortex.
>
>RVCT2.2 added Thumb-2 support and the latest tools support v7,
>including Cortex-A8 and Cortex-M3.

Ok, should dare to install 2.2 then.
(dare = Upgrade vom 2.0 to 2.1 killed my "suspend to disk".)


>GCC
Which version. An official or patched version ? I use 3.4.4



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

42Bastian Schick wrote:
>>GCC
> 
> Which version. An official or patched version ? I use 3.4.4

    Try this one:

http://www.codesourcery.com/gnu_toolchains/arm


			Laurent

In comp.sys.arm 42Bastian Schick <bastian42@yahoo.com> wrote:
> Ok, should dare to install 2.2 then.
> (dare = Upgrade vom 2.0 to 2.1 killed my "suspend to disk".)

Ah that would probably be due to the MAC_MOT.sys non-plugin and play driver.
This was a binary only component which ARM had no control over. RVDS 3.0 no
longer includes this driver although I don't think we go as far as
uninstalling it if it is present. RVDS 2.2 does include it.

I suggest you contact ARM support with the problem.

-p
-- 
 "What goes up must come down, ask any system administrator"
--------------------------------------------------------------------

Laurent <laurent.desnogues@nowhere-in-arm.com> wrote:
> http://www.codesourcery.com/gnu_toolchains/arm

To clarify Code Sourcery does GCC development targeting ARM and makes
releases. These changes are then folded back into the mainline GCC usually
after bugs have been picked up and fixed due to people using the Code
Sourcery release.

-p
-- 
 "What goes up must come down, ask any system administrator"
--------------------------------------------------------------------

Wilco Dijkstra wrote:

> "Jim Granville" <no.spam@designtools.co.nz> wrote in message
> news:442a0892@clear.net.nz...
> 
>>Wilco Dijkstra wrote:
> 
> 
>> As typical users will not be used to getting their data from two
>>companies, perhaps you, (or better someone from Luminary actually involved
>>in the silicon), could clarify just which available WEB documents DO refer
>>to the Cortex M3, as shipped by Luminary ?
> 
> 
> Let me quote you some text from a random LPC2000 User Manaul:
> 
> "The ARM7TDMI-S processor is described in detail in the ARM7TDMI-S
> data sheet that can be found on official ARM website."
> 
> So people are not used to this? You must be the only one...

Which users ?, these ones, to quote you :
<paste Wilco Dijkstra wrote:>
  "It's clear these Luminary parts aren't trying to compete head on with
the current ARM7 MCUs, they are going for a lower price/functionality
point that appeals more to 8/16-bit users."

  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

... and my original question still remains unanswered.

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


> 
>>>>## Remember: This IS a single sourced core, that needs new tool chains!
>>>
>>>
>>>No it isn't. Anybody can license Cortex-M3 and produce their own MCUs.
>>>Several companies have already done so, and it is just a matter of time
>>>before they announce their Cortex-M3 based MCUs.
>>
>>Small detail here:
>>I used the present tense, you used the future tense. Case proven.
> 
> 
> Eh, future tense in which language? Not in English... I used present tense
> and present perfect tense. Case dismissed.

Let's try again.
Present = available NOW.  - not "just a matter of time.."

Feel free to list the URLs of places to order all these Cortex M3s,
for volume delivery, next week ?

> 
>>>Also you don't need to
>>>change your favorite tool chain as several (4) already support Cortex-M3.
>>
>>.. and those would thus be _new_ tool chain compilers/libraries ? - or is
>>a new version, somehow not really new ?
> 
> 
> A new version is needed, just like you need a new version if you want
> bug fixes, new features, or support for a new MCU. That is a lot simpler
> and cheaper (upgrades are often for free) than having to switch to a
> different unfamiliar toolchain. All the upgrade does is add an extra
> option (eg --cpu=Cortex-M3) that selects all the right settings,
> optimizations and libraries for that particular core. So it is pretty
> trivial to rebuild an existing project for a new CPU.
> 
> 
>>>>~~~~~ Quick scan of the data sheet ~~~~~~ :
>>>>** Strange method to 'kludge around' BIT manipulation.
>>>>Yes, you can set a single port bit, but need a lot of opcode, and
>>>>memory space, to do so. - ie it is not a native opcode, but
>>>>actually a memory-decode patch.
>>>
>>>
>>>It is a nice trick to add bit operations without adding extra opcodes.
>>>You can read or write a bit with a single load or store, just like some
>>>CISCs.
>>
>>any examples of this in use, on more than one tool chain ?
> 
> 
> With a set of trivial macros this can be done efficiently by any compiler
> (1 load/store for a bit read/write). I wouldn't be surprised if some are
> providing a header, but it's easy to write your own. Some compilers
> may choose to support bit access natively in C, allowing normal bitfields
> to use the bitbanding as well.

All sounds rather open ended, and very non-portable to me.....
That's the problem with a kludge, with no follow through :
- everyone handles it differently, and thus it becomes non-portable.

> 
> 
>>>>** SFR space looks 'fat' - 32 bit's wide, and large offsets,
>>>>suggests INIT of SFR values will consume CODE space.
>>>>Not such an issue on larger devices, but this has only 8K Flash.
>>>
>>>
>>>Actually because it is 32-bit rather than 8- or 16-bit, it means you
>>>need fewer instructions and data for initialisation - think about it.
>>
>>You have read the datasheet ?
>>Seen how much of that 32 bit word is wasted, on average ?
> 
> 
> There is no actual wastage, not in hardware, not in software.
> 
> 
>>Some real code examples could help show just how much it takes,
>>because I cannot see 'fewer instructions' on their info...
> 
> 
> That's because it is obvious that 32-bit CPUs need fewer instructions
> to write 32-bit fields, even if not all bits are used. For example the
> SysTick reload value register is 24 bits, so it takes a single 32-bit store
> to set it to a particular value. If you use 8-bit stores it takes 3 times as
> many instructions:
> 
> *p = 0x112233;  // store a 24-bit constant
> 
> // using a 32-bit constant, and 32-bit store: 2 instructions, 8 bytes
> LDR r0,=0x112233  // load literal from literal pool
> STR r0,[r1]
> 
> // using 3 8-bit constants and stores: 6 instructions, 12 bytes
> MOVS r0,#0x33
> STRB r0,[r1,#0]
> MOVS r0,#0x22
> STRB r0,[r1,#1]
> MOVS r0,#0x11
> STRB r0,[r1,#2]

and now let's carry on, _reading_ the data sheet,
with some of the Timer control register active/wasted values  :

GPTMCFG  :  3 active bits
GPTMTAMR :  4 active bits
GPTMTBMR :  4 active bits
GPTMCTL  : 12 active bits
GPTMIMR  :  7 active bits
GPTMTAPR :  8 active bits
GPTMTBPR :  8 active bits

Luminary should provide examples on how best to initialise these with
the least code-space cost.

> 
> 
>>and those peripherals probably matter more, than 'which 32 bit core'
>>to the typical designer.
> 
> 
> If that was true only a few 32-bit cores would be available (Z80000 anyone?)
> and ARM Ltd (and others) would be losing money big time. However in reality
> most development time is spent on writing software. So if a particular core
> can help you achieve small & fast code with less effort it is obviously
> desirable.

  Of course, but so far we seem to have missed on the 'fast code' 
delivery, ( a mere 20MHz... )  and 'small' is always relative .... ?

  In my experience, most designers don't care about a few % of code size,
until the code no longer fits, and then they care a lot, but ...

  Most common reaction is to move to a larger sibling device (Oh dear?) 
- just look at how all the mature players in the Microcontroller market
pitch their families.

  HLLs insulate the user from the core, so I am rather lost how you
think a core-flavour can save development time in any significant way ?

  I can see that a new core/peripherals/compiler/library/debug/errata 
will take time to learn, and thus slow the development cycle, and that 
single sourced cores expose a project to more risk.

  When there are a LOT of 32 bit cores to choose from, users will
base their purchase decision the peripherals.

  Now, I appreciate that someone whose wages are paid by a 
core-developer will naturally like to believe the core is vitally 
important :)

-jg