www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Mein Protokoll hat einen Bug! HELP!


Autor: Tobias Schlegel (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
HI!

Da ich nicht weis, wo ich das hier hinposten soll,
post' ich's einfach mal hier rein, mit der bitte,
es gegebenenfalls zu verschieben!

Ein kleines GROßES Problem:

Ich habe ja ein Protokoll geschrieben,
das funktioniert soweit auch WUNDERBAR!

Es funktioniert so:
Der Masterprozessor ist ein MEGA16, das Slave ein AT90S4433.

Sie sind beide über seriellen UART miteinander verbunden.
Der Slave dient dem Master sozusagen als "Depp vom Dienst",
der einfach dem Motor steuert und Servos ansteuert.

Das Problem ist: Man kann nur ein Befehl geben,
denn das Protokoll stürzt nach dem ersten sozusagen ab.

Die Quellcodes sind beide in BASCOM AVR BASIC geschrieben.
Sie sind beide in dem ZIP-File drin.

UART SPP-Master_TEST.bas ist der Quellcode für den Master
(ist eine einfache Testroutine...),
UART SPP-Slave.bas ist der Quellcode für den Slave.

Wenn ihr irgendwelche Fragen habt... Dateien benötigt... just say!!

Die Files sind beide in den Standardeinstellungen für den
jeweiligen Chip compiliert.

Leute, ich mach da jetzt schon ewig rum...
Aber meist steckt der Teufel ja im Detail...
NEED HELP!!

Liebe Grüße und Danke schonmal!,
Tobi

Autor: Andi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na ja, ohne Kommentare kann man als 'fremder' schlecht erkennen, was
was ist.
Und was A, B, C oder D sein soll, weist auch nur Du.

Gruß
Andi

Autor: Christof Krüger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du eine richtige umfassende Protokollspezifikation geschrieben?
Beschreib bitte mal formal oder in Worten, was das Protokoll leisten
soll.

Autor: Tobias Schlegel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Oops.. Ja Kommentieren hab' ich vergessen SORRY!!

Also das Protokoll soll:
-Die Motoren ansteuern
-Bis zu 10 Servos ansteuern NNR
-Die restlichen IO/Ports ansteuern NNR

NNR: Noch Nicht Realisiert.

Ich habe es speziell für den Einsatz in meinem Roboter 'Meech'
konzipiert und entwickelt.

Der Kommunikationsablauf funktioniert dann so:

Master: mot  //Er will irgendwas mit den Motoren machen.
Slave: o /*oder*/ f //o für okay f für fehler.
Master(bei o): fwd  bcw  stp / trn // In welche Richtung soll
  der/die Motor/en umgeschaltet werden? fwd: Forwärts, bcw: Rückwärts
  stp: Stop, trn: Turn; drehen.
Slave: o /*oder*/ f //o für okay f für fehler.
Usw.

Ich mache morgen eine Verson der Quelltexte mit Komments;
Mama sagt ich muss jetzt ins Bett. Schade.

Ich kann euch auch eine Grafik mit dem Protokollverlauf machen.
Nur wie gesagt... Mama sagt...

Liebe Grüße und Danke soweit!!

Tobi

Autor: Mark Hämmerling (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Salut,

Du sendest immer Strings? Find ich überflüssig kompliziert. Und
human-readable muß das Protokoll doch sicher nicht werden.
Sende doch einfach nur Bytes, ebenso die Antworten - z.B. 0x00 für
Erfolg, alles andere für entsprechende Fehlercodes: "Ungültiger
Befehl", "Wertebereichsüberschreitung", etc...
Das spart ne ganze Menge Arbeit bei der Auswertung der empfangenen
Strings.

Gruß,
Mark

PS: Und viele Grüße an Mama. Sie soll sich der Wissenschaft nicht so in
den Weg stellen. ;)

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
seh ich auch so.
-Eine Startsequenz vereinbaren
-Befehlsbyte (s) senden
-Datenbyte(s) senden
-CRC-Byte

Etwas einfacher wird die Programiererei, wenn man von Anfang an auf
feste Paketlänge setzt.

Autor: Tobias Schlegel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
HI!

Im Grunde genommen SIND das ja Bytes, die ich versende.
Es sind halt nur drei hintereinander und sie stehen stellvertretend für
Zeichen.
Ich wollte, dass das Befehlsversenden im Master etwas einfacher wird,
mit 1x47 könnte Motor rechts nach links drehen oder Motor links nach
Rechts drehen heißen. Und nach ein paar Tagen versteh ich das Protokoll
selber nicht mehr.

Klar, man könnte einen (Dreistelligen String-)Befehl für eine Operation
machen.Wäre eigentlich gar keine schlechte Idee.
Dann wäre der Code kürzer und der Master Slave Dialog kürzer und somit
das Protokoll schneller. Das werde ich mir durch den Kopf gehen
lassen!! Auf jeden Fall!

Aber OK. Die Kommentierte Version ist in Arbeit.

Selbst WENN ich nur einzelne Bytes versenden WÜRDE.
Würde das Protokoll warscheinlich auch abstürzen.

Ich weis nicht mal, wo ich nach dem Fehler suchen soll!


Aber Trozden DANKE schonmal bis hier!!

Liebe Grüße,
Tobi

Autor: Tobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
man kann sich konstanten anlegen und die stellvertretend für die zahlen
nehmen. dann kann man anständige name nehmen, nicht nur 3 zeichen und
ist übersichtlicher und schneller weil keine strings

Autor: Joline (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

kann sein, dass das jetzt etwas am Thema vorbeischlittert, weil Du ja
sicher schon eine Menge Zeit investiert hast. ;o)

Ohne mir den Code jetzt angesehen zu haben, nur aus den Kommentaren der
anderen schliesse ich, dass Du Dir ein Protokoll selber ausgedacht hast.
Aber warum sollte man nicht ein funktionierendes und weit verbreitetes
Protokoll einsetzen. Spontan fällt mir da der Modbus ein. Ist ziemlich
einfach zu implementieren, in der Industrie sehr verbreitet (deshalb
auch erprobt) und kann das abdecken, was Du machen willst.

Schau Dir dazu mal das hier an:

Modicon Modbus Protocol Reference Guide
   http://www.modicon.com/techpubs/TechPubNew/PI_MBUS_300.pdf

und

Demo mit Bascom
   www.mcselec.com/modbus.htm

Ich hoffe, das hilft.

Joline

Autor: Tobias Schlegel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
HI

Der /die /das Modbus-Protokoll ist sicher nicht schlecht.
Aber auf der MCS Seite habe ich den Slave dazu gesehen.
Ich habe in meinem Roboter leider nur wenig Platz,
Sodass ich nicht noch riesige Slaves einbauen kann.
Trozdem gute Idee! Danke!

Mein Protokoll soll von Atmel zu Atmel mit 2 Drähten
funktionieren. Es soll auch möglichst einfach sein.

DESHALB habe ich mich entschlossen, das Protokoll so umzubauen,
dass es immer EINEN Befehl für EINE Operation gibt.
Der Befehl wird wie immer 3Zeichen lang sein.
Dadurch wird das Ganze etwas übersichtlicher.

wie crazy horse geschrieben hat
wird dass dann so funktionieren:

-Initialisierungsbyte (Ein Byte mit der "IP" des Slave)
  Dann kann man mehrere Slaves an einen UART bus hängen,
  und es gibt noch tolle initialisierungsmöglichkeiten...
-Der angesprochene Slave antwortet mit seiner eigenen IP.(1Byte)
-Befehl 3 String Zeichen...
-Antwort: Ok-Byte bzw. Fehlercode (1 Byte)
-Eventuelle Parameter z.B. bei Servos den neuen Wert, wieder
  als 1 Byte.
-Antwort: Done-Byte bzw. Fehlercode (1 Byte)

Das ist viel einfacher.

Einigen wir uns Darauf: Ich schreibe das Protokoll um und teste es
dann ausführlichst. Wenn der Fehler wieder auftritt, werde ich diesen
Thread weiterschreiben...

OK?

Liebe Grüße,
Tobi

Autor: Tobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wenn du schonmal umbaust lass doch auch die 3 zeichn für den befehl weg.
ein zeichen/byte reicht und mit dem was ich oben geschrieben hatte nimmt
die übersichtlichkeit auch zu

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.