hi, zwei uC sollen allerlei Daten sammeln und weiterleiten; zwei deshalb, weil es viele Quellen gibt. Es gibt aber nur eine Leitung "nach oben", siehe Symbolbild. Steuerbefehle "von oben" werden einfach parallel von beiden uC empfangen und mittels eines Adressbits unterschieden. Nur senden dürfen sie eben nicht gleichzeitig. Die Daten fallen ziemlich asynchron in Päckchen von ca. 7 Byte an, sind bei 115200 Baud also weniger als 1ms lang. Man könnte notfalls mit 1kHz abwechselnd senden, aber wenn von einer Seite ein Burst kommt, nutzt man die Leitung nicht einmal zur Hälfte aus. Jetzt wäre eine Art Mutex-Hardware oder ein Test-And-Set-Befehl aus Gatterbausteinen gefragt, im Bild mit 3 Fragezeichen angedeutet. Meine Suchmaschinen finden nur Software-Lösungen, hat evt. jemand eine Idee?
Angehängte Dateien:
-
mutex.png
10 KB
Hi, die Daten, welche ja in Paketen vorliegen, solltest du sowieso mit sowas wie einer CRC oder ähnlich sichern. Da hardwaremässig beim Senden nichts kaputt gehen kann, würde ich den uC einfach drauf los senden lassen. Wenn es jetzt eine Kollision gibt, dann empfängt die Gegenseite Mist und stellt fest, dass die CRC nicht passt. Die Gegenstation muss dann jeden uC mitteilen, dass sein Telegramm korrupt war und nochmals gesendet werden muss. Nachdem die Gegenseite aber das Telegramm absetzt, dass dass die CRC falsch war, müssen die beiden uC für eine zufällige Zeit warten, bis jeder sein Telegramm nochmals sendet, da es sonst sofort wieder zu einer Kollision kommt. Den Zufallszahlengenerator für die Wartezeit kannst du mit einem LFSR machen. Oder andere Idee, mach es wie Token Ring. Obwohl du zwar keinen Ring hast ;-) die Berechtigung zum Senden wird jeweils "im Kreis herum gereicht". D.h. nur der, der gerade "dran" ist, darf senden. Wenn er nichts zu sagen hat, sagt er seinem Nachbar "ich bin fertig". Die sauberste Lösung wäre aber übrigens wirklich CAN, da du da die CRC und eine saubere Adressierung über Node IDs schon mit drin hast.
eagle user schrieb: > Jetzt wäre eine Art Mutex-Hardware oder ein Test-And-Set-Befehl aus > Gatterbausteinen gefragt, im Bild mit 3 Fragezeichen angedeutet. Meine > Suchmaschinen finden nur Software-Lösungen, hat evt. jemand eine Idee? Auch mit Hardware ist eine Race Condition nicht ausgeschlossen, mach das doch in Software. EXOR zum MASTER alleine nutzt dir da auch nicht viel, ohne Arbitration geht das trotzdem in die Hose. Theoretisch besteht immer die Möglichkeit, dass beide gleichzeitig anfangen zu senden, deswegen wäre ein CAN-Transceiver, z.B. MCP2551 zu empfehlen, also CAN nur auf Hardwareebene benutzen, da es die Möglichkeit der Arbitration bietet. uC1 hat z.B. die Adresse 0x08, uC2 hat 0x07, die Adresse wird als erstes Byte gesendet, wenn alles in Ordnung ist, wird weiter gesendet. Nach erfolgreicher Sendung werden die Adressen getauscht, jetzt hat uC1 die Adresse 0x07, uC2 die Adresse 0x08 usw. Sollte es zur Kollision kommen, wartet derjenige, bei dem die Adresse nicht durchgekommen ist, bis zum Paketende und sendet dann sein Paket mit der neuen (niedrigeren) Adresse.
Man kann vieles basteln, und manchmal macht das basteln auch Sinn. Hier eher nicht. Dein Controller hat CAN on Chip. 2 billige Transeiver dran und locker die Daten rausspucken. 7 Byte pro Nachricht - noch ein Grund für CAN. 8 Byte passen in eine Nachricht, da brauchst du dich um gar nichts kümmern, einfach rausfeuern (Ok, bis der Bus tatsächlich voll ist :-). Wenn deine RS232-Leitung mit 115k funktioniert, geht es mit CAN mit 1MBit.
Baendiger schrieb: > Oder rs485 Der Unterschied zwischen CAN und RS485 ist nur, dass bei CAN das Mehrfachzugriffsproblem durch das Protokoll und den CAN-Controller gelöst ist, bei RS485 muss man sich selber darum kümmern.
RS485 hilft hier gar nichts, es sei denn Bandbreite wäre das Problem. Das eigentliche Problem (wer darf wann senden) besteht genauso wie bei der obigen UART-Parallelschaltung oder ist sogar noch komplizierter (der Weg vom Tx-Master zu Rx-Slave funktioniert immer, bei RS485 nicht von alleine).
Der Knackpunkt ist, daß Du ohne Not 2 MCs verwenden willst. Damit bürdest Du Dir einen riesen Haufen Protokoll auf, damit die beiden vernünftig zusammen arbeiten können. Nimm nur einen MC und wenn Du mehr UARTs brauchst, nimm dumme UART-SPI Umsetzer, z.B. MAX14830 (4-fach UART). Ein 32Bit-Bolide kann leicht auch weitere UARTs mit Timern (Input-Capture, PWM-Output) in Software realisieren. Glaub mir, 2 oder mehr MCs unter einen Hut zu bringen ist so ziemlich die komplizierteste Lösung.
Du könntest, wenn Du an 2 Controllern unbedingt festhalten möchtest, die beiden Controller 'Daisy-Chainen'. D.h. µC1 sendet die Daten 'von oben' auch an µC2 weiter. Die Daten die 'nach oben' sollen, wandern von µC2 aus direkt nach oben, Pakete von µC1 werden in µC2 zwischengebuffert und gesendet, wenn er selber nichts zu senden hat. Gruß Jobst
Erstmal herzlichen Dank für alle Antworten! Tobias Plüss schrieb: > Da hardwaremässig beim Senden nichts kaputt gehen kann, würde ich > den uC einfach drauf los senden lassen. (...) müssen die beiden uC > für eine zufällige Zeit warten, bis jeder sein Telegramm nochmals sendet Damit hätte auch endlich der fette STM32L476 seine Berechtigung, der hat einen echten RNG :) > mach es wie Token Ring. Obwohl du zwar keinen Ring hast ;-) > die Berechtigung zum Senden wird jeweils "im Kreis herum gereicht". Das dürfte die einfachste (nur je 2 GPIOs) Lösung sein und es funktioniert von selbst. Na gut, man muss aufpassen, falls zeitweise nur 1 uC läuft. Nachteil: ohne weitere Tricks wird das Token mit mehr als 1 MHz hin- und hergeschoben solange nichts los ist. Das wäre dann mit Abstand der höchste Takt außerhalb von einen Chip. Marc Vesely schrieb: > Auch mit Hardware ist eine Race Condition nicht ausgeschlossen, (...) > ohne Arbitration geht das trotzdem in die Hose. Genau das war meine Frage: wie könnte eine Arbitration-Hardware aussehen. > Theoretisch besteht immer die Möglichkeit, dass beide gleichzeitig > anfangen zu senden, deswegen wäre ein CAN-Transceiver, z.B. MCP2551 > zu empfehlen, also CAN nur auf Hardwareebene benutzen, da es die > Möglichkeit der Arbitration bietet. Naja, der MCP2551 kann auch nicht mehr, als mein AND-Gatter. Ohne echte CAN-Controller bringt der garnichts. Peter Dannegger schrieb: > Der Knackpunkt ist, daß Du ohne Not 2 MCs verwenden willst. > Damit bürdest Du Dir einen riesen Haufen Protokoll auf die Token-Ring-Lösung wäre schon noch überschaubar, oder? > wenn Du mehr UARTs brauchst, nimm dumme UART-SPI Umsetzer, > z.B. MAX14830 (4-fach UART). Ein 32Bit-Bolide kann leicht auch > weitere UARTs mit Timern (Input-Capture, PWM-Output) in Software > realisieren. Dafür ein extra Danke, SPI-UARTs und Software-UARTs waren völlig in Vergessenheit geraten, obwohl ich ein reines softes einsetze :( > Glaub mir, 2 oder mehr MCs unter einen Hut zu bringen ist so > ziemlich die komplizierteste Lösung. Aber auch die interessanteste, CAN kann ja jeder -- außer mir. Ich fürchte mich dermaßen davor, die Treiber zu programmieren, das ist wie Angst vor Gewitter, da kann man nichts machen. Dabei bietet sich CAN hier wirklich an: H.Joachim Seifert schrieb: > Dein Controller hat CAN on Chip. 2 billige Transeiver dran > und locker die Daten rausspucken. 7 Byte pro Nachricht - > noch ein Grund für CAN. Ja, auch die Art, wie und wo die Nachrichten anfallen, ist CAN-typisch. Zu allem Überfluss gibt es auch 2 bis 3 Nachrichten-Prioritäten... Ein echtes Argument gegen CAN hätte ich doch: Dank der Abschlusswiderstände braucht CAN deutlich mehr Strom als RS422. Jobst M schrieb: > Die Daten die 'nach oben' sollen, wandern von µC2 aus direkt > nach oben, Pakete von µC1 werden in µC2 zwischengebuffert und > gesendet, wenn er selber nichts zu senden hat. das mache ich schon an anderer Stelle, aber das ist doch langweilig ;) Ich dachte, es müsste doch auch parallel gehen, hätte ja sein können. Wenn ich auf die universelle Lösung für maximale Bandbreite verzichte, geht es ja auch ganz einfach, immer abwechselnd für ca. 1ms.
Ev. ist eine 2.UART an einem der mc eine Lösung, wenn Dir CAN zu kompliziert ist: mc2 UART1 TXD ------> UART2 RXD mc1 UART1 TXD -----> Host RXD mc2 UART1 RXD <------ UART2 TXD mc1 UART1 RXD <----- Host TXD Gruß, Stefan
eagle user schrieb: > Aber auch die interessanteste, CAN kann ja jeder -- außer mir. Ich > fürchte mich dermaßen davor, die Treiber zu programmieren, das ist wie > Angst vor Gewitter, da kann man nichts machen. Dabei bietet sich CAN > hier wirklich an: Hm, gibts doch bestimmt fertig, nur ein klein wenig anpassen (habe es mit einem STM32 noch nicht gemacht) > Ein echtes Argument gegen CAN hätte ich doch: Dank der > Abschlusswiderstände braucht CAN deutlich mehr Strom als RS422. Das ist falsch. Aber woher kommt plötzlich RS422? Wenn du das in einen MC bekommst, ist das auf jeden Fall die beste Lösung.
eagle user schrieb: > Steuerbefehle "von oben" werden einfach parallel von > beiden uC empfangen und mittels eines Adressbits unterschieden. Na dann mach halt einen zusätzlichen Befehl "Sende deine Daten", und nur der adressierte antwortet - m.a.W. ein Master-Slave-Betrieb, und alles wesentliche dafür ist ja schon vorhanden. Georg
H.Joachim Seifert schrieb: > Aber woher kommt plötzlich RS422? > Wenn du das in einen MC bekommst, ist das auf jeden Fall die > beste Lösung. Ich meinte dieses RS422: https://de.wikipedia.org/wiki/EIA-422#Beschreibung das sind doch nur andere Pegel auf dem Kabel, ansonsten sehe ich keinen Unterschied zu V.24. Insofern ist RS422 alleine keine Lösung, oder wie meinst du "in einen MC bekommen"? Im Symbolfoto hab' ich MAX232 eingezeichnet, weil, wer kennt schon ISL3171E. Die sind Slew-Rate begrenzt und brauchen deshalb auf kurzen Kabeln keine Abschlusswiderstände. Dadurch brauchen sie weniger als 1mA. CAN braucht doch immer die Widerstände? Georg schrieb: > Master-Slave-Betrieb Dann müsste ich ja ständig pollen und selbst bei 100 Abfragen pro Sekunde wäre die Latenz noch 10 mal größer als jetzt.
eagle user schrieb: >> Theoretisch besteht immer die Möglichkeit, dass beide gleichzeitig >> anfangen zu senden, deswegen wäre ein CAN-Transceiver, z.B. MCP2551 >> zu empfehlen, also CAN nur auf Hardwareebene benutzen, da es die >> Möglichkeit der Arbitration bietet. > > Naja, der MCP2551 kann auch nicht mehr, als mein AND-Gatter. Ohne echte > CAN-Controller bringt der garnichts. Auch wenn es schon bedeutend bessere Vorschläge zu deinem Problem gibt: Der MCP2551 kann schon mehr, nämlich den Zustand am Sendebus erkennen. Wenn du 0x08 sendest, aber 0x07 wird zurückempfangen, dann ist das schon eine Arbitration. CAN als Protokoll brauchst du dafür gar nicht - nur die Hardware. EDIT: Oder 0x07 raus, 0x08 rein, habs vergessen. EDIT2: LOL, Null ist Dominant, hab mich erinnert. :-)
:
Bearbeitet durch User
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.