First Cortex-M3 MCUs available
in [Embedded]
|
From: Jim Granville on 29 Mar 2006 04:25 Richard wrote: >>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. 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
From: Boudewijn Dijkstra on 29 Mar 2006 05:53 Op Wed, 29 Mar 2006 09:59:45 +0200 schreef Richard <nospam(a)thanks.com>: >> 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 (?). CrossWorks is an IDE (and some other stuff) on top of GCC. -- Gemaakt met Opera's revolutionaire e-mailprogramma: http://www.opera.com/mail/
From: Paul Gotch on 29 Mar 2006 07:31 Jim Granville <no.spam(a)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" --------------------------------------------------------------------
From: Wilco Dijkstra on 29 Mar 2006 14:09 "Boudewijn Dijkstra" <boudewijn(a)indes.com> wrote in message news:op.s658jeoxy6p7a2(a)ragnarok.lan... > Op Wed, 29 Mar 2006 09:59:45 +0200 schreef Richard <nospam(a)thanks.com>: > >>> 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. 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
From: Wilco Dijkstra on 30 Mar 2006 03:40
"Jim Granville" <no.spam(a)designtools.co.nz> wrote in message news:442a0892(a)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 |