Luminary Micro

> Crossworks supports it with their debugger and simulator. I haven't
> tried them, though.

I have used all the available tools.  CrossWorks tools work nicely: 
http://www.freertos.org/portcortexcrossworks.html, as in fact do the Keil, 
GCC and IAR tools.

Regards,
Richard.

+ http://www.FreeRTOS.org
+ http://www.SafeRTOS.com
for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430
Microblaze, Coldfire, AVR, x86, 8051 & PIC18 * * * *

Jim Granville wrote:
> rickman wrote:
> > I just had a telecon with LM personel and specifically mentioned that
> > their parts had nothing on the ARM7 competition when it came to power,
> > most likely because they were still at 0.25 um while everyone else was
> > doing 0.18 or finer.  Asking if they had future plans for power
> > reduction they offered nothing.  They only talked about parts with more
> > memory.
>
> Keep in mind that as these things shrink, static Icc can climb markedly.
> So finer devices are not always lower power. (FPGAs are a good example)
>
> I also see their Icc spec mentions SRAM execution and does not specify
> FLASH Icc ( which is often higher )
> Remember Scenix, they got fast flash specs, but at the cost of very high
> Icc values.

The high static Icc is a feature of some 4 or 5 generations beyond the
0.25 um they are using.  I think you will find that core voltages of
1.8 and even 1.5 still allow low static currents with modern
processing.  The person I spoke to referred to their process as
"mature" as if that was automatically a good thing.  There is a reason
why we keep moving ahead with processing.  Likely they work with 0.25
um because it gives them a lower startup cost to get their first 20
devices out the door.  I would like to see a plan for moving forward
with 0.18 or even 0.15 um to reduce the cost and power.  But they
indicated all the currently planed devices will also be 0.25 um.


> > The two important aspects in our designs is size and power.  They are
> > in a good package, the TQFP48, but they are definitely not there on
> > power.  They also don't do any better on price although that is always
> > negotiable.  They made it very clear that price would not be an issue.
>
> Could you use two processors, a smaller, more frugal one to wake up the
> more powerful one, when needed ?

See the first consideration, size?  Besides, I can get lower power ARM
devices and the speed advantage of the LM parts is not that clear.

