Moin Moin und: Frohe Weihnachten! Ich möchte die Ablaufsteuerung eines Messgerätes per AVR ( Atmega 8 oder ATmega 16 ) steuern. Der AVR soll via USB/RS232 von "aussen" gesteuert/getriggert werden. Der Messablauf soll im AVR selbstständig ( AD / DA via Multiplexer ) gehandhabt werden. Zunächst hatte ich vor, ein eigenes Binär basierendes Protokoll zu verwenden um das Parsing möglichst kurz und ressourcen schonend zu gestalten. Jetzt, über Weihnachten habe ich einen schicken Funktionsgenerator geschenkt bekommen der SCPI kann. Damit bin ich auf die Idee gekommen das gleiche Protokoll in meinem eigenen Messgerät zu verwenden um die externe Software möglichst frei gestalten zu können. Z.B. LabView/Matlab usw. Nur das Parsing macht mir etwas "Sorgen". Auf einem PC wäre dies gut mit lex/yacc oder "von Hand" möglich. Im AVR ist´s aber recht "eng" um einen komplexen Parser zu realisieren. Andererseitz müssen die "professionellen" Messgeräte ja auch nur mit einem µC auskommen. Ist das Vorhaben SCPI in einem "kleinen" AVR zu implementieren sinnvoll und praktikabel oder soll ich lieber ein propäritäres ( eigenes ) Protokoll verwenden? Hat einer von euch schon mal SCPI in AVR realisiert und ist gewillt Infos/SourceCode zu Posten? Allerbeste Grüße und Happy Basteln in der besten Zeit des Jahres... Karsten
Naja. du musst nicht igendwelche Befehle decodieren koennen, sondern nur 2-3 spezifische fuer die gewuenschte funktion. Dies erreicht man mit einer Zustandsmaschine. Ist kein Problem, nur ein paar wenige Zeilen.
Moin hacky, Danke für deine schnelle Antwort. Nun, nimmt man IEEE488.2 "ernst" so ist´s dann doch nicht sooo einfach. Es lassen sich ja z.B. mehrere Befehle zusammenfassen, Kurz/Langform, Parameter(Listen),Trigger/waits usw. Ich muss mehrere Spannungenund und Ströme "gleichzeitig" messen und regeln, Grenzwerte einhalten und konfigurierbar machen usw. Mit ein paar simplen *RST/MEASure oder ähnlichem komme ich leider nicht aus. Ich werde also mindestens drei tree´s ( Config/Trigger/system ) mit einigen subsystemen nötig haben :-( Abgesehen von ebenfalls unterschiedlichen zahlensystemen wie int,float,hex... die zu behandeln sind. Von Syntaxprüfung, Wertebereiche und Sinnhaftigkeit ( Paranoia-mode :-) ) mal ganz abgesehen. Gruß Karsten
Eine 1990 definierte Kommandosprache für Messgeräte wird man damals wohl kaum so komplex gestaltet haben, dass ein nicht zu teures Controllersystem damaliger Technik damit überfordert gewesen wäre. Und damit sollte ein heutiger AVR also durchaus mithalten können. Die Frage ist also eher, ob man den Aufwand, den man dafür reinstecken muss, als lohnend erachtet.
Moin prx, Nun, wenn ich mir so die Dokumente für SCPI ( IEE488.2) ansehe ist das ganze nicht trivial ( zumindest für mich ). Ob das nun 2011 oder 1990 standartisiert wurde ist ja auch egal, TCP wurde früher festgelegt und ist definitiv nicht trivial in eime microcontroller zu implementieren. Aber du hast recht! Es ist die Frage ob sich der Aufwand lohnt. Eine andere standartisierte Schnittstelle zu Messgeräten kenne ich nicht. Im Nachfolgenden erspare ich mir aber wahrscheinlich viel Aufwand mit der PC-Software wenn ich SCPI nutze. Dann kann man aus dem "Fundus" der SCPI fähigen Steuer/Visualisierer Software zurückgreifen. Es wäre eben interessant zu wissen ob hier im Forum schon mal jemand ein SPCI parser für AVR realisiert oder es zumindest ernsthaft versucht hat. Ein Erfahrungsaustausch könnte mir dann viel bei der Entscheidungsfindung helfen. Beste Grüße und vielen Dank für deinen INput! Karsten
Karsten K. schrieb: > TCP wurde früher festgelegt und > ist definitiv nicht trivial in eime microcontroller zu implementieren. Yep, aber TCP/IP war für die damaligen Minicomputer konzipiert, nicht für embedded Systeme. Beim IEC-Bus wird man aber kaum im Auge gehabt haben, jedem Messgerät einen 486-Prozessor in den Bauch zu schnallen. Ausserdem habe ich schon einen kompletten PL/65-Compiler für/mit 6502 in 8KB gesehen, der dies freilich mit einer recht speziellen Programmiertechnik realisierte. Wäre der Bezug zum anderen Messgerät nicht da, würde ich mich in diesem Fall allerdings nach einer FORTH-Implementierung als Basis umsehen. Daraus entwickelt sich die Steuersprache quasi automatisch und der autark arbeitenden Automatisierung sind dann kaum Grenzen gesetzt.
Gast
#2473337
Typisch für viele SCPI-Implementierungen ist es, dass sich eher lose an den Standard gehalten wird. Wenn es halbwegs wie SCPI aussieht und halbwegs wie SCPI funktioniert, dann geht es als SCPI durch.
Moin Mischmasch, Mischmasch schrieb: > Wenn es halbwegs wie SCPI aussieht und > halbwegs wie SCPI funktioniert, dann geht es als SCPI durch. O.K. Das überzeugt mich es mit SCPI zu versuchen! Solange ich nicht alles und jedes einhalten muss, kann ich nur die Dinge implementieren die ICH wirklich benötige. Herzlichen dank an alle für die hilfreichen Tipps! Gruß Karsten
Gast
#2473538
SCPI parser beispiel allerdings für PIC gibts hier http://www.usbtmc.de/index.html
Karsten K. schrieb: > ( Atmega 8 oder > ATmega 16 ) Gönn' Dir doch einfach einen atmega328p, da kannst Du Dich dann protokollmäßig austoben. Karsten K. schrieb: > TCP wurde früher festgelegt und > ist definitiv nicht trivial in eime microcontroller zu implementieren. Da ist dann oft genug auch nur eine kleine Untermenge "drin". Die Implementierung, die ich mir mal angesehen habe, konnte nur "antworten", nicht fragmentieren usw. "Korrekt" ist das nicht, aber allemal "ausreichend".
Gast
#2654482
Karsten K. schrieb: > Es wäre eben interessant zu wissen ob hier im Forum schon mal jemand ein SPCI parser für AVR realisiert oder es zumindest ernsthaft versucht hat. Ja, ich.. :) Das ist ein dynamisches Konstrukt aus Parser, Interpreter und Handler. In einem aktuellen Projekt ist dieses Konstrukt ~6000Zeilen lang und nimmt ~30kB Flash in Anspruch. Da das ganze aber komerziell ist, darf ich den Quellcode nicht offenlegen.. :-/
lex und yacc kann Code für den AVR generieren lassen, wenn man will. (Wenn du das ernsthaft vorhast, kann ich dir Patches geben, mit denen man die Tabellen in den Flash bekommt.) Aber das "Grundrauschen" des erzeugten Codes ist ziemlich hoch, ich glaube etwas über 20 KiB kommt da zusammen. Dafür ist der Parser natürlich verdammt schnell. Ich denke, dass die Sprache so schwierig nicht ist, als dass man das nicht auch irgendwie "zu Fuß" machen können sollte. Im Prinzip kannst du ja jedes Kommando nach dem vierten Buchstaben als erkannt betrachten (d. h. ob da jemand MEASURE oder MEASHIT schreibt, kann dir egal sein).