LilyGo-EPD47
LilyGo-EPD47 copied to clipboard
rotate screen
is it possible to rotate the screen, from landscape to portrait? Thanks
Can't rotate right now...
Hopefully in the future?
It should be possible in the future!
My solution for now is to build a static text image using GIMP, with a size of 540x960, put the text I want displayed, and rotate the image. Then display that image...this works, but it is only static text - so not really practical.
Of course using GIMP, rotating/resizing images is easy to do, however the aspect ratio will probably be off.
I look forward to when this device natively supports rotating. Thanks.
I agree it would be great if at least text can be rotated
M5EPD driver (for the M5Paper) looks like it supports rotation, but I'm not sure what pins need to be changed to try with this display. I think they are using the same display, but are they using a different driver to drive it (?).
https://github.com/m5stack/M5EPD
This is the pin map for the M5Paper:
#define M5EPD_MAIN_PWR_PIN 2 #define M5EPD_CS_PIN 15 #define M5EPD_SCK_PIN 14 #define M5EPD_MOSI_PIN 12 #define M5EPD_BUSY_PIN 27 #define M5EPD_MISO_PIN 13 #define M5EPD_EXT_PWR_EN_PIN 5 #define M5EPD_EPD_PWR_EN_PIN 23 #define M5EPD_KEY_RIGHT_PIN 39 #define M5EPD_KEY_PUSH_PIN 38 #define M5EPD_KEY_LEFT_PIN 37 #define M5EPD_BAT_VOL_PIN 35 #define M5EPD_PORTC_W_PIN 19 #define M5EPD_PORTC_Y_PIN 18 #define M5EPD_PORTB_W_PIN 33 #define M5EPD_PORTB_Y_PIN 26 #define M5EPD_PORTA_W_PIN 32 #define M5EPD_PORTA_Y_PIN 25
It has other sensors, and a SD card which wouldn't be needed, so a striped down version of the library? Does anyone know what needs to be changed?
I’ve only just started to look at this board and driver, have you tried reversing EPD_WIDTH and HEIGHT? I’ve seen examples that have been drawn in landscape with no obvious driver changes.
the LilyGo driver is based on this https://github.com/vroland/epdiy driver - it appears to be in landscape to start with. I have thought about asking this same question on that repository, which maybe a good idea anyway. (If you read some of the post in that repository, you soon find out they reverse engineered the driver. So that's interesting) I know that M5Paper is using the same display, I don't know if it is using the same driver, M5Paper appears to be able to rotate the screen at least 90 degrees (one of the examples they have). and honestly I haven't tried anything with regards to the M5Paper driver.
With the driver provided by LilyGo I did try to change the EPD_WIDTH and HEIGHT with no luck (that would have been too simple honestly).
The pictures above, are really in landscape, just flipped and are static pictures -it was an idea that I had, it wasn't a good idea...but there you go. I created those images in GIMP and converted them to hex files for use on the board with the LilyGo driver.
I will play with the M5Paper driver a bit and see if I can get anything to work.
This is the schematic for the M5Paper - https://m5stack.oss-cn-shenzhen.aliyuncs.com/resource/docs/schematic/Core/m5paper/M5_PAPER_SCH.pdf This is the one @vke posted in the closed hardware thead (https://github.com/Xinyuan-LilyGO/LilyGo-EPD47/issues/2#issuecomment-757875009)
If I right, they are using two different drivers for the display (?) or am I looking at something wrong.
I tried the M5Paper library as is, with no luck, and then found the schematics.
As far as I understand how the driver works, all the graphics and text are drawn in the buffer and the buffer uploaded to the screen. So if you swap X and Y when drawing in the buffer I think you'll rotate the content of the screen.
@fdufnews Seems like all I am able to get it to do is move text and images around on the screen using the framebuffer. perhaps I am not using the framebuffer correctly have you tested it? can you post an example. Thanks
I have not tried rotating yet, but I'm sure font rotation will not be achieved, yes drawing objects could have their x, y values reversed, but that's all.
I am having to rotate the images in gimp before converting them to hex, it works, but it is one extra step. Of course if you are having to resize an image it only takes an extra couple of clicks to rotate it. So far that is the only way I've been able to rotate anything.
I used "Fontforge" to rotate some fonts, and converted them - but didn't have much luck getting more than 5 or 6 to display. I was trying to direct draw them, maybe I should try to load them into the buffer and see if I can't get a more then 5 or 6 characters to display. I'll give it a try and report back - but it quite a lot of extra steps to rotate a font, so still not the best option, it might be an "ok" work around for now, if loading into the buffer works that is.
Loading the framebuffer with the font that I rotated, worked (mostly), my code is not pretty, and probably not ready to be shared. And it's a lot of work to rotate fonts, in fact I think I messed up the "i" when I did it...but proof of concept I guess.
maybe we can build some common rotated fonts, and make a function that can load the framebuffer with them. (?)
@G6EJD Another proof of concept that isn't quite right, but someone who knows more can probably fix it.
The idea is to rotate the font with a font editor, convert the font, then display the font. I used fontforge to do this, I kind of "winged" my way to doing it.
I wrote a small function to load the framebuffer with a rotated font, the spacing is off, not sure how to fix that - I'm sure it's something simple that I'm over looking.
Also it has an issue if you load a 2nd or 3rd rotated char array, (see the picture) I'm not sure what it is doing, I cleared the framebuffer and it is still doing it.
So this is very much an idea, a concept, a work in progress, and something that someone who knows something can probably fix.
fontRotate.zip
P.S. this still may not be the best idea, but I'm trying things out - and that is half the fun. LOL
I’ll have a look through this today, but I’ll also look at the driver data sheet as I’m guessing there may well be a hardware option to do this. Your method could be a solution, thanks for sharing.
Looking through the ED047TC1 data sheet there is mention of the display modes being Landscape and Portrait, so I assume from this it can be rotated by hardware/ Register control, I have not yet found the application notes if there are any or a more detailed description of the registers. This is promising.
So M5 Display driver is an IT8951 versus the ED047TC1 of the LilyGo EPD board.
Unfortunately, I have not found any reference to the driver registers/control but my instinct is it's usually used in portrait mode!
So LilyGo EPD is bit banging the display (?) vs M5 using a driver chip (?) I have been looking for and all I see are various timings for the ED047TC1 but I don't see anything that says how to rotate it. But the datasheets do look like it will do both landscape and portrait. These all look like the same spec sheet... https://loboris.eu/ESP32/ED047TC1_datasheet.pdf https://www.syscom-prorep.net/media/images/upload/P-511-710-V1_ED047TC1%20Ver%201.0.pdf https://docplayer.net/61566900-Technical-specification-model-no-ed047tc1.html
And this is a forum post about the M5 paper which also has links to the display panel datasheet. https://community.m5stack.com/topic/2561/m5paper-schematic/7
That’s where I got to, but no register descriptions which would lead the way to rotating the display. I had a look through the M5 library but not find how they are rotating the display if at all.
@G6EJD I guess we will just have to wait and see if Lilygo or @lewisxhe can come up with something, mean while I'll continue to do some of my ideas for work arounds, but I don't really like what I've done, lots of work for little pay off. Have a great day.
I'm supporting rotation in my class ED047TC1 both for the epaper and also for the touch screen. Proof of concept video here Note: I'm implementing also EPDiy class to send the parallel data but I have another Adafruit GFX layer in my class that handles rotation. At the same time if you implement the touch version, rotating the displays, also sends the rotation to the touch I2C layer so it's possible to keep on using touch coordinates.
@martinberlin very nice!! Maybe one day it will work with the Arduino IDE as well (?)
Hi Leroy, If you look at the class ED047TC1 methods it's actually not too complicated. You need to keep rotation state and then update the X, Y before the epd_draw_pixel call (And I guess also in partial update if you want that it supports rotation). Actually EPDiy is a esp-idf component that can be used in arduino-esp32. I never tried to do so with mine and it's quite a long time I don't use arduino-esp32 since I like more IDF this days. I bet is not super complicated to port it, but looking at the class, all work is done by EPDiy in the background. I'm just adding C++ wrappers and some functionality. I guess you can use this as a base and do your own class.
@martinberlin acutally I tried it today, was getting some compile errors, some where easy to fix, Still getting a large number of errors however - and I'm going to spend some time and see if I can work thou them. Part of them may be my fault. I mixed what you did with the library here, and the Adafruit_GFX library that was written for the Arduino IDE (when using your Adafruit_GFX library I was getting a bunch of errors related to it, so I tried the Arduino one, and those errors cleared.) The other errors are in the CalEPD library, dealing with various variables I believe. I'm going to work thou it, see if I can't get it to clear. But this maybe a little above my head. I'm impressed with your progress thou!!! Thanks.
You can also try CalEPD directly. Esp-IDF takes some days to master but is not super complicated. Both Cale and EPDiy are not hard to setup and compile. And it comes already with parallel demos in main/demos/parallel https://github.com/martinberlin/cale-idf/tree/refactor/oop/main/demos/parallel (Branch refactor/oop) Option B is to make your own display class. Less remix and just your own class with the methods you need (can use mine as an example) Thanks for the kind words about my work!
Clearly I don't know what I'm doing here - I finally got it to compile by scaling a lot of it back, and just using a little bit of your code, the Adafrutit_GFX library, and this library from LilyGo.
When I upload the code to the board I get nothing but reboots. So clearly I've done something wrong, and not fully understanding what I've done. @G6EJD and @lewisxhe probably can get this working because I bet both know a lot more then me! :-)
I posted a gist with the errors I got, since it's not part of this project, and something I was trying I decided not to post the errors here, but if someone wants to look at them - https://gist.github.com/kd8bxp/ff9da93a377716176869aac121afd909
Using the Adafruit_GFX library as a wrapper sounds like a great idea, and hopefully someone can get it to work.
Thanks again @martinberlin
You must enable PSRAM in the compiler options!
@G6EJD maybe it will be cool to add a rotate option to this library? This can go from 0 (default) to 3 rotating 90° clockwise.
And it really does not need Adafruit GFX at all. I added that because I have a multi-epaper class where every model inherits the full GFX methods. But for rotation is not really needed. Like I mentioned, the only thing IMHO is to keep rotation state and be aware of it before drawing each pixel. Rotation is a very useful feature if you are using this display in some Firmware and you need to switch between landscape /portrait mode.
@G6EJD PSRAM was enabled. (ESP32 Dev Module, with PSRAM enabled) and tried it with multiply boards, no luck. Clearly I don't understand what I'm doing, and I'm going to stop before I mess something up. And leave it in more capable hands.