UhClem

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...

I thought that the SD library only did 50MHz for the SD clock. This is faster than that.

5us to write 512 bytes. Excellent trick. What interface are you using?

A count of writes. In this case it is the same as the number of blocks. (512 bytes)

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...

My take on eForth for the Teensy 3.6, and a logger is on my web site: http://davesrocketworks.com/electronics/logger/eforth.html

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.

They don't come any earlier.

The SD library apparently can provide more detailed error information than just, it didn't work. TeensySdioDemo/TeensySdioDemo.ino: printSdErrorSymbol(&Serial, sd.sdErrorCode());

Register 9 (GPIO) does different things on write and read.

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.

I see various constructors for SdSpiConfig() including one that specifies a particular SPI port.