> "Jim Granville" <no.spam@designtools.co.nz> wrote in message
> news:44341ef4@clear.net.nz...
>
>>Eric wrote:
>
>
>>If you want real speed, in a new 32 bit core see
>>
>>http://www10.edacafe.com/nbc/articles/view_article.php?section=ICNews&articleid=257140
>>
>>( the SH2A, like Cortex, claims better code size (25% smaller), but
>>unlike the first Cortex-M3, hits ~160MHz and also claims "(Upward
>>instruction compatibility is maintained with the SH-2 core.)"
>
>
> A few new instructions (they mention bitfield and division) isn't going to
> give 25% average codesize improvement. Few instructions improve
> codesize by more than 1% (bitfield instructions give far less), so you
> do need to do something drastic to get to 25%.
>
> It's interesting to note that Renesas recently licensed some ARM cores.
>
> A similar MCU was announced by Philips (208Mhz ARM926EJ-S with
> floating point hardware and Java acceleration):
>
> http://www.standardics.philips.com/news/lpc3180/~LPC3180/#top
>
> It looks like everybody is going after the high-end MCU (100+Mhz)
> segment.
True.
What sets the SH2A appart a little from the others (AVR32, LPC3180
Fujitsu, Freescale etc), is the SH2A claims 160MHz/320 MIPS from
internal flash(512KF).
Most other internal flash specs are 50/60/80MHz region.
Flash has always been a weakspot, and flash has been getting faster
slower than the cores.
Analog Devices dumped their FLASH DSPs, and went for RAM cores instead.
-jg
Reply by Wilco Dijkstra●April 5, 20062006-04-05
"Jim Granville" <no.spam@designtools.co.nz> wrote in message
news:44341ef4@clear.net.nz...
> Eric wrote:
> If you want real speed, in a new 32 bit core see
>
> http://www10.edacafe.com/nbc/articles/view_article.php?section=ICNews&articleid=257140
>
> ( the SH2A, like Cortex, claims better code size (25% smaller), but
> unlike the first Cortex-M3, hits ~160MHz and also claims "(Upward
> instruction compatibility is maintained with the SH-2 core.)"
A few new instructions (they mention bitfield and division) isn't going to
give 25% average codesize improvement. Few instructions improve
codesize by more than 1% (bitfield instructions give far less), so you
do need to do something drastic to get to 25%.
It's interesting to note that Renesas recently licensed some ARM cores.
A similar MCU was announced by Philips (208Mhz ARM926EJ-S with
floating point hardware and Java acceleration):
http://www.standardics.philips.com/news/lpc3180/~LPC3180/#top
It looks like everybody is going after the high-end MCU (100+Mhz)
segment.
Wilco
It's important to note that the core mA/MHz figure is almost irrelevant for low power,
low on-cycle applications.
Sure, the MSP430 has a low mA/MHz figure but the clock ramp-up and flexibility, smart
peripherals, low pin leakage are more important.
To chase low mA/MHz figures is naive for real applications unless the device spends a
lot of time at full power. The MSP430 is still very hard to beat for low on-cycle, low
power applications.
-Andrew M
Reply by Jim Granville●April 5, 20062006-04-05
Eric wrote:
>>Their errata says 1.7mA, so no, it is not MSP430 area.
>
>
> Thanks for that tip to look at errata. Sometimes I don't pay attention
> to it, and I really should, of course.
>
> I see 35 ma as typical full speed operating current in the spec sheet
> (3.3v @ 20Mhz), and 1.7 ma in deep sleep.
>
> This is definitely not a candidate for battery power. The lpc2103 has
> better numbers than these, and the new lpc2888 is supposed to be able
> to operate from a single 1.5v battery.
>
> This is still an interesting device and I'll likely get the new dev
> board from Rowley and check it out. But it lacks the main advantage I
> was looking for.
If you are looking for better maths, and low power, the metering market
has some focused devices - and they need reasonable maths to get
accurate powers.
Companies like TDK have a C51 + CoPro, and Maxim has their MAXQ,
they claim is lowest power 16 bit CPU - but the mA/MHz need
to be watched on some models.
If you want real speed, in a new 32 bit core see
http://www10.edacafe.com/nbc/articles/view_article.php?section=ICNews&articleid=257140
( the SH2A, like Cortex, claims better code size (25% smaller), but
unlike the first Cortex-M3, hits ~160MHz and also claims "(Upward
instruction compatibility is maintained with the SH-2 core.)"
-jg
Reply by Eric●April 4, 20062006-04-04
>Their errata says 1.7mA, so no, it is not MSP430 area.
Thanks for that tip to look at errata. Sometimes I don't pay attention
to it, and I really should, of course.
I see 35 ma as typical full speed operating current in the spec sheet
(3.3v @ 20Mhz), and 1.7 ma in deep sleep.
This is definitely not a candidate for battery power. The lpc2103 has
better numbers than these, and the new lpc2888 is supposed to be able
to operate from a single 1.5v battery.
This is still an interesting device and I'll likely get the new dev
board from Rowley and check it out. But it lacks the main advantage I
was looking for.
Eric
Reply by Peter Dickerson●April 4, 20062006-04-04
"42Bastian Schick" <bastian42@yahoo.com> wrote in message
news:4432042f.354248222@news.individual.de...
> On Mon, 03 Apr 2006 15:14:03 GMT, "Peter Dickerson"
> <first{dot}surname@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
>
>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@yahoo.com, it's a spam-only account :-)
Use <same-name>@monlynx.de instead !
Reply by Eric●April 4, 20062006-04-04
>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
Reply by Jim Granville●April 3, 20062006-04-03
Wilco Dijkstra wrote:
> "Jim Granville" <no.spam@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
Reply by Wilco Dijkstra●April 3, 20062006-04-03
"Jim Granville" <no.spam@designtools.co.nz> wrote in message
news:44302f02@clear.net.nz...
> 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
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