I'm used to edge-triggered PC-like UARTs which give an interrupt 
"as the parallel buffer becomes empty".... in other words if you 
set up a UART for interrupt driven transmit, and enable 
interrupts, you don't actually see an interrupt until you have 
given the UART a character, at which point it immediately 
transfers it to the serial buffer, and interrupts you demanding 
more.... then you have to work out how to shut it up when you 
don't actually have another byte to feed to it...

I get the impression that the UART/USRT in the MSP430 is more 
"level-triggered" and that it will interrupt immediately you 
enable interrupts, and ask for the first char... then transfer 
that to the serial buffer and interrupt again immediately, then 
interrupt again each time the transfer to the serial buffer 
happens...

I have to think about what to do when you have nothing to 
transmit for a while....

That's fine if it's right.... ( is it right?? )

But how does it behave as an SPI slave?

All SPI transactions seem to be bi-directional, in other words 
the master receives a byte as it transmits one, whether the byte 
has any useful contents or not, and the slave receives a byte 
each time the master clocks out a reply byte....

In the SPI mode you OUGHT to have the data you want to send 
"ready to go" in the USRT serial buffer at the moment the master 
gives you the first clock for the byte to be transferred. 

So I guess for tidiness sake you should put 0xff in the transmit 
buffer first thing in the morning..... does it just sit there 
and repeatedly go out every time the master sends you a byte????

How do you achieve the desired timing if you don't know what the 
slave's reply should be till you examine the last byte the 
master sends you..... in other words is an exchange 

	master->slave		slave->master
	command byte		don't-care
	parameter		don't-care
	don't care		1st reply byte
	don't care		2nd reply byte

possible?

