Remember the OP?  He needed 2 UARTs plus SPI.  In the MSP line, as 
some great sage said, [the offerings in the MSP line] "...lacked a 
crucial peripheral. ..."  :)  I just presented an option that
>>had<< 
the crucial peripheral.

Just as with the MSP "C" line, the AT90 AVR generation is all but 
extinct.  The new generation is roughly divided into "Tiny"s 
and "Mega"s.  Our group seldom does Tiny apps.  The Mega line is 
pretty rational in terms of price vs. size/features.  I can usually 
predict the distributor price of a new Mega by knowing the "size" and 
the cost of those already shipping.

Flipping back-and-forth from CISCy processors to the RISCy AVR is 
sometimes hard on the head, but in the end feels pretty much like a 
single-accumulator instruction set, but with 32 "accumulators".

Good luck on your projects.

Lee


--- In msp430@msp4..., onestone <onestone@b...> wrote:
> budfrog99 wrote:
> 
> > Ya don't use a dump truck as a lawn tractor, even if it
>>is<< 
wider.
> 
> Might have on the old Sydney property I lived on, it was a few 
hectares.
> 
> You don't suck stew through a straw either. Why dink about with an 
8 bit 
> architecture for example when doing a lot of RTC
calculations, or 
when 
> you need a  bit of trig, or when you need a
filter, FFT, etc etc 
etc. 
> Most of my apps are so full of calculations they
would be 
impossible 
> with an 8 bit device. In fact one product I have
was originally 
designed 
> in 1990, but its viability depended upon it being
extremely small, 
and 
> drawing very little current, whilst being able to
run some fairly 
> complex maths. It didn't become commercially viable to build this 
until 
> the advent of the low power versions of the PIC
(There was a very 
> specific maximum size, hence limitation on battery). It was crucial 
that 
> the device had at least 2 capture inputs, as it
used a digital 
sensor. 
> There was no suitably small AVR part that met
these specs. Even the 
PIC 
> meant that my first unit was severely restricted,
to 15 
transactions a 
> second, on just 2 sensors, plus a temperature
sensor for 
calibration. 
> The current MSP based version runs a total of 22
sensors, a GPS, RF 
> transceiver, and MMC card. All sensors are filtered. It performs 50 
> transactions a second, but is capable of 100. 4 things allow this. 
The 
> 16 bit architecture, allowing much faster
execution of maths 
routines. 
> The very low power consumption of the MSP430, the
10 available 
capture 
> channels, and advances in battery technology. I
doubt there is an 
AVR, 
> especially at the same price, that could meet
these conditions.
> 
> Now I'm not bagging the AVR here at all, I used to think they were 
> excllent parts, except, for my own specific needs, I never found 
one 
> that had everything I wanted. They were alwasy far
too much (I 
don't 
> mind a little overkill) or lacked a crucial
peripheral. I am a 
little 
> out of touch with what is what in the AVR world
now. I think they 
went a 
> little too much like Microchip has done. There are
confusingly far 
too 
> many parts in the family, many of them seem so
close to identical, 
and 
> not differentiated by price either. At present the
MSP is just 
slightly 
> the other way, but, they happen to fit my
immediate needs.
> 
> Al
> 
> > 
> > Lee
> > 
> > --- In msp430@msp4..., "microbit" <microbit@c...>
wrote:
> > 
> >>>>>--Re comparing prices:  look at the total 
> > 
> > microcontroller "job".  The
> > 
> >>>>>bit-width becomes irrelevant when doing the overall
system 
> > 
> > design,
> > 
> >>>Whoa! Trigger! How can that possibly be? The bit width, and, to

a 
> > 
> > lesser
> > 
> >>>extent the instruction length totally influences the overall 
> > 
> > system
> > 
> >>>design, unless, by overall system design you are talking about 
> > 
> > some very
> > 
> >>>high level abstract view of a solution. When it comes to the 
> > 
> > practical
> > 
> >>>design I'm afraid bit width is crucial in most
applications I've 
> > 
> > ever
> > 
> >>>been involved with. I approach designs for the MSP totally 
> > 
> > differently
> > 
> >>>that I do those for pure 8 bit micros. With the MSP I can 
> > 
> > immediately
> > 
> >>>start to factor in savings in transfer of 12 bit A/D values, 
> > 
> > faster, and
> > 
> >>>simplifed naths routines, optimisations of math routines using 
> > 
> > byte
> > 
> >>>swapping for example
> >>
> >>Have to completely agree with Al here, just to stir and flavour 
it 
> > 
> > a bit :-)
> > 
> >>In the last few years, if all system desings I did were to 
> > 
> > disregard the
> > 
> >>target
> >>machine instr width (and its peripherals) , most of them would 
have 
> > 
> > been a
> > 
> >>failure !
> >>(Not to mention that the CPU vs. MCU argument is so far out that 
> > 
> > it's not
> > 
> >>funny)
> >>
> >>Better start learning how to cook those Brussels Sprouts ! :-)
> >>
> >>-- Kris
> > 
> > 
> > 
> > 
> > .
> > 
> >  
> > 
> > ">http://docs.yahoo.com/info/terms/ 
> > 
> > 
> >

