Forums

SSP interrupts as SPIF behavior

Started by Tom Walsh October 26, 2006
Hello,

I've some confusion as to how the interrupts on the SSP operate and
don't seem to find any documentation regarding this. From the
documentation I've found so far, the SSP interrupt system (as
documented) appears to be useless in determining when the TX FIFO is empty?

I have an interrupt driven SPI state machine which I now need to move
over to the SSP circuit. This state machine is designed that when the
SPIF bit is set, and generates the S0SPINT vector, the state machine
advances. With the SPI this works as the SPIF interrupts indicate that
the FIFO (one byte deep) is empty.

However, on the SSP, it appears that the TNF interrupt behaves
differently and fires when you reach the low-water-mark of "less then
half full". I have seen some devices which have a dual interrupt: one
for "FIFO not full" and another for "FIFO is empty".

How would you know that the SSP TX FIFO is empty without continuously
looking at the TFE bit from a polling loop in your main software? As
they say, never assume.

I ASSUME that TNF interrupt would fire each time that a byte transfer
cycle is attempted to move a new byte into the bit shifter from the TX
FIFO, --AND--, the FIFO is less than half full? So, if I have TXIM
enabled, then put 8 bytes into the TX FIFO, I will get 3 corresponding
TNF interrupts? Three being the number of times a byte xfer cycle would
occur and the "FIFO is less than half full".

ASSUMING that the TNF will fire each time a byte transfer cycle occurs,
the last TNF will be when the last byte is loaded into the bit shifter?
I don't know how clearly I outlined this. What I essentially want is
the same operation of the SSP as what happens with SPIE for the SPI:
"interrupt me when you have sent it all".

Thanks in advance,

TomW
--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net http://cyberiansoftware.com http://openzipit.org
"Windows? No thanks, I have work to do..."
----------------

An Engineer's Guide to the LPC2100 Series

--- In l..., Tom Walsh wrote:
>
> I don't know how clearly I outlined this. What I essentially want
is
> the same operation of the SSP as what happens with SPIE for the SPI:
> "interrupt me when you have sent it all".
>

Tom,

Although I haven't used the SSP and hence can't confirm the behaviour,
your description certainly sounds reasonable given the documentation.

One question I'd have is why you need to know when the SSP "has sent
it all"? Does it really matter whether the data is in the FIFO, in
transit, sitting in receiver's FIFO, whatever...? In other words,
although it would be nice to know, it's hardly critical: you can use
the TXFIFO full status to know when to stop putting data in and once
in the data is as good as gone.

Unless I'm missing something?

Brendan.
Brendan Murphy wrote:
>
> --- In lpc2000@yahoogroups .com ,
> Tom Walsh wrote:
> >
> > I don't know how clearly I outlined this. What I essentially want
> is
> > the same operation of the SSP as what happens with SPIE for the SPI:
> > "interrupt me when you have sent it all".
> > Tom,
>
> Although I haven't used the SSP and hence can't confirm the behaviour,
> your description certainly sounds reasonable given the documentation.
>
> One question I'd have is why you need to know when the SSP "has sent
> it all"? Does it really matter whether the data is in the FIFO, in
> transit, sitting in receiver's FIFO, whatever...? In other words,
> although it would be nice to know, it's hardly critical: you can use
> the TXFIFO full status to know when to stop putting data in and once
> in the data is as good as gone.
>
Yes, but then at some point you have to remove the chipselect from one
UART and select another. heh

TomW

--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net http://cyberiansoftware.com http://openzipit.org
"Windows? No thanks, I have work to do..."
----------------
--- In l..., Tom Walsh wrote:
>
> Brendan Murphy wrote:
> >
> > --- In lpc2000@yahoogroups .com
40yahoogroups.com>,
> > Tom Walsh wrote:
> > >
> > > I don't know how clearly I outlined this. What I essentially
want
> > is
> > > the same operation of the SSP as what happens with SPIE for
the SPI:
> > > "interrupt me when you have sent it all".
> > >
> >
> > Tom,
> >
> > Although I haven't used the SSP and hence can't confirm the
behaviour,
> > your description certainly sounds reasonable given the
documentation.
> >
> > One question I'd have is why you need to know when the SSP "has
sent
> > it all"? Does it really matter whether the data is in the FIFO,
in
> > transit, sitting in receiver's FIFO, whatever...? In other words,
> > although it would be nice to know, it's hardly critical: you can
use
> > the TXFIFO full status to know when to stop putting data in and
once
> > in the data is as good as gone.
> >
> Yes, but then at some point you have to remove the chipselect from
one
> UART and select another. heh
>

