![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2018\/09\/HD44780_baner-1024x341.jpg\")
<\/a><\/figure>\n<\/div>\n\n\n<\/p>\n\n\n\n
LCD 2\u00d716 display<\/h1>\n\n\n\n
An alphanumeric LCD, or character LCD, combines many advantages such as ease of use, low price, and transflectivity in the positive version. Its drawbacks are undoubtedly weak contrast and a low refresh rate.<\/p>\n\n\n\n
Supply voltage can also turn out to be a problem. The market is dominated by displays with a 5V supply level, especially from the \u201cmajfriends\u201d. Is that a problem? In __this__<\/a> post I pointed out one of the advantages of STM32, namely 5V\u2011tolerant IO. The voltage level coming out of the LCD is taken care of. What about the input? Usually the high\u2011level tolerance of the display controller is wide enough that 3.3V should be sufficient to drive it. My test specimen is intended for 5V, yet I was able to drive it from an STM32 successfully. You can also get a 3.3V version since such ones are increasingly available, but for \u201cextra\u201d you may have to pay \u201cextra\u201d.<\/p>\n\n\n\n To talk to a classic HD44780\u2011compatible LCD we have two interfaces available \u2013 4\u2011bit and 8\u2011bit. I veeery rarely see anyone using the 8\u2011bit one. After all, it takes 4 precious MCU pins more than the popular 4\u2011bit version. In each of these modes we can in turn send data in two ways. One is continuous write<\/em> mode with the display\u2019s RW<\/em> signal tied to ground. It\u2019s the simplest and the one often found in online descriptions. The other method is handling with reading the busy flag. This requires connecting the RW<\/em> pin to the microcontroller and controlling the data direction on the MCU<->LCD line. Cost: one additional MCU pin.<\/p>\n\n\n\n I\u2019d like to test all these methods and compare them in terms of the time required to send an entire 2\u00d716 character frame to the display. Curious about the results?<\/p>\n\n\n\n The test platform will be a Nucleo\u201164 with an STM32F401RE, with HCLK<\/em> set to 84 MHz.<\/p>\n\n\n <\/p>\n\n\n\n This approach is probably the most popular among alphanumeric LCD users. I\u2019m not surprised at all. It\u2019s the simplest to implement and \u201ccosts\u201d us little in terms of MCU resources.<\/p>\n\n\n\n To drive the display I will use Nucleo F401RE<\/a>.<\/p>\n\n\n <\/p>\n\n\n\n The connection diagram looks as follows:<\/p>\n\n\n <\/p>\n\n\n\n and the STM32CubeMX configuration<\/p>\n\n\n <\/p>\n\n\n\n From the standpoint of measuring refresh time, we\u2019re interested in the time to send all commands and data to the display so that the test text appears. By tying the RW<\/em> pin to ground, we put the display into continuous write mode. In this mode you must adjust the wait time between sending subsequent data so that it is longer than the processing of the previous byte. First I\u2019ll do this using the simplest HAL_Delay(), which is offered by ST\u2019s library.<\/p>\n\n\n\n The test code I will base on looks as follows:<\/p>\n\n\n\n Unfortunately the HAL_Delay() function works with a minimum resolution of 1 ms, which is the time base for the entire STM32HAL library. For the display this is relatively long, hence the result is poor. You can clearly see the refresh on the screen because it\u2019s simply too slow. The entire test refresh procedure takes as much as 67.29 ms! That\u2019s more than three times longer than what the human eye needs to be fooled and not notice the refresh. Because of this you can also see how the second line of characters flickers badly.<\/p>\n\n\n <\/p>\n\n\n\n We need to speed this up! Unfortunately ST\u2019s library doesn\u2019t have any delay function with finer resolution. What now? I\u2019m ending the post. You can\u2019t do it on STM32 \u2013 Arduino is better \ud83d\ude41<\/p>\n\n\n\n <\/p>\n\n\n\n The MCU used in the example (like every STM32) has plenty of hardware timers. Why let them sit and gather dust? I\u2019ll use one for the delay<\/em>. Which one? For now I won\u2019t dive into the intricacies of timers and will quickly go over the configuration. Today the random choice fell on TIM3 with internal clocking. The Delay<\/em> we need should operate with 1 \u00b5s resolution, so using the magic formula we end up with a required clock of 1 MHz. Using another magic formula, with an 84 MHz clock, to supply 1 MHz to TIM3 I need to set the prescaler<\/em> to 83. I\u2019ll set the counting direction to Up, a <\/em>CounterPeriod <\/em>to the maximum value, i.e., 65535 (16\u2011bit timer). I\u2019ll leave other settings at defaults. I won\u2019t enable any interrupts or other bells and whistles for the timer. After setting it up, I regenerate the project code.<\/p>\n\n\n <\/p>\n\n\n\n For clarity I wrote the delay<\/em> code in separate files \u2013 delays.c<\/em> and delays.h. <\/em><\/p>\n\n\n\n After setting the delay between sending bytes to 120 \u00b5s, a problem appeared in the form of cutting off the beginning of the frame. The issue lies in processing the previously written cls<\/em> and locate<\/em> commands. By shortening the data transfer I also had to extend the wait after commands, as their execution takes a bit longer than accepting data. I tested various numbers of microseconds, but quickly approached a value of 1 ms.<\/p>\n\n\n\n Result? It\u2019s definitely better. You can\u2019t see \u201cwriting\u201d across the screen, so it\u2019s acceptable. Execution time? 7.14 ms, which means we can squeeze out about 140 Hz max. Success!<\/p>\n\n\n <\/p>\n\n\n\n In the next post I\u2019ll handle the busy flag. I\u2019ll see how much further I can shorten the frame transmission \ud83d\ude09<\/p>\n\n\n\n The second part of the post is >>here<<<\/a>.<\/p>\n\n\n\n If you like the display, you can buy it in various versions in my store<\/a>.<\/p>\n\n\n\n The complete code from this series of posts is on my GitHub: link<\/a><\/p>\n\n\n\n To end this post, I encourage discussion in the comments about handling the LCD on STM32. Do you think I made a mistake somewhere? Do you have an interesting idea for what can be improved? Share it in a comment! Remember that the discussion should be courteous and in accordance with the rules of the Polish language.<\/p>\n\n\n![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2018\/07\/20180717_215128.jpg\")
<\/a><\/figure>\n<\/div>\n\n\n4\u2011bit bus without checking the busy flag<\/h2>\n\n\n\n
![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2020\/07\/Nucleo-64-baner.jpg\")
<\/a><\/figure>\n<\/div>\n\n\n![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2018\/07\/4bit_bez_RW_KiCad_5V.png\")
<\/a><\/figure>\n<\/div>\n\n\n![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2018\/07\/4bit_bez_RW_Cube.png\")
<\/a><\/figure>\n<\/div>\n\n\n\/\/\n\/\/ Write byte to LCD\n\/\/\nvoid LCD_WriteByte(uint8_t data)\n{\n\tSET_LCD_E;\n\tLCD_SetDataPort(data >> 4);\n\tRESET_LCD_E;\n\n\tSET_LCD_E;\n\tLCD_SetDataPort(data);\n\tRESET_LCD_E;\n\n\tHAL_Delay(1); \/\/ <<--- wait for data processing\n}<\/pre>\n\n\n\nwhile (1)\n{\n\t\/\/ Measurement start\n\tLCD_Cls();\n\tLCD_Locate(0,0);\n\tLCD_String(\" STM32 + HD44780\");\n\tLCD_Locate(0,1);\n\tLCD_String(\"www.msalamon.pl \");\n\t\/\/ Measurement end\n\tHAL_GPIO_TogglePin(LED_GPIO_Port, LED_Pin);\n\tHAL_Delay(500);\n}<\/pre>\n\n\n\n![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2018\/07\/4-bit_bez_RW_HAL_Delay.png\")
<\/a><\/figure>\n<\/div>\n\n\nI WAS JOKING!<\/h3>\n\n\n
![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2018\/07\/Timery.png\")
<\/a><\/figure>\n<\/div>\n\n\n![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2018\/07\/TIM3_conf.png\")
<\/a><\/figure>\n<\/div>\n\n\nvoid Delay_us(uint16_t us)\n{\n htim3.Instance->CNT = 0;\n while(htim3.Instance->CNT <= us);\n}<\/pre>\n\n\n\n\/\/\n\/\/ Write byte to LCD\n\/\/\nvoid LCD_WriteByte(uint8_t data)\n{\n\tSET_LCD_E;\n\tLCD_SetDataPort(data >> 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\tDelay_us(120); \/\/<<--- wait for data processing\n}\n\n\/\/\n\/\/ Write command to LCD\n\/\/\nvoid LCD_WriteCmd(uint8_t cmd)\n{\n\tRESET_LCD_RS;\n\tLCD_WriteByte(cmd);\n\tDelay_us(1000);\/\/<<--- wait for command processing\n}<\/pre>\n\n\n\n![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2018\/07\/4-bit_bez_RW_TIM_Delay_us.png\")
<\/a><\/figure>\n<\/div>\n\n\n