budfrog99 wrote:
> Remember the OP?  

Who's he? ;@} Hmmm we have strayed a little, as often happens.

> He needed 2 UARTs plus SPI.  In the MSP line, as 
> some great sage said, [the offerings in the MSP line] "...lacked a 
> crucial peripheral. ..."  :)  I just presented an option that
>>had<< 
> the crucial peripheral.
> 
> Just as with the MSP "C" line, the AT90 AVR generation is all but

> extinct.  The new generation is roughly divided into "Tiny"s 
> and "Mega"s.  Our group seldom does Tiny apps.  The Mega line is 
> pretty rational in terms of price vs. size/features.  I can usually 
> predict the distributor price of a new Mega by knowing the "size"
and 
> the cost of those already shipping.

What I forgot to add in my description of the current project was that 
it utilises dual, UARTs + SPI. The neat capture structure of the MSP 
makes implementing a software UART very efficient. The port pins used 
for this are standard throughout the MSP range, another plus, as they 
are used in the BSL mode. Where I use an RF transceiver I nearly always 
use the software UART on these pins. It simplifes having an Rf based 
reprogram facility, and also means less hassle if I want to switch from 
a conventional UART to, say, some bit timed protocol

> 
> Flipping back-and-forth from CISCy processors to the RISCy AVR is 
> sometimes hard on the head, but in the end feels pretty much like a 
> single-accumulator instruction set, but with 32 "accumulators".
> 

I would never have considered the AVR as being even remotely RISC like. 
Far too many complex instructions, too many complex addressing modes, 
the only thing RISCy is the clunky way it can only load /store through 
registers.

> Good luck on your projects.

And the same to you..

Al

Ya don't use a dump truck as a lawn tractor, even if it
>>is<< wider.

Lee

--- In msp430@msp4..., "microbit" <microbit@c...> wrote:
> > >>--Re comparing prices:  look at the
total 
microcontroller "job".  The
> > >>bit-width becomes irrelevant when
doing the overall system 
design,
> >
> > Whoa! Trigger! How can that possibly be? The bit width, and, to a 
lesser
> > extent the instruction length totally
influences the overall 
system
> > design, unless, by overall system design you
are talking about 
some very
> > high level abstract view of a solution. When
it comes to the 
practical
> > design I'm afraid bit width is crucial
in most applications I've 
ever
> > been involved with. I approach designs for
the MSP totally 
differently
> > that I do those for pure 8 bit micros. With
the MSP I can 
immediately
> > start to factor in savings in transfer of 12
bit A/D values, 
faster, and
> > simplifed naths routines, optimisations of
math routines using 
byte
> > swapping for example
> 
> Have to completely agree with Al here, just to stir and flavour it 
a bit :-)
> In the last few years, if all system desings I did
were to 
disregard the
> target
> machine instr width (and its peripherals) , most of them would have 
been a
> failure !
> (Not to mention that the CPU vs. MCU argument is so far out that 
it's not
> funny)
> 
> Better start learning how to cook those Brussels Sprouts ! :-)
> 
> -- Kris

> >>--Re comparing prices:  look at the total microcontroller
"job".  The
> >>bit-width becomes irrelevant when doing
the overall system design,
>
> Whoa! Trigger! How can that possibly be? The bit width, and, to a lesser
> extent the instruction length totally influences the overall system
> design, unless, by overall system design you are talking about some very
> high level abstract view of a solution. When it comes to the practical
> design I'm afraid bit width is crucial in most applications I've
ever
> been involved with. I approach designs for the MSP totally differently
> that I do those for pure 8 bit micros. With the MSP I can immediately
> start to factor in savings in transfer of 12 bit A/D values, faster, and
> simplifed naths routines, optimisations of math routines using byte
> swapping for example

