First Cortex-M3 MCUs available
in [Embedded]
|
From: Jim Granville on 2 Apr 2006 16:08 Wilco Dijkstra wrote: > "Jim Granville" <no.spam(a)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 > you are assumed to know the architecture already... At least Luminary > placed the necessary documentation together on one page. Err - take a look at ? http://www.luminarymicro.com/index.php?option=com_content&task=view&id=32&Itemid=95 > >>... and my original question still remains unanswered. > > > Paul Gotch already answered it. If you still don't understand it (and > knowing you, you don't despite it being explained clearly several times), please ask > more specific questions. Do you mean this reply ? "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." Yes, that had us rolling on the floor - given that you claim something can be 'relevent to' but actually 'not refer to' - just HOW is a reader of that document meant to understand _what_ information is pertinent, to another companies (subset) core ? I see Luminary (currently) refer only to CortexM3_TRM, and mention a number of things in that, they have 'pruned'. >> Also, can anyone from Luminary explain why the ARM documents that were on >>their web site are now removed ? > > > ARM have now published the same spec: > > http://www.arm.com/products/CPUs/ARM_Cortex-M3_v7.html > > My guess is that when the final version is ready it will reappear on the > Luminary site. Well, I suppose they _are_ a new company, and we should cut them some slack, but they _really_ should have avoided the nonsensical pre-hype .... I guess once they finally have a polished release, and ARM have also published the pertinent documents, much of this will be easier to follow. > >>>>>>## 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. > > <snip> > >>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 ? > > > There is no volume production of Cortex-M3 today. Luminary is selling > samples and has made this very clear. So according to your contorted > logic Cortex-M3 doesn't even exist! As a volume part, no, but I was giving them some credit for having real silicon, and an errata. Anything else is pure vaporware. <snip> > > 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. I also see the first data sheet for AVR32, and Freescale showing signs of waking up. Interesting times. -jg
From: Paul Gotch on 2 Apr 2006 17:43 In comp.sys.arm Jim Granville <no.spam(a)designtools.co.nz> wrote: > Yes, that had us rolling on the floor - given that you claim something > can be 'relevent to' but actually 'not refer to' - just HOW is a reader > of that document meant to understand _what_ information is pertinent, to > another companies (subset) core ? That is just the point. In order to be conformant to an architecture you must implement *all* of it. In general ARM partners license an ARM core and put more IP around it, they are not allowed to change the ARM core that they have licensed(1). To put this in the clearest possible terms. The last paper edition of the ARM Architecture Reference Manual was published in December 2000 (they've been electronic since then). This document covers up to version 5TE of the ARM Architecture. However the last implementations of the ARMv5TE architecture such as ARM1026, ARM968 and some of the Intel XScale cores were designed years later. However the ARMv5TE Architecture Reference Manual is just as relevent to those cores as it is to the ones that were designed before it was published. Please can you tell me how an Architecture Reference Manual can refer to something that was designed *after* it was published? Cortex-M3 is the *first* implementation of ARM Architecture Version 7M. There will undoubtably be other implementations in the future and the Architecture Reference Manual for ARMv7M will be just as relevent to those designs as it is to Cortex-M3. -p (1) Well unless you are an Architecture licensee but that's a different ball game. -- "What goes up must come down, ask any system administrator" --------------------------------------------------------------------
From: Jim Granville on 2 Apr 2006 19:06 Paul Gotch wrote: > In comp.sys.arm Jim Granville <no.spam(a)designtools.co.nz> wrote: > >> Yes, that had us rolling on the floor - given that you claim something >>can be 'relevent to' but actually 'not refer to' - just HOW is a reader >>of that document meant to understand _what_ information is pertinent, to >>another companies (subset) core ? > > > That is just the point. In order to be conformant to an architecture you > must implement *all* of it. In general ARM partners license an ARM core and > put more IP around it, they are not allowed to change the ARM core that they > have licensed(1). OK, but then I read this in the Luminary datasheet Section 2.2 : "Important: The ARM? Cortex?-M3 Technical Reference Manual describes all the features of an ARM Cortex-M3 in detail. However, these features differ based on the implementation. This section describes the Stellaris implementation." 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." > To put this in the clearest possible terms. The last paper edition of the > ARM Architecture Reference Manual was published in December 2000 (they've > been electronic since then). This document covers up to version 5TE of the > ARM Architecture. > > However the last implementations of the ARMv5TE architecture such as > ARM1026, ARM968 and some of the Intel XScale cores were designed years > later. However the ARMv5TE Architecture Reference Manual is just as relevent > to those cores as it is to the ones that were designed before it was > published. > > Please can you tell me how an Architecture Reference Manual can refer to > something that was designed *after* it was published? I follow the KISS principle, and I DO agree with your earlier comment Paul Gotch wrote: "I will agree that for the micro-controller market it might be better to have unified documentation however that is up to the partner." For a potential new user, looking at a new chip, with a new core like the Luminary devices, they are going to want to know just what is 'in' and what is 'out', for the variant they are focused on. The devil is in the details. Normally, that's reasonably straight forward : one data sheet will list the opcodes, and features, valid for that variant. eg Atmel AVR's have OpCode/Core deviation across families, and they list this in the device data sheets. With the Luminary chip, we seem to have 3 'early release' documents, from two companies, one of which is claimed to be relevent, but not to actually refer to Cortex M3. The ARM Cortex-M3 TRM _is_ cross referenced in the Luminary data, so it certainly seems pertinent. 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 ? -jg
From: Eric on 3 Apr 2006 00:38 >it's £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. 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. Eric
From: Jim Granville on 3 Apr 2006 02:01
Eric wrote: >>it's ?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. > > 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. Their errata says 1.7mA, so no, it is not MSP430 area. It also seems to lack a proper 32KHz osc : Spec's "an external 32KHz Clock " Still, if your battery is big enough .... :) -jg |