Kurt I've just used the sketch that was attached to your post, (yes I swapped the wires for CS and DC on my breadboard) and the latest SPIN library.
RXMSK worked better for me than NOSTALL
Ok I'm sure you get it running. Perhaps try to check the IDLE Bit to see if the last transfer is done.
Thanks, I will go back to trying the RXMSK... Earlier I thought I checked for idle but will double check. Yesterday I had it semi working with NOSTALL, but at the end it would push out several dummy words, but at least not hang...
@KurtE
SPI error and Radiohead Library
Could you add that to your next SPI update. If not I can do it.
Will do. Or you can if you wish as I have no open PR requests...
Frank B said:
Decided to work on my ILI9341_DMA library again, since I need it for emulators and more and need LPSPI4-CS for audio out. Works now, with any CS/DC pins, some functions are still missing (but that's just copying..) and i have an idea how to optimize it a little bit more...
Sounds great. Hopefully will have mine fully functioning as well very soon now... Comparisons of timings is always an interesting discussion. They are sort of apple versus oranges. Example if we look at the test for fill screens:
Code:
unsigned long testFillScreen() {
unsigned long start = micros();
tft.fillScreen(ILI9341_BLACK);
tft.fillScreen(ILI9341_RED);
tft.fillScreen(ILI9341_GREEN);
tft.fillScreen(ILI9341_BLUE);
tft.fillScreen(ILI9341_BLACK);
return micros() - start;
}
With all of the other setups, you will (or at least should) see the screen fully fill with Black, then Red, Green, Blue, Black. And that is what your timing is based on. With the DMA library, the timings is probably just how long does it take for you to set the frame buffers memory to each of these colors. What you see on the screen? May be partials the colors depending on where the screen refresh is at the points of the color changes...
Likewise with test like Rounded Rectangles - Are you mainly after seeing how long it takes to update the screen to the final output, or do you wish to see the progressions? Where the rounded rectangles start at the exterior of screen and work their way in toward the center...
@Frank (and others) - As you mentioned in earlier post, maybe makes sense to break up my library. But not sure which way I would go, also not sure what direction the main line ili9341_t3 library should take. A lot depends on usage patterns. Currently mine has maybe 4 ways of working, all with plus and minus
a) like adafruit library or ili9341_t3 library - Each time you call a graphic primitive, the screen is updated then. Requires no frame buffer or the like. This is however where you get the biggest speed gains when you use the hardware CS pin as DC as you can fully keep the SPI bus busy... This is what is shown in current graphic test numbers.
b) Use Frame Buffer, and call updateScreen when you wish for the screen to be updated. This is great for doing things like, you can update a text field, by simply filling the area with background color, then draw new text... Then update screen and not get any screen flashing... Code can optimized to only update those portions of the screen that were changed.... Requires no DMA. updateScreen is a version of the primitive: writeRect... Note: this could be made almost as fast without using hardware CS pin for DC, as you only need to do a few updates of DC for whole screen...
c) Use frame buffer and use DMA to update the screen once per call (Which I am debugging now) - like b) but when you call it's version of update:
updateScreenAsync, the code starts up a DMA operation, and you don't have to wait until it completes, before your code can do something else. There are support functions, that allow you to know if the update is still active or wait until it completes. This is great if you wish to update some stuff on the screen go do work and then if you want to update the screen again, you can then wait until the previous update is completed before touching frame buffer...
Note: this code is currently setup to always update whole screen.
d) Use Frame buffer and do continuous DMA updates of the screen, like Frank's code. Plus is using hardware CS for DC gives you almost nothing as you only change them initialize the first screen update, and then everything is running through DMA... (part of the debugging of c)
Great for things like video. But if you do things like clear an area (or whole screen) to draw new stuff, you may or may not get screen flashing and the like, so you need to understand how your updates may show up on screen. Example updating text field on screen, would probably work like a) and use opaque text output, such that the pixels are only updated once...
Again I guess the real question I am asking here is how we should try to make ili9341_t3 library work? Does it need to be compatible with how it works on a T3.x? Should it require hardware CS pin? Should it use FB? DMA? ...