Jim Granville wrote:
> Eric wrote:
> > Luminary licensed the peripheral support from a more experienced firm
> > in this first set of chips so they could introduce a more mature set of
> > support peripherals in a new chip.
>
> Hmmm. They buy the core from ARM, and the peripherals from someone else
> :( - that suggests the errata will be a long time being resolved ?
> Some of the errata sound fundamental.

Where do you get this stuff???  How does using third party peripherals
equate to errata?  For any number of companies I would prefer that they
get third party peripherals... besides, there are more parts of the MCU
that are from ARM on the Cortex M3.  The interrupt controller is one
and I don't recall the others, but it may include the IO ports.  It
also includes a MPU.  The UART is a standard 16550 which has TONS of
code base around.  These common peripherals alone are a big boost to
porting your code between ARM vendors once the Cortex M3 is more
common.

If the power issue is dealt with by the other vendors the Cortex M3 may
be the next 8051.  The ARM7 is called the 32 bit equivalent to the
8051, but the Cortex M3 may actually replace it in all but the lowest
cost apps!  Now, if someone would make an FPGA with a hard Cortex M3
core, I would be in heaven.  I could use that in so many places.


> > By the way, I understand that ST Micro also licensed the Cortex M3
> > core, but they haven't announced any specific chips yet. I was told
> > there were 5 licensees at the time I asked several months ago, but only
> > ST and Luminary were mentioned by name.
>
> CM3 makes sense in an ASIC, but is a harder sell into the merchant uC
> market, where you a buying a lot more than just the core.
> ( see rickman's comments on the Icc )

I don't see why you make this claim.  The Icc of the Luminary devices
has to do with the implementation that is at least one generation
behind the rest of the field.  If they used a more current technology
(which the other vendors certainly will when they produce product) the
current consumption would likely beat anything on the market.  Maybe I
should have said "a LESS 'current' technology" ;^)


> > I'm more than a little confused by ST lately. They seem to be expanding
> > in many directions at once. I hope they're not over-extending
> > themselves.
>
>   Yes, they have lots of cores!. All the 8 bit ones, ARM7, ARM9, and
> their newest ST10 devices are quite powerful, if not super-cheap.
> There was talk of an ARM uPSD as well !

That does not bother me.  If they are making chips that compete
internally with their ARM cores, I feel that provides the highest level
of competition.  Competition is what makes a group push their designs
and make real progress.

rickman wrote:

> Jim Granville wrote:
> 
>>Eric wrote:
>>
>>>Luminary licensed the peripheral support from a more experienced firm
>>>in this first set of chips so they could introduce a more mature set of
>>>support peripherals in a new chip.
>>
>>Hmmm. They buy the core from ARM, and the peripherals from someone else
>>:( - that suggests the errata will be a long time being resolved ?
>>Some of the errata sound fundamental.
> 
> 
> Where do you get this stuff???  How does using third party peripherals
> equate to errata?  

  My comment related to the time to resolve the errata, not the errata 
themselves.


  When they buy from 3rd parties, first they have to 'discuss' who pays 
for the mistakes, then assuming that is settled, they have to go
into the queue to be fixed.....

A look at the errata on the S815, has some eyebrow raising ones :

Two involved Debug port lockup - hmm, I thought this was all from ARM ?

One involves poor ADC noise : classic cut & paste errata, that one.

A 0% operation on temperature sensor ?

LDO aspects also look rather untested, but their LDO is ambitious.

All the same, Freescale and SiLabs can get much lower power, on
similar processes.

-jg

Jim Granville wrote:
>   My comment related to the time to resolve the errata, not the errata
> themselves.
>
>   When they buy from 3rd parties, first they have to 'discuss' who pays
> for the mistakes, then assuming that is settled, they have to go
> into the queue to be fixed.....

That is an assumption that the peripheral core is new.  The peripherals
are often things that are existing, well debugged designs such as the
16550 UART.  In fact that is a good reason for using third party IP,
that other customers have debugged it for you.  You can speculate, but
do you have any basis for your claim?


> A look at the errata on the S815, has some eyebrow raising ones :
>
> Two involved Debug port lockup - hmm, I thought this was all from ARM ?
>
> One involves poor ADC noise : classic cut & paste errata, that one.
>
> A 0% operation on temperature sensor ?
>
> LDO aspects also look rather untested, but their LDO is ambitious.
>
> All the same, Freescale and SiLabs can get much lower power, on
> similar processes.

I have never seen an new chip that did not have errata the first time
out of the shoot.  I don't see how any of this supports your contention
that their designs will be more buggy than normal because of the third
party peripherals.  I remember some very notable failures by very
experienced companies such as TI.  There was more than one product that
never made it to market because of the year long delay getting the
TMS320C50xx core onto a general chip rather than the custom chips in
cell phones.  Do you think that was due to third party peripherals?

Or how about the errata with the Atmel SAM7 parts so that the quiescent
current goes up dramatically if you try to use the JTAG interface?  I'm
not so familiar with the Philips or Freescale ARM chips so I don't know
what problems they had coming out of the shoot.

Design problems are par for the course.  If anything these chips will
have problems because they are brand new, not because of the source of
their IP.

rickman wrote:
> Or how about the errata with the Atmel SAM7 parts so that the quiescent
> current goes up dramatically if you try to use the JTAG interface?  I'm
> not so familiar with the Philips or Freescale ARM chips so I don't know
> what problems they had coming out of the shoot.

The shoot?  Your spell checker run amok? ;)

More on point.  The Philips parts seem to have a problem with race
conditions.   A lot of the errata appear as if they were race
conditions of one form or another.

Robert

rickman wrote:
> Jim Granville wrote:
> 
>>  My comment related to the time to resolve the errata, not the errata
>>themselves.
>>
>>  When they buy from 3rd parties, first they have to 'discuss' who pays
>>for the mistakes, then assuming that is settled, they have to go
>>into the queue to be fixed.....
> 
> 
> That is an assumption that the peripheral core is new.  The peripherals
> are often things that are existing, well debugged designs such as the
> 16550 UART.  In fact that is a good reason for using third party IP,
> that other customers have debugged it for you.  You can speculate, but
> do you have any basis for your claim?
> 
> 
>>A look at the errata on the S815, has some eyebrow raising ones :
>>
>>Two involved Debug port lockup - hmm, I thought this was all from ARM ?
>>
>>One involves poor ADC noise : classic cut & paste errata, that one.
>>
>>A 0% operation on temperature sensor ?
>>
>>LDO aspects also look rather untested, but their LDO is ambitious.
>>
>>All the same, Freescale and SiLabs can get much lower power, on
>>similar processes.
> 
> 
> I have never seen an new chip that did not have errata the first time
> out of the shoot.  I don't see how any of this supports your contention
> that their designs will be more buggy than normal because of the third
> party peripherals.  

  Again, I did not claim their designs are more buggy, per se,  but 
commented on  the time to resolve those bugs.

  If you want an example of the perils of "cut and paste" design, just
look at the ADC specs in the errata. Or the high Idle Icc....

  Let's see how long to takes to clear all those errata, from the B5 
silicon ?

  I recall an 80C51 variant some years back, that pasted in a nice 32Khz
cell, and yes, they got a low uA Oscillator. Problem was, they followed 
it with a HCMOS grade buffer, and so the non square wave icc was much 
higher : The cut and paste operator, did not realise the linear Icc of 
the buffer was very important as well.

  Their 6.1 errata sounds broadly similar, tho I suspect some 
workarounds  could be found, even tho they say 'none' (depends on the 
precise fault location). We did manage to discover a couple of 
work-arounds for that 80C51 Osc oops.

  Of course all devices have errata, and I have also seen some real
clangers from companies that should have known better.

-jg

In article <1157325272.989795.241350@e3g2000cwe.googlegroups.com>, sub2
@aeolusdevelopment.com says...
> rickman wrote:
> > Or how about the errata with the Atmel SAM7 parts so that the quiescent
> > current goes up dramatically if you try to use the JTAG interface?  I'm
> > not so familiar with the Philips or Freescale ARM chips so I don't know
> > what problems they had coming out of the shoot.
> 
> The shoot?  Your spell checker run amok? ;)
> 
> More on point.  The Philips parts seem to have a problem with race
> conditions.   A lot of the errata appear as if they were race
> conditions of one form or another.
> 
> Robert

