Hallo, ich hab gerade ein paar Probleme eine vernünftige Vorgehensweise zu finden mit dem ich einen RaspberryPi für Grafikanwendung aufzusetzen. Ich möchte keine Oberfläche wie StartX verwenden. Also quasi keine "Windows-Oberfläche" sondern Grafik in der CMD-Line analog zur DOS-Zeit. Bisher habe ich ein paar Experimente mit Python gemacht, welche aber nicht wirklich zufriedenstellen war (unter anderem die Laufzeit). Zum Testen habe ich mehrere Raspis verwenden, vom Modell 2 bis zum RPiZeroW zum Modell 3 B+. Für die Grafik bei Python verwende ich TKinter und Pygames. Die Programmierung mach ich vom PC aus mit Notepad++ Jedoch habe ich mir mal die Beispiele auf dem Raspi angesehen im Verzeichniss /opt/vc/src/hellopi Die Vorgehensweise für Grafik finde ich am besten. Jedoch ist es extrem mühselig zu coden, die Datei auf den Raspi zu kopieren, zu kompillieren und dann zu starten. Gibt es eine einfachere Möglichkeit bereits am PC die Sourcen zu kompillieren und dann die .bin auf den Raspi zu kopieren? Ich verwende Windows 7. Grüße Alex
Mit Lazarus / Freepascal geht das. Das ist dann aber eine richtige Programmiersprache und kein Python.
Karl schrieb: > Mit Lazarus / Freepascal geht das. Das ist dann aber eine richtige > Programmiersprache und kein Python. Danke! Ist zwar kein C, aber Pascal habe ich auch mal gelernt. Mal sehen ob ich damit noch klar komme. Aber dennoch würde ich gerne C/C++ oder Basic bevorzugen, falls jemand eine Idee hat :)
Habe gute Erfahrung mit FLTK gemacht. https://de.wikipedia.org/wiki/Fast_Light_Toolkit Funktioniert sogar mit so exotischen Betriebssystemen wie MS-Windows ;-) Nimmt auf dem RasPi wenig Platz weg und kann vor Ort compiliert werden. Edit:Typo
Hallo alex. Alex W. schrieb: > Für die Grafik bei Python verwende ich TKinter und > Pygames. Die Programmierung mach ich vom PC aus mit Notepad++ Dann bist du doch schon dicht ran. Python mit tkinter läuft als Skript sowohl unter Windows als auch auf dem Raspberry. Ok, bei Pygames weiss ich nicht, denke aber, dass das auch geht. Ok, wenn Du auf etwas sehr Betriebssystem spezifisches zugreifst (wie find oder grep), dann geht das nicht, aber Dateiauswahlfenster, Datei öffnen/lesen/schreiben/schliessen, Uhr und Schnittstellen klappt meistens. > Jedoch ist es extrem > mühselig zu coden, die Datei auf den Raspi zu kopieren, zu kompillieren > und dann zu starten. > Warum codest du nicht auf dem Raspberry? Im Zweifel per Remote Desktop? Wieso willst du unbedingt kompilieren? Python ist als Skriptsprache konzipiert. Und für das meiste schnell genug. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Alex W. schrieb: > Jedoch ist es extrem > mühselig zu coden, die Datei auf den Raspi zu kopieren, zu kompillieren > und dann zu starten. Wenn Du Visual Studio als IDE benutzt, nimmt es Dir diese Arbeit ab. Die Sourcen werden lokal bearbeitet, beim Build auf das Target kopiert und dort übersetzt, und bei Run/Debug dort auch gestartet. Mit Visual Studio Code sollte das auch gehen. Eclipse basierte Sachen gibt es wohl ebenfalls. Alex W. schrieb: > Gibt es eine einfachere Möglichkeit bereits am PC die Sourcen zu > kompillieren und dann die .bin auf den Raspi zu kopieren? Ich verwende > Windows 7. Das geht prinzipiell auch. Du brauchst u.a. einen passenden Crosscompiler. Den kannst Du schlimstenfalls auf Basis von MinGW/MSys auch selber bauen, sollte es im Netz aber auch fertig geben. Hier mal ein paar Links: https://www.cososo.co.uk/2015/12/cross-development-using-eclipse-and-gcc-for-the-rpi/ http://gnutoolchains.com/raspberry/tutorial/
Lazarus ist wirklich ideal für diesen Anwendungsfall. Du kannst auf
deinem Desktop in Windows/Linux die GUI und den Logikteil, der nicht auf
die spezielle Raspihardware zugreift, basteln und ausführen. Für die
hardwarespezifichen Sachen muss natürlich auf dem Raspi getestet werden.
Diese kannst du aber einfach über Direktiven abtrennen ({$IFDEF
Raspberry}) dann bleibt dein Programm immer unter Win und
Raspberry-Linux kompilier- und ausführbar und damit testbar.
Das Raspberryprogramm lässt sich vom PC aus crosskompilieren, also kein
Übertragung für jeden Kompilierversuch nötig.
Hi, wenn Du wirklich schnelle Grafik haben willst, dann probier mal die libSDL aus. Kompilieren würde ich immer auf dem Raspi, das geht z.B. mit Code::Blocks schnell genug. Als Gegenstück kann man MobaXTerm nehmen, welches Code::Blocks in Deinem Windows einblendet. Das funktioniert recht geschmeidig und schneller als VNC. Ich habe mit der libSDL einen schönen Raspi-Bilderrahmen realisiert, der zur Freude der Familie jetzt schon seit drei Jahren die neuesten Aufnahmen präsentiert. Gruß, Oliver
Bernd W. schrieb: > Wieso willst du unbedingt kompilieren? Python ist als Skriptsprache > konzipiert. Und für das meiste schnell genug. Das ist natürlich richtig, aber gleichzeitig nur ein Teil der Wahrheit. Richtig ist, daß Python primär eine sehr schnelle Skriptsprache und als solche für die meisten Dinge schnell genug ist. Python wurde aber auch dazu konzipiert, wahlweise als "Glue-Sprache" für kompilierten Code oder aber in andere Sprachen eingebettet zu werden. [1] Beispiele für Pythons Verwendung als Glue-Sprache sind natürlich dessen eigene Standard-Module wie _sre.so als Backend des re-Moduls für Regular Expressions oder das csv-Modul mit _csv.so für das Parsen von CSV-Dateien. Auch externe Libraries für rechenintensive Aufgaben nutzen oft kompilierte Shared Objects bzw. Dynamic Link Libraries, zum Beispiel viele Teile von numpy und scipy. Auch als Embedded-Skriptsprache ist Python sehr beliebt, bekannt sind eventuell FreeCAD, 3ds Max, Blender, Maya, Lightwave, GIMP, Inkscape, Scribus und Paint Shop Pro. Für C bietet Python selbst bereits das nötige Rüstzeug, für C++ bietet das Boost-Projekt mit Boost.Python eine moderne und mächtige Bibliothek für die Verwendung in beiden Anwendungsfällen. Auch aus anderen Gründen bietet sich Python für solche Anwendungsfälle an; neben der Standardimplementierung CPython gibt es auch noch weitere Python-Implementierungen wie Jython in Java und IronPython in .NET, die direkt auf nativen Code der jeweiligen Umgebungen zugreifen können. Und es gibt natürlich den Python-Interpreter PyPy, der mit dem Ziel höherer Performance entworfen und entwickelt wurde und zwar keine Wunder bewirkt, aber bei bestimmten Anwendungsfällen doch deutlich besser performt als der Standard-Interpreter. Und wem das alles noch nicht reicht, der kann Python-Code mit nuitka oder Cython in C- oder C++-Code übersetzen, der sich dann in nativen Binärcode kompilieren läßt. Insofern hat der TO jetzt die Qual der Wahl: natürlich kann er auf C, C++ oder Pascal/Lazarus umsteigen -- wobei letzteres vermutlich besonders viel Arbeit erfordern würde, um die C-Bibliotheken des Raspi einzubinden. Oder er kann schauen, wo es bei seiner Anwendung denn mit der Laufzeit klemmt ("Measure, don't guess!" (Kirk Pepperdine)) und die betreffenden Teile der Anwendung in C oder C++ implementieren und in Python einbinden. Oder er probiert eben einfach mal einen der genannten Compiler nuitka oder Cython, ob die damit erzeugten Kompilate die gewünschte Performance bringen. Ich würde diese Liste vermutlich von hinten abarbeiten: erst die Compiler ausprobieren, und wenn der dadurch erreichte Performancegewinn noch nicht ausreichend ist, mal messen, wo es hakt und die betreffenden Teile als C- oder C++-Bibliotheken umsetzen. Und erst wenn das alles nicht ausreicht, würde ich die Reimplementierung in einer anderen Sprache erwägen. Aber das hängt natürlich im Wesentlichen vom Anwendungsfall ab -- mit ein bisschen Erfahrung in Python und anderen Sprachen merkt man normalerweise ziemlich schnell, welcher Ansatz der Erfolgversprechendste sein dürfte. Ansonsten sagt meine Erfahrung als jemand, der Python bei seinem AG als Standard-Skriptsprache durchgesetzt und darum einigen Dutzend Kollegen beigebracht hat: wer sich über die Performance von Python beschwert, hat meistens entweder extrem intensive Rechen- oder Speicheroperationen zu erledigen, oder etwas flashc gemacht. Es hilft jedenfalls, sich einmal durch Werke wie "High Performance Python" und "Fluent Python" (beide O'Reilly) gearbeitet zu haben, um zu verstehen, wie der Interpreter arbeitet, und zu sehen, wo man mit wenig Aufwand viel erreichen kann. Ein Beispiel für einen Fehler, den ich bei meinen Anfängern regelmäßig sehe, betrifft das Einlesen und Konkatenieren großer Listen. Das wird häufig so gemacht (hier am Beispiel einer Datei):
1 | content = '' |
2 | with open('file.txt', 'r') as ifh:
|
3 | for line in ifh: |
4 | content += line |
Dabei gibt es eine wesentlich performantere Variante:
1 | content = list() |
2 | with open('file.txt', 'r') as ifh:
|
3 | for line in ifh: |
4 | content.append(line) |
5 | content = ''.join(line) |
Sowas performt übrigens auch in Perl wesentlich besser. ;-) (Ach ja: Python hat natürlich auch ein mmap-Modul, mit dem sowas im Falle einfacher Dateien nochmal viel performanter umgesetzt werden kann. ;-)) [1] https://www.python.org/doc/essays/omg-darpa-mcc-position/
guest schrieb: > Wenn Du Visual Studio als IDE benutzt, nimmt es Dir diese Arbeit ab. Ist das wirklich wahr? Eine bestimmte IDE als Heilsbringer? Entschuldige bitte, aber das kann jede IDE und sogar jeder vernünftige Editor. Ganz egal, ob Du den vi(m) oder den Emacs benutzt, Notepad++, UltraEdit, Geany, Sublime, oder ob Du mit Makefiles oder noch etwas professioneller mit Ansible, Puppet, oder Chef arbeitest: das sind die Basics, die jede Entwicklungsumgebung leisten muß!
Hallo Sheeva Plug. Sheeva P. schrieb: >> Wieso willst du unbedingt kompilieren? Python ist als Skriptsprache >> konzipiert. Und für das meiste schnell genug. > > Das ist natürlich richtig, aber gleichzeitig nur ein Teil der Wahrheit. > Richtig ist, daß Python primär eine sehr schnelle Skriptsprache und als > solche für die meisten Dinge schnell genug ist. Python wurde aber auch > dazu konzipiert, wahlweise als "Glue-Sprache" für kompilierten Code oder > aber in andere Sprachen eingebettet zu werden. [1] Danke für Deine Info.....aber ab hier habe ich fast kein Wort mehr verstanden. ;O) Da habe ich wohl Monate zu tun, um mich da einzulesen, und das sind ja eigentlich Jahre, weil ich es in meiner Freizeit mache. C/C++ ist für mich schon ein Problem, weil ich nur alle paar Monate dazu komme, ein paar Zeilen Code zu schreiben, und dann komplett raus bin.....Darum nehme ich lieber Python. Das ist in dem Punkte etwas einfacher, aber Details gehen auch verloren. > Ich würde diese Liste vermutlich von hinten abarbeiten: erst die > Compiler ausprobieren, und wenn der dadurch erreichte Performancegewinn > noch nicht ausreichend ist, mal messen, wo es hakt und die betreffenden > Teile als C- oder C++-Bibliotheken umsetzen. Und erst wenn das alles > nicht ausreicht, würde ich die Reimplementierung in einer anderen > Sprache erwägen. Und in beiden Fällen benötigt man C/C++ Kentnisse. > Aber das hängt natürlich im Wesentlichen vom > Anwendungsfall ab -- mit ein bisschen Erfahrung in Python und anderen > Sprachen merkt man normalerweise ziemlich schnell, welcher Ansatz der > Erfolgversprechendste sein dürfte. Erfahrung kommt nur vom oft Anwenden. > Ein Beispiel für einen Fehler, den ich bei meinen Anfängern regelmäßig > sehe, betrifft das Einlesen und Konkatenieren großer Listen. Das wird > häufig so gemacht (hier am Beispiel einer Datei): Hab ich mir gerade in der Frühstückspause angesehen, und nicht verstanden. Braucht auch mehr Zeit. > (Ach ja: Python hat natürlich auch ein mmap-Modul, mit dem sowas im > Falle einfacher Dateien nochmal viel performanter umgesetzt werden kann. > ;-)) Was auch immer das ist. ;O) Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Ich würde mal einen Blick auf Qt und den QtCreator riskieren... Ich mach das so: Entwicklungsumgebung inkl. Compiler und Debugger läuft auf dem PC (Linux-VM im Hyper-V mit X forwarding - sieht aus wie "echtes" Windows). Das Programm wird für's Debugging automatisch übers Netzwerk auf das Target geladen und mit gdbserver ausgeführt. In meinem Fall ist es zwar ein anderes SoC, aber ich denke für den Raspberry mit seiner großen Community gibt's da eine ganze Menge an Anleitungen im Netz.
Du wolltest zwar kein Windows.... Aber warum nicht die cmd box von Windows verwenden??? Die startet im fullscreen.
Wenn Du Android auf das Raspberry installierst, kannst Du Unity für die Grafikprogrammierung verwenden. https://www.youtube.com/watch?v=Tz2hbhVmrW0
Offenbar bricht gerade ein Wettstreit aus wer die kompliziertes und unhandlichste Lösung findet??? ??
Bernd W. schrieb: > Warum codest du nicht auf dem Raspberry? Im Zweifel per Remote Desktop? Das mache ich ja, aber das ist Dreck! Alleine schon weil ich jedesmal "sudo export=DISPLAY:0 python blablabla.py" eintippen muss, damit er nicht versucht das auf dem SSH darzustellen. Witzigerweise geht ein Python auf dem einen Pi, stecke ich die SD in einen anderen geht wieder was nicht. Der eine Pi hat 4 Kerne, der andere 1. Ich hätte gerne ne IDE am PC wo ich dann dort coden kann ohne jedesmal den Monitor/Tastatur umstecken zu müssen. Ich habe Lazarus ausprobiert. Das mit dem Crosscompile scheint zu funktionieren. Auch habe ich VisualGTK ausprobiert was sehr komfortabel ist. Aber schon beim Test mit nem "Hello world" kam halt keine Ausgabe auf dem RPi. Mit sowas brauche ich dann nicht weiter machen, wenn ich Tastatur umstecken muss um das Ding lokal zu starten. Bei Windows CE 6 war das richtig komfortabel! Einfach compile und man konnte sich das Programm auf dem Arm ansehen. In einem anderen Post habe ich was von Kivy gelesen. Ich habe mir dann mal die Mühe gemacht schritt für schritt durchzuarbeiten. Bis zu dem Punkt als er dann erfolgreich den Fehler über OpenGL 1 gebracht hatte das er gerne als 2.0 mindestens sehen wollte. Ganz ehlrich, wenn ich einen Installer habe, bei dem ich jeden schritt in der cmd eintippen muss, was soll das? Python lässt sich ja auch mit dem Installer auf den Rechner bringen. Warum macht man das bei Kivy so umständlich? Da ist die werbung "Open source Python library for rapid development of applications" doch Bauernfängerei! "Rapid" ist da mal gar nichts. Und zu aller letzt, setzen die meisten auch noch das blöde X11 voraus. Ich meine jetzt nicht den Server, sonder die Oberfläche wie man sie mit Startx hochfährt. Das brauche ich aber nicht! Was will ich mit den vielen Symbolen, wenn ich vollbild benötige. TKinter hat bisher am besten funktioniert. ich glaube ich werde mir nochmal ein Image machen bei dem nur das Raspian-Strech drauf ist. Den Desktop kann man ja abschalten und in die CMD booten.
Alex W. schrieb: > Und zu aller letzt, setzen die meisten auch noch das blöde X11 voraus. > Ich meine jetzt nicht den Server, sonder die Oberfläche wie man sie mit > Startx hochfährt. Das brauche ich aber nicht! Was will ich mit den > vielen Symbolen, wenn ich vollbild benötige. Du hast das schon richtig getrennt: X11 hat erstmal nichts mit der Oberfläche/Icons, Displaymanager und dem Windowmanager zu tun. Du kannst auch einfach X11 starten und nur Dein Programm im Vollbildmodus laufen lassen. So machen wir das hier bei unserer Maschinensteuerung auch: wir benötigen nur dieses eine Programm. > TKinter hat bisher am besten funktioniert. Wir arbeiten hier mit dem "Original" (Tcl/Tk) ;-) Ist aber quasi dasselbe. Wenn Du damit gut zurecht kommst, spricht doch nichts dagegen, das zu verwenden. Außerdem sparst Du Dir das compilieren und kannst am laufenen Programm(code) Änderungen vornehmen (gerade bei GUI-Entwicklung sehr angenehm). > ich glaube ich werde mir > nochmal ein Image machen bei dem nur das Raspian-Strech drauf ist. Den > Desktop kann man ja abschalten und in die CMD booten.
:
Bearbeitet durch Moderator
Wenn du wirklich Grafik brauchst (also Pixelauflösung) und in C programmieren möchtest, empfehle ich dir libSDL - ne Low-Level Grafik-Bibliothek (also keine Buttons, Eingabefelder, Auswahlboxen etc). Das gibt's für beide Platformen (Linux/Windows), macht sowohl Aus- als auch Eingabe (Tastatur/Maus) und ist auch für Spiele fix genug (viele Emulatoren benutzen das als Ein-/Ausgabesystem). Die Linux-Version kann sowohl in X11 laufen als auch Standalone. Da libSDL auch unter Windows läuft, könntest du das Programm direkt auf der Windows-Kiste testen und brauchst es erst gar nicht auf den Raspberry übertragen. Wenn du es unter Windows für den Raspberry übersetzen willst, brauchst du nen Cross-Compiler. Mir ist das zu umständlich - ich arbeite per ssh direkt auf der ARM-Kiste. PS: Mit startx startest du den gesamten Desktop. X11 selbst ist, nach heutigen Maßstäben, ziemlich schlank und zeigt nach dem Starten nur nen leeren Bildschirm. Der ganze Bling (Fensterrahmen, Fenster verschieben, Icons, Controlbar, etc) kommt erst durch zusätzliche Programme. Allerdings gebe ich zu, dass die direkte X11-Programmierung, bedingt durch das komplett asynchrone Design und die Hardwareflexibilität, doch einiges an Einarbeitung erfordert.
Bernd K. schrieb: > ssh existiert. Alex W. schrieb: > eintippen muss, damit er nicht versucht das auf dem SSH > darzustellen. mein kleiner Padawan :) Chris D. schrieb: > Du hast das schon richtig getrennt: X11 hat erstmal nichts mit der > Oberfläche/Icons, Displaymanager und dem Windowmanager zu tun. Du kannst > auch einfach X11 starten und nur Dein Programm im Vollbildmodus laufen > lassen. So machen wir das hier bei unserer Maschinensteuerung auch: wir > benötigen nur dieses eine Programm. Danke! Ich dachte schon ich hätte mich etwas blöd ausgedrückt. Ist halt so, wenn man sich ärgert. Chris D. schrieb: > Wir arbeiten hier mit dem "Original" (Tcl/Tk) ;-) Ist aber quasi > dasselbe. > > Wenn Du damit gut zurecht kommst, spricht doch nichts dagegen, das zu > verwenden. Außerdem sparst Du Dir das compilieren und kannst am laufenen > Programm(code) Änderungen vornehmen (gerade bei GUI-Entwicklung sehr > angenehm). Cool, dann gibts also doch jemand welcher es umsetzen kann! Ich hoffe ich frage nicht etwas das nicht genannt werden darf: Wie löst ihr das Problem, das wenn ich über SSH auf den RPi zugreife und ein .py starten möchte, dass es auf dem Display am Pi angezeigt und ausgeführt wird? Ich schireb ja oben mit dem "export". Aber im Py müsste man das doch abfragen und steuern können? Habt ihr ein paar Referenzen die man sich als Beispiel ansehen kann?
foobar schrieb: > Da libSDL auch unter Windows läuft, könntest du das Programm direkt auf > der Windows-Kiste testen und brauchst es erst gar nicht auf den > Raspberry übertragen. Wenn du es unter Windows für den Raspberry > übersetzen willst, brauchst du nen Cross-Compiler. Mir ist das zu > umständlich - ich arbeite per ssh direkt auf der ARM-Kiste. Geil! Sowas suche ich! C wäre natürlich deluxe, aber py würde auch reichen! Ist halt nur die Frage was man alles anstellen muss um die IDE dafür aufzusetzen.
Alex W. schrieb: > Wie löst ihr das Problem, das wenn ich über SSH auf den RPi zugreife und > ein .py starten möchte, dass es auf dem Display am Pi angezeigt und > ausgeführt wird? Den Export nicht machen, und beim SSH den -Y Parameter mitgeben. "ssh -Y pi". Unter Windows haben viele SSH Clients aber keinen X11 Server. Unter Linux kann man noch mit "sftp" ein Verzeichnis des PI lokal über ssh mounten, damit muss man das nicht immer explizit hochladen/runter laden. Unter Windows könnte man eine folgender Libraries versuchen, aber ich verwende kein Windows, also kann ich nicht sagen wie gut die sind: https://github.com/dokan-dev/dokan-sshfs https://github.com/billziss-gh/sshfs-win Und gegen das Maus umsteck Problem gibt es programme wie z.B. Synergy, aber ich habe diese noch nicht ausprobiert.
> aber py würde auch reichen! Für viele Sprachen gibt's SDL-bindings. Für Python finde ich gleich zwei pySDL und pySDL2 ;-) > Ist halt nur die Frage was man alles anstellen muss um die IDE dafür > aufzusetzen. Wenn die IDE mehr Probleme verursacht als sie löst, lass das "I" einfach weg - nen Shell, nen Editor, Compiler und Make reicht doch ;-)
> Wie löst ihr das Problem, das wenn ich über SSH auf den RPi zugreife und > ein .py starten möchte, dass es auf dem Display am Pi angezeigt und > ausgeführt wird? Im Shell einmal "export DISPLAY=:0" eingeben (":0" ist das erste lokale Display des Rechners, auf dem das Programm läuft). Das "ssh -Y" leitet X11-Verbindungen von dem remote-Rechner auf den lokalen um - macht nur Sinn, wenn lokal auch nen X-Server läuft.
Bernd W. schrieb: > Wieso willst du unbedingt kompilieren? Python ist als Skriptsprache > konzipiert. Und für das meiste schnell genug. Oh man, was wurde früher auf Basic rumgehackt, weil das ja nur im Interpreter läuft und soooo langsam ist. Das Argument "langsam" kommt heute noch, obwohl es seit Jahrzehnten gut Basic-Compiler gibt. Und jetzt ist es plötzlich hip, für ein Programm mit 20 Zeilen, welches als C, Pascal oder Basic-Compilat gerade mal ein paar kByte hätte, einige 100 MByte an Interpreter zu laden. Und dann jammern die Leute rum, dass ihnen ein Raspi heute nicht schnell genug ist für Aufgaben, die früher auf einen C64 oder Amiga500 liefen, mit 1/1000 des Arbeitsspeichers und 1/100 der Taktfrequenz. Ihr spinnt doch.
Karl schrieb: > Bernd W. schrieb: >> Wieso willst du unbedingt kompilieren? Python ist als Skriptsprache >> konzipiert. Und für das meiste schnell genug. > > Oh man, was wurde früher auf Basic rumgehackt, weil das ja nur im > Interpreter läuft und soooo langsam ist. Das Argument "langsam" kommt > heute noch, obwohl es seit Jahrzehnten gut Basic-Compiler gibt. > > Und jetzt ist es plötzlich hip, für ein Programm mit 20 Zeilen, welches > als C, Pascal oder Basic-Compilat gerade mal ein paar kByte hätte, > einige 100 MByte an Interpreter zu laden. Redest du von Python, dem "hippen Shit" dens gibt seits ihr Deutschen noch Ost- und West warts?
Jetzt nochmal.... Mach windows iot drauf. Schliess ein Display an... 10 und du kannst die Kommandozeile öffnen... Installiert visual studio community Edition.... Programmier mit oder ohne Oberfläche... In der Sprache die dir am besten liegt... C++, Javascript, and typescript, python, c#, vb... Fertig... Programm am raspberry ausführen und fertig.... Ssh Verbindung? Einschalten und fertig... Alles weitere unter https://docs.microsoft.com/de-de/windows/iot-core/getstarted. Loslegen und Spaß haben...
Sheeva P. schrieb: > Ein Beispiel für einen Fehler, den ich bei meinen Anfängern regelmäßig > sehe, betrifft das Einlesen und Konkatenieren großer Listen. Das wird > häufig so gemacht (hier am Beispiel einer Datei): > content = '' > with open('file.txt', 'r') as ifh: > for line in ifh: > content += line > > Dabei gibt es eine wesentlich performantere Variante: > content = list() > with open('file.txt', 'r') as ifh: > for line in ifh: > content.append(line) > content = ''.join(line) Und warum macht dieser Syntactic Suggar einen Unterschied in der Performance? Sowas ist doch eher ein Zeichen dafür dass in der Implementierung geschlampt wurde. Hier erwarte ich als Entwickler gleiches Verhalten, ansonsten ist das Pfusch auch wenn es dokumentiert ist. Wenn ich zu solchen "Tricks" genötigt werde, weil das eine ein Pseudofehler ist na dann gut nacht. Aber Python hat ja auch Whitespace als Syntaxelement, da wundert einen der Rest auch nicht mehr. > Sowas performt übrigens auch in Perl wesentlich besser. ;-) Hast du es getestet? Welche Version?
Alex W. schrieb: > Bernd K. schrieb: >> ssh existiert. > > Alex W. schrieb: >> eintippen muss, damit er nicht versucht das auf dem SSH >> darzustellen. > > mein kleiner Padawan :) Bash script existiert. Nutze die Kraft.
Bernd K. schrieb: > Alex W. schrieb: >> Bernd K. schrieb: >>> ssh existiert. >> >> Alex W. schrieb: >>> eintippen muss, damit er nicht versucht das auf dem SSH >>> darzustellen. >> >> mein kleiner Padawan :) > > Bash script existiert. Nutze die Kraft. Nutze du lieber mal die Kraft des Lesens, denn das was du vorschlägst habe ich oben bvereits geschrieben und nochmals zitiert! Viel zu lesen du noch hast...
Ich hab jetzt nochmal mit einem frisch installierten Raspian-Image von der raspi-seite einen Versuch gestartet. Sobald ich in der Kommandozeile ein Testprogramm aufrufe, kommt die Fehlermeldung "tkinter.tclerror no display name and no $display environment variable". Ich verstehe nicht wo die Ursache ligt. Wenn ich kein Display drann hätte, könnte ich die Fehlermeldung nicht lesen.
Alex W. schrieb: >>>> eintippen muss, damit er nicht versucht das auf dem SSH >>>> darzustellen. >>> >>> mein kleiner Padawan :) >> >> Bash script existiert. Nutze die Kraft. > > Nutze du lieber mal die Kraft des Lesens, denn das was du vorschlägst > habe ich oben bvereits geschrieben und nochmals zitiert! Und ich zitiere es jetzt ebenfalls nochmal damit jeder sehen kann daß Du es offensichtlich nicht begriffen hast: Also: Schreibe ein Script, dann musst du nichts mehr eintippen.
Bernd K. schrieb: > Also: Schreibe ein Script, dann > musst du nichts mehr eintippen. Für eine Windows-Umgebung? Ernsthaft?
> Sobald ich in der Kommandozeile ein Testprogramm aufrufe, kommt die > Fehlermeldung "tkinter.tclerror no display name and no $display > environment variable". Bei X11 kommunizieren Anwendungen und X11-Server (der macht die Ein-/Ausgabe) über eine Netzwerkverbindung. Dazu müssen die Anwendungen wissen, welchen X11-Server sie ansprechen müssen. Der standardmäßige X11-Server, wird vom Login-Prozess in der Umgebungsvariable DISPLAY hinterlegt. Bei den meisten wird das ":0" sein, der erste lokale X11-Server. Einige Programme (z.B. su) löschen diese Variable für Kindprozesse - die wissen dann nicht mehr, wohin sie ihre Ausgaben machen sollen und erzeugen Fehlermeldungen (wie z.B. dein tkinter oben). DISPLAY ist eine ganz normale popelige Umgebungsvariable. Umgebungsvariablen kannst du dir mittels "env" anzeigen lassen und auch einfach neu setzen, z.B. mittels "DISPLAY=:0; export DISPLAY" oder im Bash kürzer mit "export DISPLAY=:0". Eventuell bekommst du noch weitere Fehlermeldungen von der Zugriffskontrolle des X11-Servers. Dann hilft z.B. ein "xhost +local:root" in der Login-Session (einmalig, bevor du "su" o.ä. machst) um lokale Verbindungen von root zu diesem X11-Server zu erlauben.
Hallo, hier ist ja mal wieder geladene Stimmung. Also ich setzt gerade Kivy ein für eine einfache Oberfläche ein. Kivy kann aber auch gut Grafik. Geht wirklich sehr gut. Ich benutze Python 3.6 (Anaconda) und Spyder zum Entwickeln, auf Arbeit leider unter Windows. Ob es allerdings auf dem Pi läuft habe ich nicht selber getestet, aber laut Doku sollte es gehen. Gerade mit Multitouch fähigen Displays finde ich es spannend es mal auf dem Pi zu testen. Warum sollte man für Windows keine Skripte schreiben können?
Verwundert schrieb: > Warum sollte man für Windows keine Skripte schreiben können? Kann man schon machen!Wenn das aber jeder für sich macht "dann ists halt Kacke". Das Script sollte auf der Website zugänglich sein, so hätte jeder was davon
Alex W. schrieb: > Bernd K. schrieb: > Also: Schreibe ein Script, dann > musst du nichts mehr eintippen. > > Für eine Windows-Umgebung? Ernsthaft? Cygwin existiert. Windows 10 existiert.
Alex W. schrieb: > Das mache ich ja, aber das ist Dreck! > > Alleine schon weil ich jedesmal "sudo export=DISPLAY:0 python > blablabla.py" eintippen muss, damit er nicht versucht das auf dem SSH > darzustellen. > > Witzigerweise geht ein Python auf dem einen Pi, stecke ich die SD in > einen anderen geht wieder was nicht. Der eine Pi hat 4 Kerne, der andere > 1. > > Ich hätte gerne ne IDE am PC wo ich dann dort coden kann ohne jedesmal > den Monitor/Tastatur umstecken zu müssen. Gut, wenn du das alles so umständlich machst, ist mir klar, dass du das für "Dreck" hältst. > Aber schon beim Test mit nem "Hello world" kam halt keine Ausgabe auf > dem RPi. Mit sowas brauche ich dann nicht weiter machen, wenn ich > Tastatur umstecken muss um das Ding lokal zu starten. Musst du nicht. Über eine SSH kannst du alles machen. Und ja, du musst dich dann um die DISPLAY-Environment-Variable kümmern, aber nur EINMAL, nicht bei jedem einzelnen Start des Programms. > Und zu aller letzt, setzen die meisten auch noch das blöde X11 voraus. > Ich meine jetzt nicht den Server, sonder die Oberfläche wie man sie mit > Startx hochfährt. Welche setzen das voraus? Karl schrieb: > Und jetzt ist es plötzlich hip, für ein Programm mit 20 Zeilen, welches > als C, Pascal oder Basic-Compilat gerade mal ein paar kByte hätte, > einige 100 MByte an Interpreter zu laden. Welcher Python-Interpreter braucht denn "einige 100 MByte"? Alex W. schrieb: >> Bash script existiert. Nutze die Kraft. > > Nutze du lieber mal die Kraft des Lesens, denn das was du vorschlägst > habe ich oben bvereits geschrieben und nochmals zitiert! Nein. Du tippst die Zeilen, die ein Skript erledigen könnte, einzeln von Hand ein und beschwerst dich dann darüber, dass du sie einzeln von Hand eintippen musst.
Ich würde da Xojo vorschlagen, das kann auch Raspi-Programme. Bin gerade an einem Projekt, macht sich ganz gut ... Beispiel: https://www.youtube.com/watch?v=3xJ441iOgSM
:
Bearbeitet durch User
Rolf M. schrieb: > Karl schrieb: >> Und jetzt ist es plötzlich hip, für ein Programm mit 20 Zeilen, welches >> als C, Pascal oder Basic-Compilat gerade mal ein paar kByte hätte, >> einige 100 MByte an Interpreter zu laden. > > Welcher Python-Interpreter braucht denn "einige 100 MByte"? Das ist ja auch Unsinn. Tcl bspw. benötigt keine 300kByte. Und man kommt ganz ohne compilieren aus und kann GUI/Quellcode während des laufenden Programms anpassen. Das ermöglicht hier deutlich kürzere Zykluszeiten, gerade in der GUI-Entwicklung.
Karl schrieb: >> Wieso willst du unbedingt kompilieren? Python ist als Skriptsprache >> konzipiert. Und für das meiste schnell genug. > > Oh man, was wurde früher auf Basic rumgehackt, weil das ja nur im > Interpreter läuft und soooo langsam ist. Das Argument "langsam" kommt > heute noch, obwohl es seit Jahrzehnten gut Basic-Compiler gibt. Nein. Seit mindestens 20 Jahren für die meisten Anwendungen nicht mehr. Aber es gibt halt immer irgend eine Anwendung, mit der man Software und Hardware an die Grenze und darüber hinaus bringt. ;O) > > Und jetzt ist es plötzlich hip, für ein Programm mit 20 Zeilen, welches > als C, Pascal oder Basic-Compilat gerade mal ein paar kByte hätte, > einige 100 MByte an Interpreter zu laden. 1) Du übertreibst. Das sind keine 100MByte. ;O) 2) Du hast den Interpreter aber nur einmal auf der Platte. Und gerade Python (3) ist die mit Abstand einfachste Programiersprache die ich je erlebt habe. Für Gelegenheitsprogrammierer wie mich ein wichtiges Argument, und man kann damit auch relativ schnell ein Programm erstellen. > Und dann jammern die Leute rum, dass ihnen ein Raspi heute nicht schnell > genug ist für Aufgaben, die früher auf einen C64 oder Amiga500 liefen, > mit 1/1000 des Arbeitsspeichers und 1/100 der Taktfrequenz. Wenn Du einen Eselskarren hast, jammerst Du, dass da so wenig drauf geht. Hast Du einen 150t Muldenkipper, jammerst Du auch, wenn Du da 200t draufpacken möchtest. ;O) Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
:
Bearbeitet durch User
Alex W. schrieb: > Grafik in der CMD-Line analog zur DOS-Zeit Alex W. schrieb: > Aber dennoch würde ich gerne C/C++ oder Basic bevorzugen, falls jemand > eine Idee hat Hast du dir Eric schrieb: > ncurses mittlerweile mal angeguckt? Gib das doch mal in die Google Bildersuche ein.
Hi Leute, wollte mich mal zurück melden! Nochmals danke für die vielen Vorschläge und Hilfestellungen! Ich habe gestern Abend nochmals ein Image genommen dass ich schon hatte (im Doenloadordner nur älter), auf eine SD geschrieben und gestartet. Danach die Updates mit apt-get. Dieses Image geht einwandfrei! Ich kann Grafikdateien öffnen und anzeigen. Buttons darüber legen und sogar die RaspiCam darstellen (ich nehme hier Python2). Die selben Quelldateien gehen auf dem anderen Image von Raspian nicht (das was aktuell bei Raspberrypi.org ladbar ist)! Verstehen muss ich es nicht, wenn aber jemand den Grund kennt wäre es schon zu erfahren wie man den Fehler behebt! PS: Ich hab zum Test sogar TV-Out benutzt und keine Probleme gehabt (altes Image). Ich werde heute Abend mal versuchen herauszufinden welches Image es war! Grüße
Md M. schrieb: > Eric schrieb: >> ncurses > > mittlerweile mal angeguckt? Gib das doch mal in die Google Bildersuche > ein. ncurses ist aber Text, ich möchte Grafik! Habe ich mittlerweile auch zum laufen bekommen, nachdem ich ein anderes Raspian-Image genommen habe.
mmm schrieb: > Ich würde mal einen Blick auf Qt und den QtCreator riskieren... +1 Mit Qt hast du sehr viele Funktionen (Buttons, Diagramme, 2D/3D Grafik, Dateisystem inklusive Formate wie csv/ini/png, Sound, Netzwerk, ...) unter einem Dach. Es gibt auch einen Port nach Python, falls du nicht so sehr auf C++ und kompilieren stehst.
Alex W. schrieb: > Bernd W. schrieb: >> Warum codest du nicht auf dem Raspberry? Im Zweifel per Remote Desktop? > > Das mache ich ja, aber das ist Dreck! Entschuldige bitte, aber der eigentliche "Dreck" ist, daß Du Dein Werkzeug leider nicht richtig beherrschst. > Alleine schon weil ich jedesmal "sudo export=DISPLAY:0 python > blablabla.py" eintippen muss, damit er nicht versucht das auf dem SSH > darzustellen. Der Befehl "sudo export=DISPLAY:0 python blablabla.py" ist an gleich so vielen Stellen falsch, daß ich gar nicht weiß, wo ich anfangen soll. Also: Dein Programm benutzt das X11-Protokoll für die Darstellung. Die kann aber auf einem beliebigen X-Server erfolgen, der über das Netzwerk erreichbar ist. Du mußt dem Programm nur mit der Umgebungsvariable DISPLAY sagen, wo Du die Darstellung haben willst, und dem X-Server mit dem Programm xhost(1) erklären, daß er Netzwerkverbindungen von Deinem X-Client annehmen soll. Also brauchst Du einen X-Server, da reicht da auch ein nackter X-Server ohne Desktop Environment. So einen X-Server kannst Du entweder auf Deinem Windows-Client installieren oder gleich einen SSH-Client mit Unterstützung für das X11-Protokoll benutzen, wie Moba XTerm. Letzteres ist besonders komfortabel: einfach mit Moba XTerm auf den RasPi verbinden und dort Dein X-Programm aufrufen, schon wird es auf Deinem Windows dargestellt als ob es lokal laufen würde. "export=DISPLAY:0" ist ebenfalls Irrsinn, denn das bewirkt nur, daß die Umgebungsvariable "export" auf den Wert "DISPLAY:0" gesetzt wird. Aber Du willst stattdessen natürlich die Umgebungsvariable DISPLAY setzen, und dafür müßtest Du nur einmal am Anfang Deiner Shell-Session den Befehl "export DISPLAY=localhost:0.0" aufrufen. Durch das "export" bleibt die Variable dann nämlich für den Rest der Shell-Session gesetzt. Das kannst Du auch einfach in Deine $HOME/.profile oder $HOME/.bashrc eintragen, die beim Einloggen automatisch abgearbeitet wird. Aber wenn Du Moba XTerm benutzt, mußt Du nicht einmal das, denn dann tunnelt der Client die X-Session über die bestehende SSH-Session. Ob und wozu Du ein "sudo" davor brauchst, weiß ich natürlich nicht. Aber wenn Dein Programm keine Superuser-Rechte braucht, kannst Du es weglassen. Du mußt auch nicht jedesmal "python blablabla.py" aufrufen. Es reicht, in die erste Zeile des Programms eine Shebang-Zeile wie "#!/usr/bin/python" enthalten und die Datei mit dem Befehl "chmod u+x blablabla.py" als ausführbar markiert werden. Aber Achtung: das aktuelle Verzeichnis liegt aus Sicherheitsgründen nicht im Suchpfad für ausführbare Dateien, daher kannst Du das Skript danach nicht einfach mit "blablabla.py" ausführen, sondern mußt Deiner Shell ausdrücklich sagen, daß Du das Programm im aktuellen Arbeitsverzeichnis liegt: "./blablabla.py". Du mußt Deine Befehle auch nicht jedesmal neu eintippen, die Bash-Shell führt eine History. Einfach einmal Taste "Pfeil hoch" drücken, schon bekommst Du den zuletzt ausgeführten Befehl zurück, mit zweimal "Pfeil hoch" den vorletzten, und so weiter. Was in Deiner History steht, kann überraschenderweise mit dem Befehl "history" angezeigt werden. ;-) > Bei Windows CE 6 war das richtig komfortabel! Einfach compile und man > konnte sich das Programm auf dem Arm ansehen. Das ist unter Linux auf dem RasPi ganz genauso, wenn man es richtig macht. > Und zu aller letzt, setzen die meisten auch noch das blöde X11 voraus. > Ich meine jetzt nicht den Server, sonder die Oberfläche wie man sie mit > Startx hochfährt. Das brauche ich aber nicht! Was will ich mit den > vielen Symbolen, wenn ich vollbild benötige. Sie setzen tatsächlich nur den Server voraus, kein Desktop Environment und eigentlich nichtmal einen Windowmanager -- ich würde aber trotzdem einen leichten Windowmanager wie matchbox benutzen, der Einfachheit halber. > TKinter hat bisher am besten funktioniert. ich glaube ich werde mir > nochmal ein Image machen bei dem nur das Raspian-Strech drauf ist. Den > Desktop kann man ja abschalten und in die CMD booten. Du kannst sogar ein minimales Stretch-Image nehmen und dort dann einfach nur einen nackten X-Server ohne Desktop Environment installieren. Danach solltest Du ernsthaft in Erwägung ziehen, einen lokalen Linux-Stammtisch aufzusuchen und Dir dort von einem erfahrenen Linux-Anwender zeigen und erklären zu lassen, wie das richtig geht. Viel Spaß und Erfolg!
Ja aber warum? Leute, der Raspi hat 1GB RAM und kann FullHD Grafik. Starte das Ding mit grafischer Oberfläche und hol es Dir per VNC auf den PC. Man kann sich auch zum Joggen nen Nagel ins Knie treiben. Man kanns aber auch sein lassen.
Sheeva P. schrieb: > Moba XTerm Den schaue ich mir später an! Danke für den Tip! Mit Putty geht das nämlich nicht! Sheeva P. schrieb: > Du nur einmal am Anfang Deiner Shell-Session den > Befehl "export DISPLAY=localhost:0.0" aufrufen. Durch das "export" > bleibt die Variable dann nämlich für den Rest der Shell-Session gesetzt. > Das kannst Du auch einfach in Deine $HOME/.profile oder $HOME/.bashrc > eintragen, die beim Einloggen automatisch abgearbeitet wird. Auch hier danke ich! Sheeva P. schrieb: > Einfach einmal Taste "Pfeil hoch" drücken, schon > bekommst Du den zuletzt ausgeführten Befehl zurück Das kenne ich bereits! Sheeva P. schrieb: > Entschuldige bitte, aber der eigentliche "Dreck" ist, daß Du Dein > Werkzeug leider nicht richtig beherrschst. Mag sein, aber nachdem ich ein anderes Image benutzt habe, klappt das wie ich möchte! Meine Codes laufen schlicht nicht auf dem aktuellen Raspi-Image. Ob ich nun zu doof bin eine benötigte Änderung zu erkennen und durchzuführen, oder ob es ein Bug is, sei egal. Sollte ich meine Codes weitergeben und ein Anfänger diese ausprobieren wollen, klappt es bei ihm nicht. Und das kann es nicht sein! Wenn du weist wo das Problem ligtz, wäre ich dankbar wenn du mir eine Lösung aufzeigen könntest. Guten Start ins Wochenende (ist ja Freitag ;))
Alex W. schrieb: > Sheeva P. schrieb: >> Einfach einmal Taste "Pfeil hoch" drücken, schon >> bekommst Du den zuletzt ausgeführten Befehl zurück > > Das kenne ich bereits! Kennst du auch Strg+R? Damit kannst du in der History suchen.
Karl schrieb: > und hol es Dir per VNC auf den PC. Warum wird auch heute noch immer dieses gruselige schrottige lahme VNC empfohlen? Noch nie was von x2go gehört? Das gibts doch jetzt auch schon ne Weile.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.