Have to completely agree with Al here, just to stir and flavour it a bit :-)
In the last few years, if all system desings I did were to disregard the
target
machine instr width (and its peripherals) , most of them would have been a
failure !
(Not to mention that the CPU vs. MCU argument is so far out that it's not
funny)

Better start learning how to cook those Brussels Sprouts ! :-)

-- Kris

budfrog99 wrote:

> Ya don't use a dump truck as a lawn tractor,
even if it >>is<< wider.

Might have on the old Sydney property I lived on, it was a few hectares.

You don't suck stew through a straw either. Why dink about with an 8 bit 
architecture for example when doing a lot of RTC calculations, or when 
you need a  bit of trig, or when you need a filter, FFT, etc etc etc. 
Most of my apps are so full of calculations they would be impossible 
with an 8 bit device. In fact one product I have was originally designed 
in 1990, but its viability depended upon it being extremely small, and 
drawing very little current, whilst being able to run some fairly 
complex maths. It didn't become commercially viable to build this until 
the advent of the low power versions of the PIC (There was a very 
specific maximum size, hence limitation on battery). It was crucial that 
the device had at least 2 capture inputs, as it used a digital sensor. 
There was no suitably small AVR part that met these specs. Even the PIC 
meant that my first unit was severely restricted, to 15 transactions a 
second, on just 2 sensors, plus a temperature sensor for calibration. 
The current MSP based version runs a total of 22 sensors, a GPS, RF 
transceiver, and MMC card. All sensors are filtered. It performs 50 
transactions a second, but is capable of 100. 4 things allow this. The 
16 bit architecture, allowing much faster execution of maths routines. 
The very low power consumption of the MSP430, the 10 available capture 
channels, and advances in battery technology. I doubt there is an AVR, 
especially at the same price, that could meet these conditions.

Now I'm not bagging the AVR here at all, I used to think they were 
excllent parts, except, for my own specific needs, I never found one 
that had everything I wanted. They were alwasy far too much (I don't 
mind a little overkill) or lacked a crucial peripheral. I am a little 
out of touch with what is what in the AVR world now. I think they went a 
little too much like Microchip has done. There are confusingly far too 
many parts in the family, many of them seem so close to identical, and 
not differentiated by price either. At present the MSP is just slightly 
the other way, but, they happen to fit my immediate needs.

Al

> 
> Lee
> 
> --- In msp430@msp4..., "microbit" <microbit@c...> wrote:
> 
>>>>>--Re comparing prices:  look at the total 
> 
> microcontroller "job".  The
> 
>>>>>bit-width becomes irrelevant when doing the overall system 
> 
> design,
> 
>>>Whoa! Trigger! How can that possibly be? The bit width, and, to a 
> 
> lesser
> 
>>>extent the instruction length totally influences the overall 
> 
> system
> 
>>>design, unless, by overall system design you are talking about 
> 
> some very
> 
>>>high level abstract view of a solution. When it comes to the 
> 
> practical
> 
>>>design I'm afraid bit width is crucial in most applications
I've 
> 
> ever
> 
>>>been involved with. I approach designs for the MSP totally 
> 
> differently
> 
>>>that I do those for pure 8 bit micros. With the MSP I can 
> 
> immediately
> 
>>>start to factor in savings in transfer of 12 bit A/D values, 
> 
> faster, and
> 
>>>simplifed naths routines, optimisations of math routines using 
> 
> byte
> 
>>>swapping for example
>>
>>Have to completely agree with Al here, just to stir and flavour it 
> 
> a bit :-)
> 
>>In the last few years, if all system desings I did were to 
> 
> disregard the
> 
>>target
>>machine instr width (and its peripherals) , most of them would have 
> 
> been a
> 
>>failure !
>>(Not to mention that the CPU vs. MCU argument is so far out that 
> 
> it's not
> 
>>funny)
>>
>>Better start learning how to cook those Brussels Sprouts ! :-)
>>
>>-- Kris
> 
> 
> 
> 
> .
> 
>  
> 
> ">http://docs.yahoo.com/info/terms/ 
> 
> 
> 

budfrog99 wrote:
> 
> On to the second "cold one".
> 
> --It just ain't right Peter--you ain't playing by fair rules.
> Comparing your '1200 "ancient" project to current '430
models isn't
> right.  Maybe I should compare the newest AVRs to the "C"
> series '430s with no flash--you see what I mean.
> 

Fair!? are we supposed to be playing fair now? 
Actually, if any AVR could run at low power it should be the most basic
and simple device available, the 1200 is about as basic as you can get.

