Mensch Peter...Zustandsübergangsdiagramme, da hab ich doch schonmal was von gehört. Das scheint mir genau das zu sein nach dem ich suche...
Mensch Peter...Zustandsübergangsdiagramme, da hab ich doch schonmal was von gehört. Das scheint mir genau das zu sein nach dem ich suche...
Findest du auch in Datenblättern. Ein kleines einfaches bei den meisten µCs, wenn es um Reset, Sleep usw. geht.Zitat von White_Fox
Mensch Peter...Zustandsübergangsdiagramme, da hab ich doch schonmal was von gehört. Das scheint mir genau das zu sein nach dem ich suche...
Ich hatte mal ein recht komplexes für eine Maschine gezeichnet. Waren so 20 bis 30 Seiten. Hatte ich dann bei mir an die Wand geklebt und die Transitions mit farbiger Nähseide markiert. War sonst zu mühsam die Labels immer auf den Blättern zu suchen.
Manchmal frage ich mich, wieso meine Generation Geräte ohne Simulation entwickeln konnte?
Ok...ich schätz ich weiß wie ich es (zumindest auf der PC-Seite) angehe. Da gibt es ein prima Entwurfsmuster, um einen Zustandsautomaten zu realisieren, da hatte ich doch unlängst ein klasse Buch in der Hand (Entwurfsmuster von Kopf bis Fuß-äußerst empfehlenswert).
In Java kann ich das gut machen, aber in C (ich will das ja noch einen Mikrocontroller programmieren) leg ich mir damit die Karten. Na-aber auch das Problem erschlag ich schon irgendwie. Erstmal das Ganze in Java zum Laufen bringen (das wird mit einem ausführlichen Unit-Test eh lang genug dauern...)
Vielen Dank für eure Anregungen bisher. Ich rolle den Thread wieder auf wenn ich das in C implementiere...
Wenn du den Automaten gezeichnet hast, kannst praktisch direkt ab der Zeichnung codieren.
Zuerst gibt es einen grossen Switch mit allen Zuständen.
In jeden Zustand siehst du dann, welche Bedingung in welchen anderen Zustand wechselt und was zu tun ist.
Bis du das zusammen, und auch alle Ausnahmen berücksichtigt, hast, musst du am Meisten Nachdenken.
Das State-Diagramm ist wie eine Flow-Chart, die Codierung ist wirklich nur einen Fleissarbeit.
Zumindest für mich war das dann der langweilige Teil der Arbeit.
Manchmal frage ich mich, wieso meine Generation Geräte ohne Simulation entwickeln konnte?
Ja, das Codieren selber find ich auch nicht allzu spannend. Die Denkarbeit reizt mich auch mehr, naja...
Wobei die Implementierung eines Zustandsautomaten mit Klassen deutlich einfacher geht als mit einer riesigen Switch-Anweisung.
Eine Frage zu deinem Protokoll-Kopf hab ich noch:
Du schickst den CRC gleich sofort mit. Warum, wo ist da der Vorteil?
So wie ich das am Anfang machen wollte, ist der CRC kein Bestandteil des Telegramms. Den Teil, wo der CRC enthalten ist, kann ich ja schlecht in die Prüfsummenberechnung einschließen, da das Ergebnis zur Zeit der Berechnung selbstverständlich nicht bekannt ist.
Also...warum hast du es so gelöst?
Die Prüfsumme wird als letztes angehängt, zu diesem Zeitpunkt ist alles bekannt.
Die Prüfsumme befindet sich übrigens auf OSI-Layer 2 Wobei in der Beschreibung Level 2 und 3 teilweise zusammengefasst sind, bzw. nicht sauber getrennt werden, weil dies mehr Daten ergäbe.
OSI ist nur eine Empfehlung und Stütze, kein Zwang!
BTW: Prüfsumme und CRC sind zwei etwas unterschiedliche Verfahren.
MfG Peter(TOO)
Manchmal frage ich mich, wieso meine Generation Geräte ohne Simulation entwickeln konnte?
ich schicke die Prüfsumme auch gleich mit, dann kann der Empfänger die Prüfsumme nach Empfang sofort nachrechnen und mit der mitgeschickten vergleichen, und sieht dann sofort, ob alles ok ist mit der Nachricht.
Der Härtetest ist die abreißende Verbindung. Wenn also der Stecker gezogen und anschließend wieder angesteckt wird (oder die Funkverbindung mal kurzfristig abreißt), sollten beide Seiten störungsfrei weiterlaufen.
Wenn das funktioniert, ist das Protokoll gut.
Berechtigungen
Zitieren
Lesezeichen