Hallo ich programmiere zur Zeit einen Roboter auf STM32 Basis, ARM, GCC. Dieser soll sich in einem Raum auf eine bestimmte Art bewegen. Das Austüfteln dieser Algorithmen will ich aber nicht auf dem uC entwickeln. Also dachte ich: Ich schreib diese Programmteile in reinem C auf einem PC und simuliere die Roboterbewegung. Also ein PC Programm mit einer sehr einfachen GUI das mir den Raum von oben zeigt und die Position des Roboters. Schnittstelle sollte etwa so sein: Drehe x Grad, Fahre 500 Steps mit Geschwindigkeit x. Die Simulation auf dem PC sollte das dann ausführen. Nun komme ich aber aus der Linux / Java Ecke und kenne die C IDEs nicht. Anforderungen wären: - C Programm sollte später einfach auf ARM portierbar sein. Deshalb C und kein C++/C# - Einfache GUI bzw. "Canvas" zum zeichnen - Entwicklungsrechner ist ein älterer, eher langsamer XP Laptop. Habt Ihr einen Tipp, was man da nehmen kann?
QT, QT Creator als IDE: https://qt-project.org/ Visual Studio Express: http://www.microsoft.com/de-de/download/details.aspx?id=40787 Code::Blocks mit MinGW und wxWidgets: http://www.codeblocks.org/ Eclipse CDT + MinGW und QT/wxWidgets: https://www.eclipse.org für die letzten beiden muss man MinGW per Hand einrichten: http://www.mingw.org/ MinGW 64Bit+32Bit: http://tdm-gcc.tdragon.net/
:
Bearbeitet durch User
Hallo Maik, super. Vielen Dank!! Werd mir alle Vorschläge mal anschauen. Jens.
Wenn du aus der Linux-Ecke kommst und dich da besser auskennst, warum machst du das dann nicht unter Linux?
Jens schrieb: > Hab in nächster Zeit nur diesen Rechner. Schon mal was von virtuellen Maschinen gehört? z.B. den VMWare Player, der geht sehr gut unter Windows und ist kostenlos.
radiostar schrieb: > Schon mal was von virtuellen Maschinen gehört? z.B. den VMWare Player, Ob Jens schrieb: > ein älterer, eher langsamer XP Laptop dafür geeignet ist, ist allerdings fraglich.
Rolf Magnus schrieb: > Ob > > Jens schrieb: >> ein älterer, eher langsamer XP Laptop > dafür geeignet ist, ist allerdings fraglich. Kein Problem. Nur mind. 2 GB Speicher sollte man haben und das Linux sollte nicht gerade in der Maximalkonfiguration laufen.
Hallo, bin vielleicht etwas spät dran, will aber unbedingt Pelles C (http://www.smorgasbordet.com/pellesc/) empfohlen haben. Vorteile: - unterstützt C99 und C11 - unterstützt Microsoft Erweiterungen (d.h. falls du Bibliotheken brauchst, kannst du .LIBs nutzen, also Bibliotheken die mit MSVC++ statt mit gcc kompiliert wurden) - eingebauter Resourceneditor - gibts nativ in 32 oder 64 Bit (das letzte mal als ich einen 64 Bit gcc und 64 Bit Qt brauchte, sah es schlecht aus; ist allerdings auch schon etwas her)
Mit c# die grafischen Umsetzung programmieren und mit PInvoke auf eine c-Dll zugreifen. Dann ist man auch dieses gruselige Linux los.
Jens schrieb: > - C Programm sollte später einfach auf ARM portierbar sein. Deshalb C > und kein C++/C# C++ und C# sind zwei völlig verschiedene Dinge, daher ist "C++/C#" ziemlicher Unsinn. C++ ist standardisiert, und wenn du standard-konformen Code schreibst ist dieser perfekt portabel. Mehr als Java oder C#, und mindestens so wie C. In C++ ist es allerdings komfortabler: In C portabel einen 32bit-Integer ausgeben:
1 | int32_t x = 42; |
2 | printf ("Die Zahl ist " PRId32 ".", x); |
In C++:
1 | int32_t x = 42; |
2 | std::cout << "Die zahl ist " << x << "."; |
Wenn man nachträglich den Typ auf zB uint16_t ändert, muss man in C jegliche Ausgabe auf PRId16 ändern. In C++ muss man gar nichts ändern.
Gustav schrieb: > Erzähl mal! Java ist nur für 32bit-Plattformen konzipiert, denn dessen "int" Datentyp muss immer 32bit groß sein. Auf einer 36bit oder 25bit Plattform müssen diese erst kompliziert (und langsam) emuliert werden. In C++ ist dann ein "int" halt 25bit groß, portabler Code sollte sich nicht daran stören. Außerdem sind in Java Array-Indices immer "int", d.h. 32bit - daher kann Java nur 4GB-Arrays anlegen, auch wenn die Plattform mehr könnte (wie zB x86_64). In C++ kein Problem, denn dort verwendet man size_t für Array-Größen & Indices, was je nach Plattform zB 32 oder 64bit groß ist. C++ Code passt sich also der Plattform an um dort direkt effizient zu laufen, während Java Anforderungen stellt die bei weitem nicht immer effizient erfüllbar sind, weswegen es auch gar keine JVM's auf solchen Plattformen gibt.
Dr. Sommer schrieb: > Auf einer 36bit oder 25bit Plattform Viel Spaß noch mit deiner PDP10 oder Honeywell 6000!
Gustav schrieb: > Viel Spaß noch mit deiner PDP10 oder Honeywell 6000! Oder diverse moderne DSP's. Bei denen gibt's zB gar keinen 8-Bit-Datentypen - sehr schlecht für Java und sein Zwangs-8bit-"char". C(++) hat kein Problem mit 36bit oder 32bit- "char"...
Java hat auch kein Problem damit, weil die JVM auch auf deinen exotischen Gedankenspiel-Rechnern korrekte Datentypen bereitstellen kann.
Dr. Sommer schrieb: > Java und sein Zwangs-8bit-"char". Ist doch gut, dann läuft der Code so wie man es erwartet (und ist nicht abhängig von der Platform).
Gustav schrieb: > Java hat auch kein Problem damit, weil die JVM auch auf deinen > exotischen Gedankenspiel-Rechnern korrekte Datentypen bereitstellen > kann. 1. sind die keineswegs Gedankenspiele und 2. geht das nur sehr suboptimal und ineffizient. Theoretisch lässt sich jede Sprache auf jeder Plattform nutzen solange sie turing-vollständig ist (weswegen die Portabilitäts-Diskussion theoretisch hinfällig ist); praktisch bereitet aber die aus Java's Inflexibilität resultierende Ineffizienz derartige Probleme dass das nicht sinnvoll machbar ist. Und wie du vielleicht weißt ist x86_64 (AMD64) keine besonders exotische Architektur, und dennoch kann Java dessen kompletten Speicher nicht ausnutzen aufgrund der 32bit-Array-Größe & Indices. Die Logik ist ganz einfach: Die Menge an Plattformen auf denen Java sinnvoll läuft ist eine echte Teilmenge der Plattformen auf denen C(++) sinnvoll läuft, ergo ist C(++) portabler als Java. Da kannst du auch nichts durch Herunterspielen von dir nicht passenden Plattformen dran ändern.
Boris P. schrieb: > Dr. Sommer schrieb: >> Java und sein Zwangs-8bit-"char". > > Ist doch gut, dann läuft der Code so wie man es erwartet (und ist nicht > abhängig von der Platform). Korrekter C(++) Code ist nicht abhängig von der Plattform, denn dieser erwartet nicht dass ein char 8bit groß ist, denn das ist in den C und C++ Standards nirgends garantiert!
Dr. Sommer schrieb: > Und wie du vielleicht weißt ist x86_64 (AMD64) keine besonders exotische > Architektur, und dennoch kann Java dessen kompletten Speicher nicht > ausnutzen aufgrund der 32bit-Array-Größe & Indices. Warum sollte man ein Array definieren wollen, dass den ganzen Speicher des Systems ausnutzt? Wenn du tatsächlich Daten in der Größenordnung ablegen willst, wirst du auch eine sinnvolle Datenstruktur brauchen. Und ja, das geht mit java problemlos. Und damit kann man ohne weiteres hunderte von GB an Speicher vollklatschen, wenn man das möchte...
Boris P. schrieb: > Warum sollte man ein Array definieren wollen, dass den ganzen Speicher > des Systems ausnutzt? Weil niemand mehr als 640KB RAM braucht? Java ist einfach nicht aufwärts/Zukunfts-Kompatibel, wenn es quasi überall 32bit-Integer vorschreibt. Selbst im viel älteren C hat man begriffen, dass man für Array Größen & Indices einen flexiblen Datentyp braucht (size_t). Im Java's altem Datei-API wurden 32bit-Integer sogar für Dateioffsets verwendet, d.h. man konnte nur maximal 2 GB große Dateien anlegen. Aber wer hat schon Festplatten in der Größe, gell. Zum Glück haben sie dafür jetzt ein neues API. Arrays sind aber Bestandteil der Sprache und daher nicht so leicht zu ändern. Wenn die üblichen RAM-Größen & Bedarf ähnlich weiterwachsen wie Festplatten, werden die 32bit auch irgendwann zu Problemen führen...
Dr. Sommer schrieb: > Weil niemand mehr als 640KB RAM braucht? Du vielleicht nicht. Ich stoße mit meinen 16GB schon manchmal an Grenzen... ;-) Dr. Sommer schrieb: > Weil niemand mehr als 640KB RAM braucht? Java ist einfach nicht > aufwärts/Zukunfts-Kompatibel, wenn es quasi überall 32bit-Integer > vorschreibt. Java gibts doch auch als 64bit Version. Damit kommt man speichertechnisch recht weit.
:
Bearbeitet durch User
Boris P. schrieb: > Java gibts doch auch als 64bit Version. Damit kommt man > speichertechnisch recht weit ;-) Aber da ist "int" immernoch 32bit groß. Das ist ein prinzipielles Problem der Sprache, das man nicht durch bessere JVM's lösen kann, sondern nur durch Re-Design der Sprache selbst.
Dr. Sommer schrieb: > Aber da ist "int" immernoch 32bit groß. Das ist auch gut so. Und es hat nichts damit zu tun, wie viel Speicher du mit einerJava Anwendung nutzen kannst.
Boris P. schrieb: > Das ist auch gut so. Und es hat nichts damit zu tun, wie viel Speicher > du mit einerJava Anwendung nutzen kannst. Aber wie groß ein Array sein kann. Versuche mal ein Array mit mehr als 2^31 Einträgen anzulegen.
Dr. Sommer schrieb: > Aber wie groß ein Array sein kann. Versuche mal ein Array mit mehr als > 2^31 Einträgen anzulegen. So what? Einen praktischen Nutzen hat sowas nicht => Braucht kein Mensch :-) Du willst ja nicht Daten zum Selbstzweck speichern. Du willst sie durchsuchen, ändern, hinzufügen und entfernen können. Und dazu taugt ein Array mit 4294967297 Einträgen nun wahrlich nicht. Da wäre dann eine Baumstruktur o.Ä. angemessen.
Boris P. schrieb: > Da wäre dann eine > Baumstruktur o.Ä. angemessen. Die könnte man da hineinspeichern (Heap-Struktur). Wäre effizienter als 1000000x "new" aufzurufen und Referenzen zu verwenden. Boris P. schrieb: > So what? Einen praktischen Nutzen hat sowas nicht => Braucht kein Mensch > :-) Genau wie die 640 KB RAM - braucht auch keiner - noch nicht. Es ist wie gesagt ein prinzipielles Problem, was u.a. darin begründet ist dass Java keine Typ-Aliase hat. Aber all das ändert immer noch nicht die Tatsache, dass C(++) portabler als Java ist.
Ob euer Gefeilsche um ein wenig mehr Performance dem TE wirklich weiterhilft? Der wollte doch ausdrücklich C und KEIN C++ und wohl auch kein Java, obwohl er das bereits kennt? Gibt es überhaupt eine Möglichkeit die QT Widgets zu verwenden bei REINEM C Code? Meiner Kenntnis nach nicht.
C C++ oder was schrieb: > Der wollte doch ausdrücklich C und KEIN C++ und wohl auch > kein Java, obwohl er das bereits kennt? Der Punkt ist, dass er bezüglich der Begründung für "kein C++" scheinbar einem Mythos aufgesessen ist.
C C++ oder was schrieb: > Gibt es überhaupt eine Möglichkeit die QT Widgets zu verwenden bei > REINEM C Code? Nö, es sei denn, man bastelt sich eine DLL, die den QT-Krempel kapselt und ein C-Aufrufinterface bietet. Aber das entfernt sich immer weiter von dem, was der Threadstarter wohl will. Der aber hat sich seit mehreren Tagen hier nicht mehr blicken lassen.
Dr. Sommer (Gast) schrieb: > Der Punkt ist, dass er bezüglich der Begründung für "kein C++" scheinbar > einem Mythos aufgesessen ist. Weiß ich nicht. Ich denke viele wie der TE tun sich eher schwer mit der Syntax von C++ zurechtzukommen.
1 | class MyWidget : public QVBox |
2 | {
|
3 | public:
|
4 | MyWidget( QWidget *parent=0, const char *name=0 ); |
5 | };
|
6 | |
7 | MyWidget::MyWidget( QWidget *parent, const char *name ) |
8 | : QVBox( parent, name ) |
9 | {
|
Ist halt doch was anderes als C.
Rufus Τ. Firefly (rufus) (Moderator) schrieb: C C++ oder was schrieb: >> Gibt es überhaupt eine Möglichkeit die QT Widgets zu verwenden bei >> REINEM C Code? > Nö, es sei denn, man bastelt sich eine DLL, die den QT-Krempel kapselt > und ein C-Aufrufinterface bietet. Danke! Konnte auch bisher nichts brauchbares im Netz finden. Es wird dem Geneigten wenn es um QT geht einfach zu oft C++ als "C" untergeschoben. > Aber das entfernt sich immer weiter von dem, was der Threadstarter wohl > will. > Der aber hat sich seit mehreren Tagen hier nicht mehr blicken lassen. Tippe mal auf typische Reaktion "verschreckt". ;) Ist doch eigentlich ein spannendes Thema.
Nein, dem Thredstarter geht es nicht um die Syntax, sondern er nimmt an, daß es Probleme mit der Portierung von C++ - Code auf einen ARM geben wird. Hier wird ja noch oberflächlicher gelesen, als ich das an schlechten Tagen hinbekomme ...
Rufus Τ. Firefly (rufus) (Moderator) schrieb: > Nein, dem Thredstarter geht es nicht um die Syntax, sondern er nimmt an, > daß es Probleme mit der Portierung von C++ - Code auf einen ARM geben > wird. > Hier wird ja noch oberflächlicher gelesen, als ich das an schlechten > Tagen hinbekomme ... Verstehe ich nicht. Ich habe es so verstanden, dass er auf dem PC die GUI zur Simulation benötigt. Was also hat dieser Teil des Codes mit dem Programmcode eines Mikrocontrollers ARM in Sachen "Portierung" zu tun? Das sind doch zwei Paar Schuhe. ARM: C-Code PC: C++ GUI (will er nicht) ARM: C-Code PC: (auch nur Code in) C GUI (will er) SO habe ich das verstanden.
C C++ oder was schrieb: > SO habe ich das verstanden. Aha: > Anforderungen wären: > - C Programm sollte später einfach auf ARM portierbar sein. > Deshalb C und kein C++/C#
>Code::Blocks mit MinGW und wxWidgets: >http://www.codeblocks.org/ für das hab ich mich entschieden und ist genau das richtige. ARM: Algrothmis zum Bewegen in C, Bewegung selbst: PID Regler in C, Endstufe, Motoren. PC: Algorithmus zum Bewegen in C, Simulation und Darstellung der Bewegung in C/C++
Als ich so um '98 Simulationen mit grafischer Ausgabe unter Windows in C geschrieben habe, war das glaub ich direkt mit den Funktionen der gdi und user DLLs (damals noch 16 Bit Code). Zum Zusammenklicken der Dialoge hatte MSVC++ einen Ressourcen Editor. Die MFC habe ich definitiv nicht verwendet. Heutzutage würde ich zu Mingw greifen und mir irgendwo anders einen grafischen Ressourcen Editor beschaffen, wenn Dialoge überhaupt benötigt werden.
Falls du es nicht schon getan hast, kannst du darüber nachdenken, die Roboter- und die Simulationssoftware in getrennten Programmen laufen lassen, die untereinander über Sockets kommunizieren. Damit bist du zum einen in der Wahl der Programmiersprache für die Simulation und das GUI völlig frei. Zum anderen ist es ohne allzu viele Änderungen möglich, eine ähnliche Kommunikationsschnittstelle (über TCP-Sockets oder UART) zwischen PC und realem Roboter (ARM) einzurichten, und es ergeben sich mehrere mögliche Testkonfigurationen für die Robotersoftware: - Roboteralgorithmen auf PC <---> Simulation/GUI auf PC - Roboteralgorithmen auf PC <---> realer Roboter mit ARM - Roboteralgorithmen auf ARM <---> Simulation/GUI auf PC - Roboteralgorithmen auf ARM <---> realer Roboter mit ARM Zudem können, falls die Rechenleistung eines einzelnen PCs oder ARMs nicht ausreichen sollte, die Roboteralgorithmen und die Simulation bzw. die Low-Level-Robotersteuerung problemlos auf verschiedenen Rechnern laufen: - Roboteralgorithmen auf PC1 <---> Simulation/GUI auf PC2 - Roboteralgorithmen auf ARM1 <---> realer Roboter mit ARM2 Je nachdem, was getestet werden soll, hat jede dieser Konfigurationen ihre Vor- und Nachteile. Glücklich ist der, der aussuchen kann :)
:
Bearbeitet durch Moderator
Das ganze Theater mit sockets und DLLs ist nicht nötig - man kann Objectfiles von einem C Compiler mit Objectfiles von einem C++ Compiler zusammenlinken. Der C++ Compiler braucht noch ein extern "C" in der Schnittstellendeklaration. Geht besser, als Objectfiles von 2 verschiedenen C++ Compilern :-) Damit kann man dann die GUI in C++ machen, und das zu testende Programm in C. Alternativ, auch die GUI in C: - Irgendein C-Compiler - hat nichts mit der GUI zu tun (wenn die GUI-Bibliothek keine besonderen Anforderungen stellt). - Eine GUI-Bibliothek aussuchen. Mir fallen z.B. ein: - IUP (sehr einfach, Plattformunabhängig) - Win32 (etwas komplizierter...) - gtk (Tut auch auf Windows, obwohl es von Unix kommt)
Rufus Τ. Firefly (rufus) (Moderator) schrieb: C C++ oder was schrieb: >> SO habe ich das verstanden. > Aha: >> Anforderungen wären: >> - C Programm sollte später einfach auf ARM portierbar sein. >> Deshalb C und kein C++/C# Nix "Aha". Er hat es ja jetzt nochmals präzisiert ARM: C-Code PC: C++ GUI in WxWidgets ; Algorithmen in C Ob WxWidgets gegenüber Qt Vorteile hat wäre dann nochmals eine andere Frage. Aber das muss er selber wissen. Gibt außerdem auch noch andere GUI Toolkits.
Angehängte Dateien:
-
python.gif
15 KB
Forderung
> - Einfache GUI bzw. "Canvas" zum zeichnen
Siehe Anhang!
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.