First Cortex-M3 MCUs available
in [Embedded]
|
From: Eric on 1 Apr 2006 00:22 I think the Keil eval software has an integrated debugger that can talk to the USB JTAG port, but it's probably got a small memory limit. I don't know of any open source code that can talk to either a ulink or a jlink.
From: dominic.rath on 1 Apr 2006 06:44 Eric wrote: > Do you think your OpenOCD will work with these chips? Do you think the > Cortex-M3 4-wire JTAG interface is compatible with older ARM7TDMI JTAG > interfaces? No, it wont work with the Cortex-M3. The JTAG interface is similar, but that's just the lowest level. The debugging functionality is completely different, and would have to be rewritten. Regards, Dominic
From: Richard on 1 Apr 2006 07:19 "Eric" <englere.geo(a)yahoo.com> wrote in message news:1143868818.310824.71420(a)z34g2000cwc.googlegroups.com... > Dominic, > > Do you think your OpenOCD will work with these chips? Do you think the > Cortex-M3 4-wire JTAG interface is compatible with older ARM7TDMI JTAG > interfaces? > > I hope we can get Olimex or someone else to make low cost dev boards. > I'd really like to play with these devices. > > Eric > I'm currently creating a FreeRTOS.org demo for a dinky dev board produced by Rowley Associates. I believe it is going to be available for ?99. There is nothing on the Rowley WEB site just now about it but there will be in the next day or two. It has a LM3S101 and USB interface for debugging. Regards, Richard. http://www.FreeRTOS.org *Now for ARM CORTEX M3!*
From: Paul Curtis on 1 Apr 2006 08:11 "Richard" <nospam(a)thanks.com> wrote in message news:fduXf.46012$wl.36409(a)text.news.blueyonder.co.uk... > "Eric" <englere.geo(a)yahoo.com> wrote in message > news:1143868818.310824.71420(a)z34g2000cwc.googlegroups.com... >> Dominic, >> >> Do you think your OpenOCD will work with these chips? Do you think the >> Cortex-M3 4-wire JTAG interface is compatible with older ARM7TDMI JTAG >> interfaces? >> >> I hope we can get Olimex or someone else to make low cost dev boards. >> I'd really like to play with these devices. > > I'm currently creating a FreeRTOS.org demo for a dinky dev board produced > by Rowley Associates. I believe it is going to be available for ?99. > There is nothing on the Rowley WEB site just now about it but there will > be in the next day or two. It has a LM3S101 and USB interface for > debugging. Actually, it is an LM3S102 with I2C as that's the way the ADC is interfaced to the LM3S102. Yes, 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. I've just uploaded the information to the website, and hopefully the ISP's caches won't cause too many problems. Our selected manufacturer for the board, Embedded Artists, had no problem purchasing parts and they have already been delivered and the boards are now in production. -- Paul Curtis.
From: Wilco Dijkstra on 2 Apr 2006 11:38
"Jim Granville" <no.spam(a)designtools.co.nz> wrote in message news:442bb5bc(a)clear.net.nz... > 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 ? .... >> So people are not used to this? You must be the only one... .... > 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 - you are assumed to know the architecture already... At least Luminary placed the necessary documentation together on one page. > ... 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. > 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. >>>>>## 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! >>>>>** Strange method to 'kludge around' BIT manipulation. .... >> 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. Simple macros are trivial to port - that's exactly the point. So you can recompile source that uses bitbanding into code that doesn't and visa versa. If there is compiler support this happens automatically depending on the selected CPU. Remember the ARM world has 10+ years of experience with dealing with cores with different features - this stuff is all handled automatically behind the scenes without you even needing to think about it. > 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. You clearly haven't ever used ARM... You don't have to worry about such basic things - the compiler will choose the smallest instruction sequence (2 instructions for the above cases, 4-6 bytes). Even the assembler chooses the smallest possible instructions for you. If you do many such initialisations and you want the absolute minimum footprint then you have to work on it. You can't expect anybody to write your software. A simple LZ-style algorithm would give a reasonable 2-4x compression. The ARM/Keil compilers use it for data initialization when it reduces the flash size but you could write your own. If you do embedded stuff you should be familiar with small footprint and in-place data compression. > 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 ? If the compiler generates small and fast code and the core is efficient there is no need to write assembler to get faster or smaller code. It is very common to write large amounts of assembler just because their compiler produces inefficient code - moving to a different core/architecture/compiler may solve this problem. I know of an OS which contained 100K lines(!) of assembler. When they upgraded to a new compiler it turned out it generated better code than the assembler they had written... Cortex-M3 allows all code (startup, interrupt etc) to be written in C - on other ARMs you need some assembler. You also don't need to choose between ARM and Thumb to get the best balance of codesize and performance (on many current ARM MCUs you need to execute ARM code from SRAM to get good performance). > 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. 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. > 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 :) As a reseller of 8/16-bit tools I appreciate you must be concerned by people moving to 32-bit CPUs and reducing your market :-) Wilco |