Or would I have to set it up as

	master->slave		slave->master
	command byte		don't-care
	parameter		don't-care

	[don't care		pad         rept as reqd]

	don't care		1st reply byte
		"		more replies as required
		
so the slave has time to work out what it wants to say and put 
it in the parallel and serial reply buffers?

I guess if I just initially put one 0xff in the transmit buffer 
it will be clocked out as the command byte is clocked in... then 
the state machine will say the parallel and serial buffers are 
both empty, and the first byte I put in the parallel buffer will 
be immediately shifted to the serial buffer and be sent... but 
how fast do I have to be to meet the timing so it is the next 
byte sent? and should I be caring, or just telling the master to 
ignore 0xff bytes, and make sure there are no replies beginning 
0xff???

I suppose whatever system I set up should allow for a situation 
where the slave has to think about the problem for a few 
moments, so maybe I don't actually NEED an answer to the 
question at all....

There is one further complication - where does the clock come 
from that drives the transfer from the parallel buffer into the 
serial buffer? I know the UART runs on a state machine.... but 
is that state machine clocked from a hidden clock, or does it 
use the transmit clock? When does it do the transfer from the 
parallel buffer to the serial buffer --- immediately using a 
hidden clock... or does it sit still until the SPI master starts 
clocking and use that clock? So if the master is doing nothing, 
will I still get two interrupts immediately I enable interrupts, 
or does either of them not happen until the master starts 
clocking?

Details... details... is there a decent write-up of this stuff 
in any TI or other publication?

thanks for any help

David

Hi,

I guess you missed something in the initializatian
part of the USART. I'm using the SPI to transfer some
data int a 32 bit shift regsiter from MSP, I'm using
interrupt driven transmission and I have no problems
with fake interrupts after the transmission interrupt
is enabled.

For the second problem if the MSP acts like a slave
then the clock is comming from the master device, you
need to implement a sort of protocol, the master will
send a command to the slave and after that the master
will send a sort of query command to know when the
slave it's ready to transmit the response for the
command. 

Regards,
Boby



--- from_yahooMSP430@from... wrote:

> I'm used to edge-triggered PC-like UARTs
which give
> an interrupt 
> "as the parallel buffer becomes empty".... in other
> words if you 
> set up a UART for interrupt driven transmit, and
> enable 
> interrupts, you don't actually see an interrupt
> until you have 
> given the UART a character, at which point it
> immediately 
> transfers it to the serial buffer, and interrupts
> you demanding 
> more.... then you have to work out how to shut it up
> when you 
> don't actually have another byte to feed to it...
> 
> I get the impression that the UART/USRT in the
> MSP430 is more 
> "level-triggered" and that it will interrupt
> immediately you 
> enable interrupts, and ask for the first char...
> then transfer 
> that to the serial buffer and interrupt again
> immediately, then 
> interrupt again each time the transfer to the serial
> buffer 
> happens...
> 
> I have to think about what to do when you have
> nothing to 
> transmit for a while....
> 
> That's fine if it's right.... ( is it right?? )
> 
> But how does it behave as an SPI slave?
> 
> All SPI transactions seem to be bi-directional, in
> other words 
> the master receives a byte as it transmits one,
> whether the byte 
> has any useful contents or not, and the slave
> receives a byte 
> each time the master clocks out a reply byte....
> 
> In the SPI mode you OUGHT to have the data you want
> to send 
> "ready to go" in the USRT serial buffer at the
> moment the master 
> gives you the first clock for the byte to be
> transferred. 
> 
> So I guess for tidiness sake you should put 0xff in
> the transmit 
> buffer first thing in the morning..... does it just
> sit there 
> and repeatedly go out every time the master sends
> you a byte????
> 
> How do you achieve the desired timing if you don't
> know what the 
> slave's reply should be till you examine the last
> byte the 
> master sends you..... in other words is an exchange 
> 
> 	master->slave		slave->master
> 	command byte		don't-care
> 	parameter		don't-care
> 	don't care		1st reply byte
> 	don't care		2nd reply byte
> 
> possible?
> 
> Or would I have to set it up as
> 
> 	master->slave		slave->master
> 	command byte		don't-care
> 	parameter		don't-care
> 
> 	[don't care		pad         rept as reqd]
> 
> 	don't care		1st reply byte
> 		"		more replies as required
> 		
> so the slave has time to work out what it wants to
> say and put 
> it in the parallel and serial reply buffers?
> 
> I guess if I just initially put one 0xff in the
> transmit buffer 
> it will be clocked out as the command byte is
> clocked in... then 
> the state machine will say the parallel and serial
> buffers are 
> both empty, and the first byte I put in the parallel
> buffer will 
> be immediately shifted to the serial buffer and be
> sent... but 
> how fast do I have to be to meet the timing so it is
> the next 
> byte sent? and should I be caring, or just telling
> the master to 
> ignore 0xff bytes, and make sure there are no
> replies beginning 
> 0xff???
> 
> I suppose whatever system I set up should allow for
> a situation 
> where the slave has to think about the problem for a
> few 
> moments, so maybe I don't actually NEED an answer to
> the 
> question at all....
> 
> There is one further complication - where does the
> clock come 
> from that drives the transfer from the parallel
> buffer into the 
> serial buffer? I know the UART runs on a state
> machine.... but 
> is that state machine clocked from a hidden clock,
> or does it 
> use the transmit clock? When does it do the transfer
> from the 
> parallel buffer to the serial buffer --- immediately
> using a 
> hidden clock... or does it sit still until the SPI
> master starts 
> clocking and use that clock? So if the master is
> doing nothing, 
> will I still get two interrupts immediately I enable
> interrupts, 
> or does either of them not happen until the master
> starts 
> clocking?
> 
> Details... details... is there a decent write-up of
> this stuff 
> in any TI or other publication?
> 
> thanks for any help
> 
> David
> 


__________________________________________________
 

> I guess you missed something in the initializatian
> part of the USART. 

I'm still think about it - haven't tried it yet!

> I'm using the SPI to transfer some
> data into a 32 bit shift regsiter from MSP, I'm using
> interrupt driven transmission and I have no problems
> with fake interrupts after the transmission interrupt
> is enabled.

it wouldn't be a "fake", the device is ready, you've enabled

interrupts, why shouldn't it interrupt you :-)

but you may not, yet, know what the byte to be sent is....

I guess you can enable and disable the transmit interrupt for 
each packet - that should be fine - and may be the way to go.

> For the second problem if the MSP acts like a
slave
> then the clock is comming from the master device, you
> need to implement a sort of protocol, the master will
> send a command to the slave and after that the master
> will send a sort of query command to know when the
> slave it's ready to transmit the response for the
> command. 


I understand the overall principle ( as you can see from the 
diagrams ) - it's the detail that's bugging me.

David

Hi,

Ok, here it is: "A set transmit interrupt flag,
UTXIFGx, indicates that data has moved from
UxTXBUF to the TX shift register and UxTXBUF is ready
for new data. It does not indicate RX/TX completion."
- this is from MSP430x1xx family User's Guide.
So when you enable TX interrupt then the MSP will
generate an interrupt. If you don't want this then you
should reset the UTXIFGx flag in the corresponding
IFGx regsiter before enabling the TX interrupt.

Regards,
Boby



--- from_yahooMSP430@from... wrote:

> > I guess you missed something in the
initializatian
> > part of the USART. 
> 
> I'm still think about it - haven't tried it yet!
> 
> > I'm using the SPI to transfer some
> > data into a 32 bit shift regsiter from MSP, I'm
> using
> > interrupt driven transmission and I have no
> problems
> > with fake interrupts after the transmission
> interrupt
> > is enabled.
> 
> it wouldn't be a "fake", the device is ready, you've
> enabled 
> interrupts, why shouldn't it interrupt you :-)
> 
> but you may not, yet, know what the byte to be sent
> is....
> 
> I guess you can enable and disable the transmit
> interrupt for 
> each packet - that should be fine - and may be the
> way to go.
> 
> > For the second problem if the MSP acts like a
> slave
> > then the clock is comming from the master device,
> you
> > need to implement a sort of protocol, the master
> will
> > send a command to the slave and after that the
> master
> > will send a sort of query command to know when the
> > slave it's ready to transmit the response for the
> > command. 
> 
> 
> I understand the overall principle ( as you can see
> from the 
> diagrams ) - it's the detail that's bugging me.
> 
> David
> 


__________________________________________________
 

Another posibility is to prepare the data in an array,
when you want to send just enable the TX interrupt and
before you write the last byte in the TX buffer then
you disable the TX interrupt.

Hope this helps.

Regards,
Boby


--- Robert Bacs <robert_bacs@robe...> wrote:

> Hi,
> 
> Ok, here it is: "A set transmit interrupt flag,
> UTXIFGx, indicates that data has moved from
> UxTXBUF to the TX shift register and UxTXBUF is
> ready
> for new data. It does not indicate RX/TX
> completion."
> - this is from MSP430x1xx family User's Guide.
> So when you enable TX interrupt then the MSP will
> generate an interrupt. If you don't want this then
> you
> should reset the UTXIFGx flag in the corresponding
> IFGx regsiter before enabling the TX interrupt.
> 
> Regards,
> Boby
> 
> 
> 
> --- from_yahooMSP430@from... wrote:
> 
> > > I guess you missed something in the
> initializatian
> > > part of the USART. 
> > 
> > I'm still think about it - haven't tried it yet!
> > 
> > > I'm using the SPI to transfer some
> > > data into a 32 bit shift regsiter from MSP, I'm
> > using
> > > interrupt driven transmission and I have no
> > problems
> > > with fake interrupts after the transmission
> > interrupt
> > > is enabled.
> > 
> > it wouldn't be a "fake", the device is ready,
> you've
> > enabled 
> > interrupts, why shouldn't it interrupt you :-)
> > 
> > but you may not, yet, know what the byte to be
> sent
> > is....
> > 
> > I guess you can enable and disable the transmit
> > interrupt for 
> > each packet - that should be fine - and may be the
> > way to go.
> > 
> > > For the second problem if the MSP acts like a
> > slave
> > > then the clock is comming from the master
> device,
> > you
> > > need to implement a sort of protocol, the master
> > will
> > > send a command to the slave and after that the
> > master
> > > will send a sort of query command to know when
> the
> > > slave it's ready to transmit the response for
> the
> > > command. 
> > 
> > 
> > I understand the overall principle ( as you can
> see
> > from the 
> > diagrams ) - it's the detail that's bugging me.
> > 
> > David
> > 
> 
> 
> __________________________________________________
>  
> 



		
__________________________________ 

> Hi,
> 
> Ok, here it is: "A set transmit interrupt flag,
> UTXIFGx, indicates that data has moved from
> UxTXBUF to the TX shift register and UxTXBUF is ready
> for new data. It does not indicate RX/TX completion."
> - this is from MSP430x1xx family User's Guide.
> So when you enable TX interrupt then the MSP will
> generate an interrupt. If you don't want this then you
> should reset the UTXIFGx flag in the corresponding
> IFGx regsiter before enabling the TX interrupt.

If you read that carefully you'll see what worries me.

The flag indicates that the char has been shifted... but in the 
first place there is no character to shift, so there should be 
no interrupt...
That's how other UARTs work - you don't get an interrupt until 
you have given it the first character....

I'm trying to work out if that's the way this one works...

Hi,

I worked with several platforms (ex. x86, Mitsubishi
or Renesans etc.) and both have the same thing. For
example the Intel 386EX have an interrupt enable
register (IER0 an IER1) and the second bit is Transmit
Buffer Empty flag (when 1 is activated, when 0 is
off). On the other hand Mitsubuishi or Renesans
platform offers two interrupt cause: transmit buffer
empty and transmission completed. I guess you are
agree that is much more efficient to interrupt the uC
when the transmit buffer is empty.

The only thing is that the reset state of the UTXIFGx
bit is 1 and when you enable interrupts the uC will
generate an interrupt, but you can reset this bit
before you enable the transmit interrupt and this will
be like on x86 platform.

Regards,
Boby


--- from_yahooMSP430@from... wrote:

> > Hi,
> > 
> > Ok, here it is: "A set transmit interrupt flag,
> > UTXIFGx, indicates that data has moved from
> > UxTXBUF to the TX shift register and UxTXBUF is
> ready
> > for new data. It does not indicate RX/TX
> completion."
> > - this is from MSP430x1xx family User's Guide.
> > So when you enable TX interrupt then the MSP will
> > generate an interrupt. If you don't want this then
> you
> > should reset the UTXIFGx flag in the corresponding
> > IFGx regsiter before enabling the TX interrupt.
> 
> If you read that carefully you'll see what worries
> me.
> 
> The flag indicates that the char has been shifted...
> but in the 
> first place there is no character to shift, so there
> should be 
> no interrupt...
> That's how other UARTs work - you don't get an
> interrupt until 
> you have given it the first character....
> 
> I'm trying to work out if that's the way this one
> works...
> 



		
__________________________________