Using STM32 DMA to speed up hardware SPI and U8G2 - Attempt 1 - Simple DMA

Using STM32 DMA to speed up hardware SPI and U8G2 - Attempt 1 - Simple DMA

 

So we have finished all the basic hardware connection, setup and using hardware SPI to let u8g2 to communicate to LCD12864. Please check this post for detail:

STM32 and U8G2 to draw on LCD12864 Using hardware SPI

It works well, however there is a tiny problem, it's too slow.

The speed problem of SPI of LCD12864(ST7920)

Every time we call u8g2.sendBuffer(), this operation takes 43milliseconds.

How to measure sendbuffer() 's time usage in stm32cubeIDE:

    uint32_t start_ts = HAL_GetTick();
    u8g2.sendBuffer();
    uint32_t end_ts = HAL_GetTick();
    unsigned int delta_msec = end_ts - start_ts;
    printf("sendbuffer used %u ms\r\n", delta_msec);

 

Using stm32F103C8T6 bluepill, system speed 72Mhz, spi speed 572kbit/s

Without doing much (just write some text) in the main loop, the LCD screen just have a FPS about 16FPS ( with some printf() to output debug info ).

If we let the MCU work on some real work like ADC, calculation for PWM, PID algorithm, then the speed /FPS should drop even more! To simulate some "real work", I added a modest sleep(20ms) to slow down the main loop

HAL_Delay(20);

With this sleep 20ms, the FPS dropped to 12, I guess we can't run DOOM on it then ??

So this is bad.

Using STM32's DMA to Speed it up

 Is there something we can do to improve the speed ?

Yes, STM32 can do DMA, Direct memory access,  which doesn't use CPU time, to help to transfer data from memory to memory, or memory to SPI bus.

Not working solution - simple DMA:

So the first attempt would be, you may have already thought of, is to replace the HAL_SPI_Transmit() function for the message U8X8_MSG_BYTE_SEND inside the hw_spi call back function we defined for u8g2 to use, to replace it with a DMA version of the SPI transmit function:  HAL_SPI_Transmit_DMA 


inline uint8_t u8x8_byte_3wire_hw_spi(u8x8_t *u8x8, uint8_t msg, uint8_t arg_int, void *arg_ptr) {
    switch (msg) {
    case U8X8_MSG_BYTE_SEND:
         // HAL_SPI_Transmit(&LCD_SPI, (uint8_t*) arg_ptr, arg_int, 10000);
         HAL_SPI_Transmit_DMA ( );
        break;

So this change is simple, does it work? unfortunately no, this DMA call will instantly return, and u8g2 will calls it repeatedly again and again, so it messes up the DMA mechanism. We also need to add while() loop to block it and wait until the DMA is done like this:

 while (HAL_DMA_GetState( LCD_SPI.hdmatx) != HAL_DMA_STATE_READY){};

         HAL_SPI_Transmit_DMA ( );

How does it work?  Unfortunately It not only couldn't make the screen correct and clean, but also the time is the same slow.

After some debug , break point, show variables work, it turned out that u8g2 keep calling the  U8X8_MSG_BYTE_SEND function to send 16 bytes each time (one line of dots, 16X8=128), so each time we send 16bytes, instantly we need to call the DMA to send again, but DMA is still sending it, so we have to wait, blocking, and send again, then wait again, that explains why the DMA way of sending buffer uses pretty much the same amount of time!

Also, 16 bytes is really not a lot to send, seems wasting DMA's ability to send large amount of data without using DMA's time.

At last, to fill up the whole 12864 screen, this DMA call need to be called for at least 64times, and we need to wait for 64 blocking times, this totally make the simple DMA method useless.

And last last bad news, after using this simple DMA method, the FPS dropped even more, it's even slightly slower than the regular non-DMA SPI transmit speed.

Test shows FPS is only 11 and sendbuffer() takes 45ms(was 42ms in the regular SPI send)...not to mention the screen content is totally broken.

I guess the reason of broken content is totally NOT worth the time and effort to investigate due to the slow speed.



Comments

Post a Comment

Popular posts from this blog

STM32 and U8G2 to draw on LCD12864 Using hardware SPI

Image
STM32 bluepill and U8G2 to draw on LCD12864 Using hardware SPI   Since there are not a lot of info about this on Internet, so I am making this guide. We can see some info/guide or example about using Arduino board, or Arduino IDE, or Software SPI to draw using U8g2. But in this guide, we will use hardware SPI, Stm32 chip, and use Stm32CubeIDE to draw. Keyword here: Bluepill, blackpill, u8g2, LCD12864(5V, works with 3.3V stm32 MCU), hardware SPI communication, Stm32CubeIDE.  Part List in the test: LCD12864 screen, Bluepill dev board(stm32F103C8T6) or Blackpill dev board( stm32F401CCU6), 5V power supply, stlinkV2 device to flash or debug.   Low cost LCD12864 (ST7920), it's large, and good resolution(128X64), cheap. It has a lot of pins for parallel connection, DB0 DB1 DB2...DB7, but who has so many pins to connect?? In fact, this LCD can support SPI connection, it only need 2pins to MCU: MOSI and SCK, CS and RESET is optional, no need to connect to MCU.   In SPI mode, ...
Read more

Using STM32 DMA to speed up hardware SPI and U8G2 - Attempt 2 - buffered DMA

Image
Using STM32 DMA to speed up hardware SPI and U8G2 - Attempt 2 - buffered DMA So we have tried the simple DMA method, simple DMA method which doesn't work, let's try another way. In this test, we will cache everything the u8g2 trys to send to the LCD screen over SPI, then we will find a good chance to send the whole huge buffer to LCD using SPI DMA. Step 1 store data to our buffer define a function to be put inside the SPI back function for message U8X8_MSG_BYTE_SEND. cache_spi_data_to_buffer_for_dma_u8g2_callback this function doesn't send anything at all, it only cache the data into our DMA buffer. Since STM32 bluepill has 20kb and blackpill has more, so it's easy for us to spare 2.65KB for u8g2 and LCD DMA buffer. According to my tests so far, every time we call u8g2 sendbuffer() function, all the accumulated data before the last EndTransfer call, the total transmitted size is 25XX, so 2.65KB should be enough for our buffer size. Step 1.1 In this store and cache f...
Read more

DIY Weller Solder Tweezers Controller

Image
DIY Weller Soldering Controller for desoldering tweezer Project Objectives: Make a low cost soldering station for Weller solder tweezers.  Finished product: Background: I so happen to have a used Weller desoldering tweezers, obviously I can't use it by itself, so I thought about buying a weller soldering station, oh, the price is surprisingly high, a few hundred dollars to one thousand dollars....so, buying is not an option, not to me.    So I did some investigation, and realized that making our own DIY weller soldering controller is really not that difficult. There are already some people did that, and there are some useful information about the handle schematics and thermocouple info. However some of their design choices could be better. Anyway, let me make one, with some awesome features. Feature List: A nice display of LCD screen1602 (16 characters , 2 lines). It's just about $3 dollars, use I2C to communicate to host MCU. It should show target temperature, current te...
Read more