Actually, it is understood that the Philips LPC2xxx parts have a problem 
with race conditions on the ARM High Speed Bus (AHB), which is used to 
communicate with many peripherals;  the problems are with the (ARM-
designed) bus, not with the Philips peripherals.

--Gene

Gene S. Berkowitz wrote:
> In article <1157325272.989795.241350@e3g2000cwe.googlegroups.com>, sub2
> @aeolusdevelopment.com says...
> > More on point.  The Philips parts seem to have a problem with race
> > conditions.   A lot of the errata appear as if they were race
> > conditions of one form or another.
> > Robert
>
> Actually, it is understood that the Philips LPC2xxx parts have a problem
> with race conditions on the ARM High Speed Bus (AHB), which is used to
> communicate with many peripherals;  the problems are with the (ARM-
> designed) bus, not with the Philips peripherals.

The bus or the interface between the bus and Philips peripherals?  I
would have thought the latter.

Robert

Jim Granville wrote:
> rickman wrote:
> > I have never seen an new chip that did not have errata the first time
> > out of the shoot.  I don't see how any of this supports your contention
> > that their designs will be more buggy than normal because of the third
> > party peripherals.
>
>   Again, I did not claim their designs are more buggy, per se,  but
> commented on  the time to resolve those bugs.

Funny you mention that.  Atmel has simlar errata on their SAM7 parts
that has been in place for a year or so with no fix in sight.  I
counted 27 errata on the SAM7S64 device.  Obviously, long standing
errata is not an uncommon thing.


>   If you want an example of the perils of "cut and paste" design, just
> look at the ADC specs in the errata. Or the high Idle Icc....
>
>   Let's see how long to takes to clear all those errata, from the B5
> silicon ?

I just don't see your point.  You are saying that because they might
have to communicate with a different company (who will be getting the
same complaints from other customers) rather than a different
department, there will be a noticable delay in a fix to the errata?  I
just don't see this as significant.  All the chip vendors fix problems
based on a priority of how it affects their customers (and by that I
mean their *major* customers).  If they need for it to be fixed, it
will get fixed.  If not, the huge cost of respinning the chip will make
a much larger impact than the delay in negotiating with a vendor.


>   I recall an 80C51 variant some years back, that pasted in a nice 32Khz
> cell, and yes, they got a low uA Oscillator. Problem was, they followed
> it with a HCMOS grade buffer, and so the non square wave icc was much
> higher : The cut and paste operator, did not realise the linear Icc of
> the buffer was very important as well.
>
>   Their 6.1 errata sounds broadly similar, tho I suspect some
> workarounds  could be found, even tho they say 'none' (depends on the
> precise fault location). We did manage to discover a couple of
> work-arounds for that 80C51 Osc oops.
>
>   Of course all devices have errata, and I have also seen some real
> clangers from companies that should have known better.

Yes, now you get it!