First Cortex-M3 MCUs available
in [Embedded]
|
From: 42Bastian Schick on 30 Mar 2006 04:20 On Wed, 29 Mar 2006 19:09:07 GMT, "Wilco Dijkstra" <Wilco_dot_Dijkstra(a)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(a)yahoo.com, it's a spam-only account :-) Use <same-name>@monlynx.de instead !
From: Laurent on 30 Mar 2006 04:43 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
From: Paul Gotch on 30 Mar 2006 05:31 Laurent <laurent.desnogues(a)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" --------------------------------------------------------------------
From: Paul Gotch on 30 Mar 2006 05:25 In comp.sys.arm 42Bastian Schick <bastian42(a)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" --------------------------------------------------------------------
From: Jim Granville on 30 Mar 2006 05:41
Wilco Dijkstra wrote: > "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... 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 |