Jump to content

[C/C++] Compile from Source - winapifamily.h error


Recommended Posts

Hallo zusammen,

 

als Neueinsteiger in die Welt des RedBricks und all seinem Zubehör, bin ich nun am Punkt des Programm-Uploads angekommen.

Habe in C++ eines der bereitgestellten Entwürfe für mich angepasst und wollte dies nun einmal auf dem RedBrick einspielen, um die Funktion standalone zu testen.

 

Es handelt sich um die Ansteuerung eines Servos über den ServoBrick. Aus Visual Studio 2013 Professional heraus funktioniert der Ablauf wie gewünscht.

 

Mit der Erstellung eines Makefiles habe ich mich ebenfalls beschäftigt und den bereitgestellten Makefile ebenfalls modifiziert. Auch habe ich soweit alle header-Dateien die benötigt werden zusammen getragen. Jedoch ist beim "Compile from Source" immer wieder ein und der selbe Error festzustellen:

 

In file included from example_configuration_modified.cpp:6:0: windows.h:1:26: fatal error: winapifamily.h: No such file or directory

 

Die winapifamily.h ist defintiv im passenden Ordner eingebracht, wird aber nicht erkannt. Was läuft hier schief? Was kann ich tun, um das Problem zu beheben? Oder habe ich generell etwas vergessen zu beachten?

 

Danke für eure Hilfe im Voraus auf meine anfänglichen Startschwierigkeiten!

 

 

Link zu diesem Kommentar
Share on other sites

Aufpassen. Du hast dein Programm unter Windows geschrieben unmd getestet.

Auf dem RED läuft aber Linux.

Da existieren nicht alle Klassen in C++.

Du müsstest schon der Quelltext posten damit man es sieht.

Kleiner Tip. Ich schreibe mein Programm unter QT. Das ist eine Crossplattform.

Damit kannst du sowohl unter Windows als auch Linux schreiben. Kostet auch nix. ;)

Link zu diesem Kommentar
Share on other sites

Guten Abend FlyingDoc,

 

danke für deine Antwort! Ich werde mich damit einmal befassen!

 

Daher gehe ich also bisher FALSCH der Annahme, wenn ich eine C++ beschreibe und dieses beim Import im RED kompilieren lasse, wird mein C++ Projekt nicht in die Sprache für den ARM Chip umgesetzt? Wenn nicht, warum? Bereits aus meinem "Windows" Visual Studio kann ich doch über die Schittstelle über mein per Windows kompilierten Code bspw. den Servo, diesen ansteuern?

 

Code wird morgen nachgeliefert!

Link zu diesem Kommentar
Share on other sites

Weil es halt winapifamily.h nicht auf Linux gibt.

Und warum sollen die Leute bei TF auch noch einen Konverter bauen, welche Funktionen aus der WinAPI zur STL konvertiert, zu mal da nicht mal sichergestellt ist, das es ein Äquivalent dazu gibt.

 

Was greift denn in deinem Programm auf die winapifamily.h zu? Eventuell gibt es ja etwas ähnliches aus der STL.

 

Und das dein Code unter Windows funktioniert ist klar, unter Linux halt nicht.

 

 

Link zu diesem Kommentar
Share on other sites

Vielleicht kurz zu dem hier:

Daher gehe ich also bisher FALSCH der Annahme, wenn ich eine C++ beschreibe und dieses beim Import im RED kompilieren lasse, wird mein C++ Projekt nicht in die Sprache für den ARM Chip umgesetzt?

Deine Annahme ist schon korrekt: nach dem Compile-Vorgang liegt ARM-Code vor.

Aber um erfolgreich zu compilieren, muss das Projekt die Besonderheiten der (ggf. verschiedenen) Zielumgebungen beachten.

 

Die TF-API ist erstmal frei von Windows- / Linux-Spezifika; intern sind zwar Unterschiede, die API ist aber frei davon.

 

Wenn Du nun ein Programm in C++ schreibst, musst Du einfach aufpassen, welche sonstigen API's Du verwendest, die nicht Standard C++ sind. Alles was Windows spezifisch ist, wird auf dem RED nicht funktionieren (auch auf MAC auch nicht ..).

Link zu diesem Kommentar
Share on other sites

Guten Mogen,

 

danke für eure Antworten! Es hat nun bei mir geklingelt.

Mein Problem ist aktuell folgendes. Ich binde die windows.h ein, die auf die winapifamily.h zugreifen will. Mit der Windows.h stelle ich aktuell noch die Sleep()-Funktion dar, die mir eine "geordneten" Programmablauf ermöglicht. Gibt es "Linux"-Alternativen für Sleep()? Hab mich ein wenig umgeschaut, aber nicht wirklich etwas mit Hand und Fuß entdecken können.

Link zu diesem Kommentar
Share on other sites

Ich bevorzuge sowas in der Art

 

#include <chrono>
#include <thread>

std::this_thread::sleep_for(std::chrono::milliseconds(x));

Das sollte unter Windows und Linux gehen, wenn die Compiler nicht zu alt sind. Ansonsten gibt es unter Linux "sleep" (nur ganze Sekunden warten) und "usleep".

 

Mit man 3 sleep bzw. man 3 usleep bekommst Du unter Linux die Hilfe zu der API (sofern im Image installiert).

Link zu diesem Kommentar
Share on other sites

  • 3 weeks later...

Eine Andere Sache die dir aber vermutlich Probleme bereiten wird ist der fehlende Buffer. Soweit ich weiß kann man nicht mehrere Befehle Vorweg senden. Als ich meinen 3D Drucker geplant habe, hatte ich auch darüber nachgedacht was mit TF zu machen, da dann aber genau aus dem Grund aufgegeben. Gerade wenn du sehr präzise und feine Strukturen fahren willst, müssen die X und Y absolut synchron arbeiten. Bei TF musst du aber jeden Stepper nacheinander ansprechen. Dazwischen kann es schonmal zu Verzögerungen kommen, die z.B. dafür sorgen würden, dass die Y Achse etwas weiter ist als die X Achse. Deshalb werden einem 3D Drucker immer mehrere Positionswerte in den Buffer geschrieben, sodass der Drucker bereits mit den nächsten Werten arbeiten kann.

 

Link zu diesem Kommentar
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Gast
Reply to this topic...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Clear editor

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...