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
Would like to add support for Cinread IT8951 module #242
Comments
Hello @martinberlin
I went on a hunch and set the values I have little understanding of IT8951. I certainly might be better off getting one of your recommendations. |
@martinberlin Forget for a moment about specifying the offset as described earlier. Since M5Paper's image buffer address was 0x001236E0, I had specified a fixed value in my source code. |
@martinberlin
When spi_3wire is set to true, send and receive are performed on the MOSI pin. |
Hello Lovyan, ESP_LOGI("debug", "_tar_memaddr: %06x", _tar_memaddr); This is what I'm getting now. Is still pointing to a wrong mem address, since I get only a gray image:
Right one seems to be 0x119FC0 (Not sure how's read, but seems buf[3] & buf[4] ?) |
@martinberlin Once again, I have updated the develop branch, so please try this. |
Thanks Lovyan,
It seems to me that changed the speed it's not affecting how it's read. What I don't get correctly is that in specs says this is data[2] and data[3], but what I see if the reading is correctly (Since it does not seem to be a speed issue after last update) Image Buffer Address = 0x119FC0 is coming on I (889) debug: buf[3] = 9fc0 |
@martinberlin As far as I have tried, when the clock is increased, the same value appears in buf more often in succession. I have once again updated the develop branch. I have reduced the send speed and added |
Confirmed!
Some statistics with S3: 125439 bytes read from http://img.cale.es/jpg/fasani/5e636b0f39aac Is quite fast, since it's downloading a 125 Kb JPG and rendering it on the display in 2.5 seconds (After it connects to WiFi) |
Video demo: https://twitter.com/martinfasani/status/1531153415530848256 |
@martinberlin I have come to think that LovyanGFX could have something like EPD's gamma correction process. |
That would be nice addition! I still need to try to load the JPG using your library. It's so far working everytime and it didn't add any noticeable delay to read this address from SPI. By the way this Issue is solved. @lovyan03 you can close it once it's merged in master branch. Thanks a lot for this! |
New Hardware project started after getting this to work: Will be a small HAT that can be connected on top from DEXA-C097 and make it easier for developers to send the image buffer using fast ESP32S3. If you have any wishes for this small PCB just tell it to me over twitter and I will consider adding it. |
Hello @lovyan03 So I tried turning it off using the sleep method from your library. That works and sends the consumption back to 3 mA. UPDATE // Turn on the 3.7 to 5V step-up
gpio_set_level(GPIO_ENABLE_5V, 1);
display.init();
vTaskDelay(pdMS_TO_TICKS(100));
display.wakeup(); It works back again but still shows a strange gray, like if the clearDisplay() would stop before being finished. |
@martinberlin It may be possible to wake up by using the The following functions can be used to change modes.
|
I tried using powerSaveOff() replacing the wakeup code I posted before. The IT8951 is not refreshing the display when I do that. What I can confirm is that looking at consumption, both display.sleep() and display.powerSaveOn() seem to have the same effect, leaving my cheap USB multimeter at 3 mA. But let me know if I need to test any other cases, like doing powerSaveOn before deepsleep and powerSaveOff when the S3 wakes up. My entire demo sketch is here in the epaper-weather-station repository. |
@martinberlin
Try placing a 1 second delay immediately after boot, then run If the image memory is already volatiled, the user's code must redraw the image. Try executing a simple fillCircle in this state. |
I understand. But even doing a: // Turn on the 3.7 to 5V step-up
gpio_set_level(GPIO_ENABLE_5V, 1);
display.wakeup(); // changing this for init() does not change anything
vTaskDelay(pdMS_TO_TICKS(800)); Does not work good. Only if I do: display.init(); // Followed by another init() also works
display.wakeup();
// No wait needed. But even if I do only one init() does not work. I don't get why. Is like if it would need more time but adding a wait 800 ms does not make it. One thing that could be maybe enhanced is the reaction time, since it needs like 1 second from wake-up to update the epaper display. But that's not an important subject right now, what I would like to do is to keep consumption at minimum to do something that developers can take profit for a client's project. One curious thing is that calling wakeup first: display.wakeup();
display.init(); It won't work. Only if you call init() first works right. But if after sleep I call init() just one time, it won't refresh alright, I need to call it two times. |
Last comments where related to also the slow SPI, not only after setVCOM, but it seems also after waking up. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
This issue has been automatically closed because it has not had recent activity. Thank you for your contributions. |
Hello Lovyan,
I've been playing with this tiny new parallel controller that Good display is selling for the 9.7" (1200*825 pix)
Fabricator of the PCB is https://www.cinread.com/EINK.html
After fighting like 3 days with it, I could send the framebuffer using an ESP32S3, but there is still a problem. It's looking like clipped. I'm waiting for Goodisplay support on this, but maybe you know any different initialization, that can make this work better?
For example sending this picture:
I'm getting this displayed on the epaper:
Testing now signals
My test sketch: https://github.com/martinberlin/cale-idf/blob/feature/45-it8951/main/www-jpg-render/main/jpg-render-cinread8951.cpp
Why I would like to make this work?
Because I know it should work with your library just as we could make work the Waveshare big 6" display on #147
And also because at 56 dollars price, plus 25 or 30 more for any generic 9.7" epaper in Aliexpress, could be a nice professional controller to use.
If you would like to get one @lovyan03 I'm shipping one to you and an additional Epaper directly from Aliexpress so you can try some other controller and have a bigger display than M5. Just tell me if you are interested.
The text was updated successfully, but these errors were encountered: