Dan D.

Important changes to forums and questions

All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.

9 years, 1 month ago.

lcd.printf slow?

Hello,

First, thanks for the great library. I'm using a 20x4 character LCD along with the Adafruit I2C backpack. I'm running the I2C bus at 1MHz and things seems to be working well.

Although, I am finding that printf statements are quite slow, taking about 11-12ms to execute. I am often using them using standard stream formatting, ie:

lcd.printf("1:%4u 4:%4u 7:%4u", sensor[0].rawvalue, sensor[3].rawvalue, sensor[6].rawvalue);

Per the LCD's datasheet, a "Set Address" should take 39us and a "Write Data to RAM" should take 43us for a total of 82us, times 20 characters = 1.6ms. I'm sure that's ideal, though.

Is this expected behavior? Can this be improved?

EDIT: Also, i notice that in "TextLCD_Config.h", there is a #define for "LCD_PRINTF" that allows it to be set to 1 or 0. 1 is supposed to enable the Stream implementation of the function. However, i see that allthe "=1" cases in the code are commented out. How is this working?

Thanks again, Dan

Question relating to:

Last updated: 06 Nov 2015
Updated for more display types. Fixed memoryaddress confusion in address() method. Added new getAddress() method. Added support for UDCs, Backlight control and other features such as control through I2C and … HD44780, LCD, PCF2116, ST7032, ST7036, text, TextLCD, WS0010

1 Answer

Wim Huiskamp
9 years, 1 month ago.

Hi Dan, the I2C backpack solutions are indeed relatively slow. The reason is that the LCD device is controlled using 4 bit nibbles. Every command or databyte is spilt up in two parts of 4 bit each. Each of these needs several transactions on the I2C bus (slaveaddress, datanibble1, toggle of the enablebit to write the data, datanibble2,toggle of the enablebit to write the data). That adds up to several bytes I2C traffic @100kbit second. Also note that the lib needs to set the display address for every character to make sure that we can deal correctly with all the possible different display configurations. The instruction delays required by the displaycontroller (39us) come on top of this traffic. You will also need some processing time in the printf routines. All that makes the I2C portexpander solution significantly slower than displays that support native I2C (eg ST7032i). I am looking into possibilities to improve the portexpander solutions, but dont expect dramatic changes. Go for a native SPI or I2C controller if you need more speed. The lib supports those too.

Regarding the LCD_PRINTF define: it serves to remove the mbed printf lib code from the TextLCD library. This will reduce the memory footprint at the cost of loosing all formatting options in the TextLCD lib. You can then use it only to print predefined strings or you need to add your own routines to print integers etc. I did comment out the actual implementation of this define because it breaks all the doxygen html documentation generation due to a bug in Doxygen.. You can reactivate it by removing the comments in the Class declaration for TextLCD (inherit from Stream).

Accepted Answer

Hi Dan, I have improved the I2C portexpander access. Give the new lib (revision 37) a go. Should be about twice as fast as the previous version.

posted by Wim Huiskamp 29 Mar 2015