cancel
Showing results for 
Search instead for 
Did you mean: 

Inefficient BSP LCD code

bitbank
Associate II
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);
  }
}
1 ACCEPTED SOLUTION

Accepted Solutions

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!

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

View solution in original post

3 REPLIES 3
Danish1
Lead II

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.

bitbank
Associate II

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.

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!

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..