Homosapiens, homosapiens, ja so schwierig ist es.

Die Version von Baui ist zwar nicht schlecht, da einfach zu behandeln,
aber eben auch kein echter RS485 / Profibus mehr.
Wenn wir schon einen Standard verwenden dann so wie dieser definiert ist.

Beim RS485/Profibus reichen sogar nur zwei Leitungen (ohne GND) aus.


Die "denke" von Vitis hat eines nicht bedacht,
woher soll der UART wissen dass gerade das was er Empfängt für "seinen Slave" ist.
Das passiert auch bei der Variante von Baui


Um Rechenzeit zu gewinnen, und nichts anderes sollte doch die IRQ Variante bringen,
hilft es nur wenn der Bus quasi intelligent überwacht würde und seine CPU nur dann stört, wenn es "wichtig" ist.

Klar könnte ein UART einen IRQ auslösen,
dann aber bei jeden Bit das auf dem Bus herumspaziert,
ob es nun für seinen "Kunden" ist oder nicht.

Also IRQ kann auch lästig sein,
speziell wenn mehrere Teilnehmer im Bus verbunden werden und nicht nur zwei.

Bei einem Punkt zu Punkt Protokoll ist dies ja nich weiter tragisch,
z.B. nur um die Leitungslänge des RS485 zu nutzen.
(RS232 kann ja normalerwesise max. 15m lt. definition und RS485 mehrere hundert Meter (1500?) ohne weitere "Booster")

Quasi ein "aufgemoztes" RS232 aber eben kein BUS.
Dann könnte man auch ein Acknolege mit RTS/CTS und DTR/DSR aufbauen.

Wenn am Bus viel Traffic ist, kommt der Slave aus seinen IRQ's gar nicht mehr raus
bzw. fällt von einen IRQ in den nächsten



Frage:
Kriegt man dann irgendwann sowas wie einen IRQ oder Stack overflow? wenn zu viele IRQ's ausgelöst werden.

Ein IRQ unterbricht ja ein Programm um eine definierte Subroutine abzuarbeiten.
Die Interruptbehandlung wird (absichtlich) währenddessen nicht abgeschaltet (kein "Disable IRQ")

Wenn während dieser IRQ-Routine nun wieder ein IRQ ausgelöst wird,
und währen diesem wieder und wieder.
Irgendwann muss doch der Speicher für die Rücksprungadressen (Return) mal platzen.