C-Code inLabVIEW Embedded for ARM ?

Hallo,

ich möchte einen grösseren bereits vorhandenen C-Code in ein "LabVIEW-Embedded for ARM" Projekt integrieren. Wenn ich sowas für das normale LabVIEW mache, erstelle ich eine DLL, die ich dann über ein "Call Libary Function Node" aufrufe. Hier ist mir auch der Sinn einer DLL klar, da man so die Funktionalität direkt nutzen kann.
Wenn ich jedoch den Code mit Matlab Embedded auf einem ARM ausführe, dann macht eine DLL meines erachtens nicht sehr viel sinn - da das Modell bei Ausführung ohnehin komiliert wird. Zudem weis ich nicht, wie ich eine passende DLL für den ARM erstelle. Gleiche gilt für CIN, wobei dieses ja, da in LabVIEW Embedded nicht vorhanden, ohnehin nicht funktionieren wird.

Gibt es keine Möglichkeit einfach C-Projekt in Sourcen Form einzubinden, so das diese Platformübergreifend funktionieren ? Etwa so wie bei dem Inline-C-Node, welcher aber nur für einfache Funktionen nutzbar ist, da hier ja nur ein C-File + Header genutzt werden kann, oder sehe ich das falsch ?

Gruß & Danke

amin

Anzeige

CIN ist für Embedded Varianten nicht unterstützt, also schmink Dir das gleich ab. Für C Code gibt es im Embedded Module die C Node, oder sowas. Sieht ähnlich aus wie eine Forumula Node aber Du fügst dort echten C Code ein der zusammen mit dem anderen C Code der vom LabVIEW Diagramm generiert wird, mit der Toolchain für Dein Zielsystem kompiliert wird. Der C code muss demgemäss auch ganz genau kompatibel sein mit dem Zielsystem Compiler.

Rolf Kalbermatter

Hallo,

vielen Dank erstmal.

Das mit dem Inline C-Node scheint bei den ersten Versuchen prinzipiell zu funkionieren. Jedoch habe ich hier ein Problem das ich in den eingebundenen Header Files immer die dazugehörigen gleich benannten C Files nochmal als include setzen muss. Und hierbei auch noch den kompletten Pfad angeben muss, obwohl sie im gleichen Ordner liegen.

Gibt´s dafür eventuell eine elegantere Lösung, so dass ich den Ordner irrgendwo definieren kann und LabVIEW dann von selbst die C Files findet ?

Gruß

amin

' schrieb:Hallo,

vielen Dank erstmal.

Das mit dem Inline C-Node scheint bei den ersten Versuchen prinzipiell zu funkionieren. Jedoch habe ich hier ein Problem das ich in den eingebundenen Header Files immer die dazugehörigen gleich benannten C Files nochmal als include setzen muss. Und hierbei auch noch den kompletten Pfad angeben muss, obwohl sie im gleichen Ordner liegen.

Gibt´s dafür eventuell eine elegantere Lösung, so dass ich den Ordner irrgendwo definieren kann und LabVIEW dann von selbst die C Files findet ?

Gruß

amin

Das hat wahrscheinlich wenig mit LabVIEW zu tun. Der Code aus der inline Node wird einfach mit in den C Code übernommen, den LabVIEW aus den VIs generiert. Dieser wird dann an den entsprechenden C Compiler geschickt den Du in Deiner Umgebung als Teil der Toolchain konfiguriert hast. Ich denke dass Du da ansetzen musst, und nehme mal an dass Du in den Project Settings eine Sektion hast wo Du solche Dinge wie die Umgebungseinstellungen die an den C Compiler übergeben werden müssen, einstellen kannst.

Rolf Kalbermatter

Danke !

Da hast Du natürlich recht, hier wird wohl die Hauptschuld beim Compiler zu suchen sein. Jedoch gehört dieser (Keil uVision) eigentlich fest zu zu LabVIEW Embedded for Arm.
Eine Einstellmöglichkeit habe ich im Übrigen leider nicht gefunden.

Gruß & Danke nochmal

amin

' schrieb:Danke !

Da hast Du natürlich recht, hier wird wohl die Hauptschuld beim Compiler zu suchen sein. Jedoch gehört dieser (Keil uVision) eigentlich fest zu zu LabVIEW Embedded for Arm.
Eine Einstellmöglichkeit habe ich im Übrigen leider nicht gefunden.

Gruß & Danke nochmal

amin

Frag mal bei NI Tech Support. Da muss es irgendwo Konfigurationsmöglichkeiten geben. Eventuel zumindest durch Umgebungsvariablen auf Systemebene.

Rolf Kalbermatter

