Hi zusammen, ich möchte für mein Kommunikationskonzept einen UART am Atmega168 nutze um mehrere miteinander zu verbinden. Nun frage ich mich ob es möglich ist eine art Fehlerüberprüfung mit "Rücklesen" der soeben gesendeten Daten vom "Bus" zu realisieren. Kann man mit dem UART überhaupt gleichzeitig schreiben und lesen, was passiert mit den Interrups, kann soetwa ineinaner haken, oder muss ich mit Problemen rechnen? Wenn ein "gesendet" bit kommt, kommt ja auch gleichzeitig ein "empfangen" Bit. Habt Ihr soetwas mal gemacht, bzw. Erfahrungen mit dem Thema? Gruß, Thorsten
Du kannst das machen, aber das wird nix bringen da du dann nicht weisst ob die Daten falsch angegekommen sind oder dein Empfang fehlerhaft war. Außerdem ist UART kein "Bus" sonder P2P, das "Listen while talking" braucht man nur wenn Gefahr besteht, dass andere "dazwischenreden".
Thorsten S. schrieb: > um mehrere miteinander zu verbinden. Nun frage ich mich ob es möglich > ist eine art Fehlerüberprüfung mit "Rücklesen" der soeben gesendeten > Daten vom "Bus" zu realisieren. Sicher ist das möglich. Der Empfänger schickt das was er gelesen hat postwendend wieder zurück. Das Problem ist nur: wie gehts dann weiter? Wartet der Empfänger dann auf den Sender, dass der die Bestätigung schickt "Du hast alles korrekt empfangen" und was ist, wenn in dieser Bestätigung ein Fehler auftritt. Muss der Empfänger dann die Bestätigung der erfolgreichen Übertragung auch wieder bestätigen? > Kann man mit dem UART überhaupt > gleichzeitig schreiben und lesen, Klar kann man > was passiert mit den Interrups, Nichts. Was soll damit sein? Wer zuerst kommt, malt zuerst. Der andere Interrupt wartet. > kann > soetwa ineinaner haken, Wenn man sich ungeschickt anstellt und zb in einer ISR die Interrupts freigibt: klar kann das haken > oder muss ich mit Problemen rechnen? Wenn ein > "gesendet" bit kommt, kommt ja auch gleichzeitig ein "empfangen" Bit. Äh. Nein. UART funktioniert (für dich als Programmierer) auf Bytebene. Um die Bits kümmert sich die Hardware, die geht dich als Programmierer nichts mehr an. > Habt Ihr soetwas mal gemacht, bzw. Erfahrungen mit dem Thema? Wie wäre es wenn du erst mal eine ganz normale UART Übertragung baust?
Hallo, mit "bit" meinte ich das entsprechende "Uart Transmit Complete" o. "Receive Complete" Bit. War etwas unglücklich ausgedrückt. Eine "normale" Datenstrecke habe ich schon im gange, nur wird es nun etwas komplizierter, denn ich komme wieder mal an die Grenze dessen was man hat, und dessen was man will. Ich setze den Atmega168 in mehreren Projekten ein... Mein Plan ist es ein Bussystem mittels des UARTs im Atmega und einem CAN Physical Layer Baustein (82C250) zu realisieren. Die "Rückmeldung" von der ich sprach ist somit schon das "eigene Wort". Im grunde genommen möchte ich das machen was die meisten an der Stelle wollen, mehrere Controller miteinander verbinden, und jeder kann beleibig senden, also nicht alle abfragen, ein dezentrales System. Die RS232 Kommunikation mittels mehrerer CAN Bausteine funktioniert auch schon, jeder hört jeden, das klappt. Ich benötige nur nicht den komlizierten Aufbau der CAN Schnittstelle. Dennoch, wenn es auf diesem Wege zu kompliziert wird, hilft es alles nichts. Ich würde nur gern bei HMD Komponenten bleiben und platzlich bekomme ich diese auch unter. Nun stehe ich vor dem Problem des CD Collision Detect... Gruß, Thorsten
Jetzt weißt du auch, warum man mit UART nach Möglichkeit kein "jeder darf zu jedem beliebigen Zeitpunkt" macht.
Informiere dich mal nach "K-Bus" Die machen da sowas ähnliches. Da hast du nen UART TX auf nen Open Collector Treiber geschaltet und die RX Leitung liest quasi das zurück, was hinter dem Treiber ist (Also auch das was du selber sendest) --> Wenn jemand "dazwischen redet" wirst du nicht mehr das empfangen, was du gesendet hast...
Hi! Beim normalen CAN wird das so gemacht: Derjenige der etwas senden will, guckt ob die Leitung frei ist (rezessiver Buspegel). Wenn ja, fängt er an zu senden und zwar zuerst seine eigene Adresse (= die Priorität der Nachricht, man kann auch die Priorität nach vorne packen, ansonsten ist die eben an die Absenderadresse fest gekoppelt). Wenn zufällig jemand anderes gleichzeitig anfängt zu senden, überlagern sich die Pegel auf dem Bus: der dominante Pegel gewinnt (schaltungstechnisch) über den rezessiven Pegel. Jeder hört jetzt während er sendet gleichzeitig den Bus ab. Wenn er einen dominanten Pegel auf dem Bus feststellt, selbst aber gerade ein rezessives Bit sendet muss da noch jemand anderes sein der sendet - der hat eine höhere Priorität (an den beiden Adressbytes "zuerst" einen dominantes Bit wo der andere ein rezessives hat). Der unterlegene Sender stellt daraufhin die Sendung ein damit ein späteres dominantes Bit nicht dem eigentlich bevorrechtigten Sender die Adresse zerschießt (wenn dieser an der Stelle rezessiv senden würde). Das Problem das mit der U(S)ART zu machen ist jetzt dummerweise, dass du mit deiner Sendung sofort dann aufhören musst wenn du erkennst, dass der andere bevorrechtigt ist. Das merkst du aber erst dann, wenn du das komplette Byte schon verschickt hast - dann hast du eventuell dem anderen schon das erste Byte "zerschossen". Selbst wenn du sagen würdest "okay, wenn das erste Byte falsch gesendet wird macht das nichts" hättest du ein Problem - denn sowohl der berechtigte als auch der unberechtigte Sender würden eventuell ein Byte vom Bus zurücklesen wo es ein paar Unstimmigkeiten zwischen dem gesendeten und dem empfangenen Byte gibt. Keiner der beiden weiß allerdings, ob ein der andere schon 2 Bit weiter vorne als er selber "aussteigen" wollte. Du hast dann also keine Möglichkeit, die Busarbitrierung (die Entscheidung wer senden darf) zu treffen sondern nur die Möglichkeit, die Kollision zu erkennen und es dann nach einer kurzen Wartezeit nochmal zu probieren. Dabei solltest du auch beachten, dass andere Teilnehmer die am Bus hängen die "verfälschte" Nachricht auch als solche erkennen können müssen. Heißt: Irgendeine Prüfsumme mitschicken die die veränderte Nachricht hinreichend sicher erkennt, sonst werden von den anderen Busteilnehmern noch irgendwelche Sachen ausgeführt, die nicht beabsichtigt waren. Für die Kollisionserkennung alles garkein Problem - eleganter wäre hier aber wohl eine Software-UART die die Bits gleich wieder einliest, vergleicht und bei nicht-übereinstimmung die Sendung für eine kurze Zeit unterbricht. Das entspricht dann auch dem "echten" CAN-Protokoll, welches so eigentlich garnicht schlecht ist ;) Gruß, Tobi
Ergänzung: Eine Möglichkeit, dass zu machen wäre das "Aussteigen" (also einen Unterschied zwischen Buspegel und Ausgang des µC) direkt in einer zwischengeschalteten Logik zu machen: - Wenn der µC senden will, resettet er die Logik. Diese schaltet dann den Ausgangspegel des µC an den CAN-Baustein. - Sobald der µC einen High-Pegel sendet, der Bus allerdings dominant ist (=low), schaltet die Logik den µC "vom Netz". Der µC erkennt aufgrund des Bytes, welches er danach einliest (oder durch einen extra "Kollisions"-Pin der Logik) das er abgewürgt wurde und versucht es nach einiger Zeit nochmal. - Zwischen "High-Pegel vom µC" und dem Prüfen des Bus-Levels auf dominanten Pegel solltest du eine kurze Zeit warten - der CAN-Treiber dürfte zwar recht schnell sein, aber auch da gibts Limits. Mit ein bisschen Bastelei also zu machen - allein die Frage bleibt, obs mit der Software-UART nicht einfacher geht ;) Gruß, Tobi
K-Bus der 82C250 macht eben genau das in einem Baustein, sodas ich dieses nicht mehr einzeln aufbauen muss... ...hallo Tobi, vielen Dank für die ausführliche Antwort. Mir ist wichtig das ich ganz klar kein CAN nachbauen will... Sobald erkannt wird das zwei gleichzeitig gesendet haben, kann man sich ja einen anderen plan überlegen, die die gesendet haben werden es beide merken...oder man sorgt dafür.. die die zuhören könnten es auch über eine spezielle nachricht erfahren oder ähnliches... Es muss keine Prioritäten geben, es werden nur ab und zu mal ein paar Pakete gesendet... Viel mehr sorgt mich etwas der Parser, wie bekomme ich das in den griff, falls mal etwas scheif geht, das alle damit klar kommen.. Gruß, Thorsten
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.