Electron + SSD1351 OLED/SDCard issues with Adafruit_SSD1351/SdFat libs

Troubleshooting
1

So I think this is not a new topic. For some reasons I can’t explain I’m getting some kind of “interferences” (lines or weird sections of display) on my device making it unreadable mostly when the SDcard is accessed, and I’m pretty certain it comes from some incompatibilities between the SdFat and the SSD1351 libs.

I can’t post example of code, that would be far too complex (project is huge), but I’m fairly certain my code is not doing anything wrong, and I suspect more some timing issues.

From my tests I noticed:

  • the order I instantiate my Display and the SD card is important (otherwise one or the other fails)
  • using hardware SPI for one, the other or both doesn’t work (mostly either one or both device fail)
  • using software SPI (all pins passed when instantiating the SSD1351, using SdFatSoftSpi for the Sd card) works on a device with just the display AND the sdcard, but I get the interferences when other actions occur on peripheral components (e.g. RS comms). Note that I already obtained the same interferences WITHOUT the other components (basically, electron, OLED and SdCard), so I can’t conclude the other components cause them.

Mostly what I’d like to know is, if someone else noticed these, and if they found a way to remove them by changing any settings in the libs, or adding delays, etc…

Thanks in advance,
Phil.

2

In such a case it's always best - for your own debugging and anybody willing to help or fileing an issue report - to create a minimal project/test case which exhibits the perceived issue.

People who might want to help don't necessarily want to spend the time to create that test case themselves.
In your case there potentially are - additionally to yourself - three parties involved Particle for SPI implementation, the contributor of the SDFat library and the contributor of the Adafruit_SSD1351 library.
Either party may equally say

But for your "question"

I'm not sure if we are seeing the same thing, but I am trying to get SDFat to work together with a VS1053 audio chip on a Boron and see a similar behaviour.
But since there are too many differences between your and my setup - with only SDFat being the common part - it might either point to SDFat or be completely unrelated :blush:
In order to get to the bottom of this I'll see what a logic analyzer will show.

Update:
Which SSD1351 library are you using exactly?
Could you provide a link?
There is on in the Particle Library repository but that does not use SPI transactions whie SDFat does.

I solved my problem by ensuring that the VS1053 library uses SPI transactions - previously it appeared to be using it, but after double checking it turned out the respective code blocks were deactivated.

When I look at Adafruit_SSD1351 it uses Adafruit_SPITFT which relies on SPI_HAS_TRANSACTION being defined.
This is the case on most Arduino platforms but Particle hasn't (yet) defined that macro.
Hence I've opened this issue
https://github.com/particle-iot/firmware/issues/1668

For the time being you can define that macro yourself (this is what I did with my issue)

#if defined(PARTICLE)
# include <Particle.h>
# if (SYSTEM_VERSION >= 0x00060100)
#   if !defined(SPI_HAS_TRANSACTION)
#     define SPI_HAS_TRANSACTION 1
#   endif
# else
#   warn "Requires Particle Device OS 0.6.1+ to support SPI transactions"
# endif
#endif
2 Likes
4

Thanks ScruffR,

Note, in my SdFat's settings ENABLE_SPI_TRANSACTIONS is still 0 and I use SD_SPI_CONFIGURATION set to 3. I couldn't have it compile properly otherwise.

I also use SdSpiFatLib for my SD class, which I thought was making use of SPI. I finally succeeded in having SPI work, after tweaking the divisor in the SSD1351 lib to SPI_CLOCK_SPI16, setting the SSD1351 internal divisor SSD1351_CMD_CLOCKDIV to 0xF2 and initializing the SD class with SPI_CLOCK_DIV4. It is however very unstable and I still get some occasional noise...

Regarding using the Arduino lib for SSD1351, will I lose the benefit of Adafruit_mfGFX lib which I need for fonts among others?

Thanks for your help, I know that sharing code would help, and I will share specific sections if that helps,

5

The Adafruit_mfGFX library does not use SPI directly. This is why a driver is required such as the SSD1351 library which provides the low-level functions for the specific display. So, you are safe!

4 Likes