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
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.
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.
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-sshfshttps://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.
> 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.
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
Alex W. schrieb:> Grafik in der CMD-Line analog zur DOS-ZeitAlex 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.
