AVR looking weak against TI and Cygnal

> I paid 7.75 GBP each (about $13) for 20 off LPC2106 from my distributor: 
> Silica/Avnet, here in the UK. The pound is strong against the dollar at 
> present, which helps. I think the '2104 is under $10 in quantity, here. 
> How about me buying your chips here and selling them on to you, I can 
> probably get 100 pcs immediately. 8-)

Silica have no rep for Bulgaria, I sent request to the quoted office
in Slovenia on their web page and never got reply, same is with Arrow
which is also quoted as their distributor, it seems that Philips have
no enough stock to cover even the initial interest they made with the
LPC2100 buzz.

Best regards
Tsvetan
---
PCB prototypes for $26 at http://run.to/pcb
(http://www.olimex.com/pcb)
Development boards for PIC, AVR and MSP430 
(http://www.olimex.com/dev)

"Chris Carlen" <crcarle@BOGUS.sandia.gov> wrote in message
news:brv79i0s6b@enews4.newsguy.com...
> Unbeliever wrote:
> > "Chris Carlen" <crcarle@BOGUS.sandia.gov> wrote in message
> > news:brsqbr02b5v@enews2.newsguy.com...
> >
> >>... even at 8MHz, the 16-bit MSP430 core is of similar performance to
the
> >>16 MHz AVRs, ....
> >>
> >
> > I beg to differ.  Having used the MSP430 for some time, I recently
> > benchmarked it against the AVR for an IP stack app.  The AVR won hands
down.
> > The MSP430 might be comparable to the AVR for 16 bit stuff, but an 8 bit
> > app. is much faster on the AVR.  The problem is that an MSP430 averages
> > about 4 cycles per instruction, giving about 2 mips for an 8MHz part (6
and
> > a bit for 25MHz) whereas the AVR averages about 1.8 cycles per
instruction
> > for about 9 Mips.  The MSP430 is a fantastic low power processor with a
> > bunch of peripherals available but its speed is not quite in the same
> > ballpark as the AVR.
>
> Hmm.  I see.  Thanks for the input.  I haven't actually worked with
> MSP430, but have been considering that if and when a 25MHz MSP430
> becomes available, to weigh it against the AVR as a possible replacement
> for some signal synthesis applications that are pushing the AVR to it's
> limits.
>
> Perhaps I'd be better served by just a faster AVR, though I like the
> integrated 12-bit analog IO on AVR's competitors.  Since I know and
> *really* like the AVR architecture, and the tools are cheap and easy,
> I'd much rather stick with it than say, work with the Cygnal parts.
> 8051, blech!  I don't care that the 8051 is big-time, since I do mainly
> laboratory instrumentation where easy=fast results is more important
> that product margins for million unit sales.
>

I've used both the AVR and the msp430, and I like both architectures - but
the msp430 is definitely nicer to work with both in C and assembly.  The avr
is more elegant in some ways, resulting in code that runs very close to one
instruction per clock.  But the msp430 has a very flexible instruction set
that has two big advantages over the avr, especially for C programing - it
is 16-bit wide, and it has a single flat memory space.  The avr's Harvard
architecture may be faster, but the single memory space is vastly easier to
deal with (no more complications with strings and data in flash).

> > Now the ARM is a different container of herrings altogether.
>
> Yes, and it's something I'll have to delve into at some point.  I was
> actually hoping the Motorola 68000 family stuff like Dragonball would
> remain of similar popularity to the ARM, but that doesn't seem to be the
> likely outcome.  I figured the 68k assembly language would be a cinch to
> learn, compared to ARM (I figure I will need to understand the assembly
> to work competently with any CPU, since there are times when I have to
> step through the compiler output to make sure it's doing things right).
>   But now I feel it might not be worth the effort to learn the 68000
> considering it seems to be fading and ARM taking over.
>

The 68k programming model is still going strong.  The 68332 microcontroller
seems to be pretty much immortal - no matter how much Motorola says they
want people to switch to the ColdFire and/or the MPC, the 68332 is still
popular.  Then there is the ColdFire family - it is the same programming
model as the 68000 (to within about 90%, anyway), but a new and more
efficient implementation of the core, and it is very popular.

> Good day!
>
>
>
> --
> ____________________________________
> Christopher R. Carlen
> Principal Laser/Optical Technologist
> Sandia National Laboratories CA USA
> crcarle@sandia.gov
>

> Hi Ulf!
>
> Yes, the FPSLIC is a bit better.  But I guess I'm more interested in
> seeing better analog IO, including DACs on the plain controllers, as
> well as a moderate boost in speed.  Even 25MHz would be nice for the
> time being.

Yes, Analog and built in Flash would be a nice addition to the FPSLIC.
The new 58.8k process will make that possible. - No promises though.

> Is the mega8 at 33MHz just an overclocked standard mega8 (whatever 0,NNu
> process you are using for production megas right now), or is it a new
> process?  Does it mean Atmel actually intends an upgrade to the speed
> capabilities of the AVR-mega family anytime soon (or later)?
>
> Thanks for input.

Overclocked standard issue 0,35 u Mixed signal process running at 3.3Volt.
Same process as everything else.
Does not mean anything unfortunately.


-- 
Best Regards
Ulf at atmel dot com
These comments are intended to be my own opinion and they
may, or may not be shared by my employer, Atmel Sweden.

"David Brown" <david@no.westcontrol.spam.com> writes:

> 
> I've used both the AVR and the msp430, and I like both architectures - but
> the msp430 is definitely nicer to work with both in C and assembly.  The avr
> is more elegant in some ways, resulting in code that runs very close to one
> instruction per clock.  But the msp430 has a very flexible instruction set
> that has two big advantages over the avr, especially for C programing - it
> is 16-bit wide, and it has a single flat memory space.  The avr's Harvard
> architecture may be faster, but the single memory space is vastly easier to
> deal with (no more complications with strings and data in flash).

I agree about the problems with putting strings and data in flash! 
While it's easy enough to do, it does make it difficult to write
general purpose, portable C that is not littered with special macros
and functions to specify flash or ram storage.

Isn't there a problem with the MSP430 and word/byte accessing? See the
last paragraph of this link from the msp-gcc documentation:

<http://mspgcc.sourceforge.net/manual/x213.html>

Perhaps this is just a limitation of the msp-gcc port.



-- 

John Devereux

"John Devereux" <jd1@devereux.me.uk> wrote in message
news:8765gcy5tp.fsf@cordelia.devereux.me.uk...
> "David Brown" <david@no.westcontrol.spam.com> writes:
>
> >
> > I've used both the AVR and the msp430, and I like both architectures -
but
> > the msp430 is definitely nicer to work with both in C and assembly.  The
avr
> > is more elegant in some ways, resulting in code that runs very close to
one
> > instruction per clock.  But the msp430 has a very flexible instruction
set
> > that has two big advantages over the avr, especially for C programing -
it
> > is 16-bit wide, and it has a single flat memory space.  The avr's
Harvard
> > architecture may be faster, but the single memory space is vastly easier
to
> > deal with (no more complications with strings and data in flash).
>
> I agree about the problems with putting strings and data in flash!
> While it's easy enough to do, it does make it difficult to write
> general purpose, portable C that is not littered with special macros
> and functions to specify flash or ram storage.
>
> Isn't there a problem with the MSP430 and word/byte accessing? See the
> last paragraph of this link from the msp-gcc documentation:
>
> <http://mspgcc.sourceforge.net/manual/x213.html>
>
> Perhaps this is just a limitation of the msp-gcc port.
>

No, that's exactly the same as with every other 16-bit (or more)
microcontroller - some peripherals need to be accessed as 8-bit and others
as 16-bit to work correctly, while others are freely accessible as either.
All you need to do is make sure the peripherals are declared properly (i.e.,
volatile unsigned chars or volatile unsigned ints), and the compiler fixes
things correctly.  It applies to all compilers - it's just that the msp-gcc
manual gives a lot of information about that sort of thing.

"David Brown" <david@no.westcontrol.spam.com> writes:

> "John Devereux" <jd1@devereux.me.uk> wrote in message
> news:8765gcy5tp.fsf@cordelia.devereux.me.uk...
> > Isn't there a problem with the MSP430 and word/byte accessing? See the
> > last paragraph of this link from the msp-gcc documentation:
> >
> > <http://mspgcc.sourceforge.net/manual/x213.html>
> >
> > Perhaps this is just a limitation of the msp-gcc port.
> >
> 
> No, that's exactly the same as with every other 16-bit (or more)
> microcontroller - some peripherals need to be accessed as 8-bit and others
> as 16-bit to work correctly, while others are freely accessible as either.
> All you need to do is make sure the peripherals are declared properly (i.e.,
> volatile unsigned chars or volatile unsigned ints), and the compiler fixes
> things correctly.  It applies to all compilers - it's just that the msp-gcc
> manual gives a lot of information about that sort of thing.


The text seemed to imply that the problem was more general than that,
but now I am not so sure! If it is just peripheral access that is
affected, then that in itself hardly stops the processor "supporting
strict C compliance" as the author stated. I read it to mean that
arbitrary structures in memory cannot be copied byte-by-byte.


-- 

John Devereux

"John Devereux" <jd1@devereux.me.uk> wrote in message
news:87zndlw62v.fsf@cordelia.devereux.me.uk...
> "David Brown" <david@no.westcontrol.spam.com> writes:
>
> > "John Devereux" <jd1@devereux.me.uk> wrote in message
> > news:8765gcy5tp.fsf@cordelia.devereux.me.uk...
> > > Isn't there a problem with the MSP430 and word/byte accessing? See the
> > > last paragraph of this link from the msp-gcc documentation:
> > >
> > > <http://mspgcc.sourceforge.net/manual/x213.html>
> > >
> > > Perhaps this is just a limitation of the msp-gcc port.
> > >
> >
> > No, that's exactly the same as with every other 16-bit (or more)
> > microcontroller - some peripherals need to be accessed as 8-bit and
others
> > as 16-bit to work correctly, while others are freely accessible as
either.
> > All you need to do is make sure the peripherals are declared properly
(i.e.,
> > volatile unsigned chars or volatile unsigned ints), and the compiler
fixes
> > things correctly.  It applies to all compilers - it's just that the
msp-gcc
> > manual gives a lot of information about that sort of thing.
>
>
> The text seemed to imply that the problem was more general than that,
> but now I am not so sure! If it is just peripheral access that is
> affected, then that in itself hardly stops the processor "supporting
> strict C compliance" as the author stated. I read it to mean that
> arbitrary structures in memory cannot be copied byte-by-byte.
>

I think it is just that C has no standard way of dealing with specialised
access for peripherals.  Even declaring things as volatile does not force
the compiler into specific behaviour, nor does it force the compiler to use
particular access widths.  So all the manual is saying is that the
peripherals in the msp430 cannot be accessed in a pure standard C way.
Arbitrary data memory (ram and flash) can be accessed arbitrarily.

"David Brown" <david@no.westcontrol.spam.com> writes:

> "John Devereux" <jd1@devereux.me.uk> wrote in message
> news:87zndlw62v.fsf@cordelia.devereux.me.uk...
> > The text seemed to imply that the problem was more general than that,
> > but now I am not so sure! If it is just peripheral access that is
> > affected, then that in itself hardly stops the processor "supporting
> > strict C compliance" as the author stated. I read it to mean that
> > arbitrary structures in memory cannot be copied byte-by-byte.
> >
> 
> I think it is just that C has no standard way of dealing with specialised
> access for peripherals.  Even declaring things as volatile does not force
> the compiler into specific behaviour, nor does it force the compiler to use
> particular access widths.  So all the manual is saying is that the
> peripherals in the msp430 cannot be accessed in a pure standard C way.
> Arbitrary data memory (ram and flash) can be accessed arbitrarily.

Well that's no problem then, that makes the msp430 a very nice "C
friendly" micro. A big improvement over the AVR in that respect I would
say, with its awkward handling of flash data.

 

-- 

John Devereux

"John Devereux" <jd1@devereux.me.uk> wrote in message
news:87vfo9vwa2.fsf@cordelia.devereux.me.uk...
> "David Brown" <david@no.westcontrol.spam.com> writes:
>
> > "John Devereux" <jd1@devereux.me.uk> wrote in message
> > news:87zndlw62v.fsf@cordelia.devereux.me.uk...
> > > The text seemed to imply that the problem was more general than that,
> > > but now I am not so sure! If it is just peripheral access that is
> > > affected, then that in itself hardly stops the processor "supporting
> > > strict C compliance" as the author stated. I read it to mean that
> > > arbitrary structures in memory cannot be copied byte-by-byte.
> > >
> >
> > I think it is just that C has no standard way of dealing with
specialised
> > access for peripherals.  Even declaring things as volatile does not
force
> > the compiler into specific behaviour, nor does it force the compiler to
use
> > particular access widths.  So all the manual is saying is that the
> > peripherals in the msp430 cannot be accessed in a pure standard C way.
> > Arbitrary data memory (ram and flash) can be accessed arbitrarily.
>
> Well that's no problem then, that makes the msp430 a very nice "C
> friendly" micro. A big improvement over the AVR in that respect I would
> say, with its awkward handling of flash data.
>

And that would lead us back to my original point - for C programming, the
msp430 feels more natural than the AVR.  In assembly, both work well, and I
find I write (or wrote - I use mostly C now on both chips) accurate code
with a very low error rate on both chips.

It's interesting to note how different compilers deal with the two chips -
in particular, comparing gcc to commercial embedded compiler specialists
like ImageCraft.  On the avr, gcc has to go through a number of hoops
(macros, attributes, etc.) to deal with flash-based data, while the msp430
port works smoothly as flash data is as accessible as any other data.
ImageCraft (and others) has a big advantage on the avr, in that they can
"cheat" and use keywords to give a smoother coding style (in this case,
"const" data is in flash).

There are other aspects of the msp430 that make it more C-friendly than the
avr - it has SP+index addressing modes, which make access to local
non-register data far smoother than the AVR (in which it is a PITA -
ImageCraft gets around it by dedicating a pointer register as a data stack
pointer).  It can also use any register as a pointer - the AVR has far too
few pointer-capable registers.

"Leon Heller" <aqzf13@dsl.pipex.com> wrote in message
news:3fe2a241$0$7013$cc9e4d1f@news.dial.pipex.com...
> I paid 7.75 GBP each (about $13) for 20 off LPC2106 from my distributor:
> Silica/Avnet, here in the UK. The pound is strong against the dollar at
> present, which helps.

I think the weak dollar would make it cheaper in the states.  The Philips
distributor
I use quoted me in the $7.50 (USD) range for the 2106 at one point.  Plus
the
FAEs are drooling over this part, therefore I have found them quick to
respond
and unsually knowledgeable about it...

Here's their page:
http://www.futureelectronics.com

--Keith