www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Programmbeispiele für fortgeschrittene Programmierung


Autor: Matthias W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Abend,

ich suche Lösungsansätze für fortgeschrittene Programmierung, da ich 
eine größere Applikation schreiben möchte. Mir geht es z.B. um die 
sinnvolle Bearbeitung empfangener Daten. Wie prüfe ich diese, wie 
springe ich die entsprechenden Routinen zu den empfangenen Befehlen an, 
wie behandle ich Fehler usw. Kurz: Ein Beispiel einer größeren 
Applikation, die ein Befehlsprotokoll enthält, mit Fehlerprüfung 
(Kommunikationsfehler als auch "Parameter"-Fehler), Fehlerbearbeitung 
und Rückmeldung an den User usw.
Alles was mir mein Hirn gebracht hat, war irgendwie nur halbgar, 
vielleicht stell ichs mir zu kompliziert vor :-)
Kann hier jemand so eine Applikation posten? Das wär echt super!

Matze

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich glaube eine richtig fertige App wirst du hier nicht unbedingt 
bekommen. Aber wenn du konkrete Fragen stellst, kann bestimmt jemand 
auch eine Antwort liefern, die dir hilft (im Gegensatz zu dieser hier 
;-)

Gast.

Autor: Matthias W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Gast:

Du hast bestimmt recht, im Prinzip wärs darauf hinausgelaufen, dass ich 
mir meine App aus verschiedenen fremden Apps zusammengestückelt hätte, 
und mich dann gefragt hätte, warums nicht tut...

Also mal sehen, ich möchte dem Controller Befehle senden. Der Aufbau der 
Befehle sieht etwa so aus:

BB[DD...DD]CR

BB = Befehlsbyte
DD = optionale Datenbytes
CR = Carriage Return

Das Befehlsbyte liegt im Bereich der darstellbaren Zeichen, also von 
0x20 bis 0x7F. Meistens handelt es sich um Buchstaben.
Die Datenbytes sind ausnahmslos ASCII-Hex-Zeichen.
Der Controller soll auf jeden Befehl antworten, und zwar so, dass der 
User im Fehlerfall erkennt, was der Fehler war (Bufferüberlauf, falsche 
Werte eingegeben, falsche Zeichen, etc.)

Ich habe eine Routine geschrieben, die die Daten empfängt, und in einem 
Buffer ablegt. Der Buffer ist gegen Überlauf geschützt, die Routine wird 
solange ausgeführt, bis das CR-Zeichen kommt, selbst wenn ein Überlauf 
auftrat. Ein Datenzähler enthält die Anzahl der empfangenen Daten.

Das heisst, nach dieser Funktion habe ich einen Buffer, der mindestens 
ein Befehlszeichen plus optionaler Daten enthält.

So und jetzt wirds für mich kribblig. Eine Wandlung der 
ASCII-Hex-Zeichen nach Hex bekomme ich noch hin, logischerweise sollte 
ich das machen, bevor ich einen Befehl ausführe, sonst kann ich in jeder 
Befehlsroutine konvertieren, das halte ich für ungünstig.

Aber wie löse ich z.B. das Anspringen der entsprechenden Befehlsroutinen 
abhängig vom Befehlsbyte? Ein Switch-Case-Konstrukt wird da sicher 
unübersichtlich. Hm... vielleicht Funktionspointer? Mir bildet sich da 
grad ne Idee... Die muss ich mir mal durchn Kopp gehen lassen...

Egal, was mich dann noch interessiert, wie behandle ich Fehler? 
Beispiel: Ich erkenne, dass die empfangenen Daten zwar ASCII-Hex-Zeichen 
sind, aber sie sind ausserhalb des Bereichs (also hat der Bediener 
gemurkst --> falschen Wert eingegeben). Wie löse ich es so, dass der 
User anhand der Antwort vom Controller den Fehler entdeckt, also ob er 
einen falschen, ungültigen Wert oder ob er ein "verbotenes" Zeichen 
gesendet hat? Oder ob der Buffer übergelaufen ist?
Fragen über Fragen...

Matze

