LabView VI zur Dekodierung von Ethernet Frames

Ob Du mit dieser Aufgabe bei Labview richtig aufgehoben bist, wage ich 
zu bezeifeln. Mein Einstellung zu diesem Thema habe ich hier kundgetan:

Beitrag "Re: FPGA grafisch programmieren"

Hallo,

hab mir deinen Beitrag durchgelesen, und will nicht darüber urteilen ob 
du in allen Punkten damit Recht hast (ich denke z.B. dass es einfach 
rein vom Benutzer abhängt ob man damit nur rum"frickelt" oder damit ein 
wohl überlegtes Konzept realisiert - ob das nun grafisch erfolgt oder 
nicht, ist da mMn nicht der ausschlaggebende Punkt).

Es ist bei meiner Aufgabe auch ziemlich nebensächlich wie diese Frames 
dekodiert werden, von daher würd ich es auch gar nicht sinnvoll finden 
hier über LabView an sich zu diskutieren. Ich bin selbst kein Fan davon, 
aber mit einem solchen VI wäre es vermutlich die schnellste Methode um 
die Dekodierung mit dem mir zur Verfügung stehenden Oszilloskop mit so 
wenig Aufwand wie möglich durchzuführen.

Lg

Robert schrieb:
> ob das nun grafisch erfolgt oder
> nicht, ist da mMn nicht der ausschlaggebende Punkt

Doch, das ist der Punkt. Bei einer Grafik muß erst eine Interpretation 
dergleichen erfolgen. Das kann nie so effizient passieren, als wenn man 
die Aufgabe direkt kodiert.

Robert schrieb:
> Es ist bei meiner Aufgabe auch ziemlich nebensächlich wie diese Frames
> dekodiert werden

Das zeigt sich, wenn LabVIEW 2 Minuten zum dekodieren benötigt, während 
eine effiziente C-Umsetzung das ganze in einer Sekunde berechnet.

Das soll jetzt auch nicht gegen LabVIEW gehen, sondern die prinzipielle 
Problematik aufzeigen. Es gibt schon einen Grund dafür, dass LabVIEW 
oder auch Matlab Schnittstellen zu nativem Code haben.