Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Message draw slow compared to legacy library (Adafruit_CharLCDPlate) #55

Open
LamptonWorm opened this issue Jan 23, 2021 · 11 comments
Open
Assignees

Comments

@LamptonWorm
Copy link

LamptonWorm commented Jan 23, 2021

Hi,

I'm using one of the older Adafruit i2c 16x2 RGB LCD Pi Plates with a Rasp. Pi 2 Model B v1.1
CircuitPython_CharLCD is working fine, but message draw is slow compared to the legacy library here https://github.com/adafruit/Adafruit-Raspberry-Pi-Python-Code/tree/legacy/Adafruit_CharLCDPlate.
You can see each letter drawing in turn, whereas the legacy code is almost instant.

Thanks,

@Arnwaltur
Copy link

Same experience here. It makes using a menu rather unpleasant.

@szyg
Copy link

szyg commented Jul 29, 2022

Also noticed the same problem. The slow refresh makes any updates to the display very jarring compared to the old library. Any plans to update this library? Any luck by others to increase the draw speed or did you just revert to the old library?

Update: Using 2to3 to convert the legacy library works just fine to run under python3 with full redraw speed.

@ladyada
Copy link
Member

ladyada commented Aug 1, 2022

are you both using older raspi computers? its a little slower here due to a refactor

@szyg
Copy link

szyg commented Aug 1, 2022

I am running on a Pi 3b model a22082. New library displays with a very distracting left to right sweep on every redraw where the old is barely a flicker. Running Raspberry OS 11 Bullseye if that is useful. Using the converted legacy library is working great for now.

@ladyada
Copy link
Member

ladyada commented Aug 1, 2022

@Neradoc do you want to try improving the performance? basically we should write 4 bits at a time rather than using DigitalIO which is more elegant but slower

@dhalbert
Copy link
Contributor

dhalbert commented Aug 1, 2022

I wrote my own char LCD library a long time ago for PCF8574 chips: https://github.com/dhalbert/CircuitPython_LCD. It does 4-bit writes. I think it could be adapted to the MCP23008 supported by this library. It is also factored in such a way that the chip-specific logic is separate from the main library.

@Arnwaltur
Copy link

@ladyada Yes, using Pi 1 & 2. It is slow and the CPU load is high compared to the old library. I use it for a web radio, and it's not uncommon for the sound to chop when the screen displays new text.

@LamptonWorm
Copy link
Author

Hi, just to confirm, yes I was also seeing this on an older Pi 2 Model B v1.1 .. thanks!

@PaulHutchInMA
Copy link

I just bought the I2C/SPI backpack (#292) with a _Standard LCD 16x_2 (#181) and am using it with a MCP2221 (#4471) on a PC running Debian 11. It takes over 6 seconds to write "Hello CircuitPython" to the display.

I tried it on a Windows 10 PC with the same result.

I found the display update speed does not change when I switch the MCP2221's I2C speed from 100kHz to 400kHz.

This is almost completely useless, I could even live with 1 second to write 19 characters but >6 seconds is not useful.

@ChaoticPumpkin
Copy link

If there isn't any easy way to fix the data transmission speed issue, is there any way to buffer the screen data and then update it all at once? The docs didn't mention anything like that, so I'm guessing no, but I might be wrong. I'm just hoping to find a way to get more responsiveness with this library.

@ladyada
Copy link
Member

ladyada commented Sep 30, 2023

yes someone could help write a variant of this library that can write the 4 data bits at once instead of one at a time, optimizations would help but of course would have to be implemented for each chipset

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants