Die genutzten Daten vom DMX-Protokoll bestehen doch auch nur aus 8 Bits. Und die passen genau in acht Bits des SPI-Frames....
Stimmt leider so nicht ganz.
Es kommt ja noch das Startbit und 1 ( oder waren es 2 ? ) Stoppbits dazu.
Wenn Du also per SPI so ein Frame generieren willst, musst Du diese Bits künstlich einfügen.
Ausserdem muß dabei die SPI kontinuierlich Daten senden, da das USART Signal ja nicht getaktet wird, wie eine normale SPI Komponente.

Da ein normaler USART sehr wenig Rechenzeit braucht, würde ich dann doch lieber einen Controller verwenden, der 2 USART's hat.

Einen für die DMX Schnittstelle und einen weiteren für die Anbindung an den PC.

Die Datenübertragung vom PC zum Interface kann in der DMX Kette der Flaschenhals werden, wenn viele Kanäle gleichzeitig geändert werden sollen.
Ich Vermute, das Pongi deshalb auch "Dimm-" Kommandos in seine Befehlsstruktur einbauen will, weil das die serielle Schnittstelle ziemlich entlasten könnte.


Als künftige Option ist, durch die 2 USART's, dann auch das Empfangen von DMX Signalen problemlos möglich. Das Gerät kann also dann auch mal als DMX Merger oder Repeater verwendet werden.
Ausserdem kann man dann auch zum PC empfangene DMX Daten übertragen, bzw. Statusmeldungen des DMX Interface geliefert bekommen.

Dafür darf aber dann auch das RAM nicht zu klein sein, weil man ja schon 2x 512Byte als Puffer für die zu sendenden/empfangenen DMX Daten braucht.
Will man dann auch noch die aktuellen DMX Werte mit den vorhergehenden vergleichen, braucht man noch mal 512Byte mehr.
Also sind 2kRam eigentlich schon die untere Grenze.