schaltlogik, brauche bestätigung, evtl. bessere lösung

[Ceos]

problem, ein RS485 bus(geplant) 2-draht "multimaster" dachte zunächst an eine busy leitung um den datenbus freizuhalten ...
nach einigen timing tests, die schlecht ausgegangen waren, hab ich mal überlegt wie das mit gattern und logischen schaltungen zu lösen wäre

kann mich dabei nur darauf stützen was ich in der einen vorlesung elektrotechnik mla gehört habe, demnach also bei jeder logikstufe/invertierung ne verzögerung entsteht

4572 als Gatterbaustein
Bild hier  

die tabelle stellt die zustände an den positionen hinter jeder logik/invertierung nach der zeit dar, daneben die schaltübergänge ... bitte kann das jemand mal verifizieren oder eventuell eine bssere lösung bringen ?

zur not kann cih auch einfach davon ausgehen das NIE 2 controller zeitgleich busy auf high ziehen, aber wenns dann mal soweit kommt krachts halt auf der leitung ... oder kann ich eine kollision anders detektieren ?

[shaun]

Schon, Du kannst RE dauerhaft aktiv halten und mithören, ob das auf dem Bus ankommt, was der jeweilige Master gerade von sich gibt. Sobald einer merkt, dass er gestört wird, bricht er ab, wartet eine zufällige(!) Zeit und versucht es nochmal, sofern nicht inzwischen jemand anders quasselt. So wird's beim Ethernet gemacht (sofern keine zwei Aderpaare für FDX zur Verfügung stehen). Ein anderer Weg wäre, einen Master zu ernennen, der alle anderen Nodes pollt, oder die Berechtigung zum Senden im Ring herumzureichen (Token-Passing, wie bei Token Ring oder Arcnet)

[Ceos]

hm ... problematisch, 2 datenleitungen setzt nen master vorraus und polling verbrennt nur unsinnig leistung, oder ich setze nen extracontroller gezielt als master ein der alle controller abklappert ... nur inwiefern das ausfallsicher sit bleibt fraglich, wenn mal n controller die hufe macht z.B.

token passing ist genauso problematisch, was wenn einer der controller ausfällt ....

multimaster über eine ader ist schon am besten, muss ich hat nur kollisionsdetektion machen und ne ganz triviale busy-schaltung nehmen ...

wenn !busy -> claim -> busy -> send -> release -> !busy

und WENN mal 2 oder 3 gleichzeitig senden ... das ethernet verfahren, funktioniert dort doch auch ganz gut