First Cortex-M3 MCUs available
in [Embedded]
|
From: Wilco Dijkstra on 3 Apr 2006 19:39 "Jim Granville" <no.spam(a)designtools.co.nz> wrote in message news:44302f02(a)clear.net.nz... > 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 These parts only have an instruction set description. That is not the same as an architecture document. So you still need a second document describing the architecture, the register set, how interrupts are handled etc. My point is that most if not all CPUs require at least 2 documents: one for the chip, and one for the architecture. It's how things work. However I agree that it would be useful if Luminary added a detailed M3 and instruction summary to their specs. Combining the documents (quite apart from legal issues) would not be useful given they total over 1000 pages... [ I take it that the difference between architecture and implementation has been cleared up between you and Paul ] >>> Also, can anyone from Luminary explain why the ARM documents that were >>> on their web site are now removed ? Oh, they have reappeared already. Tthe Cortex-M3 TRM and v7 architecture spec now available on both the Luminary and ARM sites. >> 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. It's likely there will be another M3 core this year. 2007, definitely, probably 3, maybe 4. Note that existing MCU manufacturers could get an M3 to market faster than Luminary did as they have a large set of existing peripherals. > I also see the first data sheet for AVR32, and Freescale showing signs of > waking up. Interesting times. You mean the AVR32 at a disappointing 166Mhz? It's funny, they appear right next to ARM1020/1026 on the EEMBC site, and you can see the certified scores are worse than 4+ year old ARM cores... Interesting times indeed :-) Wilco
From: Jim Granville on 3 Apr 2006 21:18 Wilco Dijkstra wrote: > "Jim Granville" <no.spam(a)designtools.co.nz> wrote in message >>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 > > > These parts only have an instruction set description. That is not the same > as an architecture document. So you still need a second document > describing the architecture, the register set, how interrupts are handled > etc. Not in the ones I've looked at - they have all of that info. > My point is that most if not all CPUs require at least 2 documents: > one for the chip, and one for the architecture. It's how things work. At ARM, probably yes - however the rest of the microcontroller space are widely used to getting all their data solely from the company that makes the devices. Keeps things simple. > However I agree that it would be useful if Luminary added a detailed M3 > and instruction summary to their specs. Then we all agree, you, me and Paul. :) >>>>Also, can anyone from Luminary explain why the ARM documents that were >>>>on their web site are now removed ? > > > Oh, they have reappeared already. Tthe Cortex-M3 TRM and v7 > architecture spec now available on both the Luminary and ARM sites. :) ...and I note you now have to register to get this info, and also see in their Errata section, an ARM errata on the Cortex M3. Will the next Cortex M3 releases also have this errata, or have they got a cleaner design ? -jg
From: Eric on 3 Apr 2006 23:23 >Embedded Artists designed the board, and we're very happy with the quality >and whole experience working with them. Agreed. Their lpc2148 Educational board is an incredible value, and they're developing a lot of extender boards for it. They also have some great software (like their RTOS). This company is going places, and so is yours (Rowley). After a couple years of boredom things are starting to happen again, and that's exciting! Eric
From: 42Bastian Schick on 4 Apr 2006 01:31 On Mon, 03 Apr 2006 15:14:03 GMT, "Peter Dickerson" <first{dot}surname(a)ukonline.co.uk> wrote: > >I don't think 'portable' was mentioned. However, M3 interrupts entry and >exit is compatible with C ABI. Must have overseen this. But the documents and the discussion in this thread aren't really clearing things :( I have seen better docs from ARM before. But hands-on real hardware will clear all this :-( -- 42Bastian Do not email to bastian42(a)yahoo.com, it's a spam-only account :-) Use <same-name>@monlynx.de instead !
From: Peter Dickerson on 4 Apr 2006 02:41
"42Bastian Schick" <bastian42(a)yahoo.com> wrote in message news:4432042f.354248222(a)news.individual.de... > On Mon, 03 Apr 2006 15:14:03 GMT, "Peter Dickerson" > <first{dot}surname(a)ukonline.co.uk> wrote: > > > > >I don't think 'portable' was mentioned. However, M3 interrupts entry and > >exit is compatible with C ABI. > > Must have overseen this. But the documents and the discussion in this > thread aren't really clearing things :( The docs are beta :-( and only describe the 'application' view :-( Perhaps holding back the 'system' view documentation is adding to the problems. > I have seen better docs from ARM before. But hands-on real hardware > will clear all this :-( Hardware may clarify what the core actually does but not what it is supposed to do. You might discover that a register is cleared by some instruction (say) but that doesn't stop the architecture docs from saying the value is undefined or implementation dependent... Peter |