Autor: Bernd Rüter (Firma: Promaxx.net) (bigwumpus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also,
ich habe das mal mit einer State-Engine gelöst.

Da wurde auch der ganze Text empfangen und dann bearbeitet.
Do while
case State
State=0 ... warten auf Start-Code (Byte), dann State=1
State=1 ... Byte hat das richtige Format für Cmd ? Nein-Error
   Cmd=1 ? - State=$10
   Cmd=2 ? - State=$20
State=10 oder $20 ... HEX-Zeichen ? nein-Error
   Byte in Hex wandeln ... wenn x Bytes durch ... State=State+1
State=11 oder $21 ... Byte=CR ? nein-Error
   State=$11 ... Cmd 1 ausführen
   State=$21 ... Cmd 2 ausführen
end case
weiterrücken
loop

Da kann man dann eine Syntax prüfen und gleichzeitig einen Zustand $?1 
für mehrere Befehle nutzen (versch. Datenbytes) und es trotzdem kompakt 
halten.
Der Vorteil einer solchen State-Engine ist der starre und klare Aufbau 
(Übersicht). Man kann jeden Zustand fest einordnen und programmiert sich 
nicht zu Tode (Spagetti-Code). Aber man muß da mal etwas Gehirnschmalz 
einbringen. Ich arbeite gerne damit, weil es hilft, Programmierfehler 
(side-effects) zu vermeiden.
Klare abgeschlossene Zustände mit festen Regeln für den Wechsel in einen 
anderen Zustand (Ausgänge schalten etc.) sind der Vorteil, den man mit 
etwas Codespeicher bedingt durch die Nutzung der Compiler-Direktiven 
CASE erkauft. Aber der Speicher sollte heute nicht mehr so sehr wichtig 
sein. Zur Not kann man am Ende des Projekts noch etwas Handarbeit 
nachlegen um Code zu sparen.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias W. wrote:
> Also mal sehen, ich möchte dem Controller Befehle senden. Der Aufbau der
> Befehle sieht etwa so aus:
>
> BB[DD...DD]CR
>
> BB = Befehlsbyte
> DD = optionale Datenbytes
> CR = Carriage Return

sieht doch schon mal gut aus.

>
> Das Befehlsbyte liegt im Bereich der darstellbaren Zeichen, also von
> 0x20 bis 0x7F. Meistens handelt es sich um Buchstaben.
> Die Datenbytes sind ausnahmslos ASCII-Hex-Zeichen.

Gut

> Ich habe eine Routine geschrieben, die die Daten empfängt, und in einem
> Buffer ablegt. Der Buffer ist gegen Überlauf geschützt, die Routine wird
> solange ausgeführt, bis das CR-Zeichen kommt, selbst wenn ein Überlauf
> auftrat. Ein Datenzähler enthält die Anzahl der empfangenen Daten.

OK

> Das heisst, nach dieser Funktion habe ich einen Buffer, der mindestens
> ein Befehlszeichen plus optionaler Daten enthält.

OK

> So und jetzt wirds für mich kribblig. Eine Wandlung der
> ASCII-Hex-Zeichen nach Hex bekomme ich noch hin, logischerweise sollte
> ich das machen, bevor ich einen Befehl ausführe, sonst kann ich in jeder
> Befehlsroutine konvertieren, das halte ich für ungünstig.

Warum soll das ungünstig sein?
Letztendlich kann doch nur die Befehlsroutine wissen ob sie
jetzt eine 2 Byte Zahl oder eine 4 Byte Zahl haben möchte oder
ob die Zeichen vielleicht sogar direkt (also ohne Umwandlung)
benutzt werden sollen.

>
> Aber wie löse ich z.B. das Anspringen der entsprechenden Befehlsroutinen
> abhängig vom Befehlsbyte? Ein Switch-Case-Konstrukt wird da sicher
> unübersichtlich. Hm... vielleicht Funktionspointer? Mir bildet sich da
> grad ne Idee... Die muss ich mir mal durchn Kopp gehen lassen...

Guckst du mal hier
http://www.mikrocontroller.net/articles/FAQ#Men.C3...

anstelle des Menüs benutzt du das empfangene Befehlsbyte um
den richtigen Eintrag zu finden.

>
> Egal, was mich dann noch interessiert, wie behandle ich Fehler?
> Beispiel: Ich erkenne, dass die empfangenen Daten zwar ASCII-Hex-Zeichen
> sind, aber sie sind ausserhalb des Bereichs (also hat der Bediener
> gemurkst --> falschen Wert eingegeben). Wie löse ich es so, dass der
> User anhand der Antwort vom Controller den Fehler entdeckt, also ob er
> einen falschen, ungültigen Wert oder ob er ein "verbotenes" Zeichen
> gesendet hat? Oder ob der Buffer übergelaufen ist?
> Fragen über Fragen...

Wie wäre es mit
Einen Klartext per UART zurücksenden, der den Benutzer
darüber aufklärt.
Was auch immer gut kommt: Zumindest etwas von der Eingabe
wieder ausgeben, damit der Benutzer erkennen kann, wo den
der Fehler aufgetreten ist.
Also etwas in der Form
** Fehler in B24FG76
**               *
** ungültiges Zeichen

Autor: Matthias W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Bernd, hallo Karl-Heinz,

sorry für die späte Antwort. Danke euch beiden, ich werd das mal in 
aller Ruhe durchgehen. Mal sehen ob ich durch die State-Machine bzw. die 
geänderte Menü-Routine die App ans laufen bekomme.
Nochmals besten Dank.

Matze

Autor: rene (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias,
ein menschenlesbares Protokoll hat den Vorteil, dass man's an Hyperterm 
einhaemmern kann. Dann sollte man allerdings den CRC weglassen. Wenn das 
Protokoll mit einer Software abgearbeitet wird, macht man's anders. Dann 
muss es naemlich nicht lesbar sein, und auch nicht ASCII. Als Beispiel 
fuer ein Maschinenprotokol moege meine Seite dienen.
http://www.ibrtses.com/embedded/shortmsgprotocol.html

Rene

Autor: Matthias W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Rene,

hab mir dein Protokoll mal angeguckt. Du arbeitest ohne 
Abschlusszeichen, soweit ich das sehen kann. Was passiert, wenn z.B. ein 
Zeichen verloren geht? Lässt du ein TimeOut laufen? Oder dient das 
Sync-Zeichen dazu, vorher unvollständig empfangene Daten zu verwerfen?

Matze

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.