interrupt free spi communication.?

Go To Last Post
24 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The typical communication of an spi as I understand it  looks like this.

 

  

    SPDR = data; // Load data

    while(!(SPSR & (1<<SPIF) )); //Wait for int flag

    return(SPDR); // Return data

 

 

The complete flag is set when the data is loaded and cleared when the data is complete. I assume this means the full send/received data. I want to do this without interrupts. I'm wondering if the return data will remain until reloaded? So something like..

 

 

    SPDR = data;//SPDR is now cleared.

    _delay_ms(200);//some amount of time that ends after the total transition.

    return(SPDR); //data should still be ready, right?

 

Does this have pitfalls or even work?

 

I have two main reasons for this.

1) Interrupts are not well suited in my case. Disabling them causes issues in my bit/bang usb design (this is another discussion). So I'd like to avoid them wherever possible.

 

2) I want to miss use the SPI a bit and replace my bit banging clock latch data logic. In this case I drop the latch generate a clock and read data. No start byte is required so I'd start the SPI with 0xff or 0 depending on the resting clock state and wait for the reply. This is sort of an experiment and I'm not sure its going to work but want to try. AFAIK there is no way to tell the SPI send nothing and assume a reply, unless maybe I set up the SPI to be a salve..but in this case the slave can not lower the SS line by design. Again this is just something I want to play with.

 

My question really is can I use SPI without the interrupt flags.

 

 

 

 

 

 

 

 

This topic has a solution.
Last Edited: Sat. Jun 23, 2018 - 11:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

S_K_U_N_X wrote:
My question really is can I use SPI without the interrupt flags.
On most XMEGA and USART in SPI mode, yes.

Microchip Technology Inc

Microchip Technology

Application Notes

AN_8408 AVR1522: XMEGA-A1 Xplained Training - XMEGA USART

http://www.microchip.com//wwwAppNotes/AppNotes.aspx?appnote=en591532

(PDF, page 1)

...

This training covers basic setup and use of the Atmel AVR® XMEGA® USART and the three tasks will demonstrate how to use the USART In polling-mode, interrupt mode and how to use the DMAC (Direct Memory Access Controller) to transfer data without CPU interaction.

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

You've posted under "General Electronics" so here's a general answer:

 

In General, the Status flag is set whether or not you have an interrupt enabled on it.

 

So you can poll the flag with the interrupt disabled.

 

No messing about with blind delays!

 

Job done.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Or put another way, the first code snippet you posted waits just enough time for the SPI transfer to complete, while the second waits an arbitrary period of time.  In neither case are you using interrupts.  

Greg Muth

Portland, OR, US

Xplained/Pro/Mini Boards mostly

 

Make Xmega Great Again!

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I thought the interrupt was internal and set the flags. So what is the interrupt for ? Is it just another way to catch the end of transfer? At least in the case of atmega 328, if I disable the interrupts this first code example fails.

Last Edited: Fri. Jun 22, 2018 - 06:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

S_K_U_N_X wrote:
I thought the interrupt was internal and set the flags.

Time to go back and read the datasheet, then.

 

So what is the interrupt for ?

Errr ... interrupting!

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry made a few edits to explain myself better.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The SPI hardware sets the SPIF (SPI interrupt flag).  Whether or not this generates an interrupt, depends on the state of the SPIE (SPI interrupt enable) and the global interrupt flag in the SREG.  The first code example you posted is polling the SPIF to if it is set.  If you were actually using the interrupt, an ISR (interrupt service routine) would be invoked every time the SPIF was set.

Greg Muth

Portland, OR, US

Xplained/Pro/Mini Boards mostly

 

Make Xmega Great Again!

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok that helps, does not explain why example one fails to work when I disable all int erupts. This could have been an error I'll recheck. thx.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

S_K_U_N_X wrote:
Is it just another way to catch the end of transfer? 

It saves you having to poll the flag.

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

S_K_U_N_X wrote:

So what is the interrupt for

To prevent the CPU from wasting time polling when it could be doing other things.

Greg Muth

Portland, OR, US

Xplained/Pro/Mini Boards mostly

 

