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

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)

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

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

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

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

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