Closed KurtE closed 7 years ago
Hmm, I seem to be able to use readRect() successfully with the current code (aside from the possible 16-bit counter overflow). I tried on both the 2.2 and 2.8-inch screens with Teensy 3.5 and 3.6
I'm reading the spec section 8.2.35 Read_Memory_Continue (3Eh) and I'm skeptical that the "3FF" was actually intended as 3Fh. Plus we're using memory read (2Eh) instead of memory read continue (3Eh). The same table seems to be shown for Write_Memory_Continue (3Ch), though it doesn't make much sense there either. Maybe it was just copy-pasted and not formatted correctly?
Do you have example code for the test case that shows it failing? If it's only after certain drawing commands, maybe there is something else in those causing a conflict?
I have some readRect code in my test app, I posted on my forum thread that was failing (returning 0 values, until I made this change. Will revisit. But would be interesting to see if it is only this one display, which is one of PJRC touch screen. I will test again hopefully later today.
Thanks for checking it out
Part of my other one...
My test case for readRect was returning all 0s, so found while rereading ILI9341 pdf file it looks like we should be passing 0x3f characters in instead of zeros when we are trying to retrieve the data.
Once I did that things started to work.
Also changed the c variable from uint16_t to unit32_t as it could potentially hold a value of 320x240x3 which is > 65536 bytes.
Also as per suggesion on forum post, added new define SPICLOCK_READ 2000000 which is used in the SPI.beginTransaction calls when we are doing the readpixel and readRect calls.