Teensy 3.6 w/ RA8875 & SD Card

[Pet-Rock]

Hi All,

Working on a project right now that uses the following components:

- Adafruit Feather M0 Adalogger (https://www.adafruit.com/product/2796)
- 7.0" TFT Touchscreen (https://www.adafruit.com/product/2354)
- RA8875 TFT Driver (https://www.adafruit.com/product/1590)
- STMPE610 Touch Driver (https://www.adafruit.com/product/1571)

What I'm trying to accomplish is a GUI for a DIY CMM and could really use some guidance as to the best way to attack this.

I have a Teensy 3.6 on the way that I want to replace the Feather M0. My reason is for the higher clock speed and possible use of Sumotoy's RA8875 Library.

The couple questions I have are:
- Does the Sumotoy library work with the Teensy 3.6? I've done a lot of looking and am seeing mixed results
- Even though the built-in micro SD card slot supports SDIO 4 bit transfers, I am still limited to 1 bit transfers for communicating with the RA8875, correct? So any speed increase in SPI is directly related to the increased clock speed of the 3.6?
- The SD card uses an internal form of SPI correct? One that doesnt tie up a broken out SPI bus, so I could connect the RA8875 to SPI0 and communicate, correct?

I have the display working with the components mentioned above and the basic library that Adafruit provides for the RA8875. I have built up some sketches for it, although after coming across Sumoty's library, it seems as though he has done a ton of work to better interface with the RA8875. I would love to be able to use some of the functions from Sumotoy's library, such as the scrolling and layering features. As well as increased bitmap rendering speeds.

Any help with this is greatly appreciated guys, thanks!

 

[PaulStoffregen]

- Does the Sumotoy library work with the Teensy 3.6?

I recently tested. It seemed to work, but I didn't actually do much.

If you run into problems, please post a detailed report here.

- Even though the built-in micro SD card slot supports SDIO 4 bit transfers, I am still limited to 1 bit transfers for communicating with the RA8875, correct? So any speed increase in SPI is directly related to the increased clock speed of the 3.6?

Well, first of all, the RA8875 does not play nice with other SPI chips. It does not have proper tri-state on its MISO signal. So no matter which microcontroller board you use, putting the RA8875 and a SD card or *any* other SPI chip on the same SPI bus is problematic, unless you have a tri-state buffer added on MISO. So Teensy 3.6's dedicated SDIO will certainly help in removing the need to put the SD card on the same SPI signals.

Without overclocking, Teensy 3.6 can go up to 30 MHz SPI clock speed. But the RA8875 (probably) can't run that fast. Who knows, maybe it will? If you *really* want faster clocks, you can edit kinetis.h to enable overclocking of F_BUS. The SPI max clock speed comes from F_BUS, not F_CPU.

With SPI, raw clock speed isn't everything. The code matters, because you can end up with fast bursts of data separated by long pauses. It's a common issue with all SPI chips and code that isn't well optimized.... and you can be sure Adafruit's code has basically zero optimization work. They do very well at making their code portable and nicely documented, but optimization is almost never their focus.

- The SD card uses an internal form of SPI correct?

The built in SD card on Teensy 3.5 & 3.6 uses a 4 bit protocol called SDIO. It's not anything like SPI. During the data transfer, it's 4X faster for the same clock, and it supports faster clock speed too.

The Arduino SD lib uses this, but it doesn't (yet) take advantage the DMA or caching more than 1 sector. There are a couple other libs which do use DMA mode. In theory that could allow you to be bringing data in from the SD card while your code is busy sending to the RA8875. In practice, really optimizing things well takes careful work.

although after coming across Sumoty's library, it seems as though he has done a ton of work to better interface with the RA8875.

Yes, Sumotoy has written very well optimized code for several displays. Like with ILI9341_t3, the optimization work can make a pretty incredible difference.