It's not a flame war ... it's a simple discussion of a claim that he's made, and I'm not the least bit curious about what he's communicating with, but I am curious how he can achieve the level of performance he initially claimed, or even the 20% lower rate he most recently claimed, all the while keeping track of which bit is currently being sent, when the clock has to be sent with respect to that, AND fetch the data from an XRAM buffer, AND keep track of where his data pointer is, AND still be available for an interrupt from a UART that processes bytes at 460 ( or 480) Mbps rate, not to mention doing something with those bytes. I'd even be interested in how he persuades the internal UART/timer combination to operate at that rate when he's clocked to produce 100 MHz as his system clock.

I've found it very tricky getting a 30 MHz MCU at 30 MHz to bit bang a 3 Mbps rate. It's the same trick. Now, I get it done without clocking out, because I sync up with an external oscillator that's used to drive the external SIPO/PISO logic by means of a clock switch. That's why I was fascinated by Erik's reference to a speed switch, which, of course, was a misnomer, since his MCU simply stretches cycles, as does mine.

Since he's clearly stated he's bit-banging, and, in fact, generating the clock too, he's got some liberties that he wouldn't have with classic synchronous, Isochronous, or async formatted data. It's not parallel, though, since he's stated many times that he hasn't ever used Mode 0, and his MCU's Mode 0 timing won't go that fast.

What kind of a display requires high-rate refresh, uses serial interface, yet doesn't require some sort of rigorous protocol?

If you've followed Erik's posts over the years, you're probably aware that he designs the dot-matrix displays used, probably among other places, on busses to tell patrons which bus it is and where it's going. They're pretty big displays, with lots of dots, and have to be updated from time to time, but probably not often. The high rate is probably for dot-wise refresh, but he'd be the one to ask.

RE