Hi,
What is the maximum speed of Timer UART without using external crystal.
Can i get a speed of 19200bps without any problem(just uisng DCO), I
have to use it for RS232 communication.
And also what is the code size to implement a Timer UART.
Thankyou ...
Timer UART
Started by ●August 5, 2008
Reply by ●August 5, 20082008-08-05
Paddu,
That is a great question.
The code size will of course depend on what features you add, but a few
hundred bytes would be reasonable. We show how to do this in detail in
our book MSP430 State Machine Programming.
http://www.amazon.com/gp/redirect.html?ie=UTF8&location=http%3A%2F%
2Fwww.amazon.com%2FMSP430-State-Machine-Programming-ES2274%2Fdp%
2F0975475924%3Fie%3DUTF8%26s%3Dbooks%26qid%3D1214397954%26sr%3D8-
1&tag=softcom-20&linkCode=ur2&camp89&creative25
If that link doesn't work, then go to amazon and search for MSP430 as
one word, and choose our green and white title from the top of the list.
You can run the UART, or a timer-based implementation of one, at 19200
from the DCO, but of course that limits the low power mode. Some
examples you will see on the web suggest tuning the DCO against a low
frequency crystal (32kHz, for example), but we think a better approach
is to simply monitor the DCO-based SMCLK against a 32kHz ACLK, and then
adjust the UART divisor instead. This avoids all the DCO tuning
nonlinearities, and lets you spend the code you save on better UART
features ;-).
Either way, you will use another timer channel to monitor SMCLK against
ACLK, which can trigger certain capture/compare channels, see the
datasheet. While we don't give a specific example for monitoring SMCLK
in our book, we do brush by this concept along the way.
That is a great question.
The code size will of course depend on what features you add, but a few
hundred bytes would be reasonable. We show how to do this in detail in
our book MSP430 State Machine Programming.
http://www.amazon.com/gp/redirect.html?ie=UTF8&location=http%3A%2F%
2Fwww.amazon.com%2FMSP430-State-Machine-Programming-ES2274%2Fdp%
2F0975475924%3Fie%3DUTF8%26s%3Dbooks%26qid%3D1214397954%26sr%3D8-
1&tag=softcom-20&linkCode=ur2&camp89&creative25
If that link doesn't work, then go to amazon and search for MSP430 as
one word, and choose our green and white title from the top of the list.
You can run the UART, or a timer-based implementation of one, at 19200
from the DCO, but of course that limits the low power mode. Some
examples you will see on the web suggest tuning the DCO against a low
frequency crystal (32kHz, for example), but we think a better approach
is to simply monitor the DCO-based SMCLK against a 32kHz ACLK, and then
adjust the UART divisor instead. This avoids all the DCO tuning
nonlinearities, and lets you spend the code you save on better UART
features ;-).
Either way, you will use another timer channel to monitor SMCLK against
ACLK, which can trigger certain capture/compare channels, see the
datasheet. While we don't give a specific example for monitoring SMCLK
in our book, we do brush by this concept along the way.
Reply by ●August 5, 20082008-08-05
Can you elaborate a bit? I've used TI code to implement a 9600 baud,
bit-banged (timer-based) UART on a MSP430F1121a (pretty limited) using
DCO.
I'm wondering how reliable this is - or whether I should just use a
faster crystal (I'm using a 32). My application spends most of its
time in Low Power mode (would a faster crystal take significantly more
power?), but needs quick response when an event occurs - which could
come via either the UART (host command) or from a Port event (external
device.)
I do have your book, so feel free to indicate page#/chapter/etc.
(also, I'm using two channels on ACLK/Timer_A - one for the UART and
one as a timeout watchdog.
TIA
--- In m..., "Tom Baugh" wrote:
>
You can run the UART, or a timer-based implementation of one, at 19200
> from the DCO, but of course that limits the low power mode. Some
> examples you will see on the web suggest tuning the DCO against a low
> frequency crystal (32kHz, for example), but we think a better approach
> is to simply monitor the DCO-based SMCLK against a 32kHz ACLK, and then
> adjust the UART divisor instead. This avoids all the DCO tuning
> nonlinearities, and lets you spend the code you save on better UART
> features ;-).
>
> Either way, you will use another timer channel to monitor SMCLK against
> ACLK, which can trigger certain capture/compare channels, see the
> datasheet. While we don't give a specific example for monitoring SMCLK
> in our book, we do brush by this concept along the way.
>
bit-banged (timer-based) UART on a MSP430F1121a (pretty limited) using
DCO.
I'm wondering how reliable this is - or whether I should just use a
faster crystal (I'm using a 32). My application spends most of its
time in Low Power mode (would a faster crystal take significantly more
power?), but needs quick response when an event occurs - which could
come via either the UART (host command) or from a Port event (external
device.)
I do have your book, so feel free to indicate page#/chapter/etc.
(also, I'm using two channels on ACLK/Timer_A - one for the UART and
one as a timeout watchdog.
TIA
--- In m..., "Tom Baugh" wrote:
>
You can run the UART, or a timer-based implementation of one, at 19200
> from the DCO, but of course that limits the low power mode. Some
> examples you will see on the web suggest tuning the DCO against a low
> frequency crystal (32kHz, for example), but we think a better approach
> is to simply monitor the DCO-based SMCLK against a 32kHz ACLK, and then
> adjust the UART divisor instead. This avoids all the DCO tuning
> nonlinearities, and lets you spend the code you save on better UART
> features ;-).
>
> Either way, you will use another timer channel to monitor SMCLK against
> ACLK, which can trigger certain capture/compare channels, see the
> datasheet. While we don't give a specific example for monitoring SMCLK
> in our book, we do brush by this concept along the way.
>
Reply by ●August 5, 20082008-08-05
Thanks for asking! Chapter 10 goes into gory detail about the TimerB
UART from ACLK, but it could work from TimerA just as well and/or using
SMCLK. This chapter also has some analyses of the timings involved.
The exercises for that chapter also fill things in some.
On page 101 we mention that switching to the DCO would require changing
the default low power mode, including the work required to tune the DCO
(or, better, monitoring the DCO). Chapter 5 exercises #10 and #12 give
more detail about switching low power modes and triggering a
capture/compare from ACLK.
By counting the number of SMCLKs between ACLK edges, you can
extrapolate the current DCO frequency, which is stable enough over
intervals measured in seconds. You could then divide the DCO
measurement by the desired baud rate to get the number of SMCLK ticks
per bit. Since the baud rate is fixed (or one of a very few fixed
options), you can code the "divide by baud rate" portion as a
multiplication by the equivalent inverse encoded as a fixed-point
fraction (which can be done rapidly using bit math even on an F1121A).
There is a tradeoff between DCO frequency and accuracy, of course. For
exammple, a 1.6 MHz DCO will have about fifty ticks per ACLK, while a 4
MHz DCO will have about 122 ticks per. The former will already be two
percent uncertain, while the latter will be less than one percent off.
You can accumulate counts over several ACLK cycles in either case to
come up with a synthesized average. As long as this average is
performed over consecutive ACLKs, the average will be legitimate.
Regardless, assume you are using 32 kHz, and you think your DCO will be
somewhere between 4 MHz and 6 MHz (the exact range is unimportant), and
the actual DCO rate is 4.25 MHz (unknown to you). You measure 129
SMCLKs per ACLK (the exact value is 129.7). You could also add all
kinds of Z-domain filters to this process of course, which I ignore
here. Also, eight bits holds all frequencies up to 32768 x 255 = 8.3
MHz, plenty for our F1121A example (F2xx fans adjust accordingly).
Now the fun starts. Each bit interval is defined as:
Tbit = (32768 ACLK/sec * 129 SMCLK/ACLK )/(9600 bit/sec)
= (32768/9600) * 129 SMCLK/bit
129 is something you measured on the fly, while 32768/9600 is a fixed
application parameter. We can rewrite the 32768/9600 term as a fixed
multiple:
3.41333...
Which is 3x + 0.41333..., or
11.0110 1001 1101
as a fixed-point multiple. 11.0110 101 is 3.4140625, with an error of
only 0.02%, while 11.0110 1 is 3.40625, only 0.2% off. Let's choose
the latter and use some registers on the F1121A:
// R12 = SMCLK measurement, 1 to 255
// R13 for us to use.
mov R12,R13 // R13 = x1, 1 cyc
rla R13 // R13 = x2, 2 cyc
rla R13 // R13 = x4, 3 cyc
add R13,R12 // R12 = x5, 4 cyc
rla R13 // R13 = x8, 5 cyc
add R13,R12 // R12 = x13, 6 cyc
rla R13 // R13 = x16, 7 cyc
rla R13 // R13 = x32, 8 cyc
add R13,R12 // R12 = x45, 9 cyc
rla R13 // R13 = x64, 10 cyc
add R13,R12 // R12 = x109, 11 cyc
// Round off by adding 0x0010 in two cycles
add #0x0008,R12 // R12 = x109+, 12 cyc
add #0x0008,R12 // R12 = x109+, 13 cyc
// Now shift back down by dividing by 32
rra R12 // R12 = x54.5+, 14 cyc
rra R12 // R12 = x27.25+, 15 cyc
rra R12 // R12 = x13.625+, 16 cyc
rra R12 // R12 = x6.8125+, 17 cyc
rra R12 // R12 = x3.40625+, 18 cyc
By the way, chapter 10 assumes that the desired baud rate is an
inconvenient divisor of a low-frequency tick, so the entries for
individual bits vary to handle accumulating errors. With the DCO,
these error accumulations can be ignored more easily (unless you choose
a ridiculously high bit rate), so that table can be replaced by a RAM
variable holding the current active bit tick value. So, R12, from
above, is your full tick interval, while rra R12 is your half-bit time.
In your case, if you only want a fixed 9600 baud, I would use a 38.4
kHz crystal (as in #SE3315 on Digikey) and ignore the DCO entirely.
Tom
UART from ACLK, but it could work from TimerA just as well and/or using
SMCLK. This chapter also has some analyses of the timings involved.
The exercises for that chapter also fill things in some.
On page 101 we mention that switching to the DCO would require changing
the default low power mode, including the work required to tune the DCO
(or, better, monitoring the DCO). Chapter 5 exercises #10 and #12 give
more detail about switching low power modes and triggering a
capture/compare from ACLK.
By counting the number of SMCLKs between ACLK edges, you can
extrapolate the current DCO frequency, which is stable enough over
intervals measured in seconds. You could then divide the DCO
measurement by the desired baud rate to get the number of SMCLK ticks
per bit. Since the baud rate is fixed (or one of a very few fixed
options), you can code the "divide by baud rate" portion as a
multiplication by the equivalent inverse encoded as a fixed-point
fraction (which can be done rapidly using bit math even on an F1121A).
There is a tradeoff between DCO frequency and accuracy, of course. For
exammple, a 1.6 MHz DCO will have about fifty ticks per ACLK, while a 4
MHz DCO will have about 122 ticks per. The former will already be two
percent uncertain, while the latter will be less than one percent off.
You can accumulate counts over several ACLK cycles in either case to
come up with a synthesized average. As long as this average is
performed over consecutive ACLKs, the average will be legitimate.
Regardless, assume you are using 32 kHz, and you think your DCO will be
somewhere between 4 MHz and 6 MHz (the exact range is unimportant), and
the actual DCO rate is 4.25 MHz (unknown to you). You measure 129
SMCLKs per ACLK (the exact value is 129.7). You could also add all
kinds of Z-domain filters to this process of course, which I ignore
here. Also, eight bits holds all frequencies up to 32768 x 255 = 8.3
MHz, plenty for our F1121A example (F2xx fans adjust accordingly).
Now the fun starts. Each bit interval is defined as:
Tbit = (32768 ACLK/sec * 129 SMCLK/ACLK )/(9600 bit/sec)
= (32768/9600) * 129 SMCLK/bit
129 is something you measured on the fly, while 32768/9600 is a fixed
application parameter. We can rewrite the 32768/9600 term as a fixed
multiple:
3.41333...
Which is 3x + 0.41333..., or
11.0110 1001 1101
as a fixed-point multiple. 11.0110 101 is 3.4140625, with an error of
only 0.02%, while 11.0110 1 is 3.40625, only 0.2% off. Let's choose
the latter and use some registers on the F1121A:
// R12 = SMCLK measurement, 1 to 255
// R13 for us to use.
mov R12,R13 // R13 = x1, 1 cyc
rla R13 // R13 = x2, 2 cyc
rla R13 // R13 = x4, 3 cyc
add R13,R12 // R12 = x5, 4 cyc
rla R13 // R13 = x8, 5 cyc
add R13,R12 // R12 = x13, 6 cyc
rla R13 // R13 = x16, 7 cyc
rla R13 // R13 = x32, 8 cyc
add R13,R12 // R12 = x45, 9 cyc
rla R13 // R13 = x64, 10 cyc
add R13,R12 // R12 = x109, 11 cyc
// Round off by adding 0x0010 in two cycles
add #0x0008,R12 // R12 = x109+, 12 cyc
add #0x0008,R12 // R12 = x109+, 13 cyc
// Now shift back down by dividing by 32
rra R12 // R12 = x54.5+, 14 cyc
rra R12 // R12 = x27.25+, 15 cyc
rra R12 // R12 = x13.625+, 16 cyc
rra R12 // R12 = x6.8125+, 17 cyc
rra R12 // R12 = x3.40625+, 18 cyc
By the way, chapter 10 assumes that the desired baud rate is an
inconvenient divisor of a low-frequency tick, so the entries for
individual bits vary to handle accumulating errors. With the DCO,
these error accumulations can be ignored more easily (unless you choose
a ridiculously high bit rate), so that table can be replaced by a RAM
variable holding the current active bit tick value. So, R12, from
above, is your full tick interval, while rra R12 is your half-bit time.
In your case, if you only want a fixed 9600 baud, I would use a 38.4
kHz crystal (as in #SE3315 on Digikey) and ignore the DCO entirely.
Tom
Reply by ●August 5, 20082008-08-05
You've given me a bunch to study/think about. A couple things did
jump out:
- The chip I'm using doesn't have a Timer B, and I'm not sure it has
3 channels on Timer A - or if it did, it looked complicated enough to
tax my skill level
- you talk of DCO being stable for seconds - my application is
usually around a minute between events, and can go for hours. I think
I'm running DCO at about 2MHz (MSP430x11x1_ta_uart9600.c). Sounds
like to use DCO, I would need to set a timer to periodically
recalibrate (I considered that, but that's where the need for a third
timer came in.)
The 38.4kHz crystal sounds great!
Assuming this code fragment(from msp430x11x1_ta_uart2400.c), what
would I need to change to make it work at 9600 with the 38.4kHz crystal?
--------
#define RXD 0x04 // RXD on P2.2
#define TXD 0x02 // TXD on P1.1
// Conditions for 2400 Baud SW UART, ACLK = 32768
#define Bitime_5 0x06 // ~ 0.5 bit length +
small adjustment
#define Bitime 0x0E // 427us bit length ~ 2341
baud
unsigned int RXTXData;
unsigned char BitCnt;
void TX_Byte (void);
void RX_Ready (void);
#include
void main (void)
{
WDTCTL = WDTPW + WDTHOLD; // Stop watchdog timer
CCTL0 = OUT; // TXD Idle as Mark
TACTL = TASSEL_1 + MC_2; // ACLK, continuous mode
P1SEL = TXD; // P1.1/TA0 for TXD function
P1DIR = TXD; // TXD output on P1
P2SEL = RXD; // P2.2/TA0 as RXD input
// Mainloop
for (;;)
{
RX_Ready(); // UART ready to RX one Byte
_BIS_SR(LPM3_bits + GIE); // Enter LPM3 w/ interr
until char RXed
TX_Byte(); // TX Back RXed Byte Received
}
}
for various baud rates>
--------
TIA
--- In m..., "Tom Baugh" wrote:
>
> Thanks for asking! Chapter 10 goes into gory detail about the TimerB
In your case, if you only want a fixed 9600 baud, I would use a 38.4
> kHz crystal (as in #SE3315 on Digikey) and ignore the DCO entirely.
>
> Tom
>
jump out:
- The chip I'm using doesn't have a Timer B, and I'm not sure it has
3 channels on Timer A - or if it did, it looked complicated enough to
tax my skill level
- you talk of DCO being stable for seconds - my application is
usually around a minute between events, and can go for hours. I think
I'm running DCO at about 2MHz (MSP430x11x1_ta_uart9600.c). Sounds
like to use DCO, I would need to set a timer to periodically
recalibrate (I considered that, but that's where the need for a third
timer came in.)
The 38.4kHz crystal sounds great!
Assuming this code fragment(from msp430x11x1_ta_uart2400.c), what
would I need to change to make it work at 9600 with the 38.4kHz crystal?
--------
#define RXD 0x04 // RXD on P2.2
#define TXD 0x02 // TXD on P1.1
// Conditions for 2400 Baud SW UART, ACLK = 32768
#define Bitime_5 0x06 // ~ 0.5 bit length +
small adjustment
#define Bitime 0x0E // 427us bit length ~ 2341
baud
unsigned int RXTXData;
unsigned char BitCnt;
void TX_Byte (void);
void RX_Ready (void);
#include
void main (void)
{
WDTCTL = WDTPW + WDTHOLD; // Stop watchdog timer
CCTL0 = OUT; // TXD Idle as Mark
TACTL = TASSEL_1 + MC_2; // ACLK, continuous mode
P1SEL = TXD; // P1.1/TA0 for TXD function
P1DIR = TXD; // TXD output on P1
P2SEL = RXD; // P2.2/TA0 as RXD input
// Mainloop
for (;;)
{
RX_Ready(); // UART ready to RX one Byte
_BIS_SR(LPM3_bits + GIE); // Enter LPM3 w/ interr
until char RXed
TX_Byte(); // TX Back RXed Byte Received
}
}
for various baud rates>
--------
TIA
--- In m..., "Tom Baugh" wrote:
>
> Thanks for asking! Chapter 10 goes into gory detail about the TimerB
In your case, if you only want a fixed 9600 baud, I would use a 38.4
> kHz crystal (as in #SE3315 on Digikey) and ignore the DCO entirely.
>
> Tom
>
Reply by ●August 5, 20082008-08-05
> You've given me a bunch to study/think about. A
couple things did
> jump out:
> The 38.4kHz crystal sounds great!
>
> Assuming this code fragment(from msp430x11x1_ta_uart2400.c), what
> would I need to change to make it work at 9600 with the 38.4kHz
a) Adjust the bit-time variables, or, better
b) Rewrite using the techniques in our book ;-)
Tom
> jump out:
> The 38.4kHz crystal sounds great!
>
> Assuming this code fragment(from msp430x11x1_ta_uart2400.c), what
> would I need to change to make it work at 9600 with the 38.4kHz
a) Adjust the bit-time variables, or, better
b) Rewrite using the techniques in our book ;-)
Tom
Reply by ●August 5, 20082008-08-05
I think this has help make things clearer for me. Thanks.
While we're on the subject (kinda) of crystals, what is the impact of
faster crystals on the MSP430 - the faster the crystal, the more power
consumed?
--- In m..., "Tom Baugh" wrote:
>
> > You've given me a bunch to study/think about. A couple things did
> > jump out:
> > The 38.4kHz crystal sounds great!
> >
> > Assuming this code fragment(from msp430x11x1_ta_uart2400.c), what
> > would I need to change to make it work at 9600 with the 38.4kHz
>
> a) Adjust the bit-time variables, or, better
> b) Rewrite using the techniques in our book ;-)
>
> Tom
>
While we're on the subject (kinda) of crystals, what is the impact of
faster crystals on the MSP430 - the faster the crystal, the more power
consumed?
--- In m..., "Tom Baugh" wrote:
>
> > You've given me a bunch to study/think about. A couple things did
> > jump out:
> > The 38.4kHz crystal sounds great!
> >
> > Assuming this code fragment(from msp430x11x1_ta_uart2400.c), what
> > would I need to change to make it work at 9600 with the 38.4kHz
>
> a) Adjust the bit-time variables, or, better
> b) Rewrite using the techniques in our book ;-)
>
> Tom
>
Reply by ●August 5, 20082008-08-05
> While we're on the subject (kinda) of crystals,
what is the impact of
> faster crystals on the MSP430 - the faster the crystal, the more power
> consumed?
Yes, but you won't notice the LPM3 difference between 32 kHz and 38
kHz. A meter might, but practically speaking it's nothing.
> faster crystals on the MSP430 - the faster the crystal, the more power
> consumed?
Yes, but you won't notice the LPM3 difference between 32 kHz and 38
kHz. A meter might, but practically speaking it's nothing.
Reply by ●August 5, 20082008-08-05
--- In m..., "Tom Baugh" wrote:
>
> > While we're on the subject (kinda) of crystals, what is the impact
of
> > faster crystals on the MSP430 - the faster the crystal, the more
power
> > consumed?
>
> Yes, but you won't notice the LPM3 difference between 32 kHz and 38
> kHz. A meter might, but practically speaking it's nothing.
>
does it mean an external crystal is a must for low power operations?.
>
> > While we're on the subject (kinda) of crystals, what is the impact
of
> > faster crystals on the MSP430 - the faster the crystal, the more
power
> > consumed?
>
> Yes, but you won't notice the LPM3 difference between 32 kHz and 38
> kHz. A meter might, but practically speaking it's nothing.
>
does it mean an external crystal is a must for low power operations?.
Reply by ●August 6, 20082008-08-06
>
> does it mean an external crystal is a must for low power operations?.
>
Paddu,
Wow, we kind of wandered off the path there, huh? No, a crystal isn't
required for low power operation, but if you need to do something like
a UART, you need at least a low-frequency crystal to run ACLK. Then,
follow all the rest of the discussion about measuring the DCO to get
high baud rates, or use a high-frequency crystal.
If you don't have a need for precise timing, then the 2xx family can
run in ultra-low power just fine from that neat VLO thing (discussed in
chapter 4).
Tom
> does it mean an external crystal is a must for low power operations?.
>
Paddu,
Wow, we kind of wandered off the path there, huh? No, a crystal isn't
required for low power operation, but if you need to do something like
a UART, you need at least a low-frequency crystal to run ACLK. Then,
follow all the rest of the discussion about measuring the DCO to get
high baud rates, or use a high-frequency crystal.
If you don't have a need for precise timing, then the 2xx family can
run in ultra-low power just fine from that neat VLO thing (discussed in
chapter 4).
Tom
