First Cortex-M3 MCUs available

Thanks. Thought I had to pay for their port. (Like the gcc for c166 port).

--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
 Click to see the full signature
Reply to
42Bastian Schick
Loading thread data ...

On 30 Mar 2006 11:25:20 +0100 (BST), Paul Gotch

Good hint. Will try to remove this manually.

--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
 Click to see the full signature
Reply to
42Bastian Schick

Does it really matter? I'm fairly sure the answer to this is "ARM asked us to do it".

I remember an era not so long ago when you couldn't get the core datasheets except by ordering a free demo copy of the ARM ARM on CD and ignoring the compiler; they weren't even up on ARM's web site.

I don't recall seeing direct download links to the ARM docs on any vendor sites; not even outside links to ARM's web site. (Not to say they don't exist, of course).

Reply to
larwe

Please research how to do this correctly via MS documentation first, I suspect it has to be unregistered to stop Windows attempting to load it on boot. Your mileage may vary ... on your own head be it if attempting to remove it manually breaks Windows etc.

If you want a proper supported fix please contact ARM support with the problem.

-p

--
 "What goes up must come down, ask any system administrator"
--------------------------------------------------------------------
Reply to
Paul Gotch

The situation with respect to that port is interesting.

It's vaguely possible that they could dump the intermediate respresentation from GCC and pass that through a closed source back end without violating the GPL. However if they've made modifications to any part of GCC itself then they must make an offer of the source to any one they have distributed a binary to. They are perfectly entitled to only distribute that binary by selling it.

However they then cannot stop you distributing the modified GCC source to anyone else, they can only stop you redistributing their separate closed source components.

The Code Sourcery GCCs are downloadable in both source and binary form and as I mentioned periodically get folded back into the official mainline GCC.

-p

--
 "What goes up must come down, ask any system administrator"
--------------------------------------------------------------------
Reply to
Paul Gotch

A person from ARM said "because they are preliminary". Urk!

There seem to be times when "upper" layers at ARM don't listen to the people at the coalface. The same was also true before the introduction of commodity ARM7 parts. I suspect that ARM, as opposed to Luminary, are chasing very high volume *core* design ins at this stage.

I wish Luminary well.

Stephen

--
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
 Click to see the full signature
Reply to
Stephen Pelc

How do we interface gdb to the cortex-m3? I understand existing Wigglers don't work. Does anyone sell Wiggers that do work with it?

Reply to
Eric

The Cortex-M3 has two debug interfaces - a traditional 4-wire JTAG interface (TCK, TMS, TDI and TDO), and a single-wire debug (SWD) interface. Someone at the Luminary forum reported that they successfully used a standard Wiggler with the 4-wire interface. The SWD on the other hand might be too much for a simple device like a Wiggler to handle.

To use GDB, you'd need something that translates e.g. the GDB remote protocol into the low-level JTAG signals. There's a RDI-GDB stub available for some of the commercial debuggers, maybe you could use one of these.

Regards,

Dominic

Reply to
dominic.rath

I think the CodeSourcery/Luminary Micro setup allows GDB to talk directly to the dev kit over a USB interface. No need for a wiggler for that particular setup.

Regards, Richard.

formatting link

*Now for ARM CORTEX M3*
Reply to
Richard

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

Reply to
Eric

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.

Reply to
Eric

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

Reply to
dominic.rath

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.

formatting link

*Now for ARM CORTEX M3!*
Reply to
Richard

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.

Reply to
Paul Curtis

...

...

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.

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.

ARM have now published the same spec:

formatting link

My guess is that when the final version is ready it will reappear on the Luminary site.

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!

...

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.

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.

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).

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.

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

Reply to
Wilco Dijkstra

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:

formatting link

Err - take a look at ?

formatting link

please ask

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'.

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.

As a volume part, no, but I was giving them some credit for having real silicon, and an errata. Anything else is pure vaporware.

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

Reply to
Jim Granville

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"
--------------------------------------------------------------------
Reply to
Paul Gotch

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."

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

Reply to
Jim Granville

M3S102.

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

Reply to
Eric

LM3S102.

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

Reply to
Jim Granville

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.