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

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.

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

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.

Appears to fix issue associated with SerialFlash

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.

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

A define was under a #ifdef that it should not have been

Merged in the SPI.transfer(buf, retbuf, cnt)  version.

Also merged in the SPI.transfer(buf, retbuf, cnt, event_responder) version that does DMA access.

The current table code was setup that when we choose a specific pin for MOSI or Miso or SCK (or CS), that the only thing set at the time was the MUX value.

Well the old enable_pins that was called off of the enumlated register was setting the PORT_PCR_DSE option on pins 11 and 13...

So to fix it, I have the table, allow you to fully set the options for each pin.
Still have most all of them just setting the MUX, but do have pins 11 and 13 setting the PCR_DSE option to be compatible with old code.

Update SPI.transfer(buf, cnt) to use the FIFO queue to speed things up.
It also speeds things up to pack the data into 16 bit transfers instead
of 8 bits.

As this code is more complicated,  no longer makes sense to inline it,
so functions moved from .h to .cpp files.

SPI1 and SPI2 transfer functions were updated as well for T3.5 and T3.6

This adds support for optionally being able to use the SDCard pins for
SPI1.

This change requires the corresponding changes in the CORES project

Added SPI2 support for T34/T35 boards

These changes plus some changes in core (added register defines, plus
added logical SPCR1 register), allowed me to do quick hack to
serialFlash library and test and initialize flash memory using 3.5 test
board connected to prop shield using pins 0, 1, 20 and 6

In the comments: "Teensy 3.x" changed to "Teensy LC". Or is the LC also part of the "3" family?

http://forum.pjrc.com/threads/26776-Teensyduino-1-20-Released?p=56316&viewfull=1#post56316