First Cortex-M3 MCUs available

Luminary Micro Announces 32-bit Microcontrollers for $1.00 - First to Launch Products Based on the ARM Cortex-M3 Processor

formatting link

More details and specs:

formatting link

The long awaited ARMv7M architecture reference including full Thumb-2 details:

formatting link

Wilco

Reply to
Wilco Dijkstra
Loading thread data ...

formatting link

While we are on the subject of announcements ;-)

FreeRTOS.org V4.0.0 is now available with support included for the above mentioned Cortex-M3.

Regards, Richard.

formatting link

*Now for ARM CORTEX M3!*
Reply to
Richard

You mean $1.45/500+, for the most limited device ?

formatting link

Yes, why HAS this release taken so long ?

This is the one tagged "first beta release" ? Does that mean the Cortex core is still in a state of flux ?

It is also a little hard to fathom just how much of this ARM document applies to the Luminary Cortex3 - seems the word Cortex only appears ONCE, and then to refer to a separate "Cortex-M3 Technical Reference Manual" ?!

See also my earlier post on this:

All the hoopla, and we finally get a rather 'ordinary' device, with some strange-looking design choices.

## Remember: This IS a single sourced core, that needs new tool chains!

Will have to compete with other single-sourced cores, like Infineon XC166, STm ST10, Maxim MAXQ, Cyan technologies eCOG1X, Freescale's new Coldfire's, Rensas's offerings......[ even the Philips XA51 ! ]

Development kits - most expensive seen this decade...?

Just 20MHz - yawn .... Slowest new device release !Stellar ?

No ADC - First 32 bit uC without an ADC ?

SO28 - Prize for largest PCB / thickest package / smallest IO count ? - much more PCB area than a TQFP48, but more hobby-friendly...

Models - Seems you can have 2 Comparators, OR 2 PWM, but not both ? 4 part numbers, where others would only bother with 1

Data ? - truckloads of TBF in the columns ...

~~~~~ 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. ** UART only mentions 430K Baud, also not stellar... ** consumes 4/5 pins for Debug. Drops to just 15 IOs, the same as a 20 pin 8 bit uC .... Most of the other small uC vendors have developed lower pin-cost debug interfaces. ** 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.

Will surely struggle up against the widely multi-sourced ARM7 cores, like the LPC210x/AT91SAM's/etc which seem to have it outflanked in all system performance areas.

Seems away from the market sweet-spot, and looks like it was dumbed-down desperately to meet the '$1 in volume' hype point ?

Philips and Atmel released their tiny models, later in the roll-out.

-jg

Reply to
Jim Granville

Do NOT trust Luminary...

Imagine a bunch of liars that seem to think "caveat emptor" is standard practice. Think of them as old school liars - even the worst used-car salesman would say, "Wow, these are slimy people".

I wish I knew the right words to explain how dishonest Luminary is.

Reply to
Victor

Please judge for yourself what weight, if any, to place on the above anonymous comment. You can examine the strength of our company's partnerships and decide whether relationships spanning many, many years are based on anything but ethics and integrity.

Sincerely, Jim Reinhart, PE CEO and Co-founder Luminary Micro

Reply to
jim.reinhart

Although the press article doesn't mention it, it is standard to quote prices per 10K.

Still confused by the difference between architecture and implementation? :-)

The Cortex-M3 core is an implementation of the v7-M architecture. The 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.

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. Also you don't need to change your favorite tool chain as several (4) already support Cortex-M3.

Cortex-M3 is much faster than an ARM7 due to Thumb-2: at 20Mhz it is comparable to an ARM7tdmi running Thumb code at 30-35Mhz. So it won't beat the LPC parts but it is much faster than the 8/16-bit MCUs it is targeting. Even a 100Mhz 8051 wouldn't be able to beat an M3 at 20Mhz.

I presume 28 pins is cheaper to manufacture/mount than TQFP48. It's definitely as low end as possible. Indeed anyone could solder SO28, so if you believe the board+ice+tools are too expensive, solder you own!

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.

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. Note that Thumb-2 loads/stores have a 4KB offset so the compiler can use a single base pointer to access 1024 peripheral registers.

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. Without a doubt future devices will arrive with more memory, peripherals and MHz, and these will start to hurt the ARM7's...

Wilco

Reply to
Wilco Dijkstra

Who's Victor and where does he backup his defamatory slander? Just as well he is anonymous because if I were luminary micro I would pursue this legally.

Nah, I don't think anyone would take his unfounded accusations seriously, even minutely. The newsgroups are full of mudslingers whose hands are always full and ready. They don't care about the target, they just want to slime.

Anyway, congratulations Jim and well done on the release of your new product. Have you thought about a design competition? The various entries would really highlight your product and provide a ready base for others to develop and work from. Though I think you would have to have low-cost development kits first :)

*Peter*

snipped-for-privacy@lum> Please judge for yourself what weight, if any, to place on the above

Reply to
Peter Jakacki

?!

I trust everyone followed that ? :)

I have 3 documents ( two of which have since vanished from the Luminary web site ?! )

Datasheet_LM3S101.pdf (c) Luminary ARMv7_Ref.pdf (beta) (c) ARM 2006 CortexM3_TRM.pdf rev r0p0 (c) ARM 2006

Since you pointed to the ARMv7 doc yourself, and it was on the Luminary web site, I _assumed_ it was relevant.

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 ?

Small detail here: I used the present tense, you used the future tense. Case proven.

.. and those would thus be _new_ tool chain compilers/libraries ? - or is a new version, somehow not really new ?

any examples of this in use, on more than one tool chain ?

You have read the datasheet ? Seen how much of that 32 bit word is wasted, on average ?

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

I think we agree :)

Others can choose for themselves their own words, all really saying the same thing.....

"a lower price/functionality point" or "dumbed-down desperately to meet the '$1 in volume' hype point"

If I was bringing out a new 32 bit uC+Core, I'd try and make the device a 'step up', not a step sideways.

After all, many of those 8/16-bit users already find the price/functionality points of the better featured ARM7 variants pretty appealing.

Here are the same column WEB prices, for the closest equivalent parts ( industrial tempco, as Philips don't bother with comercial anymore )

LPC2101FBD48-S $1.85/500+ Indust 8KF 2KR 70MHz LM3S102-IRN20 $2.17/500+ Indust 8KF 2KR 20MHz

So, for 15% LESS money, you get a chip with ADC, TWO UARTs, TWO i2c,

32 io lines, many more capture channels, PLUS it has pin compatible big brothers, should sales ever add new features ....

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

-jg

Reply to
Jim Granville

Which ? My RVCS 2.1 does neither list v7 nor cortex.

GCC ?

--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
 Click to see the full signature
Reply to
42Bastian Schick

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.

Regards, Richard.

formatting link

*Now for ARM CORTEX M3!*
Reply to
Richard

Can you add the CortexM3 to the comparisons on

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

Reply to
Jim Granville

Op Wed, 29 Mar 2006 09:59:45 +0200 schreef Richard :

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

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

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.

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"
--------------------------------------------------------------------
Reply to
Paul Gotch

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

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

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

Wilco

Reply to
Wilco Dijkstra

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

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

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.

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.

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

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]

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

Reply to
Wilco Dijkstra

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

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 :-)
 Click to see the full signature
Reply to
42Bastian Schick

Try this one:

formatting link

Laurent

Reply to
Laurent

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"
--------------------------------------------------------------------
Reply to
Paul Gotch

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"
--------------------------------------------------------------------
Reply to
Paul Gotch

Which users ?, these ones, to quote you :

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

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 ?

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.

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.

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

Reply to
Jim Granville

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.