> Anyway, the 16-bit usefulness of the '430 may
be critical in some
> apps, but irrelevant in many microcontroller apps.  As some wit so
> aptly stated:  "...if an AVR had the necessary peripheral hardware on-
> chip which the MSP didn't have then I would use the AVR, but only
> because of the peripherals, not because of the CPU. "
> 

Yes, I would even use a PIC if it had just the right peripherals
for the job that no other chip came near, I mean you have to don't you?
Brussel sprouts, brussel sprouts.

> Think of the CPU architecture as just
"peripheral hardware".  :)
> 

Sorry, can't, I don't write volumes of code in "peripheral
language",
but I suppose if you program in C you could distance yourself from
the CPU architecture, but then you could use a PIC and not care.

> --Re comparing prices:  look at the total
microcontroller "job".  The
> bit-width becomes irrelevant when doing the overall system design,
> unless that particular "peripheral hardware" is needed.  I stand
> behind the cost effectiveness of the AVR Mega8 in microcontroller
> apps, and that TI has nothing to match it.  Sure you could blow it
> away in certain processing apps, but those are
micro>>processor<<
> tasks, not micro>>controller<< apps.

Look Lee, I do want to keep on taunting you but I really am ready to
listen to informed viewpoints. Just don't expect me to be nodding
my head and be busting to use an AVR in my next project.

BTW, this is the msp430 group, don't expect warm welcomes when you
burst into camp laden with AVRs. Which reminds me, some may think that 
Australians all drink Fosters or VB but I can tell you that they
would be one of the last beers I'd drink, weak southern woose beer, 
excepting Carlton Crown of course. Someone, gimme a XXXX or a Hahn!!!.

> 
> --Certainly the '430s have certain features that I like more than on
> the AVRs.  I've yet to find an app [done by my org] where I "ran
out"
> of PWM channels--6 were more than enough.  Same with input capture (a
> couple) and pin-change interrupts (up to a dozen or so).  The current
> generation has more timers than I need--usually 3 or 4.  And SPI is
> on all but the Tinys,; those types of apps I don't usually get into.
> 

SPI seems to be a favourite with the Motorola crowd, I almost always
favoured I2C which I mostly implemented in software. SPI does have its
place when some multi-megahertz serial transfer needs to take place.
It is after all just a slightly glorified shift register.

> --My latest app does indeed blink an LED, and a
bi-color one at
> that.  :)

Luv it :)

>
http://www.automatictiming.com/pages_div/phasevoltagesection/phasevolt
> age.html#MPA
> In addition, a single AVR running at 7.3728 MHz is doing:  3-phase AC
> voltage/current/power monitoring; 

I certainly hope it can do that.

> a dozen programmable trip and alarm
> points; 6 switch inputs; 2x16 VFD display; output load relays;

Not an issue in any micro really, now about those gas lights....


Peter Jakacki - on to the next round (of beer)

	I'm pretty sure brussels sprouts are the part of the plant
you're supposed to 
throw away.

	--jc

	"We've had sushi in Alabama for years.  We call it
'bait'."

On Friday 28 November 2003 11:19 am, microbit wrote:
>  > Peter Jakacki wrote:
>  > > budfrog99 wrote:
>  > > Trying to get me to use an AVR is like trying to get a
>  > > kid to eat his brussel sprouts, it is possible, just not easy.
>  > >
>  > > ho ho ho ho
>  >
>  > But I always liked Brussels perhaps I really am contrary! maybe
that's
>  > it, it all started when I was very young Doctor. My Mother fed me
>  > brussels and they were good...
>  >
>  > > --
>  > > Peter Jakacki
>
>  Ho ho,
>
>  I wholehartedly agree with Peter.
>  I'm originally Belgian and I _loved_ Brussels sprouts
>  (proviso they're cooked the proper way).
>
>  The only time they're "yucky", is because they've been
totally and utterly
>  cooked the wrong way.
>  Yet another sigma...... :-)
>
>  -- Kris
>
>
>
> Yahoo! Groups Sponsor
>
>
>
>
>
>
>  .
>
>
>
>  

> Peter Jakacki wrote:
> > budfrog99 wrote:
> > Trying to get me to use an AVR is like trying to get a
> > kid to eat his brussel sprouts, it is possible, just not easy.
> > 
> > ho ho ho ho
> 
> But I always liked Brussels perhaps I really am contrary! maybe that's

> it, it all started when I was very young Doctor. My Mother fed me 
> brussels and they were good...
> 
> > 
> > --
> > Peter Jakacki

