ILI9341 (and like displays)
Wondering what we should do for T4? As mentioned several times in this thread, the ili9341_t3 library would take a rework to run on T4 as it is highly dependent on the KinetisK SPI register set, which is very different than how the T4 SPI registers work. The biggest difference is on how the PUSHR and POPR work....
From a user point of view and not from the view of somebody who has grok'ed the internal workings of the data sheet, I would prefer that we have separate Teensy libraries with the optimizations, and not modify the Adafruit (or whatever) libraries in place. Otherwise, you get to the sad case of the ST7735, where the Teensy version of the library is 2 or 3 years out of date. Adafruit has rewritten the library to add more new displays, adding new displays based on the ST7789 chipset. Furthermore, the Adafruit-GFX library has also diverged, so that if I want the Adafruit version of the ST7735 library, I also have to not load the Teensy version of Adafruit-GFX, and use the stock version as well.
One problem of naming is whether we want the user to have to include a t3 variant of the library and a separate t4 variant, or whether we can combine them under the covers. If you combine them, then the old naming scheme of <xxx>
_t3 doesn't work as well for a name. Of course <xxx>
_teensy doesn't work either since the Teensy 2s are not compatible.
Also as a user, I would prefer if the display primitives in the class structure were the same as the base display (or at least there were mappings), so that I only need
#ifdef's around the constructor, and not around the display primitives.
I like having an optimized version and a standard version, as long as you don't have to edit the standard files to choose which version to use (i.e. perhaps using a different constructor, perhaps using a different library). I do like fall back in the libraries, so if you don't get the pins right, it will still function as a standard display.
I would expect requiring the user to edit the library file to change the defaults, would be seen as a relic of the past, and not something we do now.
I can imagine a few different options for this:
a) Punt - make ILI9341_t3 work like the Adafruit_ili9341 library with no real speed ups...
b) Take advantage of the one hardware CS pin for DC and get a lot of the speed ups but is very limited.
c) DMA and Screen Buffer - Make a version of a library that does all of the graphic Primitives in memory and then use DMA to transfer the buffer to the display...
I know that we discussed some of this already. Also a few of us have talked about it some on the Bluetooth thread:
https://forum.pjrc.com/threads/49358-T3-6-USB-Host-Bluetooth?p=201416&viewfull=1#post201416
Note: I do have a version of my ili9341_t3n library that does both b) and c) Although in c) it currently either does continuous DMA update or on when the user says update me now. in the other thread, I also proposed a third method, of combination of both in that when you call any graphic primitive it sets the screen dirty and then starts up a screen update...
My first main question here is: Should we create a new thread for this as while it is needed to solve for T4 it can also be used on T3.5/3.6 as well. Or should we only discuss here?
Probably a new thread, as this thread is already long.
Also assuming no other feed back, I may continue to hack my ILI9341_t3n library to add the on demand? Then the question will be should a version of the library be created that removes all of the code that actually updates the screen except for the DMA update? That is my current code this is a mode, where you can choose either to have a frame buffer or not...
I can imagine there are some up here who primarily want fast speed and don't care that a lot of memory is used up for buffer and I can also imagine others who would rather use this memory for something else... And I can imagine that the choice of this would be on a sketch by sketch basis...
Thoughts?
Yes, I routinely bounce between different sketches, that each have different constraints. And at times, I even build for non-Teensys, so I like choice, at least to fall back to the standard drivers. But as a programmer, I also realize that too much choice means things can be unstable to keep working.