Hallo Zusammen,
Ich habe da ein paar Fragen bezüglich der seriellen Schnittstelle der
atmega8.
Und zwar gibt es einen Masterkontroller an den ca. 4 atmega8 über die
selbe serielle schnittstelle angeschlossen sind. Wenn ich
softwaretechnisch gewährleisten kann dass immer nur einer von den
4atmega8 daten sendet, ist das ein problem wenn sie an der selben
seriellen hängen oder muss ich sie hardwaremässig irgendwie entkoppeln?
Prinzipiell möchte ich dass die hauptstation gewährleisten kann dass
alle gesendeten daten an die anderen KOntroller richtig angekommen sind:
Und zwar so:
Implementierung Haupt- atmega8:
1.) Aufrufen von "sendezeichen"
2.) Sende die daten mit usarttransmit
3.) Timer starten
4.) Wird bevor der interrupt des timers kommmt ein zeichen empfangen,
gehe zu Schritt 6.)
5.) Werden keine daten empfangen bis der interrupt auslöst, gehe
zurueck nach 2.)
6.) vergleiche das byte mit dem zuvor gesendeten byte
7.) wenn gleich--> schritt 8.), sonst gehe zurueck nach Schritt 2.)
8.) warte bis der interrupt im slaveatmega8 ausgeloest hat,
damit ein neues zeichen gesendet werden kann und verlass die
routine
Implementierung Slave atmega8:
1.) Es wird ein byte empfangen
2.) Sende das byte gleich wieder und starte einen timer
3.) Wird der interrupt ausgeloest bevor ein neues byte empfangen wird
daten waren in ordnung gebe das byte frei, ansonsten gehe verwerfe das
byte
Das ganze kann nur funktionieren, wenn ich dafür sorge dass immer nur
ein kontroller sendet. Dies lässt sich meiner meinung nach mit dem
multiprozessor modus der atmega8 realisieren.
Mich würde interessieren, wo ihr die Schwächen dieser Methode seht, oder
ob man das ganze einfacher und besser aufbauen könnte.
Danke für eure beiträge.
lg sebastian
>oder ob man das ganze einfacher und besser aufbauen könnte.
Um Dir diese Frage zu beantworten, müsste man das wirkliche Ganze ja
erstmal kennen. Ich meine diese gewissen Posts, die mit "Also eigentlich
will ich folgendes machen" anfangen... ;-)
Ansonsten würde ich immer versuchen, eine Aufgabe - wenn es irgendwie
geht - mit nur einem µC zu lösen, statt ein Multi-Prozessor-System zu
kreieren. Ich setze mich nur ungern mit Fragen des Busdesigns,
Adressmanagement, Timinggedöns, Arbitrierungsstrategien,
Übertragungsprotokolle, Vermeidung/Handling von Zugriffskonflikten und
Maßnahmen bei Datenverlust auseinander - daran führt aber kein Weg
vorbei, wenn die Chose am Schluss auch zuverlässig funktionieren soll.
Du bist ja gerade dabei, das zu merken. Ich kann mir auch Schöneres
vorstellen als die Software eines solchen Systems zu debuggen, oder
glaubst Du, so etwas läuft auf Anhieb perfekt? Nein, sowas läuft zum
Beispiel ein paar Minuten und stürzt dann "völlig unerklärlicherweise"
ab. Da kann man bei der Fehlersuche dann viel Spaß haben.
"Welche Möglichkeiten gibt es, die Aufgabe mit einem µC zu
bewältigen?" - ich fände das Gehirnschmalz in der Suche nach einer
Antwort auf diese Frage immer besser investiert. Das ist meine
Meinung. Es gibt ne Menge Leute, die mal aus irgendwelchen Gründen ein
tolles Multi-µC-System aufbauen wollten, und in ihrer Unerfahrenheit
dachten, wenn sie es "einfach so und so" machen, dann müsste es prima
gehn. Ich kenne keinen, dem es gelungen ist.
Danke für deine Antwort. Das ganze ohne mehrere µC aufzubauen ist leider nicht möglich, es muss also ein Multiprozessorsystem sein. Prinzipiell brauche ich die Zweiwegekommunikation nur, um zu gewährleisten dass die richtigen daten ankommen. Datensicherheit steht also auf oberster Ebene, weil prinzipiell müssen die Slave-Kontroller keine Daten senden. Ist das also hardewaremässig machbar, oder ist das hardewaremässig schon nicht möglich. Softwaretechnisch glaube ich nicht, dass das so ein Problem sein wird. Faktor Sendezeit ist ja egal, also kann ich da genug große Zeitfenster einbauen, dass das ganze auch stabil läuft. lg sebastian
> Wenn ich > softwaretechnisch gewährleisten kann dass immer nur einer von den > 4atmega8 daten sendet, ist das ein problem wenn sie an der selben > seriellen hängen oder muss ich sie hardwaremässig irgendwie entkoppeln? Denke daran, dass der UART auch dann, wenn er nichts sendet, die Tx-Leitung aktiv auf High zieht. Du musst in der Software also nicht nur sicherstellen, dass immer nur einer sendet, sondern auch, dass immer nur ein UART-Sender aktiviert ist, und der Portpin ansonsten als Eingang konfiguriert ist. Dann kannst du die Tx-Slave-Leitungen direkt zusammenschalten.
>Das ganze ohne mehrere µC aufzubauen ist leider nicht möglich, es muss >also ein Multiprozessorsystem sein. OK. Dann rate ich Dir, jederzeit darauf zu achten, alles so unkompliziert wie möglich zu machen. Blos keine Tricks oder irgendwelche "Quick and Dirty"-Mätzchen - darüber verlierst Du garantiert früher oder später die Kontrolle. >Prinzipiell brauche ich die Zweiwegekommunikation nur, um zu gewährleisten >dass die richtigen daten ankommen. Datensicherheit steht also auf oberster >Ebene, weil prinzipiell müssen die Slave-Kontroller keine Daten senden. Eine starke Erleichterung würde es bedeuten, wenn die Slaves nur empfangen, aber wirklich nie senden müssen. Du könntest die gewünschte Datensicherheit auch über Checksummen erreichen; dann könnten die Slaves reine Empfänger sein. Zu jedem reinkommenden Datenpaket berechnet der betreffende Slave die Checksumme und vergleicht sie mit dem vom Master errechneten mitgesendeten Wert (wobei das dann schon wieder eine der "unangenehmen" Fragen nach sich zieht, nämlich was der Slave tun soll, wenn die Checksumme nicht übereinstimmt - er kann dem Master ja keine Schick-nochmal-Aufforderung senden). Ein Zurückschicken aller empfangener Daten zum Master gewährleistet auch keine perfekte Datensicherheit. Es würde vielmehr dazu führen, dass der Master bisweilen glaubt, der Slave hätte falsche Daten, obwohl er richtige hat, nämlich immer dann, wenn die Daten auf dem Rückweg verfälscht werden. Du hast nur vier Slaves... hm... vielleicht wäre das eine Alternative: Der Master sendet über den UART Daten an die Slaves, und zwar immer an alle. Das Ansprechen einzelner Slaves wird über Adressen gemanagt. Die UART-Rückleitung von den Slaves zum Master wird nicht genutzt. Stattdessen gibt es von jedem Slave eine Extra-Leitung zum Master, über die der Master z. B. das Vorhandensein der Slaves feststellen oder einfache Statusinformationen empfangen kann. Am Master wären dann der Tx-Pin plus vier weitere normale Pins (als Input konfigurert) belegt, für jeden Slave einen. Damit wärst Du von der "Mehrere Slaves senden gleichzeitig UART-Daten an den Master"-Problematik weg.
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.