Forum: PC-Programmierung Grafikprogrammierung für Raspberry Pi - Vorschläge?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Alex W. (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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

von Karl (Gast)


Bewertung
-8 lesenswert
nicht lesenswert
Mit Lazarus / Freepascal geht das. Das ist dann aber eine richtige 
Programmiersprache und kein Python.

von Alex W. (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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 :)

von R. M. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Bernd W. (berndwiebus) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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

von guest (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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/

von *Werbung* (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Oliver R. (superberti)


Bewertung
1 lesenswert
nicht lesenswert
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

von Sheeva P. (sheevaplug)


Bewertung
2 lesenswert
nicht lesenswert
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/

von Sheeva P. (sheevaplug)


Bewertung
2 lesenswert
nicht lesenswert
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ß!

von Eric (Gast)


Bewertung
1 lesenswert
nicht lesenswert
ncurses?

von Bernd W. (berndwiebus) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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

von mmm (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Wolfgang H. (drahtverhau)


Bewertung
-2 lesenswert
nicht lesenswert
Du wolltest zwar kein Windows.... Aber warum nicht die cmd box von 
Windows verwenden??? Die startet im fullscreen.

von Johnny B. (johnnyb)


Bewertung
0 lesenswert
nicht lesenswert
Wenn Du Android auf das Raspberry installierst, kannst Du Unity für die 
Grafikprogrammierung verwenden.
https://www.youtube.com/watch?v=Tz2hbhVmrW0

von Wolfgang H. (drahtverhau)


Bewertung
2 lesenswert
nicht lesenswert
Offenbar bricht gerade ein Wettstreit aus wer die kompliziertes und 
unhandlichste Lösung findet??? ??

von Alex W. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Chris D. (myfairtux) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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
von Bernd K. (prof7bit)


Bewertung
2 lesenswert
nicht lesenswert
Alex W. schrieb:
> wenn ich
> Tastatur umstecken muss um das Ding lokal zu starten.

ssh existiert.

von foobar (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Alex W. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Alex W. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von DPA (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von foobar (Gast)


Bewertung
1 lesenswert
nicht lesenswert
> 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 ;-)

von foobar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> 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.

von Karl (Gast)


Bewertung
-6 lesenswert
nicht lesenswert
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.

von Vincent H. (vinci)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Wolfgang H. (drahtverhau)


Bewertung
-4 lesenswert
nicht lesenswert
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...

von Webfehler (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
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?

von Bernd K. (prof7bit)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Alex W. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Alex W. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Bernd K. (prof7bit)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Alex W. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Also: Schreibe ein Script, dann
> musst du nichts mehr eintippen.

Für eine Windows-Umgebung? Ernsthaft?

von foobar (Gast)


Bewertung
2 lesenswert
nicht lesenswert
> 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.

von Verwundert (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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?

von Marc Horby (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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

von Bernd K. (prof7bit)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Rolf M. (rmagnus)


Bewertung
3 lesenswert
nicht lesenswert
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.

von Frank E. (Firma: Q3) (qualidat)


Bewertung
-4 lesenswert
nicht lesenswert
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
von Chris D. (myfairtux) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

von Bernd W. (berndwiebus) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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
von Md M. (Firma: Potilatormanufaktur) (mdma)


Bewertung
-2 lesenswert
nicht lesenswert
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.

von Alex W. (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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

von Alex W. (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Strawberry (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Sheeva P. (sheevaplug)


Bewertung
2 lesenswert
nicht lesenswert
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!

von Karl (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Alex W. (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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 ;))

von Rolf M. (rmagnus)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Bernd K. (prof7bit)


Bewertung
2 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.