OK - I understand the requirement now, and you're right: it is a
pain if you need to know.

If you're not willing to poll, I guess the alternative is to use
some form of timer interrupt.

By the way, does "FIFO empty" normally mean "all data transmitted"?
I would have thought that on many (most?) parts there's a shift
register behind the FIFO that shifts the bits out, so if you need to
know when all data is gone you really need a "TX shift register
empty" status?

Brendan.
Brendan Murphy wrote:
>
> --- In lpc2000@yahoogroups .com ,
> Tom Walsh wrote:
> >
> > Brendan Murphy wrote:
> > >
> > > --- In lpc2000@yahoogroups .com > 40yahoogroups. com>,
> > > Tom Walsh wrote:
> > > >
> > > > I don't know how clearly I outlined this. What I essentially
> want
> > > is
> > > > the same operation of the SSP as what happens with SPIE for
> the SPI:
> > > > "interrupt me when you have sent it all".
> > > >
> > >
> > > Tom,
> > >
> > > Although I haven't used the SSP and hence can't confirm the
> behaviour,
> > > your description certainly sounds reasonable given the
> documentation.
> > >
> > > One question I'd have is why you need to know when the SSP "has
> sent
> > > it all"? Does it really matter whether the data is in the FIFO,
> in
> > > transit, sitting in receiver's FIFO, whatever...? In other words,
> > > although it would be nice to know, it's hardly critical: you can
> use
> > > the TXFIFO full status to know when to stop putting data in and
> once
> > > in the data is as good as gone.
> > >
> > Yes, but then at some point you have to remove the chipselect from
> one
> > UART and select another. heh
> > OK - I understand the requirement now, and you're right: it is a
> pain if you need to know.
>
> If you're not willing to poll, I guess the alternative is to use
> some form of timer interrupt.
>
> By the way, does "FIFO empty" normally mean "all data transmitted" ?
> I would have thought that on many (most?) parts there's a shift
> register behind the FIFO that shifts the bits out, so if you need to
> know when all data is gone you really need a "TX shift register
> empty" status?
>
Look at the description for the S0SPINT register of the SPI. Then look
at the SPIF bit description in the S0SPSR register. By enabling SPIE in
the S0SPCR, you will get an SPIF interrupt when the byte has been
shifted out. This does work.

So, you have a low speed peripheral which you need to move 256 bytes of
data via the SPI, you merely set up an interrupt service routine to feed
the bytes, each time an SPIF occurs, until all bytes have been send.

You cannot remove the chip select from the peripheral while the data is
being shifted out or it will abort the operation. When the SPIF
interrupt occurs, then either give it more data or move onto servicing
the next UART (IOW safely remove the chip select).

Sitting on, or polling the BSY flag is wasteful, otherwise what would be
the use of having an interrupt??? Using a timer interrupt is not
possible as I have those dedicated to other purposes.

Since there are four UARTS operating asynchronously of each other, my
state machine responds to EINT0 (UART has received data) or an SPIF
(data has been given to the UART, time for the next one, or select next
UART if all data has been sent and service that UART).

This is how I currently run the SPI to service the four UARTS. What I
need to do is find out what conditions would replicate the SPIF
operation with the SSP.

TomW

--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net http://cyberiansoftware.com http://openzipit.org
"Windows? No thanks, I have work to do..."
----------------
> I don't know how clearly I outlined this. What I essentially want is
> the same operation of the SSP as what happens with SPIE for the SPI:
> "interrupt me when you have sent it all".

I have had the same problem with this and have used the /ss signal as
an (external) clock input to one of the counters. This will give an
interrupt every n frames. The idea is you clock on the rising edge
of /ss, indicating the end of the transfer. Counter interrupts after n
frames. If you just want a 1 byte FIFO you could connect the /ss to an
external interrupt input. This ties up other resources and may not be
be feasible but I have success with this in both slave and master mode.

I can't imagine the concept behind the SSP interrupts and FIFO setup.
Maybe I missed some special application....