Ho ho,

I wholehartedly agree with Peter.
I'm originally Belgian and I _loved_ Brussels sprouts
(proviso they're cooked the proper way).

The only time they're "yucky", is because they've been
totally and utterly
cooked the wrong way.
Yet another sigma...... :-)

-- Kris

On to the second "cold one".

--It just ain't right Peter--you ain't playing by fair rules.  
Comparing your '1200 "ancient" project to current '430
models isn't 
right.  Maybe I should compare the newest AVRs to the "C" 
series '430s with no flash--you see what I mean.

Anyway, the 16-bit usefulness of the '430 may be critical in some 
apps, but irrelevant in many microcontroller apps.  As some wit so 
aptly stated:  "...if an AVR had the necessary peripheral hardware on-
chip which the MSP didn't have then I would use the AVR, but only 
because of the peripherals, not because of the CPU. "

Think of the CPU architecture as just "peripheral hardware".  :)

--Re comparing prices:  look at the total microcontroller "job".  The 
bit-width becomes irrelevant when doing the overall system design, 
unless that particular "peripheral hardware" is needed.  I stand 
behind the cost effectiveness of the AVR Mega8 in microcontroller 
apps, and that TI has nothing to match it.  Sure you could blow it 
away in certain processing apps, but those are micro>>processor<< 
tasks, not micro>>controller<< apps.

--Certainly the '430s have certain features that I like more than on 
the AVRs.  I've yet to find an app [done by my org] where I "ran
out" 
of PWM channels--6 were more than enough.  Same with input capture (a 
couple) and pin-change interrupts (up to a dozen or so).  The current 
generation has more timers than I need--usually 3 or 4.  And SPI is 
on all but the Tinys,; those types of apps I don't usually get into.

--My latest app does indeed blink an LED, and a bi-color one at 
that.  :)  
http://www.automatictiming.com/pages_div/phasevoltagesection/phasevolt
age.html#MPA
In addition, a single AVR running at 7.3728 MHz is doing:  3-phase AC 
voltage/current/power monitoring; a dozen programmable trip and alarm 
points; 6 switch inputs; 2x16 VFD display; output load relays; 
--- In msp430@msp4..., Peter Jakacki <cyb@i...> wrote:
> budfrog99 wrote:
> > 
> > "Lee (budfrog99) mentioned using an AVR but besides using an 
inferior
> > 8-bit architecture the AVR's only have
one uart (except high-end
> > mega128 $$$) and maybe one SPI. Sorry Lee, been there, done that,
> > definitely not an answer."
> > 
> > I hate to start a processor-family Holy Crusade, but it
>>is<< the
> > holiday season after all.  :)
> > 
> > --AVRs with more than one uart include Mega103 & Mega161 
(obsolete),
> > Mega162, Mega64, and Mega128.
> > 
> 
> Lee,
> 	Sure, I like a heated debate just like the next guy, but I 
usually try
> to do it over a cold beer, but since it is the
holiday season .... I
> haven't ruled out AVRs yet because I'm way too familiar with
them, 
but
> maybe not so familiar with some of the newer
variants. I've been 
using
> them since the first engineering samples were
available with the 
1200
> and 8515. But like Al and others I'm mostly
an asm man and whereas 
many
> C programmers don't see the kludgieness of
the load/store 8-bits at 
a
> time architecture, it sure bugs me, but not
anywhere near as much as
> PICs which btw do have their place, like flashing lights and timing
> things in seconds etc ;)
> 
> 
> > --Mega128 prices have dropped, and aren't much more than (say)
> > a '449.  Mega64 is about the same price as a '449.  Mega162
about
> > half that.
> > 
> 
> 8-bit CPU for 'about the same' or 'not much more' as a
16-bit CPU, 
wow!
> 
> > --Every sizeable AVR has a separate SPI & I2C in addition to the 
UART
> > (s).  Yes, Peter, only one--how many SPIs do
you need on one
> > processor, anyway?  [I guess the quick answer would be to be a 
master
> > and a slave within a bigger system??]
> 
> How many? Did I say "maybe one SPI", that is as in one or none.
> 
> > 
> > --Performance is such a subjective thing.  I don't usually run 
out of
> > gas on AVR apps even at relatively modest
clock rates.
> 
> Flashing lights again, or are they "gas" lights? ;)
> 
> > 
> > --When I need to design a system from the ground up for low power
> > consumption, I start with the '430s.  Why fight to get low power
> > consumption from an AVR when it is in the genes of the '430.
> > 
> 
> True, and I had weird things happen when I tried to run an early AVR
> 1200 off a 32K rock for low power, it just doesn't like them. The
> datasheet says it ran down to DC but didn't mention the 
unsuitability of
> the oscillator with tuning fork crystals. Then I
clocked it direct 
from
> a PIC12C509 (quick and easy clock source) and
still had weird things
> happen. Ended up running at 4Mhz and using the watchdog to wake it 
up
> for brief intervals.
> 
> > --For some things I prefer the AVR implementation.  Timers are one
> > area.
> > 
> > --'430 has >>no<< model to compete
price/features/performance with
> > the AVR Mega8.
> > 
> 
> Mmmm, if an AVR had the necessary peripheral hardware on-chip which 
the
> MSP didn't have then I would use the AVR, but
only because of the
> peripherals, not because of the CPU. But then again, I'd rather use 
a
> H8S if possible. Trying to get me to use an AVR is
like trying to 
get a
> kid to eat his brussel sprouts, it is possible,
just not easy.
> 
> ho ho ho ho
> 
> --
> Peter Jakacki
> 
> ----DISCLAIMER------
> 1. If I didn't insult you I probably meant to.
> 2. My opinion isn't any better than anyone elses, it's just that
I'm
> right.
> 3. Disputes may be settled over a cold beer or two.
> 4. In the event an agreement cannot be reached the two parties 
should
> drink more beer.

