SPI TX complete interrupts are (nearly) worthless; at 20MHz it will take ~400ns for the buffer to empty after you write the byte into it. You will actually run slower using SPI interrupts than you would if you just sat and polled the status bit (and you will be in interrupt mode all the time so it’s not like you’re going to get anything else done).

Consider that (varying somewhat between systems) it takes on the order of 50 cycles to enter/exit your interrupt handler (three cycles in the pipeline, plus ~20 cycles to stack state depending on your RAM, plus at least two flash prefetch cache misses if you aren’t lucky enough to have a single-cycle flash). If you’re worried about hogging the CPU, then you need look at DMA.

 = Mike

On 11 May 2014, at 4:51 am, Marcin Jurczuk <spock@omegastar.eu> wrote:

I'm working on some SPI driver for LCD display and it seems that there is no IRQ API for SPI interrupts.
I'm trying to setup interrupt when SPI TX buffer is empty and when I enable this interrupt everything hangs.
I read library docs and still it should work but it doesn't
Anyone care to look what is wrong ?

/* SPI1 IRQ enable *?

​void spi1_isr(void)
    if ((SPI_SR(SPI1) & SPI_SR_TXE) == SPI_SR_TXE){
/* clear pending bit */
        SPI_SR(SPI1) &= ~SPI_SR_TXE;
        /* do somethning which isn't happening */



Best regards  and thanks in advance..
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
&#149; 3 signs your SCM is hindering your productivity
&#149; Requirements for releasing software faster
&#149; Expert tips and advice for migrating your SCM now
libopencm3-devel mailing list