Hi defragster and sumotoy,
TFT_ILI9163C on SPI1: You probably have a couple of choices on how to make it work. Without using the extra pins of the SDPort, you only have one CS pin, so you can pick off this case and go the slower route, like you have for Teensy LC and use SPI1.transfer(x) and manage the CS/DC pins directly.
Or if you wish to use the extra pins, you now have 3 valid distinct CS pins on SPI1, so then you can use some of the faster access. However you then run into assumptions in the code that the SPI queue is 4 entries long, which it is for SPI0, but not for SPI1 or SPI2, which only have a queue of 1.
So you run into issues like in the function:
Code:
//Here's Paul Stoffregen magic in action...
void waitFifoNotFull(void) {
uint32_t sr;
uint32_t tmp __attribute__((unused));
do {
sr = KINETISK_SPI0.SR;
if (sr & 0xF0) tmp = KINETISK_SPI0.POPR; // drain RX FIFO
} while ((sr & (15 << 12)) > (3 << 12));
}
Where the 3 << 12 is checking for more than 3 entries... So I changed all of these to use a #define for QUEUE size - 1. Also you need to update the code that checks valid pin numbers
My quick check through the code, I did not notice any read like functions, but if there are, you may need to check those to make sure you are not depending on more than 1 return item begin queued up...
Likewise in that function, you need to setup for SPI1 vs SPI0. I defined a #define for which KINETISK_SPI I was using. Which in the above function, you needed to use to get the SR as well as the POPR... And in some other functions you will see things like: SPI0_MCR = mcr;
And you need to change those as well to something like above: KINETISK_SPI0.MCR where you again change which KINETISK_SPIn you are using.
As I mentioned, all of my changes for the ILI9341 are up on github if you wish to take a look.
What I would also like to be able to try out is to make a version of the SPI library, where we make a base class like: SPIClass which is probably mostly pure virtual and then we create sub-classes for SPI0 (SPI) and SPI1 and maybe SPI2 (if the optional bottom pins are actually making it on the board? Paul?). Then in some of these libraries, I would hold onto a Pointer to the appropriate SPI object as well as a pointer to the KINETISK_SPIx object and can compile for multiple instances. It will be interesting to see how much of a perf hit this would be to add call indirects for many of these functions that are now static inline functions. I can probably hack up a version that uses my quick and dirty SPIN object which tests a variable and then either does the SPI or the SPI1 code. Not sure if it would be faster or slower than doing indirect calls, but pretty sure more bloated...