Brauche Hilfe bei Algorithmenentwicklung (Kommunikationsprotokoll)

[Peter(TOO)]

Hallo White_Fox,

Die Idee mit den unterschiedlichen Telegrammtypen gefällt mir. Würde andere Schwierigkeiten, die ich mit meinem bisherigen Protokollentwurf noch sehe, lösen.

Ich habe so 20 Jahr Protokolle implementiert, sowohl genormte wie auch eigene. Da ist etwas Erfahrung hängen geblieben.

Allerdings steh ich immer noch vor der Frage: Wie entwickelt man Algorithmen, wenn es mit zwei simplen Rechenoperationen und einer boolschen Auswertung nicht mehr getan ist?
Ich denke da an sowas wie das Karnaugh-Veitch-Diagramm und Wertetabellen um boolsche Gleichungen aufzustellen. Gibt es für meine Aufgabe da auch ein Werkzeig? Ich kann mir schwer vorstellen daß Informatiker einfach nur im Kopf lauter If-Abfragen durchexerzieren und irgendwann ein UML da rauspressen. Das erscheint mir viel zu mühselig und...unstrukturiert.

Ich habe das immer über State Diagramme gemacht (Zustandsübergangsdiagramm).
Daraus kann man direkt eine State Machine codieren.
Diese State Machine habe ich dann direkt als Interrupt-Routine verwendet. Bei jedem Interrupt muss nur ein einzelnes Zeichen verarbeitet werden, Fehler können teilweise direkt erkannt werden und mit dem letzten Zeichen ist auch das ganze Telegramm ausgewertet, schneller gehts nicht.

Für die Zustandsübergangsdiagramme gibt es mittlerweile auch eine Reihe von Tools:
https://de.wikipedia.org/wiki/Zustan...ramm#Werkzeuge

Zudem ist das ganze auch un UML (Zustandsdiagramm (UML)) vorhanden.

MfG Peter(TOO)
P.S.
Ich habe mich zudem immer am OSI-Schichtenmodell orientiert. Wobei man nicht alle 7 Schichten wirklich getrennt implementieren muss, man kann für einfache Protokolle meistens mehrere Schichten zusammenfassen.

[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...

[Peter(TOO)]

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.

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.

[White_Fox]

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...

[Peter(TOO)]

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).

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.

[White_Fox]

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?

[Peter(TOO)]

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)

[HaWe]

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.