| Newsgroups |
gmane.comp.hardware.texas-instruments.msp430.discuss |
| Message-ID |
<[email protected]> |
Assembler only from me. But here's my init routine from a 2618 based
design that uses only a watch crystal (20ppm) and the internally
calibrated DCO settings.
/************************************************************
* Initialise USCIA0 as UART
************************************************************/
BIS.B #UCSWRST,&UCA0CTL1
CLR.B &UCA0CTL0 ;SET FOR UART 0:8:1 LSB FIRST
MOV.B #UCSSEL_2,&UCA0CTL1 ;CLOCK = SMCLK HOLD IN RESET
MOV.B #B0_460,&UCA0BR0 ;SET FOR 115.2KBAUD WRITE
BR1:BR0 AS WORD
MOV.B #B1_460,&UCA0BR1 ;SET FOR 115.2KBAUD WRITE
BR1:BR0 AS WORD
BIS.B #BRF_460+BRS_460+UCOS16,&UCA0MCTL
BIS.B #RXD,&P3SEL ;ENABLE UART RECEIVE MODE
BIC.B #UCSWRST,&UCA0CTL1
BIS.B #UCA0RXIE,&IE2 ;ENABLE THE RECEIVE ISR FOR
UART FUNCTIONS
Here are the baud settings from my header file:-
B0_460 EQU 2
B1_460 EQU 0
BRS_460 EQU 6
BRF_460 EQU 32
and here is a simple ISR that in this case handles byte at a time
reception through a flag to the foreground routine in Main. This is to
allow variable packet length and different packet formats to be handled
with ease. For fixed packet lengths and format it would be simpler to
store to a buffer and post process, or add a command byte check at the
right point so you can abort receive early if there is an error detected.
USC0RX_ISR:
BIT.B #UCA0RXIFG,&IFG2 ;CHECK FOR INTERRUPTING CHANNEL
JZ DOSPI0
MOV.B &UCA0RXBUF,&RXDATA ;AND HANDLE UART HERE
BIS.B #GOTRX,&SYSTEM_FLAGS
RETI
DOSPI0:
This runs at 460kbaud very reliably. I do retune the DCO with a software
FLL if the temperature drifts too much, but it is rarely necessary
Cheers
Al
On 18/02/2015 7:37 PM, [email protected] [msp430] wrote:
>
>
> Guys,
> Thanks for getting back to me on this :)
> I'm pretty new to MSP430, I did go over the UART lib code and I am
> familiar with how it works, I couldn't find any issue with it though.
> However, I might have missed something there.
>
> I am using UART in hardware, the ports that I'm using is P3.3,4 =
> USCI_A0 TXD/RXD
> Any chance you guys could point me to something that you are familiar
> with and know it works?
>
> BTW, you guys are right and I wouldn't use untrusted *close* source.
> In this case though, the code is open and can be tested and inspected.
>
> Mike
>
> ---In [email protected], <onestone@...> wrote :
>
> tested by whom? do you trust just anybody to develop libraries. Ti
> rarely get it right, and they should be the goto people. In this
> specific example the guy who posted the UART example code actually
> states that it is untested.
>
> Al
>
> On 18/02/2015 9:51 AM, Jake Grajewski prs.jake@...
> <mailto:prs.jake@...> [msp430] wrote:
>
>
>
> Touche, but a good software developer /*never */uses untested
> libraries, now that would just be silly. ;-P.
>
> Caption this picture
>
> On Tue, Feb 17, 2015 at 3:15 PM, Onestone onestone@...
> <mailto:onestone@...> [msp430] <[email protected]
> <mailto:[email protected]>> wrote:
>
> Wrong, totally. the first rule of software development is that
> the best code is the one that you personally know has been
> fully debugged, and usually that is one that you wrote. If you
> trust others to write better code than you then you are asking
> for a world of grief.
>
> Who says I'm a bear? Anyway it's 'built in' not 'build in'. :-P
>
> Al
>
>
>
> On 18/02/2015 9:38 AM, Jake Grajewski prs.jake@...
> <mailto:prs.jake@...> [msp430] wrote:
>>
>>
>> Hi All,
>>
>> First off, The first rule of software development is that the
>> best code is the one you didn't have to write ^^.
>>
>> I agree with Al here, why aren't you using the build in UART
>> tool in the microprocessor. It is build to be used in this
>> way, and the only reason ever not to is if you have to use a
>> certain chip and you have run out of UART ports to use.
>>
>> @Martin: Now you are just poking the bear aren't you.
>>
>> Cheers,
>> Jake
>>
>> On Tue, Feb 17, 2015 at 2:07 PM, Onestone onestone@...
>> <mailto:onestone@...> [msp430] <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> Why oh why are you bit banging this when the MSP430 has
>> an extremely simple UART in hardware. Are interrupts that
>> fightening?
>>
>> Al
>>
>>
>>
>> On 18/02/2015 2:21 AM, mikemalgin@...
>> <mailto:mikemalgin@...> [msp430] wrote:
>>>
>>>
>>>
>>> Hello, I'm trying to communicate with my RF module
>>> through UART interface. However, I get many errors even
>>> with low load. I suspect that I have an issue with the
>>> way that I configure the clock or the UART.
>>>
>>>
>>> Basically, for the UART functionality I use
>>> http://glitovsky.com/blog/?p=300
>>>
>>> (I configured the connection as 8N1at 115200).
>>>
>>>
>>> The clock configuration below is used with MCLK = 25 MHz
>>> ( when I use it with MCLK=16 MHz I cannot communicate
>>> with the UART module at all ) .
>>>
>>>
>>> P5SEL |= 0x0C;
>>>
>>> /* Select REF0 for FLL reference. */
>>>
>>> UCSCTL3 &= ~SELREF_7;
>>>
>>> UCSCTL3 |= SELREF_2;
>>>
>>>
>>> /* Set ACLK to use REF0CLK.
>>>
>>> * Set SMCLK to use the DCO.
>>>
>>> */
>>>
>>> UCSCTL4 &= ~SELA_7 & ~SELS_7 & ~SELM_7;
>>>
>>> UCSCTL4 |= SELA_2 | SELS_4 | SELM_4;
>>>
>>> /* Initialize FLL. */
>>> Init_FLL_Settle(mclk/1000L, mclk/32768);
>>>
>>> XT2_Start(XT2DRIVE_0);
>>>
>>> UCSCTL4 &= ~SELA_7;
>>> UCSCTL4 |= SELA_2;
>>> UCSCTL8 |= SMCLKREQEN | MCLKREQEN | ACLKREQEN;
>>> /* Enable interrupt for TBCCR0. */
>>> TBCCTL0 = CCIE;
>>> /* Number of ticks per millisecond. */
>>> clock.aclk = 32768;
>>> clock.ticks_per_interrupt = clock.aclk / 1000;
>>> TBCCR0 = clock.ticks_per_interrupt;
>>>
>>> /* Use ACLK, set timer to up-count mode, and start
>>> timer at zero. */
>>> TBCTL = TBSSEL_1 | MC_2 | TBCLR;
>>>
>>> /* Enable interrupts. */
>>> __bis_SR_register(GIE);
>>> Thanks,
>>> Mike
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>> --
>> Thomas J. Grajewski
>>
>>
>>
>
>
>
>
> --
> Thomas J. Grajewski
>
>
>
>
>
>
>