First Cortex-M3 MCUs available
in [Embedded]
|
From: Wilco Dijkstra on 28 Mar 2006 18:28 "Jim Granville" <no.spam(a)designtools.co.nz> wrote in message news:44285e66(a)clear.net.nz... > Wilco Dijkstra wrote: > >> Luminary Micro Announces 32-bit Microcontrollers for $1.00 - First to >> Launch Products Based on the ARM Cortex-M3 Processor > > You mean $1.45/500+, for the most limited device ? Although the press article doesn't mention it, it is standard to quote prices per 10K. >> http://www.luminarymicro.com/images/downloads/ARMv7_Ref.pdf > > 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" ?! 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. > 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! 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. > Development kits - most expensive seen this decade...? > > Just 20MHz - yawn .... Slowest new device release !Stellar ? 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. > 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... 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! > ~~~~~ 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. > ** 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. Note that Thumb-2 loads/stores have a 4KB offset so the compiler can use a single base pointer to access 1024 peripheral registers. > 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 ? 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
From: Peter Jakacki on 28 Mar 2006 20:10 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* jim.reinhart(a)luminarymicro.com wrote: > 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 >
From: Jim Granville on 28 Mar 2006 23:10 Wilco Dijkstra wrote: >>>http://www.luminarymicro.com/images/downloads/ARMv7_Ref.pdf >> >>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" ?! > > > 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. 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 ? >> >>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! > > > 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. > 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 ? <snip> > >>~~~~~ 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 ? >>** 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 ? Some real code examples could help show just how much it takes, because I cannot see 'fewer instructions' on their info... > Note that Thumb-2 loads/stores have a 4KB offset so the compiler > can use a single base pointer to access 1024 peripheral registers. > > >> 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 ? > > > 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. 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
From: 42Bastian Schick on 28 Mar 2006 23:42 On Tue, 28 Mar 2006 23:28:43 GMT, "Wilco Dijkstra" <Wilco_dot_Dijkstra(a)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 ? -- 42Bastian Do not email to bastian42(a)yahoo.com, it's a spam-only account :-) Use <same-name>@monlynx.de instead !
From: Richard on 29 Mar 2006 02:59
> On Tue, 28 Mar 2006 23:28:43 GMT, "Wilco Dijkstra" > <Wilco_dot_Dijkstra(a)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. Regards, Richard. http://www.FreeRTOS.org *Now for ARM CORTEX M3!* -- |