Re: [OT]Re: RS 232 Code für Microcontroller (GCC Compiler)
- From: Paul Rosen <proxx@xxxxxxxx>
- Date: Thu, 25 Sep 2008 02:18:51 +0200
Frank Buss <fb@xxxxxxxxxxxxx> wrote:
Das Plugin könnte man selber programmieren, da LabVIEW auch erlaubt, selbst
programmierte Plugins einzusetzen. Oder auch innerhalb von LabVIEW, mit
reinen LabVIEW-Komponenten. Ein Beispiel ist mein Silabs-Test, der über die
serielle Schnittstelle mit LabVIEW kommuniziert. Aber auch das wäre recht
viel Aufwand, verglichen mit deiner reinen C-Lösung.
Aufwand, der sich nicht lohnt, da ja jetzt Alles bis auf die genannten
Kleinigkeiten gut läuft. Jede Lösung, die Ihre eigenen Platinen oder
Chips mit fertig gebrannter unzugänglicher Firmware benötigt, ist aus
leidvoller Erfahrung ungeeignet. Man liefert sich dabei dem jeweiligen
Hersteller aus, ist auf dessen Buglösungen, Featureimplementation bzw
Liefertreue angewiesen. Außerdem machen sie mich extrem unflexibel bei
einer effizienten Hardwareimplementation. Alles wird aufgeblasen mit
eigenen Hardware und Software Tools sowie Compiler, die das
wiederholen, was es eigentlich in effizienter Form schon alles (in
diesem Falle bei Microchip) erprobt von einer Unmenge an Personen
schon gibt. Man bräuchte seine Lösung hier nur reinzuimplementieren.
Dazu kommen aufwendige Hardware, Gehäuse und Steckverbindungen. Für
das Ganze braucht man denn wieder große Schaltschränke.
Dabei könnte es so einfach sein. Mit einem Controller und ein bißchen
Peripherie sowie in die Entwicklungsumgebeung direkt hinein zu
implementierenden Tools, das deren Inline-Debugging Schnittsttelle
nutzt, kann man schon eine ganze Menge erschlagen. Aber so etwas gibt
es einfach nicht. Hier liegt meiner Meinung nach eine rein in Software
zu implementierende echte Marktlücke brach, für die es eine Unmenge
zahlungskräftige Klientel gäbe. Es bräuchte "nur" eine Art erweitertes
http://www.ti.cs.uni-frankfurt.de/wwr/LogiFlash.swf
oder Labview zu geben, das den C- oder Assembler-Code produziert und
im Debugger sowohl das Grafikfenster, als auch das des erzeugten
C/Assembler-Codes parallel anzeigt und beim Einzelschritt, Breakpoint,
animierten Run und den sonstigen üblichen Möglichkeiten des Debuggings
beide unterstützt, wobei der User das vom Debugging bediente Fenster
durch Focussierung auswählt. Die Nutzung der Inline Schnittstelle
hätte den unschätzbaren Vorteil, dass alle schon jetzt in der
Entwicklungsumgebung funktionierenden Hardware und Softwaretools
problemlos weiter verwendet werden könnten.
Ein kleines Beispiel für eine Minimierung unnötigen Overheads: Ein
Messgerät in einem großen 19 Zoll Gehäuse, Preis 16.000 Euro habe ich
nach jahrelanger Suche des Messverfahrens durch einen Controller und
ein bißchen Peripherie ersetzen können. Bisher war der Aufwand an
zusätzlicher Hardware und Software immens, um das empfindliche
Analogsignal unbeschädigt von der Messstelle aus der bewegten Mechanik
zum Gerät zu beförden, das zudem ein Hindernis bei der Wartung der
Maschine darstellte. Für diese Geräte gibt es weltweit nur einen
einzigen Hersteller. Daher ging man dort auch nicht auf unsere
Änderungswünsche ein (oder konnte es mangels nicht mehr greifbarem
Software Entwickler nicht mehr). Da wir das Gerät nicht exakt seiner
ursprünglichen Zielsetzung entsprechned nutzen, wäre es nämlich für
uns sehr hilfreich gewesen, eines der Zwischenergebnisse beim
Berechnen des ausgegebenen Endwertes gehabt zu haben, ohne das unser
Prozess nur suboptimal lief und daher aufwendige Maßnahmen zur
Kompensation erforderlich waren.
Diese analoge Lösung des Herausführens des Messsignales selbst zu
entwickeln, wäre mir zeitlich kaum möglich gewesen. Jetzt fährt der
Controller mit gerade mal 200 Zeilen Paules SPS Code +
Spezial-Software- Messbaustein spazieren und setzt das Signal 1 cm von
der Messstelle entfernt um, die analoge Herausführung braucht es nicht
mehr, das Zwischenergebnis ist bekannt und alle Probleme sind in Luft
aufgelöst. Auch sämtliche bisherigen Störungen des Messsignals durch
den EMV verseuchten Prozess existieren nicht mehr. Für die Messung
muss der Prozess jetzt nicht mehr aufwendig gestoppt werden. In der
nächsten Generation kann die Mechanik der Maschine erheblich
vereinfacht werden. Z.B. auf einem Controller mit Fertigfirmware wäre
diese Entwicklung wegen des ganzen Overheads und damit Verschleierung
beim hardwarenahen Debugging und der fehlenden Flexibilität wohl kaum
möglich gewesen.
Das bei den Lösungsanbietern natürlich niemals laut ausgesprochene
Motto "Nach der Kohle die Sintflut." ist sogar ein Stück weit
verständlich. Schließlich braucht man immer wieder neue
Einnahmequellen. Solange bleibt wohl nichts Anderes übrig, als dass
jeder seine eigene Lösung immer wieder neu erfindet.
.
- References:
- Re: [OT]Re: RS 232 Code für Microcontroller (GCC Compiler)
- From: Paul Rosen
- Re: [OT]Re: RS 232 Code für Microcontroller (GCC Compiler)
- From: Raimund Nisius
- Re: [OT]Re: RS 232 Code für Microcontroller (GCC Compiler)
- From: Paul Rosen
- Re: [OT]Re: RS 232 Code für Microcontroller (GCC Compiler)
- From: Frank Buss
- Re: [OT]Re: RS 232 Code für Microcontroller (GCC Compiler)
- From: Paul Rosen
- Re: [OT]Re: RS 232 Code für Microcontroller (GCC Compiler)
- From: Frank Buss
- Re: [OT]Re: RS 232 Code für Microcontroller (GCC Compiler)
- From: Paul Rosen
- Re: [OT]Re: RS 232 Code für Microcontroller (GCC Compiler)
- From: Frank Buss
- Re: [OT]Re: RS 232 Code für Microcontroller (GCC Compiler)
- From: Paul Rosen
- Re: [OT]Re: RS 232 Code für Microcontroller (GCC Compiler)
- From: Frank Buss
- Re: [OT]Re: RS 232 Code für Microcontroller (GCC Compiler)
- Prev by Date: Re: [OT]Re: RS 232 Code für Microcontroller (GCC Compiler)
- Next by Date: Re: nntp.arcor.de nicht erreichbar?
- Previous by thread: Re: [OT]Re: RS 232 Code für Microcontroller (GCC Compiler)
- Next by thread: Re: [OT]Re: RS 232 Code für Microcontroller (GCC Compiler)
- Index(es):
Relevant Pages
|