Make Xmega Great Again!

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

S_K_U_N_X wrote:
does not explain why example one fails to work when I disable all int erupts

As ever, post a minimal but complete example which demonstrates this.

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

S_K_U_N_X wrote:

does not explain why example one fails to work when I disable all int erupts.

 You haven't shown enough code for anyone to explain much of anything...

Greg Muth

Portland, OR, US

Xplained/Pro/Mini Boards mostly

 

Make Xmega Great Again!

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It seems Andy and I are on the same wavelength...

Greg Muth

Portland, OR, US

Xplained/Pro/Mini Boards mostly

 

Make Xmega Great Again!

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

laugh

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Greg_Muth wrote:

S_K_U_N_X wrote:

does not explain why example one fails to work when I disable all int erupts.

 You haven't shown enough code for anyone to explain much of anything...

- Sorry was not looking for a answer, sort of typing out load. Anyways I see where I was confusing myself. The interrupt confusion is done with 

 

I have generated one last question I'm still not able to answer. Or possibly I did not ask the question right above. 

 

 

So more relevant code 

 

SPDR = data;

while(!(SPSR & (1<<SPIF)));

_delay_us(100);//this is needed for the salve to talk back.

return SPDR;

 

set up is SPCR = (1<<SPE)|(1<<MSTR)|(1<<SPR1)|(1<<SPR0)|(1<<DORD)|(1<<CPHA)|(1<<CPOL);//needed for psx, could try without (1<<SPR0) 
    

 

I was under the impression the following statement (taking from a write up)  meant complete transfer

"The SPI Interrupt Flag is set whenever a serial transfer is complete."

​So "interrupt"  aside one can still check the flag as shown above, but in my example I need that 100 us. If I watch this on an analyzer and use a pin for debug at the moment that while loop exist, it occurs just as the master has completed the send.  Is it possible to know when the full transfer is complete without catching an ISR ?

 

 

Last Edited: Sat. Jun 23, 2018 - 04:14 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can send a byte of data and come back at a later time and still test the spif flag. If you know that later is greater than the time it takes to send the byte, you can ignore testing the spif flag. If you’ve not enabled spi interrupts, then you’ll not get an interrupt.

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You seem to have failed to grasp how SPI works!

 

SPI is inherently full-duplex - as each bit is clocked out from the Master, one bit is clocked in from the slave.

 

The clock is always and only generated by the Master sending; if the master is not sending, there is no clock - so the slave cannot be sending.

 

Therefore, the moment the Master finishes sending is the moment that the transfer is complete! There is nothing more to wait for!

 

See the diagram & animation in this post: https://www.avrfreaks.net/commen...

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I see where I was confusing things. I guess when I read about SPI the doc tried to tell me that but I rejected it because there is no way the slave would know what to reply if the master has not sent the data yet. Now I see it is intended for the data to be ready thus if an ID for a particulate register is needed you need at least two bytes.

 

mosi rID 00 

miso 00  data

 

this way on byte transfer 1 we send the id but get the data in that register on transfer 2. 

 

 

 

Another question. Does that enable line normally change during each byte sent or the entire data? The device I'm working with seems to want the enable line lo during the entire communication. I though it was used to tell the slaveX I'm sending you data. and that it should bring it hi when complete. Could just be Sony (playstation controller) and the way they did it.

See the attention line.

 

Last Edited: Sat. Jun 23, 2018 - 04:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's usually enable, one/multiple byte transfers, disable. Not an enable / disable around every byte transfer.
.
If you are going to do the master->slave command byte then slave->master return value don't forget that the slave may need some cycles to decode the command and prepare the return value before the master starts to SCK. So maybe consider a short delay between the bytes the master sends.

Last Edited: Sat. Jun 23, 2018 - 07:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

yeah looks like it needed about 10 us. Looks like I got it all working, thx for all the help.

Last Edited: Sat. Jun 23, 2018 - 10:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Time to mark the solution, then?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Didnt know about that.... thx

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Go on - after 806 posts, you've never noticed those buttons:

 

 

Not to mention those tips ...

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...