Ich suche eine Programmiersprache plus Programmierumgebung, mit der ich
plattformübergreifend programmieren kann, und zwar:
- für Windows und unter Windows
- für Android unter Windows
- für Raspberry Pi unter Windows und auf dem Pi
- tendenziell unter Linux für Linux, Android und Pi
Es soll eine Compilersprache sein für kleine Programme zur
Meßwerterfassung über RS232 (USB, Bluetooth), Speicherung und grafischen
Darstellung und so Kram. Z.B. ein serielles Terminal.
Es soll definitiv keine Interpretersprache wie Java oder Python sein.
Bisher habe ich Qt und den Qt-Creator gefunden, aber der braucht wohl
einige zusätzliche Pakete wie das VisualStudio mit VisualC++, welches
dann wieder auf MS zurücklenkt.
Außerdem wxWidgets, oder MingW, die wohl mit Qt und auch mit Codeblocks
gehen. Da weiß ich aber nicht, ob die auch für Android nutzbar sind.
Das läuft dann alles auf C++ hinaus.
Alternativ wäre noch Lazarus mit FreePascal, welches anscheinend alle
gewünschten Plattformen unterstützt. Hat damit jemand Erfahrung?
Und es wäre schön, wenn die IDE schlank und nicht so überfrachtet wäre.
Was hälst du denn von Qt mit dem QtCreator - der eigenen IDE? Finde sie
sehr übersichtlich und bedient sich gut. Kann aber alles nötige und ist
für M$, Apfel und unix verfügbar.
Timm T. schrieb:> Bisher habe ich Qt und den Qt-Creator gefunden,
Das ist keine Sprache, sondern eine Klassenbibliothek (und darauf
angepasste Entwicklungsumgebung) für eine Sprache. Nämlich für C++.
> Außerdem wxWidgets, oder MingW
Das eine ist eine Klassenbibliothek, das andere eine
Entwicklungsumgebung.
wxWidgets "geht" nicht mit Qt, sondern ist eine Alternative dazu.
Timm T. schrieb:> Ich suche eine Programmiersprache plus Programmierumgebung, mit der ich> plattformübergreifend programmieren kann,> - für Windows und unter Windows
C#, C, C++, Java, Delphi, (Visual) BASIC (.NET), usw.
> - für Android unter Windows
Java
> - für Raspberry Pi unter Windows und auf dem Pi
C, C++, ein Haufen Scripting Sprachen, Java
> - tendenziell unter Linux für Linux, Android und Pi
Läuft auf dem Pi nicht Linux? Also was soll das? C, C++, Java
> Es soll definitiv keine Interpretersprache wie Java oder Python sein.
Pech gehabt. Z.B. auch wenn es C für Android gibt, Java ist die Sprache
der Wahl auf Android.
> Bisher habe ich Qt
Eine GUI-Bibliothek. Was soll das mit einer Programmiersprache zu tun
haben?
Du wirst wohl aus deiner Komfort-Ecke rauskommen müssen. Das ist so wie
im richtigen Leben:
Wie nennt man jemanden, der drei Sprachen spricht?
Trilingual.
Wie nennt man jemanden, der zwei Sprachen spricht?
Bilingual.
Wie nennt man jemanden, der eine Sprache spricht?
Einen Amerikaner.
Als Amerikaner der Programmiersprachen wirst du nicht weit kommen. Nicht
über dein virtuelles Texas hinaus.
Timm T. schrieb:> Es soll definitiv keine Interpretersprache wie Java oder Python sein.
Java ist keine Interpretersprache. Java ist hier definitiv das Mittel
der Wahl. Aber dennoch wirst du wahrscheinlich kein Programm schreiben
können, das unter Android und auf PC läuft, dazu sind die Plattformen zu
verschieden.
Hannes J. schrieb:> Eine GUI-Bibliothek. Was soll das mit einer Programmiersprache zu tun> haben?
QT ist nicht einfach nur eine GUI-Bibliothek. Es enthaelt eine komplette
Abstraktionslayer, so dass eine Entwicklung fuer alle Plattformen
moeglich ist. Im Prinzip ist QT genau dass, was der TE sucht.
Die Wahl der Programmiersprache ist fuer Multi-Plattform Entwicklung
unerheblich. Die richtige Wahl der Schnittstellen ist wichtig. Die
bietet QT in grosser Vielzahl, vor allem in Verbindung mit QML.
Verfuegbare Plattformen:
https://de.wikipedia.org/wiki/Qt_%28Bibliothek%29#Unterst.C3.BCtzte_Plattformen
Timm T. schrieb:> Es soll definitiv keine Interpretersprache wie Java oder Python sein.
Dann schau dir Cython an: flexibilität von Python, mit C-Elementen.
Oder anders gesagt: Python-Like-Code mit C ähnlicher geschwindigkeit da
statisch compiliert.
1
About Cython
2
3
Cython is an optimising static compiler for both the Python programming
4
language and the extended Cython programming language (based on Pyrex).
5
It makes writing C extensions for Python as easy as Python itself.
6
7
Cython gives you the combined power of Python and C to let you
8
write Python code that calls back and forth from and to C or
9
C++ code natively at any point.
10
11
easily tune readable Python code into plain C performance by
12
adding static type declarations.
13
14
use combined source code level debugging to find bugs in your
15
Python, Cython and C code.
16
17
interact efficiently with large data sets, e.g. using multi-
18
dimensional NumPy arrays.
19
20
quickly build your applications within the large, mature and
21
widely used CPython ecosystem.
22
23
integrate natively with existing code and data from legacy,
24
low-level or high-performance libraries and applications.
Cython Projekt: http://cython.org/
Buch zu Cython:
http://www.amazon.de/Cython-Kurt-W-Smith/dp/1491901551/ref=sr_1_1?ie=UTF8&qid=1458377885&sr=8-1&keywords=CythonTimm T. schrieb:> Es soll definitiv keine Interpretersprache wie Java oder Python sein.
Warum nicht? Angst das Python 'zu langsam' ist?
Das bezweifel ich ganz stark.
Ja, natürlich ist pure Python langsamer als z.B. gut geschriebener
C-Code. Aber das interessiert gar nicht wenn du eh auf Daten einer
Schnittstelle (RS232, Netzwerk, what ever) warten musst.
Wenn man natürlich die Resourcen nicht nutzt, und alles Old-School in
einer riesiegen main-Loop abfeiert, und die anderen drölf Kerne seiner
CPU ungenutzt lässt, ja, dann kann das Tatsächlich zu einem Problem
werden...
Aber in Zeiten, wo es gar kein Problem ist
multi-threading/multi-processing Anwendungne zu schreiben, ist die
Sprache das kleinste Problem. Schlechten Code kann man in jeder Sprache
schreiben, auch in C oder Assembler...
Bei einer Script-Sprache sehe ich sogar den Vorteil das man das ganze
eben nicht bei jeder änderung für X Platformen neu compilieren muss
(Windows (x86), Linux(x86), Linux(ARM), Android,...). Einfach
rüberkopieren und gut.
Und ja, das sehe ich als einen entscheidenen Vorteil. Denn spätestens,
wenn dein Compiler auf einer Platform nicht alle Compiler-Flags
unterstützt wie auf einer anderen Platform, dann ist das ganze schon
scheiße. (Ja, dieses Problem hatte ich mit CLang auf dem RPi. Da
unterstütze der Compiler das sanitize-flag nicht.)
Und mit Python hast du auch Qt. Und Qt ist ein wirklich sehr gutes
Framework.
Ganz viele Möglichkeiten hast du nicht zur Auswahl:
- Java
- C/C++ mit Qt
- Python mit Qt
- Eine Mischung aus C/C++ mit Python/Cython und Qt
Wenn du Java und Python aber vornherin ausschleißt, ist die Sache klar.
Dann nimm Qt und den Qt-Creator als IDE, C/C++ als Sprache und dann hau
in die Tasten.
Rufus Τ. F. schrieb:> Das ist keine Sprache, sondern eine Klassenbibliothek (und darauf> angepasste Entwicklungsumgebung) für eine Sprache. Nämlich für C++.
Deswegen steht da drunter:
Timm T. schrieb:> Das läuft dann alles auf C++ hinaus.Hannes J. schrieb:> Läuft auf dem Pi nicht Linux? Also was soll das? C, C++, Java
Jaja, und auf dem Pi läuft auch Win10.
Trotzdem können nicht alle Umgebungen für Linux (auf x86) auch auf dem
Pi (ARM) genutzt werden.
Kaj schrieb:> Warum nicht? Angst das Python 'zu langsam' ist?> Das bezweifel ich ganz stark.
Nun, zumindest gibt es Leute, denen Fhem welches in Pyhton geschrieben
ist, zu langsam ist. Und dabei ist Fhem "nur" eine Oberfläche, um ein
paar Meßwerte darzustellen, welche auf einem 1GHz Prozessor läuft.
Nicht daß ich jetzt Fhem nachbasteln möchte...
Timm T. schrieb:> Nun, zumindest gibt es Leute, denen Fhem welches in Pyhton geschrieben> ist, zu langsam ist.
Das muss aber nicht zwingend an der Sprache liegen. Man kann in jeder
Sprache schlechten, schnarlangsamen Code schreiben. Ebenso kann man aber
mit Python ebenfalls Code schreiben der mehr als schnell genug ist.
Und Fhem selber ist nicht in Python geschrieben. Fhem ist in Perl
geschrieben: http://fhem.de/fhem_DE.html
1
FHEM (eingetragene Marke) ist ein in perl geschriebener,
2
GPL lizensierter Server für die Heimautomatisierung.
Es mag aber durchaus ein Frontend dazu geben, welches in Python
geschrieben ist. Das sind aber 2 paar Schuhe.
Und gerade bei der Auswertung/Aufbereitung/Darstellung/Sortierung von
Daten kann man viel falsch machen, so das Code wirklich langsam wird, so
wie in jeder Sprache.
Gutes Beispiel dazu:
Beitrag "Re: Python 3: neue Werte in einer Liste finden"
Man muss es nur "richtig" machen.
Timm T. schrieb:> Nun, zumindest gibt es Leute, denen Fhem [...] zu langsam ist.
Ja, mir ist ein frisch installiertes Windows auf einer nagelneuen SSD
mit 8 Kern Prozessor auch zu langsam...
Mein 50Mbit internet ist mir auch zu langsam...
Gibt auch Leute denen ist Tempo 220 auf der Autobahn zu langsam...
Das empfinden von Geschwindigkeit ist subjektiv, eben so von Lautstärke.
In einem Auto empfindest du 25km/h als schnarchlangsam. Fahr aber mal
25km/h auf einem alten Traktor, ohne Kabine und ohne Windschutzscheibe,
da wird dir das ganz schön schnell vorkommen.
Das selbe hast du bei Software. Wenn man natürlich nur einen Desktop
gewöhnt ist, der 4 bis 8 Kerne und 3 bis 4 GHz hat, dann kommt einem der
RPi natürlich ultra langsam vor.
Nimm einen RPi (egal ob welcher) und versuch mal damit im Internet zu
surfen... Das finde ich ebenfalls mega langsam.
Aber am Browser kanns ja nicht liegen, der ist ja in C++ geschrieben...
So, liegt es jetzt an der Verwendeten Sprache, in der der Browser
geschrieben ist? Oder liegt es daran, das der Browser einfach schlecht
programmiert ist? Oder liegt es vielleicht doch an der Hardware?
(Ja, ein Browser ist hier ein schlechtes Beispiel, weil ein Browser
natürlich noch viel viel mehr macht!)
Spontan zu sagen: "Da sind Leute, die sagen das Anwendung X zu langsam
ist, weil es in Sprache Y geschrieben ist", und deswegen eine Sprache
auszuschließen, ohne es mal selbst probiert zu haben, ist, meiner
Meinung nach, einfach dumm.
Denn dann drüfte es keine Anwendungen geben die in C++ geschrieben sind,
weil C++ ja soooooo einen Overhead im vergleich zu C hat. Ebenso dürfte
es keine Programme geben die in C geschrieben sind, weil C ja sooooooo
einen Overhead im gegensatz zu Assembler hat...
Gibt immerhin Leute die das behaupten, auch noch im Jahre 2016, auch
wenn das alles schon tausendfach widerlegt wurde.
Man muss eine Sprache nur richtig anwenden.
Kaj schrieb:> Das muss aber nicht zwingend an der Sprache liegen. Man kann in jeder> Sprache schlechten, schnarlangsamen Code schreiben.
Sicher.
> Ebenso kann man aber> mit Python ebenfalls Code schreiben der mehr als schnell genug ist.
Was ist schon schnell genug? Python als Bytecode, der auf einer VM
ausgeführt wird, ist etwa 10 bis 50 mal langsamer als compilierter
Maschienencode. (Gleichfalls für Ruby.) Cython oder PyPy mögern die
Sache womöglichg etwas verbessern. Oder man versucht die kritischen
Teile in C zu schreiben. Das wahre ist das aber alles nicht.
Python mag für viele Sachen OK sein, wahrscheinlich auch für den Herrn
Thaler. Erst recht, wenn im Wesentlichen nur Bibliotheksroutinen
aufgerufen werden, die ja meist in C geschrieben sind. Aber von Seiten
der Sprachen gibt es jetzt ja genügend (bessere) Alternativen -- bei
cross plattform GUI, Tools, Bibliotheken und Support leider nicht.
Stefan Salewski schrieb:> Python als Bytecode, der auf einer VM> ausgeführt wird, ist etwa 10 bis 50 mal langsamer als compilierter> Maschienencode
1. wird es von einem Interpreter ausgefürt, nicht einer VM, und 2. kann
man so pauschal nicht sagen. Ein guter Interpreter kann genauso schnell
oder sogar schneller als nativer code sein.
Das hat mich mal bei einem meiner Benchmarks von asmjs vs js erstaunt,
damals erhöte ich eine Variable in einer Schleife bis sie wieder bei 0
ankahm. Getestet habe ich das Erhöhen in asmjs direkt (1s), in einer
modulfunktion (5s) und in einer modulfunktion eines anderen Moduls
(6min). Der js code hat die Variable in einer anderen Funktion
hochgezählt, brauchte aber nur 1s. Die uhrsache wird wohl gewesen sein
das der JS Interpreter zur runtime den Funktionsaufruf wegoptimieren
konnte, der compilierte asmjs code aber nicht.
Daniel A. schrieb:> 1. wird es von einem Interpreter ausgefürt, nicht einer VM, und 2. kann> man so pauschal nicht sagen. Ein guter Interpreter kann genauso schnell> oder sogar schneller als nativer code sein.
Na Du weisst es sicher besser als Wikipedia und andere Quellen im Netz:
https://en.wikipedia.org/wiki/Python_(programming_language)
"The main Python implementation, named CPython, is written in C meeting
the C89 standard.[78] It compiles Python programs into intermediate
bytecode,[79] which is executed by the virtual machine."
Und ich kann es so pauschal sagen -- meine Aussage war auf Python (oder
Ruby) bezogen. Insbesondere auf das übliche CPython von Guido. Dazu habe
ich noch keinen Benchmark gesehen, wo der Python Code nicht wenigstens
10 mal langsamer als entsprechender Code in C oder einer ähnlich gut in
Maschienencode compilierten Sprache wäre. Dümmliche Benchmarks, wo
lediglich eine C-Bibliothek von Python aus aufgerufen wird zählen
natürlich nicht.)
Dass Java Code in einigen Benchmarks schneller ist als vergleichbarer C
Code ist mir bekannt -- was mich auch tatsächlich etwas verwundert. Aber
in Java ist in den letzten 20 Jahren eben auch extrem viel Manpower
investiert worden.
Daniel A. schrieb:> 1. wird es von einem Interpreter ausgefürt, nicht einer VM, und 2. kann> man so pauschal nicht sagen. Ein guter Interpreter kann genauso schnell> oder sogar schneller als nativer code sein.
Ein echter Interpreter wird das nur dann sein, wenn der native Code
schlechtere Algorithmen verwendet, oder wenn die Einzelbefehle des
interpretierten Codes komplexe optimierte Operationen sind und der
Interpretationsaufwand darin verschwindet.
Möglicherweise beziehst du dich auch auf just-in-time Compiler mit
ausgeprägter Hotspot-Optimierung, wie sie bei Java existieren. Aber das
sind Compiler, keine Interpreter, nur eben teilweise zur Laufzeit.
@ Stefan Salewski (Gast)
Ups, ich hatte den Context des Satzteils
> Python als Bytecode, der auf einer VM ausgeführt wird
Falsch Interpretiert. Ich dachte es würde aussagen, dass Python immer
als Bytecode auf einer VM ausgeführt wird, was nicht der Fall ist, da
ein Programm das ein Script analysiert & ausführt per Definition ein
Interpreter ist.
https://de.wikipedia.org/wiki/Interpreter:
> Ein Interpreter (im Sinne der Softwaretechnik) ist ein Computerprogramm,> das einen Programm-Quellcode im Gegensatz zu Assemblern> oder Compilern nicht in eine auf dem System direkt ausführbare> Datei übersetzt, sondern den Quellcode einliest, analysiert und ausführt.
Ich hätte bemerken müssen, das "Python als Bytecode, der auf einer VM
ausgeführt wird", eine spezifische Implementationsmöglichkeit eines
Python Interpreters ist, auf welche hier Bezug genommen wurde.
Mein Fehler.
Uninteressant! Python hatte ich schon ausgeschlossen.
Ich möchte nach dem Kompilieren eine ausführbare Datei erhalten, die auf
dem System läuft. Ohne das noch irgendwelche Interpreter oder VMs
dazwischenhängen, egal ob die Textzeilen oder Bytecode ausführen.
Was ist mit Lazarus bzw. Freepascal? Scheint auf allen vier Plattformen
zu gehen.
Die Syntax von Pascal sagt mir jedenfalls mehr zu als die von C(++).
Timm T. schrieb:> - für Windows und unter Windows> - für Android unter Windows> - für Raspberry Pi unter Windows und auf dem Pi> - tendenziell unter Linux für Linux, Android und Pi>> Es soll eine Compilersprache sein für kleine Programme zur> Meßwerterfassung über RS232 (USB, Bluetooth), Speicherung und grafischen> Darstellung und so Kram. Z.B. ein serielles Terminal.
Ich habe seinerzeit EcmSpy - im Prinzip auch nichts anderes als die
Anzeige seriell erfasster Daten - unter Linux mit C# und Gtk# und Mono
entwickelt, das lief unter Windows sowohl mit einer Mono Runtime als
auch .Net, wenn Gtk# nachinstalliert wurde. Als IDE konnte MonoDevelop
(jetzt Xamarin irgendwas) oder unter Windows zusätzlich Visual Studio
benutzt werden. Android fällt dann natürlich als Plattform aus, aber um
Linux und Windows zu versorgen fand ich es damals den einfachsten Weg,
um den Preis, dass es auf beiden Plattformen nicht voll nativ ist.
Timm T. schrieb:> Was ist mit Lazarus bzw. Freepascal? Scheint auf allen vier Plattformen> zu gehen.
Sehr empfehlenswert, wird meistens ignoriert, weil "unsexy".
Wenn du zu den Leuten gehörst, die bereits genug gesehen haben, um zu
wissen, daß "unsexy" eine Stärke ist, dann greif zu!
Timm T. schrieb:> Ich suche eine Programmiersprache plus Programmierumgebung,
..
> Es soll eine Compilersprache sein für kleine Programme zur> Meßwerterfassung über RS232 (USB, Bluetooth), Speicherung und grafischen> Darstellung und so Kram. Z.B. ein serielles Terminal.> Es soll definitiv keine Interpretersprache wie Java oder Python sein.
Damit schiesst Du dir bezüglich:
> plattformübergreifend programmieren kann
selbst ins Bein. Eine Programmiersprache allein taugt nicht mehr als
Assemblercode. Den Komfort/Nutzen macht die runtime-Umgebung und die
Programmbibliotheken resp der Zugang zur API des OS. Das alles bringt
eine VM resp. scriptsprache mit.
Eine gute scriptsprache/VM liefert auch eine vernünftige
Debug-schnittstelle (Single step/variable dump/watchpoint) mit so dass
als Programmierumgebung ein Editor mit syntax highlight komplett
aussreicht.
MfG,
Da kommt eigentlich nur C# in Frage.
Damit kannst du
- für Windows entwickeln (Visual Studio, .NET oder .NET Core).
- für Linux/Pi entwickeln (Mono Develop oder Xamarin Studio, Mono oder
.NET Core).
- für Android entwickeln (Visual Studio oder Xmarain).
- für Mac entwickeln (Mono Develop oder Xamarin Studio, Mono oder .NET
Core).
- ...
Unter Windows, Mac und Linux musst du den Code oft nicht mal neu
kompilieren, da eine solche .exe direkt unter allen Systemen lauffähig
ist.
IDEs (alle kostenlos):
- Visual Studio Community
- Visual Studio Code
- MonoDevelop
- Xamarin Studio
Frameworks:
- .NET (Windows)
- .NET Core (Alle Platformen)
- Mono (Mac, Linux, ...)
- Xamarin (Mobile Platformen: Android, iOS usw.)
Boris P. schrieb:> Da kommt eigentlich nur C# in Frage.
HAHAHA. Das kommt natürlich nicht in Frage. MS behauptet da zwar
manchmal was, aber wie üblich geht da nichts richtig.
Schau dir mal die großen OSS-Projekte an, wie die das machen. Firefox,
Thunderbird, LibreOffice, usw. laufen auf allen Plattformen ohne
Probleme und haben überall den gleichen Code. Ein paar kleine
Eigenheiten müssen über Dateien für die jeweilige Plattform geregelt
werden.
PS:
Timm T. schrieb:> - für Raspberry Pi unter Windows und auf dem Pi
Windows hat auf einem RPi nichts zu suchen...
Nimm Purebasic.
https://de.wikipedia.org/wiki/PureBasichttp://www.purebasic.com/german/index.php
Ich habe es nur unter Windows benutzt, weiß aber von Anderen, daß die
erzeugten Programme auch für Linux übersetzt werden können. Für Windows
kommt eine .exe raus, die nichts weiter benötigt (kein .net und andere
Rattenschwänze)
Es gibt eine kostenlose Probierversion davon.
mfG Paul
Horst schrieb:> HAHAHA. Das kommt natürlich nicht in Frage. MS behauptet da zwar> manchmal was, aber wie üblich geht da nichts richtig.
Ach Horst...
Ich habe hier einige Tools, die ich sowohl auf Windows als auch auf dem
Mac laufen lasse. Auch diverse Server habe ich unter Windows/Mac
erstellt, und lasse sie momentan auf einem Raspberry Pi laufen. Und
meine erste Android App in Xamarin habe ich auch die Tage geschrieben.
Mein Fazit:
Das funktioniert alles ganz wunderbar.
Also, wenn man keine Ahnung hat einfach mal den Mund halten...
(oder hast du gegenteilige Erfahrungen gemacht? Wie genau sehen die
aus?)
Marc schrieb:> Sehr empfehlenswert, wird meistens ignoriert, weil "unsexy".
Hab mal ein bißchem damit rumprobiert und finde es schonmal angenehmer
als C. Hast Du Erfahrungen, wie gut das für Raspberry Pi und Android
funktioniert?
Horst schrieb:>> - für Raspberry Pi unter Windows und auf dem Pi> Windows hat auf einem RPi nichts zu suchen...
Ich meinte damit auch "unter Windows das Programm für den Pi schreiben
und auf dem Pi verfeinern und kompilieren".
Paul B. schrieb:> Nimm Purebasic.
Ich arbeite seit einigen Jahren mit PB, es ist wunderbar um schnell zu
einem Ergebnis zu kommen. Mein größtest Projekt - gerade mal geschaut -
waren 12000 Zeilen PB-Code*.
Leider kann PB zwar für Linux auf PC-Architektur, aber nicht für Linux
auf ARM kompilieren. Damit fällt es für den Raspberry Pi leider aus, und
leider wird das nach Freds Aussage auch noch eine Weile so bleiben. Ich
bedauere das sehr, sonst wäre das meine erste Wahl gewesen.
*) Und nein, es gibt in den 12000 Zeile keine einzige Goto-Anweisung.
cppler schrieb:> Und nun stellt Euch mal vor was bei der Suche nach QT gefunden wird:
Gefunden habe ich auch viel. Ich würde nur gern ein bißchen Feedback
haben, was davon brauchbar ist.
Ich würde mich ja auch durchaus auf die C/C++ Schiene einlassen, wenn es
sinnvoll ist. Obwohl meine Ausflüge in C auf dem AVR meine Vorurteile
bezüglich dieser Sprache eher bestätigt haben. Ich würde nur ungern viel
Zeit in eine Richtung investieren, um dann in ein paar Monaten
festzustellen, daß ich nicht weiterkomme: Hätteste mal lieber das Andere
genommen.
Besonders geht es mir hier um Schnittstellen zu Datenerfassung, z.B.
eine RS232 über Bluetooth oder USB-Seriell-Wandler am Tablet. Das ist
immer noch was anders als ein Hello World zum Laufen zu bringen, das hab
ich auch schon mit Scratch geschafft.
Timm T. schrieb:> cppler schrieb:>> Und nun stellt Euch mal vor was bei der Suche nach QT gefunden wird:>> Gefunden habe ich auch viel. Ich würde nur gern ein bißchen Feedback> haben, was davon brauchbar ist.>
Dazu müßtest Du erstmal passendes "Waswillicheigentlichwirklich"
angeben.
> Ich würde mich ja auch durchaus auf die C/C++ Schiene einlassen, wenn es> sinnvoll ist. Obwohl meine Ausflüge in C auf dem AVR meine Vorurteile> bezüglich dieser Sprache eher bestätigt haben. Ich würde nur ungern viel> Zeit in eine Richtung investieren, um dann in ein paar Monaten> festzustellen, daß ich nicht weiterkomme: Hätteste mal lieber das Andere> genommen.
Also C/C++ bei µC bringt keine Nachteile, außer man will auf'm Tiny10
alle Bits ausnutzen und kann Assembler oder besser gleich Opcode aus dem
FF.
Was machst Du dann mit Deinem optimiertem Code wenn ein anderer
Controller notwendig wird ?
Sobald Du es in einer Hochsprache implementiert hast braucht es idR nur
eine Anpassung an die neue Hardware (I/O, Timer usw.) da kommt man aber
niemals drum herum.
Dafür bleibt aber der Programmablauf identisch und man muß sich nicht
darum kümmern ob nun jmp o.ä. vorher einen push o.ä. braucht, denn das
übernimmt der Compiler.
>> Besonders geht es mir hier um Schnittstellen zu Datenerfassung, z.B.> eine RS232 über Bluetooth oder USB-Seriell-Wandler am Tablet. Das ist> immer noch was anders als ein Hello World zum Laufen zu bringen, das hab> ich auch schon mit Scratch geschafft.
QT ist eine sehr mächtige Klassenbibliothek ursprünglich plattform
übergreifend für grafische Ausgaben und Standardeingaben (Tastatur, Maus
usw.).
Für Deine spezifische Hardware mußt Du selber Hand anlegen, das kannst
Du aber einfach tun indem Du von bestehenden Klassen erbst und dort dann
die Funktionen in Deiner Klasse an Deine Anforderungen anpaßt.
Wenn Du über USB, Bluetooth o.ä. kommunizieren willst schaue nach ob und
wo das implementiert ist und wenn Du einen passenden Treiber brauchst
mußt Du entweder eine weit verbreitete Hardware nehmen oder selber
hardwarenah programmieren.
Die Kunst besteht darin Deine Anpassungen so zu implementieren das sie
transparent im Code sind und das Interface sich nicht ändert.
Sehr mächtig ist z.B. Operatoren Überladung, da kannst Du dann einfach
1
<<
und
1
>>
für Dein I/O nehmen und Deine Klasse kümmert sich darum ob das stdIO
ist oder Bluetooth oder Seriell oder CAN oder was auch immer benötigt
wird.
QT für Oberfläche, C++11 für Programmablauf und eigene angepaßte Klassen
für spezifische Hardware würde ich persönlich empfehlen.
Eierlegendewollmilchsäue die tun was man will ohne selber Hirnschmalz
einzusetzen geht nicht, auch wenn das die Rapid-Vertriebler behaupten.
Erstelle erstmal eine Klasse die für Dein I/O in C++ transparent ist,
dann erbst Du davon und paßt sie an die aktuelle Hardware an.
