I know about DMA however I need exactly information when data are really send not only when SPI TX buffer is empty.
Here is sample two transmissions:
http://www.zimagez.com/zimage/screenshot-12052014-233910.php

First line is CE latch low pulse
Second is SCK
Third line are data.
LATCH (CE LOW) must be send after 14 spi 8bit transmission since LCD shift register is 112 bits.

I will look if this is possible to get such behavior with DMA. Within spi1_isr() I just check counter of send packets after BSY is clear.
Previous solution with TXE flag wasn't working since TXE flag is set but in the meantime data tranmission is still in progress.
I applied SPI to not exactly SPI typical task (CE low when transmission is in progress)

Anyway thanks for feedback.


P.S Where I can submit patches ? I'm also working with STM32F030C6 chips and I think I founded minor bug regarding SPI in f0 code (typo) ..




On 12 May 2014 22:23, Mike Smith <drziplok@gmail.com> wrote:

IME, it's better to use DMA and then poll BSY in your DMA completion handler, since it will never stay set for more than one byte time. (Assuming the transfer is large enough to justify not simply polling).

 = Mike

On May 12, 2014, at 9:13 AM, Chuck McManis <chuck.mcmanis@gmail.com> wrote:

Yes, many people have discovered the almost useless implementation of SPI by SM. I built a driver for an LCD display and used the hack of counting receive interrupts to know when it would be 'safe' to take my CS pin high. If you look at the STM32F429 branch of my libopencm3-examples repo on Github[1] you can see my workaround (the lcd-serial example is the one that uses it).


--Chuck



On Mon, May 12, 2014 at 12:52 AM, Marcin Jurczuk <spock@omegastar.eu> wrote:
You re right,

They are almost useless. Thing is that LCD is driven  "spi like". I need to fill 112 bit shift register a then latch data using CS low level pulse.
I used BSY flag inside spi1_isr()  after 14 bytes send to latch data, and this solution works perfectly.

Funny think is that when you (me) spent a day with this issue and post to mailing list hour later I founded solution.

My problem was wrong understanding how NSS works in STM32 SPI. In fact you can't setup MCU to enter low level CS pin for transmition time only.
And driving it by TXE interrupt is also bad since you are getting TXE interrupt when buffer is empty  but bytes are still processed by SPI hardware and my CE pulse was after ~ 3 bits send by spi hardware :/




On 12 May 2014 06:32, Michael Smith <drziplok@gmail.com> wrote:

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:

Hi,
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 *?
    SPI_CR2(SPI1) |= SPI_CR2_TXEIE;
    nvic_enable_irq(NVIC_SPI1_IRQ);


​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
http://p.sf.net/sfu/perforce_______________________________________________
libopencm3-devel mailing list
libopencm3-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libopencm3-devel



------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
libopencm3-devel mailing list
libopencm3-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libopencm3-devel


------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs_______________________________________________
libopencm3-devel mailing list
libopencm3-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libopencm3-devel


------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
libopencm3-devel mailing list
libopencm3-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libopencm3-devel