{"id":4361,"date":"2018-08-08T20:00:48","date_gmt":"2018-08-08T18:00:48","guid":{"rendered":"https:\/\/msalamon.pl\/?p=4361"},"modified":"2025-12-27T20:37:15","modified_gmt":"2025-12-27T19:37:15","slug":"16x2-lcd-display-on-stm32-hal-part-2","status":"publish","type":"post","link":"https:\/\/msalamon.pl\/en\/16x2-lcd-display-on-stm32-hal-part-2\/","title":{"rendered":"16\u00d72 LCD Display on STM32 + HAL, Part 2"},"content":{"rendered":"\n

In the last >>part<<<\/a> I examined the refresh time of a 16\u00d72 LCD on STM32 using a 4-bit communication bus and a predetermined wait time for processing the supplied data. Today I will check how reading<\/p>\n\n\n\n\n\n\n\n

the so-called busy flag by the MCU will affect the refresh time. Let’s go!<\/p>\n\n\n

\n
\"\"<\/a><\/figure>\n<\/div>\n\n\n

<\/p>\n\n\n\n

4-bit bus with busy flag checking<\/h1>\n\n\n\n

To read the busy flag<\/em> from the display controller, I need to modify the wiring and the code. The modifications I made are:<\/p>\n\n\n\n

    \n
  1. \n
      \n
    1. Pin no. 5, i.e., RW<\/em>, will this time be connected to the STM32, which will control the direction of data flow on the bus. Thanks to this, it will be possible to read data from the LCD.<\/li>\n<\/ol>\n<\/li>\n\n\n\n
    2. Changing the direction of the GPIO<\/em> dedicated to communication with the display \u201con the fly\u201d. The library is supposed to do this by itself.<\/li>\n<\/ol>\n\n\n
      \n
      \"\"<\/a><\/figure>\n<\/div>\n\n\n

      <\/p>\n\n\n\n

      I will configure the GPIO for pins LCD_DB4\u2026LCD_DB7 as Input<\/em> or Output<\/em> in the way suggested by STM32CubeMX. I have also appropriately modified the transmit and receive functions.<\/p>\n\n\n\n

      As a base I will use Nucleo<\/a> F401RE.<\/a><\/p>\n\n\n

      \n
      \"\"<\/a><\/figure>\n<\/div>\n\n\n

      <\/p>\n\n\n

      \n
      \"\"<\/a><\/figure>\n<\/div>\n\n\n

      <\/p>\n\n\n\n

      static void LCD_DataOut()\n{\n\tGPIO_InitTypeDef GPIO_InitStruct;\n\n\tGPIO_InitStruct.Pin = LCD_DB4_Pin|LCD_DB5_Pin|LCD_DB6_Pin|LCD_DB7_Pin;\n\tGPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;\n\tGPIO_InitStruct.Pull = GPIO_NOPULL;\n\tGPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;\n\tHAL_GPIO_Init(GPIOB, &amp;GPIO_InitStruct);\n}\n\nstatic void LCD_DataIn()\n{\n\tGPIO_InitTypeDef GPIO_InitStruct;\n\n\tGPIO_InitStruct.Pin = LCD_DB4_Pin|LCD_DB5_Pin|LCD_DB6_Pin|LCD_DB7_Pin;\n\tGPIO_InitStruct.Mode = GPIO_MODE_INPUT;\n\tGPIO_InitStruct.Pull = GPIO_NOPULL;\n\tHAL_GPIO_Init(GPIOB, &amp;GPIO_InitStruct);\n}\n\n\/\/\n\/\/ Write byte to LCD\n\/\/\nuint8_t LCD_ReadByte(void)\n{\n\tuint8_t result = 0;\n\tLCD_DataIn();\n\n\tSET_LCD_RW;\n\n\tSET_LCD_E;\n\tresult = (LCD_GetDataPort() &lt;&lt; 4);\n\tRESET_LCD_E;\n\n\tSET_LCD_E;\n\tresult |= LCD_GetDataPort();\n\tRESET_LCD_E;\n\n\treturn result;\n}\n\n\/\/\n\/\/ Check Busy Flag\n\/\/\nuint8_t LCD_CheckBusyFlag()\n{\n\tRESET_LCD_RS;\n\treturn LCD_ReadByte();\n}\n\n\/\/\n\/\/ Write byte to LCD\n\/\/\nvoid LCD_WriteByte(uint8_t data)\n{\n\tLCD_DataOut();\n\n\tRESET_LCD_RW;\n\n\tSET_LCD_E;\n\tLCD_SetDataPort(data &gt;&gt; 4);\n\tRESET_LCD_E;\n\n\tSET_LCD_E;\n\tLCD_SetDataPort(data);\n\tRESET_LCD_E;\n\n\t\/\/ HAL_Delay(1);\n\t\/\/ Delay_us(120); \/\/ Wait for data processing\n\twhile((LCD_CheckBusyFlag() &amp; (1&lt;&lt;7))); \/\/ Wait for data processing\n}<\/pre>\n\n\n\n
      I run the code and\u2026 WOW! Although the microcontroller performs a ton of operations on the pins, the frame refresh time was only 2,74 ms! Is this speed worth one GPIO pin? I think in many cases definitely yes.<\/p>\n\n\n
      \n
      \"\"<\/a><\/figure>\n<\/div>\n\n\n
      <\/p>\n\n\n\n
      Or maybe I can shave off a bit more? The LCD controller offers up to an 8-bit communication bus width. I will check whether doubling the amount of data sent at once will halve the frame refresh time. First I will check without reading the busy flag.<\/p>\n\n\n\n
      8-bit bus without busy flag checking<\/h2>\n\n\n\n
      Due to the hopelessly long refresh time I achieved using only the delay<\/em> functions built into STM32HAL, I will skip considering this method for 8-bit. I will perform measurements only using a function operating on a timer<\/em>.<\/p>\n\n\n\n
      I start by connecting the remaining 4 lines, i.e., LCD_DB0\u2026LCD_DB3.<\/p>\n\n\n
      \n
      \"\"<\/a><\/figure>\n<\/div>\n\n\n
      <\/p>\n\n\n\n
      The code modification consists of assigning new functions to the appropriate pins in STM32CubeMX<\/p>\n\n\n
      \n
      \"\"<\/a><\/figure>\n<\/div>\n\n\n
      <\/p>\n\n\n\n
      \u2026and modifying the code for the wider bus. The functions related to setting the GPIO pins, sending one byte of data, and the display initialization function change, which now sets the LCD controller to 8-bit mode.<\/p>\n\n\n\n
      The time obtained is nothing special. Basically, almost nothing got shorter compared to the 4-bit version. The whole frame transferred in 7,11 ms.<\/p>\n\n\n
      \n
      \"\"<\/a><\/figure>\n<\/div>\n\n\n
      <\/p>\n\n\n\n
      8-bit bus with busy flag checking<\/h2>\n\n\n\n
      For the 4-bit mode, replacing delays<\/em> with reading LCD busyness worked brilliantly \u2013 the time decreased significantly. I will check whether for 8-bit the result will be equally spectacular.<\/p>\n\n\n
      \n
      \"\"<\/a><\/figure>\n<\/div>\n\n\n
      <\/p>\n\n\n
      \n
      \"\"<\/a><\/figure>\n<\/div>\n\n\n
      <\/p>\n\n\n\n
      I rework the code and\u2026 to be honest, I expected something better \ud83d\ude41 In this way I got 2,74 ms, i.e., exactly the same result as with the 4-bit mode.<\/p>\n\n\n
      \n
      \"\"<\/a><\/figure>\n<\/div>\n\n\n
      <\/p>\n\n\n\n
      Further optimization?<\/h2>\n\n\n\n
      You can still replace the HAL functions for controlling GPIO<\/em> with direct register operations. Is it worth going further down this road? Probably not. It should be possible to shave off maybe 0,2 ms, because the time to set GPIO<\/em> unfortunately has a negligible effect \u2013 the waiting time for the LCD controller is definitely greater, and I won\u2019t shorten that.<\/p>\n\n\n\n
      Looking at the waveforms you can also infer quite an interesting thing. Namely, the first 1,5 ms at the beginning of the transfer is spent clearing the display. With busy-flag handling, this is more than half the time needed to display two full lines! Maybe that\u2019s where to try to bite? For example, instead of sending the clear command, write spaces, hmm? Or send a pre-prepared complete buffer from the microcontroller\u2019s RAM? There are many ways to buffer and in the future a thread on this topic will certainly appear on the blog.<\/p>\n\n\n\n
      Summary<\/h2>\n\n\n\n
      I\u2019ve reached the end \ud83d\ude42 I examined all 4 possible ways of communicating with a popular LCD display with a controller compatible with HD44780 using the STM32F401RE microcontroller. The research results are presented in the table below.<\/p>\n\n\n\n
      Mode<\/th>Time<\/th><\/tr><\/thead>
      4-bit HAL_Delay<\/td>67,29 ms<\/td><\/tr>
      4-bit without BF<\/td>7,14 ms<\/td><\/tr>
      4-bit with BF<\/td>2,74 ms<\/td><\/tr>
      8-bit without BF<\/td>7,11 ms<\/td><\/tr>
      8-bit with BF<\/td>2,74 ms<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
      Which mode to use? You can immediately reject the method using the built-in HAL_Delay<\/em>. This time is definitely unacceptable! Don\u2019t waste your life, I don\u2019t recommend it.<\/p>\n\n\n\n
      Comparing the two 4-bit modes shows how big an impact reading the busy flag has. You don\u2019t have to guess when the controller is ready to accept data, lengthening the whole procedure. Reducing the time by more than 2.5x costs only one GPIO<\/em> pin. This time can be very valuable in a more complex project.<\/p>\n\n\n\n
      And what about 8 bits? Smoke and mirrors. The results are almost identical to those with a data bus that\u2019s twice as narrow. What does this mean? You can completely skip this mode when using alphanumeric displays. Entering 8-bit mode is a waste of four valuable microcontroller pins.<\/p>\n\n\n\n
      If you like the display, you can buy it in various variants in my store<\/a>.<\/p>\n\n\n\n
      The test code along with the library can be found on my GitHUB: link<\/a><\/p>\n\n\n\n
      In the end, I encourage you to discuss in the comments the handling of the LCD display on STM32. Do you think I made a mistake somewhere? Do you have an interesting idea on what can be improved? Share it in the comments! Remember that the discussion should be polite and in accordance with the rules of the Polish language.<\/p>\n\n\n
      \n            \n
      \n    \n
      \n            
      \n            \n\n
      <\/div>\n        <\/div>\n            
      \n            \n\n
      <\/div>\n        <\/div>\n            
      \n            \n\n
      <\/div>\n        <\/div>\n            
      \n            \n\n
      <\/div>\n        <\/div>\n            
      \n            \n\n
      <\/div>\n        <\/div>\n    <\/div>\n    \n
      \n            
      \n            \n\n
      <\/div>\n        <\/div>\n            
      \n            \n\n
      <\/div>\n        <\/div>\n            
      \n            \n\n
      <\/div>\n        <\/div>\n            
      \n            \n\n
      <\/div>\n        <\/div>\n            
      \n            \n\n
      <\/div>\n        <\/div>\n    <\/div>\n<\/div>\n                \n\n
      \n            <\/span>\n    <\/div>\n    <\/div>\n","protected":false},"excerpt":{"rendered":"
      In the last >>part<< I examined the refresh time of a 16\u00d72 LCD on STM32 using a 4-bit communication bus and a predetermined wait time for processing the supplied data. Today I will check how reading<\/p>\n","protected":false},"author":1,"featured_media":2932,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","_links_to":"","_links_to_target":""},"categories":[160],"tags":[175,176,174,177],"class_list":["post-4361","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-stm32","tag-electronics","tag-programming","tag-stm32","tag-stm32cubemx"],"_links":{"self":[{"href":"https:\/\/msalamon.pl\/en\/wp-json\/wp\/v2\/posts\/4361","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/msalamon.pl\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/msalamon.pl\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/msalamon.pl\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/msalamon.pl\/en\/wp-json\/wp\/v2\/comments?post=4361"}],"version-history":[{"count":3,"href":"https:\/\/msalamon.pl\/en\/wp-json\/wp\/v2\/posts\/4361\/revisions"}],"predecessor-version":[{"id":4472,"href":"https:\/\/msalamon.pl\/en\/wp-json\/wp\/v2\/posts\/4361\/revisions\/4472"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/msalamon.pl\/en\/wp-json\/wp\/v2\/media\/2932"}],"wp:attachment":[{"href":"https:\/\/msalamon.pl\/en\/wp-json\/wp\/v2\/media?parent=4361"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/msalamon.pl\/en\/wp-json\/wp\/v2\/categories?post=4361"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/msalamon.pl\/en\/wp-json\/wp\/v2\/tags?post=4361"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}