Reply by old_cow_yellow November 28, 20082008-11-28
TXIFG is set whenever TXBUF is ready. It is cleared if you load TXBUF
with data (or junk). But when the TX shift-register is empty, it will
automatically copy that data (or junk) form TXBUF, and TXBUF will be
ready again. Thus TXIFG will be set again.

Thus if you have more data to send, just load it to TXBUF and TXIFG
will be cleared. If you do not have more data, you can let TXIFG stay set.

This scheme is designed to keep a steady stream of TX even when the
software that feeds TXBUF has a hiccups. It works fine within the
stream. But you need some extra work to stop the current stream and to
start another stream.

Beginning Microcontrollers with the MSP430

Reply by apcjw November 28, 20082008-11-28
I am having a similar issue on a F2618 device,
I am using UCB0 in i2c mode and USCIA0 in uart mode.
To try and to understand whats happening I disabled
UCA0TXIE = 0
When the USCIAB0TX_VECTOR is exucuted I see that UCA0TXIFG=1
even though UCA0TXIE = 0
The trouble is that I can't seem to clear UCA0TXIFG
and the interrupt routine wants to process the USCA0 code for the
uart even though the uart interrupt is disabled and the interrupt
is actually for UCB0RX...
What can I do ? are there any comprehensive examples of how to use
shared interrupts on USCI modules ?
Reply by shred444 January 24, 20082008-01-24
I have grabbed my interrupts and initialization functions for both i2c and
serial. I have also uploaded them as a file in case they arent formatted
correctly in this thread...

Reply by tintronic January 24, 20082008-01-24
Sorry, I was wrong. Your device has two USCI (A&B), where the ones I
use have one or two USART (0&1). I thought you were using the same
USART0 for both interfaces, but you are using USCIA and USCIB, so
there is no problem there.

It would be helpful if you sent your interrupt service routines and
the relevant functions that are called by them.

Best Regards,
Michael K.
Reply by shred444 January 24, 20082008-01-24
tintronic wrote:
>
> I think your problem may be much more basic.
> You are using the same USART hardware for both UART and I2C
> interfaces. As far as I know, only one of those can be used at any
> time. I don't know if you have realized this and if you are taking the
> necessary precautions (both hardware and software) when changing
> between modes, but it doesn't seam you are.
> For example, you activate an Rx interrupt for UART, but your I2C init
> activates an TX interrupt, without deactivating the RX interrupt set
> by the UART init.
> I couldn't find you interrupt routines on this thread.
>
> Best Regards,
> Michael K.
>

Interesting, so i was under the impression that the microcontroller i chose
could operate uart and i2c at the same time. On the specs, it shows the
Interface as: USCI (UART/LIN/IrDA/SPI and I2C/SPI) , where as other chips
say USCI (UART/LIN/IrDA/SPI or I2C/SPI). If this is not the case, then I'm
in big trouble.
Reply by Joe Radomski January 24, 20082008-01-24
He is using A0 for the uart and B0 for the I2c.. This is ok as long as its handled properly..
Reply by tintronic January 24, 20082008-01-24
I think your problem may be much more basic.
You are using the same USART hardware for both UART and I2C
interfaces. As far as I know, only one of those can be used at any
time. I don't know if you have realized this and if you are taking the
necessary precautions (both hardware and software) when changing
between modes, but it doesn't seam you are.
For example, you activate an Rx interrupt for UART, but your I2C init
activates an TX interrupt, without deactivating the RX interrupt set
by the UART init.
I couldn't find you interrupt routines on this thread.

Best Regards,
Michael K.
Reply by Joe Radomski January 24, 20082008-01-24
Sharing the interrupts should not be a problem.. The interrupt routine is supposed to determine which port is causing the interrupt..
howvere you normally cannot start another interrupt until the previous one is completed..

I would make sure that you are not trying to do the i2c read from the previous interrupt..

The way I would do it is.. process the uart interrupt.. set a global flag if it matches.. The main routine checks the flag then iniates an i2c read (this could be interrupt based), set a flag when the data buffer is full.. the main routine it can check this flag and send data out the uart as necessary..

your receive/transmit interrupt routines have to be able to determine which port the interrupt came from

the receive interrupts are shared between Axand Bx as well as the TX interrups sharing Ax and Bx
Reply by Friedrich Lobenstock January 24, 20082008-01-24
shred444 wrote on 24/01/08 05:21 MET:
> Friedrich Lobenstock wrote:
>>
>> If I understand you correctly you are sending I2C commands out of
>> interrupt
>> context, right? If so try to create a "main" routine which is basically an
>> endless loop which queries a flag set by the UartA receive routine to
>> initiate the I2C transfer. The I2C ISR then posts the result in another
>> variable and then the main routine intiates the serial send.
>
> that's a great idea. I will try that tomorrow and let you know how it works
> out. Just to clarify... by main routine, you mean... a looping timer that
> occurs...lets say every 100ms that's constantly checking for that uartrx
> flag? Thanks again

No, I meant a real endless loop, like depicted below.


This is known as a Foreground-Background system.
A bit priecy but very much worth reading, gives a very good background in
realtime systems design:
Real-Time Systems Design and Analysis (Hardcover)
by Phillip A. Laplante <http://www.amazon.com/dp/0471228559/>

What I could find via Google
<http://www.google.com/search?q=realtime+systems+foreground+loop&hl=en>

[PDF] Review notes for single task and foreground-background systems
<http://www.informatics.bangor.ac.uk/~dewi/modules/rts/ICP3021_for_back.pdf>

--
MfG / Regards
Friedrich Lobenstock
Reply by shred444 January 24, 20082008-01-24
Friedrich Lobenstock-2 wrote:
> If I understand you correctly you are sending I2C commands out of
> interrupt
> context, right? If so try to create a "main" routine which is basically an
> endless loop which queries a flag set by the UartA receive routine to
> initiate the I2C transfer. The I2C ISR then posts the result in another
> variable and then the main routine intiates the serial send.
>
> --
> MfG / Regards
> Friedrich Lobenstock

that's a great idea. I will try that tomorrow and let you know how it works
out. Just to clarify... by main routine, you mean... a looping timer that
occurs...lets say every 100ms that's constantly checking for that uartrx
flag? Thanks again