Hallo,
wie schon in dem uShell-Thread angedeutet, stelle ich (trotz androhung
von Punktabzug bei Verwendung von Zeiger-Schweinereien :-)) hier mal die
neue Version meines Parsers vor.
Dieser Parser ist deutlich einfacher aufgebaut.
Im Gegensatz zum 1. Parser wird hier ein Eingangsbuffer benötigt.
Auch werden nicht, wie im ersten Parser, die Tokens sukzessive
ermittelt, sondern schlicht und ergreifend einfach alles in der
Command-Liste durchsucht.
Durch diese beiden Einschränkungen kann der Parser auf 1 einzige
Funktion reduziert (mit integrierter Hilfe sinds etwas mehr) werden.
Weiters sind eine intergrierte Hilfe implementiert (die sich über den
Compilerschalter PARSE_USE_HELP deaktivieren lässt), und wie schon im
ersten Parser die sogenannten Value-Codecs.
Durch Verwendung eines Eingangsbuffers haben die Value-Codecs auch
deutlich mehr Möglichkeiten.
Die Parameterübergabe des Parsers an die aufzurufenden Funktionen
erfolgt, anders als im alten Parser, über einen Datentyp, in dem eine
fest definierte Anzahl von Parametern enthalten sind. Diese Parameter
sind Unions in denen Platz für die Daten der Value-Codecs ist.
Der Präprozessor (und damit auch das Gemüt der Leute die sich diesen
Code evtl. antun :-)) wird in diesem Parser nicht so sehr strapaziert.
Allerdings konnte ich mir (nach einigen Überlegungen) es doch nicht
nehmen lassen die Konfiguration des Parsers ebenfalls in einem separaten
Konfigurations-File abzulegen.
Die Konfiguration in uParse_cfg.h erfolgt in folgenden Abschnitten :
- PARSE_DATA_UNION
Hier wird der Union-Datentyp für die Parameterübergabe definiert. Die
Variable ucType entspricht dem Value-Codec der aufgerufen wurde.
- PARSE_COMMAND_FUNC
Hier werden externals für die, per Command, aufzurufenden Funktionen
definiert.
Beispiel :
extern void vTest (UCHAR ucCmd, T_CMD_DATA_ELEMENTS *pstElements);
Mit #define PARSE_USE_HELP in diesem Abschnitt kann die Hilfe
mitcompiliert werden.
- PARSE_LIST_FUNC
Hier kann dem Makro vParserWriteChar(x) eine Funktion zum Ausgeben von
Zeichen zugeordnet werden, damit die integrierte Hilfe genutzt werden
kann.
- PARSE_CODEC
Hier werden die Funktionen der Value-Codecs eingetragen. Weiterhin kann
für die Auflistung ein Text zum jeweiligen Codec angegeben werden.
- PARSE_COMMAND
Hier stehen alle Befehle die der Parser erkennen kann. Die Value Codecs
werden über die Binärzeichen \x01 - max \x1F aufgerufen (in der
reihenfolge in der sie in PARSE_CODEC definiert wurden).
Zum Demo :
Das Demo ist für einen ATMega32 (lag gerade so langweilig herum :-). Man
benötigt nur eine RS232 und eine Systemfrequenz von 11.0592 MHz
(ansonsten muß man anpassen, ist aber nicht viel) und man kann ein paar
befehle per rs232 testen (inkl. help)
Diese Version des Parsers ist bestimmt noch nicht ganz fehlerfrei. Werde
im Laufe der Zeit (hoffentlich nach Feedback :-) korrekturen und neue
Versionen reinstellen.
Gruß
Rene
hat das denn jemand mal ausprobiert ?
oder ist das code-schnipsel mal wieder total unbrauchbar ?
ich verzweifel langsam. weder ein : "total unnütz", noch ein "jo danke",
noch ein "mmh. und was soll das jetzt".
gebt doch mal bitte ein statement dazu ab.
TheMason wrote:
> gebt doch mal bitte ein statement dazu ab.
Naja, ist immer noch recht heftig groß und Ressourcen verbrauchend.
Ich hab ja meinen einfachen Kommandointerpreter:
http://www.mikrocontroller.net/attachment/26437/COMMAND.C
Ist schön klein und übersichtlich, einfach zu erweitern und verbraucht
auch nur ganz wenig Flash.
Vielleicht sollte ich mal ne Anpasssung für die AVRs mit der
Kommandotabelle im Flash machen.
Bin aber bisher mit dem SRAM ausgekommen, habs daher auf dem AVR auch so
laufen.
Peter
dein code ist in sachen größe ja auch nicht zu schlagen :-)))
wenn ich mir so den bootloader oder das 1-draht-rs-232-display-aufm-tiny
angucke.
aber das deswegen keiner meinen code brauchen kann ?!
sollte es das wirklich sein ?
>aber das deswegen keiner meinen code brauchen kann ?!>sollte es das wirklich sein?
Bei mir nicht. Ich weiß einfach überhaupt nicht, WOZU man Deinen Code
gebrauchen KÖNNTE. Ein paar schlichte, leicht verständliche Worte
darüber, worin der Sinn und Zweck der Chose besteht, lässt Dein Beitrag
ja vermissen. Vielleicht gehts zu vielen anderen ja genauso?
Aber nix für ungut... ist nur meine Meinung :-)
>Ich weiß einfach überhaupt nicht, WOZU man Deinen Code>gebrauchen KÖNNTE.
hätte vielleicht wirklich den link zum ursprungsthread (uShell - ein
universeller Parser für uCs) setzen sollen. Sorry.
Also mal eine kurze erklärung :
Dieser Code stellt einen einfach zu konfigurierenden
Kommando-Interpreter dar, indem über eine Konfigurationsdatei sämtliche
Befehle sowie weitere Erweiterungen (sogenannte Value Codecs, welche der
dekodierung von ASCII-Zeichenfolgen wie Hexadezimalwerte,
Zeichenkettenfolgen wie Strings [ueber "..."] dienen) definiert werden
können) vorgegeben sind.
Als aufzurufende Funktionen werden die im sogennanten PARSE_COMMAND
Abschnitt definierten funktionen bei Eintreffen eines passenden
Eingangsstrings aufgerufen.
Der Code ist für AVR (speziell die RAM/Flash Problematik) angepasst und
sollte jedem der sich ein wenig in C-Code auskennt (hoffentlich) recht
einfach verständlich sein.
Ich hoffe ich habe es geschafft diesen missing link (um es mal in
dänglish) auszudrücken :-)) zu füllen.
Falls weitere Fragen bestehen einfach melden.
>Allerdings kenn ich den Vorgänger-Thread nicht, und Du hast leider>auch keinen Link dahin gesetzt.
Hier der fehlende link zum Vorgänger Thread :
Beitrag "uShell - ein universeller Parser für uCs"
Hoffe hiermit den fehlenden Informationen Genüge zu leisten.
Gruß
Rene
Moin,
ich bin gerade auf der Suche nach einem "neuen" Parser, der der bisher
verwendete ziemlich langsam und aufwändig ist.
Jetzt frage ich mich, ob deiner für meine Zwecke passt. Ich habe mir
zwar schon den Code angesehen, muß aber sagen das ich ihn bisher nicht
komplett verstanden habe.
Erst einmal habe ich Eingaben wie
L=1
?L
?dst
usw
Also immer ein Schlüsselwort und entweder einer Abfrage "?" davor oder
einen Setzbefehl mit einem Parameter. An Befehlen können da schon mal
100 verschieden zusammenkommen.
In einer Erweiterung soll das ganze dann in Richtung XML gehen:
aus L=1 wird dann so etwas wie
< cmd="L" value="1" ID="52" />
wobei die genauen Angaben noch nicht feststehen. Es ist aber auf jeden
Fall vorgesehen das ein Befehl dann aus mehreren Parametern bestehen
kann.
Ist der Parser dafür geeignet und wenn ja würdest du bei fragen zur
Anpassung helfen?
Als letztes noch: das Zielsystem ist kein AVR sondern ein 56F8367 von
Freescale, also ein Hybridcontroller (DSP und µC) ohne die
Speicherbesonderheiten vom AVR.
Gruß Mike
Hallo,
Ich habe einen eigenen Commandointerpreter bei meinem AVR Webserver
verwendet. Dieser scheint aber vom Aufbau fast identisch. Natürlich alle
Variablen und Defines vom Namen anders/umbenannt, aber die gleiche
Grundstruktur.
Gruß
Uli
Hallo Uli,
hatte mir deinen Parser noch nicht angeschaut.
Mein Grundgerüst hatte ich anfang/mitte Dezember geschrieben. Ist
eigentlich für einen Assembler (unter DOS/Windows) gewesen, habe den
aber abgespeckt für AVR, nachdem ich das Feature mit den value codecs
über die Steuerzeichen 1-31 eingebaut habe.
@mike
prinzipiell müsste sich der parser so konfigurieren lassen das du solche
eingaben machen kannst.
der ursprüngliche parser war (wie oben schon geschrieben) für einen
assembler gedacht. da hatte ich auch einen codec für programmiert mit
dem man ausdrücke (z.b. 10+20*40+b*(c+5*(a+b)) ) eingeben konnte.
allerdings ist diese variante etwas groß für den avr da dort rekursive
aufrufe oft verwendet werden.
du kannst über die value-codecs (das können namen, strings, zahlen oder
eben auch ausdrücke) dir die befehle beliebig zusammenstellen.
z.b.
"? \x01" würde bei ? xxx dir eine von dir angegebene funktion aufrufen
und als parameter "xxx" liefern.
oder mit
"\x01 = \x02" würde dir die aufgerufene funktion einmal den parameter
"x" und den parameter "5" liefern.
