I wonder how the library slows things down so that it meets the setup, hold, and clock cycle times of the SSD1309.
On slow parts I wouldn't worry too much but with these really fast ARM devices, it matters.
The manual at 20.3.2 describes the low voltage detector. Where during a low power reset you store a magic number in a particular register. The hardware then compares that to the known correct value. A difference triggers a low voltage violation...
The Teensy 4.1 RTC looks kind of complicated. Looking at the data sheet I see a Real Time Counter but not a Real Time Clock.
With there actually being two counters. A low power counter that runs from the battery and a high power counter. With...
It has been a while but I have done testing where I just tested the card. No file system involved at all. Just my code writing sequential blocks. My usual method was to have a timer running and I would write the current count into the buffer...
It has been a while so I looked up the notes I made when adding interrupts to my version of Forth.
"The ARM stacks up a bunch of registers: R0-R3,R12,LR,PC,PSR"
This is handy as r0-r3 can be clobbered so aren't saved by a function. Any...
SD writes can take randomly long times so you must have sufficient buffer space. How long? Very long. See the maximum FAT write time in the SD specification for example. (750ms!) I tested this once long ago... Longer buffers (power of 2 * 512)...
Given the very light loads presented by RS485 receivers, I can't think of any way to distinguish between a terminated DMX cable with a receiver on it and one with none. Or many.
The SD library apparently can provide more detailed error information than just, it didn't work.
TeensySdioDemo/TeensySdioDemo.ino: printSdErrorSymbol(&Serial, sd.sdErrorCode());
No idea where the source might live. I haven't restored the Teensy environment on my Linux box since I had to replace it. But when you build a project, everything gets compiled and the objects stored in a temporary directory. Find that and you...
Not driving the line. Everything on I2C is open drain so the signal will always float high (pullup resistor) when nothing is active. That bobble should be no problem as what matters is that data is stable before the rising edge of the clock.
I don't see extra start conditions in your plot. There is a start at the beginning (data high to low while clock is high) and a stop at the end. (Data goes low to high while clock is high. No extra starts in the middle.