You will find this hard to impossible with an ESP depending on exactly what other I/O etc you use. The ESP has bus contension issues. Now the above does depend on if you can tolerate occasional (say) 2mS drop outs. 400 KHz ->25 uS. AFAIR it takes 10 uS+ to set up a SPI DMA. You could pre-allocate th...

20 Mhz seems a lot. 10 Mhz might be pushing it. Unfortunately there are a lot of clone cards. I developed a product with an SD card & during reasearch bought many cards from a variety of suppliers from Amazon, ebay etc. Each supposed OEM card bought either at different times or from different suppli...

All the line numbers are posted, so post the source files! On a 30 second scan I could not see any pointer use, no mallocs etc & 9 out of 10 exceptions are stack related. Bump your stack. If that still sucks then post the source files, like C:\Users\Tom\Documents\Arduino\libraries\FastLED-3.4.0\src\...

Some code might help! I have used an SD card on ESP32 (using a hacked Ardunio driver) without issue - and I test hard. My only 'quick win' thought is that you should wind SPI clock speed back to say 1 MHz and then work up. ESP32 peripherals are slower than you might expect & GPIO muxing does not hel...

Not tried TWI on ESP before. SPI should do it. You can figure the mode. Some edge cases on hard wiring CS to figure but doable. Trouble is you have 4-6 asynchronous sources & you do not have 6 SPI devices on the ESP. 25MHz is also probably too fast if you use the ESP GPIO mux (use non native SPI pin...

You should really describe your original problem along with question.
No schmitt but a software latch, counter, RMT might work just as well (depending on you're actual problem).

Well the datasheet says that it has a level convertor but does not show you how to use 3.3V.
I would hunt for a tutorial.

If you run 5V into an ESP pin then the ESP won't love you for long.

The MQTT over web socket assumes that everything is in a single ethernet packet as I recall. If you are using websockets then check my posts, there is a patch in there somewhere. Perhaps the same issue exists with other transports? There is not enougth in your log for me to work with. Why the first ...

Hi, Yes, I suspect this is an inherent device issue. (1) ESP32 internal flash write will block code cache fetching - If your I2C driver is not located in IRAM then the driver may/will block. Simple answer is IRAM your I2C driver. There is lots of IRAM free these days & being 32 bit addressable its h...

I direct ESP_LOGx to UDP and that works fine. I do see some 232 corruptions from time to time though but hey that's 232. printf() is not declared as RT safe (its pre C++11 for a start) & so you might well see RT issues! I think you are looking quite deep. Why debug that deep when you could roll your...