Peter Jakacki wrote:
> budfrog99 wrote:
> 
>>On to the second "cold one".

...

>>Think of the CPU architecture as just
"peripheral hardware".  :)
>>
> 
> 
> Sorry, can't, I don't write volumes of code in "peripheral
language",
> but I suppose if you program in C you could distance yourself from
> the CPU architecture, but then you could use a PIC and not care.

Crashing in with Hob nail boots.

Impossible. The peripherals are peripheral to the CPU, what are we to 
consider the cpu peripheral to, I know, the instructions set, ah, but, 
hang on, that is just a way of describing the cpu architecture in a 
human digestible form. Naw! Sorry! Can't figure out what I should 
consider the CPu peripheral to.

>>--Re comparing prices:  look at the total
microcontroller "job".  The
>>bit-width becomes irrelevant when doing the overall system design,

Whoa! Trigger! How can that possibly be? The bit width, and, to a lesser 
extent the instruction length totally influences the overall system 
design, unless, by overall system design you are talking about some very 
high level abstract view of a solution. When it comes to the practical 
design I'm afraid bit width is crucial in most applications I've ever 
been involved with. I approach designs for the MSP totally differently 
that I do those for pure 8 bit micros. With the MSP I can immediately 
start to factor in savings in transfer of 12 bit A/D values, faster, and 
simplifed naths routines, optimisations of math routines using byte 
swapping for example


>>unless that particular "peripheral
hardware" is needed.  I stand
>>behind the cost effectiveness of the AVR Mega8 in microcontroller
>>apps, and that TI has nothing to match it.  Sure you could blow it
>>away in certain processing apps, but those are
micro>>processor<<
>>tasks, not micro>>controller<< apps.

The underlying implication here, perhaps fogged by more than the two 
beers you're admitting to, (unless of course you're drinking real
beer, 
not some american soft drink) is that anything requiring a bit of maths 
is a microprocessor application,. That is so far off the beam you'd be 
drummed out of the navy, no more rations of rum for you my boy!

Microprocessors are typically cpu cores with minimal peripherals, 
typically address and clock units, that are typically, but not 
exclusively optimised for data manipulation. Microcontrollers are cpu 
cores with a varying level of peripherals optimised, typically for real 
world interface. All my tasks are real world interface, and most require 
at least some level of maths. I can't imagine you do AD without 
bothering to filter or otherwise manipulate the data. Or that you never 
have to normalise readings against calibration data.

> 
> Look Lee, I do want to keep on taunting you but I really am ready to
> listen to informed viewpoints. Just don't expect me to be nodding
> my head and be busting to use an AVR in my next project.
> 
> BTW, this is the msp430 group, don't expect warm welcomes when you
> burst into camp laden with AVRs. Which reminds me, some may think that 
> Australians all drink Fosters or VB but I can tell you that they
> would be one of the last beers I'd drink, weak southern woose beer, 
> excepting Carlton Crown of course. Someone, gimme a XXXX or a Hahn!!!.

Throw me a real Warsteiner any day, not the watered down stuff they 
export..

Al