Hello,

does anybody of you have a introduction how to program the stm32F4 with assembler? At the moment i am using the normal "mbed.h" library but it doesn't work so fast as i mentioned. Now i wanna program a assemlber inline function which does it faster.. Therefore i wanna know are there any examples for this problem ?

Damn it i forgot to post something. I wanna turn on and turn off a pin at the stm32 board

STM32F4 shouldn't be that bad in toggling a pin, now switching between input and output is horribly implemented.

However that is still relative: a simple write operation can still be at least 5 times faster than with the normal mbed code (largely also because these days at every write it first checks if the pin still exists and didn't go into hiding, no idea why).

There are some assembler examples spread out over the mbed site (and also in other locations), but I don't think there is one specifically for STM ones. However to solve your IO issue, you can also have a look at: https://developer.mbed.org/users/Sissors/code/FastIO/. I don't think assembler is going to be significantly faster (although it is something I would still like to have a look at myself).

At first thank you for your reply.

Below there you can find my code.

#include "mbed.h"

void write_out(int SPI_value);


float amplitude  = 2.0f;
unsigned int f=49000000;      // Clock Frequency = 24 MHz


int samples =0;
DigitalOut Enable(D9);      // That is CS 



SPI device(D11, D12, D13);  // miso mosi und sck

int main() {

    Enable = 1;
    device.frequency(f);   // Clock Frequency     
device.format(16,0); 

    write_out(40960); // Clock data to shift register on rising Edge
    

      
    while(1) {
                            
        Enable = 0;
        device.write(155);     //  
        Enable = 1;    
              
    }
}
 

The time between enable and disable of the PD9 takes more than 140ns. That is pretty Long in that case I wanna decrease the process time. The internal clock of the STm32 is normaly 100 MHz in the mbed.h. Are i am right?

In amount it takes 1.7us for only These program lines

        Enable = 0;
        device.write(155);     //  
        Enable = 1;    

In my opinion the stm32 could do it faster ...

Problem is largely there also the SPI code most likely, which waits until it is finished to read back the MISO pin. This is also required in principle for you, since if it doesn ot wait until it is finished, you would raise the enable pin before it is finished.

But you can easily drop in FastIO to check if it makes a significant difference.

Yes, you are right. i realized it lately. I implemented the FastIO lib and i could decrease the time to 1.5us. (before I had 1.7 us)

No, i don't have to read back the MISO. I only have to send my data package. Thanks for your point of view, it will be my next step.

I measured the time between the last SPI_SCKL rectangle and the raising edge of the enable pin. This time is only 200ns whereas the time between the falling enable edge and the first SPI_SCKL rectangle 500ns is. IN comparison is the waiting rime of the SPI lib not that long.

If you need to send lots of SPI packages, for example if you need to control an SPI TFT display, you can significantly speed it up using BurstSPI lib, however that will not help you with these single transactions.

I am impressed that is your lib. It works very fine!

Your library could increase the time to 1.2us instead of 1.5us.

I think, the bottleneck during this communication is the turn on time of the SPI interface until it starts to send. At the moment it takes more or less than 480ns.

Now i have to take a closer look how the SPI interface is initialized. Do you have any further recommendations ?

For GPIO: You aren't going to get (significantly) faster than FastIO.

For SPI: I would get the reference manual, and write your own code based on the registers. You can use standard code (for example by making an mbed SPI object) to do all the initialisations and not having to worry about pinouts, etc. After that just for the transactions, use registers. Generally I am not very impressed by the STM drivers, so for high speed I would stay away from it, and just do it yourself. If you do it well, you should be able to get quite far using C.

Finally, you can look at using hardware CS instead of software. Mbed API itself does not support this sadly, the stm drivers probably do. (Or using registers).