Double checked the pin definitions and forgot to update that
there is MISO1 on pin 39, likewise CS1-0 on pin 38

Also SPI0 has two additional CS pins on 37 and 36.

It was using the wrong field in the hardware table to change the pin mode for the CS pin. (was using SCK pins value)

So updated tables to reflect this plus implemented the
setMOSI, setMISO, setSCK methods

Fix usingInterrupt()

T4 - Default allow faster speeds...

I changed the Clock that was used and settings.
So I think maximum speed changed from about 37+mhz to 60mhz

I was haing issues at 60mhz with simple test so also changed the IO ins Speed and DSE values which appeared to work.

I tried running our ILI9488_t3 library at 60mhz and it appears to work :D

T4: Support legacy (pre SPI.transaction) methods

The code would fail if the user did an SPI.transfer without calling SPI.beginTransaction.

So begin now calls beginTransaction with default parameters.

Also put in an implemention for SPI.setClockDivider as well as SPI.setDataMode

They appear to work OK...  Tried to do with out changing any of the current functionality other than to call begin/end transaction in begin to get to a stable state.

T4 Pin configuration.

There have been some issues with SCK pins and the like not appearing to work as well as on T3.x...

We have been experiementing with changing the DSE and SPEED value and this has helped in some cases.

... see forum, but I saw now it the same interrupt for every pin, so here is a more simpe solution

T4 SPISettings - just hold values passed in

With the T4 transaction code settings being dependent on which clock is choosen to be used in SPI.  All of the work had to be done at run time.

As such the statically defined ones may not work as you have no idea which clock may be actually used...

So moved the work to comput CCR into the SPI.beginTransaction  code, which is only called if something like the clock speed is different than the previous call to beginTransaction

We can still convert the bit Order and Data Mode parameters into the TCR
register value as part of the SPISettings constructor code as these do
not depend on external run time settings.

T4 correction to SPI1 mux table

T4 b2 spi1 spi2

Some of the SPI pins for SPI1 and SPI2 require
changing the Input chain mux registers.  So those register pointers and values are not stored in the SPI object and are updated as part of the begin

The second beta board may have the ability for two additional SPI ports,
So I defined them...

Next up test them when board arrives

T4 async support

If a buffer is up in the high memory, that is either in the area marked DMARAM or created by malloc and you try to do a SPI transfer using DMA, the code detects the addresses >= 0x20200000 and then calls the system functions to either flush the cache or delete the cache on the read...

Still testing and running into memory usage issues, but I think some of the basics are working.  Still need to do more testing, including verifying on larger buffers.

Added dummy end() function to SPI.ccp

Use PFD setting to prevent wrong calculation (needed for high SPI-Clo…

T4- Switch to port() and hardware() like T3.x

T4 Fixes plus macros

Implemented these two functions to use the hardware table

Appears to fix issue associated with SerialFlash

Use CCM_CBCMR instead "/7"

T4 - put inital calls for check pins and set pins...

Added - the code to set them as part of the Transaction Setttings.

Also put in implementations for,
SPI.setBitOrder and SPI.setDataMode.
Note the setDatMode like the T3.x does not appear to do anything yet.

Implemented using 16 bit writes

The buffer transfer now uses FIFO queues,

Currently it only outputs the 8 bits per entry, unlike the T3.x version which packed the bytes into words in order to speed up some more.

Warning this change uses the updates I did in core library to define a
SPI structure for the T4...

The code now uses this structure as wlll as pointer to it passed in to constructor to talk to the SPI registers.

Also Miso, Mosi and SCK pins are defined in Hardware structure which again is passed in to constructor... Still a few more things to cleanup in ::begin to make it  completely independant of the hardware such that I can define SPI1 as well...

Some libraries actually call this.  So define the Hardware data for the one pin for each of the MISO, MOSI, SCK and CS...

So far setting does nothing.

Enough to get Sparkfun Teensyview to build, other than example uses String class which is not included in link phase.

T3.5/6 Pin 45 is valid CS

but it is CS5 which encodes to 0x20 and our
macros only handled up to 0x1f... so changed
to 0x3f.

Tested on my ILI9341_t3n test now works with DC on 45... Needs change in Core as well

Example setup code bug

The code was doing:
pinMode(slaveSelectPin, OUTPUT);
pinMode(slaveSelectPin, HIGH);

Second pinMode should be digitalWrite

Add SPI Buffer functions