ZitierenIch hab mir mal die aktuelle ct (Nr. 16 vom 23.07.) besorgt. Irgendwie habe ich aber den hierfür nötigen Artikel übersehen. Auf welcher Seite wird denn darüber geschrieben?
hallo ihr da draussen.....
da jeder, der atmels programmiert, früher oder später über ein protokoll nachdenkt, das es ermöglicht, die daten des atmel und seiner peripherie auszulesen, möchte ich hier auf das derzeit aktuelle projekt der zeitschrift CT hinweisen.
dort wird ein universeller messplatz für elektroniker gebaut. das schöne daran ist nicht nur das projekt, sondern auch die "dual-use" informationen.
ct bietet den lesern eine kostenlose version der software "labview" an. diese software ermöglicht offenbar die steuerung und abfrage von beliebigen peripheriebausteinen, wie es auch atmels sein können.
ich finde die idee super... ich möchte, dass ihr mit arbeitet, um den "parser" -> das programm, dass in jedem atmel drin sein muss, um mit labview zu kommunizieren <- zu programmieren.
ich hoffe, euch gefällt die idee.
gruss klaus
Ich hab mir mal die aktuelle ct (Nr. 16 vom 23.07.) besorgt. Irgendwie habe ich aber den hierfür nötigen Artikel übersehen. Auf welcher Seite wird denn darüber geschrieben?
Wenn das Herz involviert ist, steht die Logik außen vor! \/
das mit dem CT-Lab wurd schon früher hier angesprochen, wie weit das jetzt ist weiß ich aber nicht
hier der "alte" Thread
https://www.roboternetz.de/phpBB2/ze...662&highlight=
Gruß
[X] <-- Nail here for new Monitor
folgt mal dem link auf die ct seiten:
http://www.heise.de/ct/projekte/ct-lab/
da sieht man mehr
Ja, das habe ich mir auch schon gedacht...
Man könnte verschiedenste Module entwickeln und sie zentral über das ct-lab steuern/auswerten.
Allerdings weiß ich nicht genau, wie die Anbindung an LabView funktioniert... Kann es sein, dass man dort auch erstmal eine Art Parser braucht, um mit dem ct-Lab zu kommunizieren? So ganz klar wurde das leider aus den Artikeln in der ct auch nicht (hab die Ausgaben alle hier, falls jemand Fragen hat...).
Mehr zum Thema auch hier:
http://www.heise.de/ct/projekte/mach...i/LabViewDemos
jetzt habe ich das thema ja angeregt und freue mich, das, wenn auch spärlich, einige leute interesse zeigen. also werde ich mal wieder etwas input geben.
also... labview ist ein programm der firma national instruments, das es ermöglicht irgendwelche vorgänge in verschidensten formen darzustellen. ich würde fas sagen, dass es das excel für techniker und elektroniker ist (excel kann halt balkendiagramme) und labview kann halt das, was man in dem link, den stefan_z eingestellt hat sehen kann.
hier nochmal der link:
http://www.heise.de/ct/projekte/mach...i/LabViewDemos
und stefan hat natürlich recht... es wird ein parser benötigt. wenn man in der labview software ein virtuelles messinstrument konstruiert, möchte dieses ja die darzustellenden daten irgenwo herholen. dazu benutzt es eine u.a. eine serielle schnittstelle. in unsre kleinen atmels muss also etwas hereinprogrammiert werden, was auf die anfrage von labview antwortet und die gewünschten daten sendet.
also ein parser, der auf bestimmte worte auf dem seriellen port adequat antwortet. das wäre doch super.
unser forum-kollege guenter1604 hat schon grosartige arbeit geleistet. er hat versucht, das ct-lab über fernbedienung zu steuern und entsprechenden code generiert.
ich zitiere hier mal aus seinem beitrag:
Hallo kolisson,
guck mal hier...
http://www.heise.de/ct/projekte/machmit/ctlab/ticket/10
und jetzt füge ich noch ein zitat aus dem ct-forum bei:
Re: Parser in Basic ?
Carsten Meyer, Carsten Meyer, cm@ct.heise.de (243 Beiträge seit 26.01.00)
Hallo,
einen toleranten UND platzsparenden Parser zu schreiben, ist nicht
ganz trivial. Der im c't-Lab hat gewisse Vereinfachungen, z.B. kann
man das Ausrufezeichen bei Befehlen auch weglassen (nicht jedoch das
Fragezeichen bei Abfragen).
Der Parser sammelt eingehende Zeichen zunächst in einem String, bis
ein CR oder CR/LF auftritt. Dann startet folgender Mechanismus:
Zeilen mit einem "#" am Anfang werden gleich an den OptoBus-Ausgang
durchgereicht und intern verworfen (weil Messwert von einem anderen
Modul).
Der Parser sucht zunächst nach einem Doppelpunkt. Wenn vorhanden,
nimmt er die Zahl vor dem Doppelpunkt als Modulnummer. Stimmt die
Zahl mit der über die Jumper eingestellte Modul-Adresse NICHT
überein, wird die Befehlszeile wie oben an den Ausgang durchgereicht
und verworfen.
Dann sucht er nach Buchstaben. Findet er einen, geht er davon aus,
dass man ein Mnemonik eingegeben hat. Die Buchstaben sammelt er, bis
er auf einen Nicht-Buchstaben (Leerzeichen, Sonderzeichen oder Zahl)
stößt. Dann schaut er in einer Tabelle (Array) nach, welcher
SubChannel dem Mnemonik entspricht. Findet er keinen entsprechenden
Eintrag, ist der Befehl falsch geschrieben oder unbekannt, und es
gibt eine Fehlermeldung. Ohne Mnemonik nimmt er die (erste oder die
dem Doppelpunkt folgende) Zahl direkt als SubChannel-Angabe.
Zahlen hinter dem Mnemonik (keine Zahl bedeutet "0") werden als
positive Offsets zur Mnemonik-SubChannel-Entsprechung (z.B. SCL hat
SubCh 200, SCL 1 => 200+1 => 201) gewertet, um einen eindeutigen
SubChannel zu bekommen. Leerzeichen können weggelassen werden.
Steht hinter dem Mnemonik, SubChannel oder SubChannel-Offset ein "?",
handelt es sich um eine Abfrage, und der gewünschte Wert wird
ausgegeben.
Trifft der Parser dagegen auf ein "=", handelt es sich um einen
(Ausgabe-)Befehl. Die Zahl hinter dem "=" ist der einzustellende
Wert. Leerzeichen und Nicht-Zahlen (und eigentlich auch das
abschließende "!") werden ignoriert.
Nach diesem Muster sind
0:20? {Modul-Adresse ist jetzt 0}
val 20?
VAL20?
val 20 ?
gleichwertig, ebenso wie
SCL?
SCL 0?
200?
VAL 200?
oder
0:VAL 20=1.5! {Modul-Adresse ist jetzt 0}
0:20 = +1.5
20=1.5
Hoffe, damit einige Klarheiten beseitigt zu haben.
cm
Berechtigungen
Lesezeichen