KurtE
Senior Member+
Now that several of the Teensy boards now support multiple SPI busses, it would be great if we could standardize a way to allow different drivers such as display drivers to support devices on the different SPI busses.
Currently with the Teensy we do support the different SPI busses, however each of the SPI busses are currently supported by their own class.
That is the SPI object is a member of the SPIClass
On the T-LC as well as the T3.5/6 the SPI1 object is a member of the SPI1Class
And also on T3.5/6 the SPI2 object is a member of the SPI2Class.
So for example if you wished to make a display driver like the ili9341_t3 library support a display on any of these busses, you have to do something like hard code code everywhere that does something like:
Which is not great...
To work around this I developed my own library SPIN (https://github.com/KurtE/SPIN), which created a base class for all three and then subclasses of my base class for each of the SPI busses.
The library is pretty basic, the basic functions, simply create virtual functions for each of the main SPClass functions and then have subclasses which implement this by simply calling off to that busses version of the buss. I also added a few helper functions that I thought was appropriate like being able to ask if a given pin is valid as a MISO pin or a MOSI pin or a SCLK pin... And likewise some helper functions to manage the FIFO queues on the T3.x processors...
For the most part this has worked out for me to adapt some of these other driver libraries to work on the different busses.
BUT, I wonder if this is the approach to take long term. Or should we do for SPI what Paul has recently done for Wire and update the SPI library to be closer to what some of the other Arduino platforms are doing.
That is for example if you look at current implementation for boards like the Arduino Zero, you will see that all of the sPI busses are instances of the main SPI class (SPIClass)
There constructor, takes some parameters to create the instances. In their case it takes a pointer to a SERCOM object, which does all of the real work, but I would imagine we could do it in a similar way to what Paul did for the Wire objects...
Example their implemention for the simple transfer method looks like:
This obviously works. Sort of like having the main SPIClass object hold a pointer to my SPIN object and calling it...
What I wonder is, does it make sense to migrate toward the Arduino Zero like solutiion, such that hopefully over a short period of time, we could update a lot of the device libraries to support multiple busses and hopefully have it supported on most of the platforms that have multiple busses?
Does this make sense? Suggestions?
Currently with the Teensy we do support the different SPI busses, however each of the SPI busses are currently supported by their own class.
That is the SPI object is a member of the SPIClass
On the T-LC as well as the T3.5/6 the SPI1 object is a member of the SPI1Class
And also on T3.5/6 the SPI2 object is a member of the SPI2Class.
So for example if you wished to make a display driver like the ili9341_t3 library support a display on any of these busses, you have to do something like hard code code everywhere that does something like:
Code:
if (spi_buss == 0)
SPI.transfer(x);
#if defined(__MK64FX512__) || defined(__MK66FX1M0__) || defined(KINETISL)
else if (spi_buss == 1)
SPI1.transfer(x);
#endif
#if defined(__MK64FX512__) || defined(__MK66FX1M0__)
else if (spi_buss ==2)
SPI2.transfer(x);
#endif
Which is not great...
To work around this I developed my own library SPIN (https://github.com/KurtE/SPIN), which created a base class for all three and then subclasses of my base class for each of the SPI busses.
The library is pretty basic, the basic functions, simply create virtual functions for each of the main SPClass functions and then have subclasses which implement this by simply calling off to that busses version of the buss. I also added a few helper functions that I thought was appropriate like being able to ask if a given pin is valid as a MISO pin or a MOSI pin or a SCLK pin... And likewise some helper functions to manage the FIFO queues on the T3.x processors...
For the most part this has worked out for me to adapt some of these other driver libraries to work on the different busses.
BUT, I wonder if this is the approach to take long term. Or should we do for SPI what Paul has recently done for Wire and update the SPI library to be closer to what some of the other Arduino platforms are doing.
That is for example if you look at current implementation for boards like the Arduino Zero, you will see that all of the sPI busses are instances of the main SPI class (SPIClass)
There constructor, takes some parameters to create the instances. In their case it takes a pointer to a SERCOM object, which does all of the real work, but I would imagine we could do it in a similar way to what Paul did for the Wire objects...
Example their implemention for the simple transfer method looks like:
Code:
byte SPIClass::transfer(uint8_t data)
{
return _p_sercom->transferDataSPI(data);
}
What I wonder is, does it make sense to migrate toward the Arduino Zero like solutiion, such that hopefully over a short period of time, we could update a lot of the device libraries to support multiple busses and hopefully have it supported on most of the platforms that have multiple busses?
Does this make sense? Suggestions?