Closed codewitch-honey-crisis closed 2 years ago
Thanks for this I will take a look, but it will be some time before I will be able to give it my full attention.
I have avoided the RA8875 implementation for some of the reasons you give, I opted for the 7" SSD1963 with capacitance touch screen. This has an 8 bit parallel interface and works well. Hardware clear screen would be good as it takes ~150ms to clear the 800x480 pixels.
Yes, help would be needed as I don't have one of those displays. Great to hear you have the knowledge and experience with the display, that should make things go smoothly.
I'm using the RA8875 in a commercial venture, but I'll give the SSD1963 a look, and run it by my client for any future projects. I didn't get to choose the hardware in this case, but at least it gave me an excuse to learn it.
BTW, thanks for this library, and your support of it. It is my current go to for support on the arduino framework and I've recommended in my documentation for gfx_demo that people use your driver when it's supported.
I'm not sure if I should close this here, so I'll leave it to you, as I don't know if you prefer to keep driver support requests open. Have a great day.
This display is tricky to support fully, but is nice because it can drive an 800x480 screen. That's a lot pixels to push, which is why it would be great to see your optimized library support it.
I've already written a largely unoptimized driver for it so the code should be easy to read, and I'm around to answer questions. https://github.com/codewitch-honey-crisis/gfx_demo/blob/master/src/arduino/drivers/ra8875.hpp The relevant methods are the copy_from template function and helpers which you can use as a guide for pushPixels and pushImage both. Then there's fill() which draws a rectangle or a line or a point depending on the rect. The reason is that the RA8875 supports hardware accelerated shape drawing. Much less bus traffic to draw this way.
begin_batch basically performs setAddrWindow() if it were your library.
The thing the driver doesn't do is fully leverage the hardware acceleration. It doesn't use the hardware fonts (for a number of reasons), it doesn't use hardware line or shape drawing mostly either (except in fill). Yours could, but in my experience, the display is usable without employing them.
It operates at a max frequency of 20mhz in my experience and can be a bit timing sensitive. The wait pin on most breakouts can be used to signal the completion of an operation, but you don't need it. You can poll a register. My code does that in a wait function.
Rotation is a bit weird with this display. You have to modify both the write direction (to flip it to portrait) and the scan direction (to invert it horizontally and vertically) - I use them both in tandem. I missed it in the datasheet the first time around, because i wasn't thinking about altering the scan direction. It took me a bit to work it out, so I'm giving you head's up.
Since I've already implemented this, I'm happy to help with it, or testing it or whatever.
And regarding my code's licensing, it's MIT, but I'm donating it to your project. I don't care about credit at all, and I pulled a lot of it from adafruit's lib (which I haven't added to the documentation yet because the driver isn't finished, but FYI)