As I have mentioned in some of the Beta threads for T3.5/T3.6, I hacked up a version of the ILI9341_t3 library, to make a version of it that I can use on any of the SPI busses on the processor.

So I created a duplicate of the library that I called ILI9341_t3n (https://github.com/KurtE/ILI9341_t3n)

Some of the interesting things I ran into included, the other SPI buses do not have the FIFO queue (or the do but they have 1 entry). To handle some of this stuff I broke out all of the standard functions that were in the ILI9341_t3 library and made a new library SPIN (https://github.com/KurtE/spin), which created a virtual interface for SPI and implementations for the different Queue.

I also found while testing stuff out on the new processors, that on some of these, there are only 1 hardware CS brought out. So I made the library handle it. In these cases the DC pin needs to be on the Hardware SPI CS pin.

Anyway I have been off and on playing around with this code and at one point had 3 displays hooked up to the T3.6. Sometimes with all of them on the 3 different SPI busses and sometimes two on 1...

Recently I became inspired by Franks work on the DMA version of the library as talked about in: https://forum.pjrc.com/threads/36706...eensy-3-6-only. So I decided to play with it for a few days. I think his stuff will work great for his intended application of showing videos and the like.

But I am not sure how I would apply it to the typical things I do. Most of the time, I end up setting up things like a set of buttons and text and the like, and as such I don't need continuous updates. However I do like the idea of using a logical frame buffer. As I can see several places where doing a set of graphic primitives in the background and then update the screen would be useful. Example I may wish to do something like scrolling text.

So today I started to add an optional FrameBuffer to the ILI9341_t3n. I added three new methods, whose names may change:
Code:
	uint8_t useFBTFT(boolean b);		// use the frame buffer?  First call will allocate
	void	freeFBTFT(void);			// explicit call to release the buffer
	void	updateScreen(void);			// call to say update the screen now.
Currently on the first call to useFBTFT - it will do a malloc for the frame buffer... Normally I don't like malloc, but...

When in FB mode, I do all of the outputs to the frame buffer. Example drawPixel:
Code:
void ILI9341_t3n::drawPixel(int16_t x, int16_t y, uint16_t color) {

	if((x < 0) ||(x >= _width) || (y < 0) || (y >= _height)) return;

	if (_use_fbtft) {
		_pfbtft[y*_width + x] = color;

	} else {
		beginSPITransaction();
		setAddr(x, y, x, y);
		writecommand_cont(ILI9341_RAMWR);
		writedata16_last(color);
		endSPITransaction();
	}
}
The updateScreen then writes the contents of the FB out to the screen. Currently this does a complete screen update. I may update the calls like drawPixel to keep a bounding rectangle of all of the writes since the last update and only output those to the screen. That might come in handy for things like only update the scrolling text region.

I still need to update some of the query functions, to optionally read from the buffer instead of asking the screen for the data, plus needs a lot more testing.

But I did hack up some of the graphic Test program , to add some duplicates of some of the other tests, like, filled rectangles and filled rounded rects, and I believe they are about 4 times faster.

I would paste in some of the timings, from the Serial monitor, but I disconnected USB cable and it no longer allows me to select the text...

Not sure if anyone will be interested or not, but if so I updated github with the WIP.

Anyway just having some fun!

Kurt