Ian
Brendan Murphy wrote:
>
> --- In lpc2000@yahoogroups .com ,
> Tom Walsh wrote:
> >
> > Brendan Murphy wrote:
> > >
> > > --- In lpc2000@yahoogroups .com > 40yahoogroups. com>,
> > > Tom Walsh wrote:
> > > >
> > > > I don't know how clearly I outlined this. What I essentially
> want
> > > is
> > > > the same operation of the SSP as what happens with SPIE for
> the SPI:
> > > > "interrupt me when you have sent it all".
> > > >
> > >
> > > Tom,
> > >
> > > Although I haven't used the SSP and hence can't confirm the
> behaviour,
> > > your description certainly sounds reasonable given the
> documentation.
> > >
> > > One question I'd have is why you need to know when the SSP "has
> sent
> > > it all"? Does it really matter whether the data is in the FIFO,
> in
> > > transit, sitting in receiver's FIFO, whatever...? In other words,
> > > although it would be nice to know, it's hardly critical: you can
> use
> > > the TXFIFO full status to know when to stop putting data in and
> once
> > > in the data is as good as gone.
> > >
> > Yes, but then at some point you have to remove the chipselect from
> one
> > UART and select another. heh
> > OK - I understand the requirement now, and you're right: it is a
> pain if you need to know.
>
> If you're not willing to poll, I guess the alternative is to use
> some form of timer interrupt.
>
> By the way, does "FIFO empty" normally mean "all data transmitted" ?
> I would have thought that on many (most?) parts there's a shift
> register behind the FIFO that shifts the bits out, so if you need to
> know when all data is gone you really need a "TX shift register
> empty" status?
>
It appears that the LPC2138 documentation is in error. The manual
(UM10120_1.pdf), in Section 13.4.6, for the TXIM "Software should set
this bit to enable interrupt when the Tx FIFO is at least half empty.".

This appears to be grossly incorrect!

Some testing shows that the TXIM (TX Interrupt Mask) bit is asserted
ONLY when TFE (Transmitter and FIFO Empty) occurs.

I'll have to phone NXP and see if I can get someone to answer the
question. The question is "does a TXIM interrupt occur when TFE is
asserted".

TomW
--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net http://cyberiansoftware.com http://openzipit.org
"Windows? No thanks, I have work to do..."
----------------
ian.scanlon wrote:
>
> > I don't know how clearly I outlined this. What I essentially want is
> > the same operation of the SSP as what happens with SPIE for the SPI:
> > "interrupt me when you have sent it all".
>
> I have had the same problem with this and have used the /ss signal as
> an (external) clock input to one of the counters. This will give an
> interrupt every n frames. The idea is you clock on the rising edge
> of /ss, indicating the end of the transfer. Counter interrupts after n
> frames. If you just want a 1 byte FIFO you could connect the /ss to an
> external interrupt input. This ties up other resources and may not be
> be feasible but I have success with this in both slave and master mode.
>
> I can't imagine the concept behind the SSP interrupts and FIFO setup.
> Maybe I missed some special application. ...
>
I am just looking for an "operation complete", not a single byte fifo.
The manual says one thing (interrupt when less than half full), but
testing shows a radically different behavior. It appears that the TXIM
interrupt occurs when TFE is asserted. But, never ASSUME.

I would like to get confirmation before I spend a few hours (days)
constructing software and setting up a series of verification tests.

TomW
--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net http://cyberiansoftware.com http://openzipit.org
"Windows? No thanks, I have work to do..."
----------------
Tom Walsh Wrote
>I've some confusion as to how the interrupts on the SSP operate and
>don't seem to find any documentation regarding this. From the
>documentation I've found so far, the SSP interrupt system (as
>documented) appears to be useless in determining when the TX FIFO is empty?

Since SPI is a receive on send system can you turn the problem around and
determine FIFO empty when you've recieved a byte for every byte sent?

Robert

--------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .
s...@aeolusdevelopment.com wrote:
>
> Tom Walsh Wrote
> >I've some confusion as to how the interrupts on the SSP operate and
> >don't seem to find any documentation regarding this. From the
> >documentation I've found so far, the SSP interrupt system (as
> >documented) appears to be useless in determining when the TX FIFO is
> empty?
>
> Since SPI is a receive on send system can you turn the problem around and
> determine FIFO empty when you've recieved a byte for every byte sent?
>
Hello Robert,

Thanks for the observation. Sometimes, when doing debug for example,
you have to reverse your point of view and prove "what is right".

Anyway, it looks as if the TX interrupts are meant to be used to keep
the FIFO full when transmitting data. As you suggested, I just have to
look at the problem as one of processing RX FIFO interrupts.

Thanks,

TomW

--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net http://cyberiansoftware.com http://openzipit.org
"Windows? No thanks, I have work to do..."
----------------