Skip to main content
Explorer
April 9, 2024
Solved

Inefficient BSP LCD code

  • April 9, 2024
  • 2 replies
  • 1659 views
After poking around a bit more in the STM32CubeIDE code, I'm seeing a pattern of issues that indicate a serious lack of understanding on the part of the authors of the shipping BSP code. This code was written several years ago, but it is the shipping version and suffers from serious performance problems due entirely to the inexperience of the authors. A good example:
 
Taken from (STM32Cube_FW_F7_V1.17.1/Drivers/BSP/Components/st7735)
 
In the st7735_WritePixel() function below, the author is creating 2 unique SPI transactions to send the 16 bits of the pixel color instead of sending a single 2 byte transaction. This wouldn't be such a big deal except that other graphics primitives depend on this function (e.g. DrawVLine() below).
The DrawVLine() function takes 2 orders or magnitude longer than needed simply because the author doesn't understand how Sitronix LCD controllers use memory windows to control the write pointer. It naively calls the WritePixel function and compounds the performance problem. I can find other examples, but this is enough to indicate that every component within the BSP needs a full code review. These may seem like simple issues, but the SPI LCD components are full of badly performing code like this. When using this code, it will reflect poorly on the actual speed of the MCUs because LCDs will display everything much slower than necessary. Is anyone at ST interested in fixing this?
 
/**
  * @brief  Writes pixel.
  * @PAram  Xpos: specifies the X position.
  * @PAram  Ypos: specifies the Y position.
  * @PAram  RGBCode: the RGB pixel color
  * @retval None
  */
void st7735_WritePixel(uint16_t Xpos, uint16_t Ypos, uint16_t RGBCode)
  uint8_t data = 0;
  if((Xpos >= ST7735_LCD_PIXEL_WIDTH) || (Ypos >= ST7735_LCD_PIXEL_HEIGHT))
  {
    return;
  }
  
  /* Set Cursor */
  st7735_SetCursor(Xpos, Ypos);
  
  data = RGBCode >> 8;
  LCD_IO_WriteMultipleData(&data, 1);
  data = RGBCode;
  LCD_IO_WriteMultipleData(&data, 1);
}
/**
  * @brief  Draws vertical line.
  * @PAram  RGBCode: Specifies the RGB color
  * @PAram  Xpos: specifies the X position.
  * @PAram  Ypos: specifies the Y position.
  * @PAram  Length: specifies the line length.
  * @retval None
  */
void st7735_DrawVLine(uint16_t RGBCode, uint16_t Xpos, uint16_t Ypos, uint16_t Length)
{
  uint8_t counter = 0;
 
  if(Ypos + Length > ST7735_LCD_PIXEL_HEIGHT) return;
  for(counter = 0; counter < Length; counter++)
  {
    st7735_WritePixel(Xpos, Ypos + counter, RGBCode);
  }
}
    This topic has been closed for replies.
    Best answer by Tesla DeLorean

    The threshold is definitely "look it works"

    I think some investment of time here, both in the BSP for ST product, or more broadly popular/likely product selected by the customer, would make the platform much more appealing. At this point I think it's time/resource constrained.

    The examples are generally coded by people with about as much competence as the customers, perhaps a little more, and with better/deeper support team behind them, but it definitely not what I'd call production code. Customers are expected to take it and rework/refactor to suit their standards, and deal with error handling better than stopping and dying.

    The problem is generally compounded by a want everything, pay nothing attitude. Nobody really wants to pay for good "help" or code at this point. So the market adapts, gets some "working" code, and Just Sends It!

    2 replies

    Graduate
    April 9, 2024

    In my opinion the vast majority of ST code as generated/supplied by Cube, HAL, LL is "demonstration" code. It is there to enable us to throw something together quickly and easily with a fair chance that it will work.

    I do not think they aspire to make the code efficient (or, for that matter truly reliable). I rather suspect that with some of their code, attempts to improve efficiency will break the code because of things like needing to enable clocks to a peripheral a certain number of peripheral-ticks before the first write to that peripheral.

    And I have yet to see any rigorous documentation (by which I mean explanations along the lines of "you should do this in this particular order and keep these arguments to those values").

    My approach is to base my code on the Reference Manual. Only where I need to get a demonstration together quickly or I'm struggling to understand the Reference Manual* will I look at HAL.

    *This happens more often than I like. But I do persevere.

    Graduate II
    April 9, 2024

    The threshold is definitely "look it works"

    I think some investment of time here, both in the BSP for ST product, or more broadly popular/likely product selected by the customer, would make the platform much more appealing. At this point I think it's time/resource constrained.

    The examples are generally coded by people with about as much competence as the customers, perhaps a little more, and with better/deeper support team behind them, but it definitely not what I'd call production code. Customers are expected to take it and rework/refactor to suit their standards, and deal with error handling better than stopping and dying.

    The problem is generally compounded by a want everything, pay nothing attitude. Nobody really wants to pay for good "help" or code at this point. So the market adapts, gets some "working" code, and Just Sends It!

    bitbankAuthor
    Explorer
    April 9, 2024

    I think you are correct about the creation side of the BSP code, but unfortunately I think that there are a ton of shipping products with the ST supplied code (unchanged) in them.