Hi,

I have problem with software UART on F149 uP.
Why software? I have big project, and USART1 is used at this time, 
and it always must be enabled, USART0 i use too, but in SPI mode, and 
this one must be enabled all time too.
I need an second UART (not SPI).
Help!


Any suggestions ?

Cris

> Any suggestions ?

Use an Atmel AVR where the SPI & I2C interfaces are not bound to the 
UART(s).

Lee

--- In msp430@msp4..., Krzysztof Gawry <kgprogramer@y...> 
wrote:
> Hi,
> 
> I have problem with software UART on F149 uP.
> Why software? I have big project, and USART1 is used at this time, 
> and it always must be enabled, USART0 i use too, but in SPI mode, 
and 
> this one must be enabled all time too.
> I need an second UART (not SPI).
> Help!
> 
> 
> Any suggestions ?
> 
> Cris

Cris,
	You didn't mention what problems you are having with the software uart,
is it the same as the bootstrap uart or do you have a different
implementation? Also, what speeds are you operating the s/w uart and the
spi at?

You could also look at implementing the spi in software instead of the
uart in software if the operating speed of the spi doesn't need to be
too high.

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.

--
Peter Jakacki


Krzysztof Gawry wrote:
> I have problem with software UART on F149 uP.
> Why software? I have big project, and USART1 is used at this time,
> and it always must be enabled, USART0 i use too, but in SPI mode, and
> this one must be enabled all time too.
> I need an second UART (not SPI).
> Help!

Hi Lee, it's really odd that you favour the AVR for timers, it was 
alwasy the one thing, that to me, let them down, never enough 
capture/compares. Even the lower end PIC's had 2, often the equivalent 
AVR would only have 1, certainly I never found an AVR with 10 channels 
of capture compare/pwm.

Al

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.
> 
> --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.
> 
> --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??]
> 
> --Performance is such a subjective thing.  I don't usually run out of 
> gas on AVR apps even at relatively modest clock rates.
> 
> --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.
> 
> --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.
> 
> Lee
> 
> 
> --- In msp430@msp4..., Peter Jakacki <cyb@i...> wrote:
> 
>>Cris,
>>	You didn't mention what problems you are having with the 
> 
> software uart,
> 
>>is it the same as the bootstrap uart or do you have a different
>>implementation? Also, what speeds are you operating the s/w uart 
> 
> and the
> 
>>spi at?
>>
>>You could also look at implementing the spi in software instead of 
> 
> the
> 
>>uart in software if the operating speed of the spi doesn't need to 
> 
> be
> 
>>too high.
>>
>>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.
>>
>>--
>>Peter Jakacki
>>
>>
>>Krzysztof Gawry wrote:
>>
>>>I have problem with software UART on F149 uP.
>>>Why software? I have big project, and USART1 is used at this time,
>>>and it always must be enabled, USART0 i use too, but in SPI mode, 
> 
> and
> 
>>>this one must be enabled all time too.
>>>I need an second UART (not SPI).
>>>Help!
> 
> 
> 
> 
> .
> 
>  
> 
> ">http://docs.yahoo.com/info/terms/ 
> 
> 
> 

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

my personal favourites-

"Everything you know is wrong"

or from my old office door -

"The mistakes I make are errors in your perception of reality"

Al

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

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

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

--Performance is such a subjective thing.  I don't usually run out of 
gas on AVR apps even at relatively modest clock rates.

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

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

Lee


--- In msp430@msp4..., Peter Jakacki <cyb@i...> wrote:
> Cris,
> 	You didn't mention what problems you are having with the 
software uart,
> is it the same as the bootstrap uart or do you
have a different
> implementation? Also, what speeds are you operating the s/w uart 
and the
> spi at?
> 
> You could also look at implementing the spi in software instead of 
the
> uart in software if the operating speed of the spi
doesn't need to 
be
> too high.
> 
> 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.
> 
> --
> Peter Jakacki
> 
> 
> Krzysztof Gawry wrote:
> > I have problem with software UART on F149 uP.
> > Why software? I have big project, and USART1 is used at this time,
> > and it always must be enabled, USART0 i use too, but in SPI mode, 
and
> > this one must be enabled all time too.
> > I need an second UART (not SPI).
> > Help!

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

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