Ich möchte gerne Code aus dem Keil-Beispiel "USBCDC" für das MCB2300 Board in LabVIEW benutzen. Den Code mittels einer "Inline C Node" zu integrieren, funktioniert nicht, da LabVIEW durch die große Codemenge sehr langsam wird und dann auch abstürzt. Zudem bekomme ich viele Fehlermeldungen beim Compilieren.
Die "Call Library Funktion Node" zu benutzen, scheint mir auch viel komfortabler zu sei. Da Keil und LabVIEW ja ein Paket sind, muss es doch möglich sein, mit Keil den Code irgendwie als DLL zu compilieren. Eine Library (.lib) habe ich schon erstellt, aber konnte sie nicht in LabVIEW integrieren.

Hat jemand eine Idee, wie ich mit Keil eine DLL aus C-Code erstellen kann, die mit LabVIEW kompatibel ist? Ich benutze einen LPC2368 mit MCB2300 Board.

Gruß,
Kalle

' schrieb:Ich möchte gerne Code aus dem Keil-Beispiel "USBCDC" für das MCB2300 Board in LabVIEW benutzen. Den Code mittels einer "Inline C Node" zu integrieren, funktioniert nicht, da LabVIEW durch die große Codemenge sehr langsam wird und dann auch abstürzt. Zudem bekomme ich viele Fehlermeldungen beim Compilieren.
Die "Call Library Funktion Node" zu benutzen, scheint mir auch viel komfortabler zu sei. Da Keil und LabVIEW ja ein Paket sind, muss es doch möglich sein, mit Keil den Code irgendwie als DLL zu compilieren. Eine Library (.lib) habe ich schon erstellt, aber konnte sie nicht in LabVIEW integrieren.

Hat jemand eine Idee, wie ich mit Keil eine DLL aus C-Code erstellen kann, die mit LabVIEW kompatibel ist? Ich benutze einen LPC2368 mit MCB2300 Board.

Gruß,
Kalle

Das mit der Call Library Node geht leider nicht so einfach wie Du Dir scheinbar denkst. Erstens sind DLLs eine reine Windows Angelegenheit, auf anderen Plattformen heisst das Shared Library. Zweitens weiss ich überhaupt nichts über das Format von Shared Libraries unter ARM Systemen im allgemeinen und mit dem Keil System und dem damit verbundenen RT Kern im speziellen. Es ist sehr gut möglich dass dieser Kern keine Shared Libraries unterstützt. Dass LabVIEW mit dem Code in der Inline C Code langsam wird hat wohl weniger mit der Inline C Node selber zu tun als mit dem C Code selber und selbst als Shared Library aufgerufen, wird das nicht prinzipiel schneller oder zuverlässiger funktionieren. Wahrscheinlich macht dieser Code einfach etwas dass weniger dann suboptimal ist, ob grundsätzlich oder im Zusammenhang mit der LabVIEW Umgebung sei dahin gestellt aber durch das in eine Shared Library zu verpacken und so aufzurufen veränderst Du daran im Prinizip nichts.

Rolf Kalbermatter

Also ich habe auch ein relativ großes C-Projekt bei mir drin und das funktioniert eigentlich ohne Probleme mit dem inline C-Node.
Jedoch schreibe ich nur ganz wenig in den Inline-C-Node direkt, den Rest binde ich über Header ein.

Ob DLL Blöcke bei Embedded gehen, weis ich auch nach wie vor nicht sicher. Jedoch werden ja eigentlich die nicht verwendbaren Blöcke ausgeblendet und der DLL Block bleibt da. Was aber gegen den DLL Block an sich spricht, ist das eine DLL eben, wie es rolfk schon sagte, nur was für Windows ist. Und ich habe lange rumgesucht und auch nichts dafür gefunden.

Gruß

amin

' schrieb:Also ich habe auch ein relativ großes C-Projekt bei mir drin und das funktioniert eigentlich ohne Probleme mit dem inline C-Node.
Jedoch schreibe ich nur ganz wenig in den Inline-C-Node direkt, den Rest binde ich über Header ein.

Ob DLL Blöcke bei Embedded gehen, weis ich auch nach wie vor nicht sicher. Jedoch werden ja eigentlich die nicht verwendbaren Blöcke ausgeblendet und der DLL Block bleibt da. Was aber gegen den DLL Block an sich spricht, ist das eine DLL eben, wie es rolfk schon sagte, nur was für Windows ist. Und ich habe lange rumgesucht und auch nichts dafür gefunden.

Gruß

amin

Ich denke dass die Call Library Node nicht grundsätzlich nicht funktioniert in Embedded. Man kann LabVIEW Embedded auch auf eine Embedded Linux Umgebung anpassen (was allerdings sehr viel Arbeit ist) und dort hat man üblicherweise ELF Shared Libraries zur Verfügung. Aber das LabVIEW für ARM Toolkit verwendet keinen Embeddded Linux Kernel sondern die Runtime Umgebung und Libraries die mit dem Keil Entwickelsystem mitkommt und da weiss ich echt nicht ob die sowas wie Shared Libraries überhaupt untertützen, aber das ist ja auch nicht nötig. Dne Glue Code in der C Inline Node und die entsprechenden Libraries als precompiled linked Object Libraries geht ja auch perfekt.

Rolf Kalbermatter