First Cortex-M3 MCUs available

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.

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

"Eric" <englere.geo@yahoo.com> wrote in message 
news:1143868818.310824.71420@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 &#4294967295;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!*

"Richard" <nospam@thanks.com> wrote in message 
news:fduXf.46012$wl.36409@text.news.blueyonder.co.uk...
> "Eric" <englere.geo@yahoo.com> wrote in message 
> news:1143868818.310824.71420@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 &#4294967295;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 &#4294967295;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. 

"Jim Granville" <no.spam@designtools.co.nz> wrote in message 
news:442bb5bc@clear.net.nz...
> Wilco Dijkstra wrote:
>
>> "Jim Granville" <no.spam@designtools.co.nz> wrote in message
>> news:442a0892@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 

Wilco Dijkstra wrote:
> "Jim Granville" <no.spam@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

> you are assumed to know the architecture already... At least Luminary
> placed the necessary documentation together on one page.

Err - take a look at ?
http://www.luminarymicro.com/index.php?option=com_content&task=view&id=32&Itemid=95

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

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


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

  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.

> 
>>>>>>## 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!

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

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

I also see the first data sheet for AVR32, and Freescale showing signs 
of waking up. Interesting times.

-jg

In comp.sys.arm Jim Granville <no.spam@designtools.co.nz> wrote:
>   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 ?

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

Paul Gotch wrote:

> In comp.sys.arm Jim Granville <no.spam@designtools.co.nz> wrote:
> 
>>  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 ?
> 
> 
> 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).

OK, but then I read this in the Luminary datasheet Section 2.2 :

"Important: The ARM&#4294967295; Cortex&#4294967295;-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."


> 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?

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

>it's =A399 for the board, a tethered CrossWorks for ARM license, and the
>integrated CrossConnect, so you don't need anything else to evaluate the L=
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

Eric wrote:
>>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.
> 
> 
> 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.

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