Sie sind nicht angemeldet.

Beiträge: 3 751

Registrierungsdatum: 20. Dezember 2015

Wohnort: bei Hamburg

Beruf: Rentner

  • Nachricht senden

31

Donnerstag, 7. März 2019, 11:41

Viel Spaß beim Basteln!
Ich hoffe, daß sich der noch einstellt.
Im Moment ist es mehr Frust über schlechte oder fehlende Dokumentation, unpräzise Bücher und python an sich, wo man mal wieder eine neue Sprache erfunden hat, in der alles anders formuliert werden muß, als in den Sprachen, die es vorher gegeben hat, aber nichts besser geht. Man muß nur wieder mal eine Lernkurve hochklettern, bis man wieder das gleiche kann, wie vorher mit anderen gelernten Sprachen, nur jetzt in dem Interpreter vielleicht etwas langsamer ausgeführt.
Es macht auch nicht glücklicher, wenn es für eine Anwendungsansatz (Betriebssystem, python, java, C, C++, Pascal,...) mehrere alternative Bibliotheken gibt, weil man nicht unbedingt erfährt, welches die schnellste, umfangreichste, komfortabelste, "geilste" ist, sondern das selber ausprobieren muß.

MfG Kai

Beiträge: 13 148

Registrierungsdatum: 4. April 2004

Wohnort: Meerbusch (bei Düsseldorf)

Beruf: Softwareentwickler

  • Nachricht senden

32

Donnerstag, 7. März 2019, 13:26

und python an sich, wo man mal wieder eine neue Sprache erfunden hat, in der alles anders formuliert werden muß, als in den Sprachen, die es vorher gegeben hat, aber nichts besser geht.


Ein guter Programmierer kann programmieren, keine Programmiersprachen. :)

Und der Aussage, daß in Python nichts besser geht, stimme ich nicht zu. Einiges (z.B. die Strukturierung durch Einrückung) mag erst mal gewöhnungsbedürftig seiin, erweist sich aber schnell als gute idee. Und auch ansonsten finde ich vieles wirklich vorbildlich gelöst. Elementares Beispiel: Teil-Strings und Teil-Arrays (schon mal der erste Vorteil: Beides funktioniert gleich).

Quellcode

1
2
3
4
s="Dies ist ein Test"
print(s[:4])
print(s[5:8])
print(s[-4:])



Dies
ist
Test


Quellcode

1
2
3
ai=[1,3,5,7,9]
print(ai[1:2])
print(ai[-2:])



[3, 5]
[7, 9]


Das geht in den meisten anderen Sprachen nur deutlich uneleganter.

Ich hoffe, daß sich eine ähnlich moderne, leistungsfähige Sprache mit umfangreicher Standardbibliothek auch noch mal mit statischer Typisierung und Fokus auf Compilierung in nativen Code durchsetzt und das doch inzwischen deutlich in die Jahre gekommene C++ beerbt, aber bis jetzt endeten alle entsprechenden Versuche relativ erfolglos.

Das gehört aber eher in den Programmiersprachen-Thread, 'tschuldigung für das Offtopic.

Beiträge: 3 751

Registrierungsdatum: 20. Dezember 2015

Wohnort: bei Hamburg

Beruf: Rentner

  • Nachricht senden

33

Donnerstag, 7. März 2019, 14:18

Mein Urteil mag ja vorschnell ungerecht sein, weil ich kaum etwas von python weiß,
aber
Strukturierung durch Einrückung) mag erst mal gewöhnungsbedürftig seiin, erweist sich aber schnell als gute idee
strukturiert schreiben kann man in jeder Sprache, wenn man will. Das ist ja nur eine Frage, ob der verwendete Editor das unterstützt, und der Selbst-Disziplin. Das geht selbst in Assembler oder Basic.
Ich hab gerade einen Quelltext gesehen, den hatte der Autor so großzügig eingerückt, daß die Zeilenlänge größer 256 Zeichen war.
FPC meldete jedenfalls schon beim Einlesen Fehler "zu lange Zeilen", womit unklar wurde, ob der Quell-Code das Einlesen unbeschädigt überstanden hatte.
Also mußte ich erstmal vorbeugend eingreifen und die Einrückerei auf ein vernünftiges Maß begrenzen oder einfach newlines reinhacken.
Mit der Formatier-Syntax von python stehe ich noch auf dem Kriegsfuß, bzw hab gerade keine Doku zur Hand. Wenn ich Programme schreibe, liegt das Schwergewicht allerdings meist mehr beim Rechnen als beim Formatieren.
Meine Informationsquellen zur momentanen Tätigkeit sind etwas unausgewogen: 4 Bücher über Raspi, keins über python.

MfG Kai

Beiträge: 13 148

Registrierungsdatum: 4. April 2004

Wohnort: Meerbusch (bei Düsseldorf)

Beruf: Softwareentwickler

  • Nachricht senden

34

Donnerstag, 7. März 2019, 14:32

Meine Informationsquellen zur momentanen Tätigkeit sind etwas unausgewogen: 4 Bücher über Raspi, keins über python.


Guck' mal auf Wikibooks, da gibt's mehrere.

Beiträge: 3 751

Registrierungsdatum: 20. Dezember 2015

Wohnort: bei Hamburg

Beruf: Rentner

  • Nachricht senden

35

Donnerstag, 7. März 2019, 17:30

Danke,
inzwischen hab ich gesehen, daß man über idle-python2.7 (mit den idleX Erweiterungen) auch in eine einem Buch wohl gleichwertige python-Dokumentation hineinkommt.

Im Moment hab ich ein neues Problem, diesmal mit wxPython. Einige Beispiele aus dem genannten Buch benutzen das für erste GUI-Anwendungen. Das war auf dem Raspi 3B+ offenbar noch nicht installiert. Deshalb habe ich das eben mit
sudo pip install wx Python==4.0.4
versucht.
Es wurden 68.8 MB wxPython-4.0.4.tar.gz downgeloaded, dann vermutlich expandiert und nach einiger Wartezeit kam dann eine Exception Meldung und ein roter traceback von mehreren Standard-Terminal-Höhen. Ganz zum Schluß stand da rot auf schwarz: MemoryError.
Weil ich noch einige andere Applikation geöffnet hatte, hab ich die alle geschlossen und den Befehl nochmal abgesetzt in der Hoffnung, daß nun der Speicher ausreicht. Es lief aber wieder genauso ab.
Habe ich nun einen Haufen File-Leichen auf dem Datenträger und nicht freigegebenen Speicher ?
Muß ich da erstmal mit weiteren Abrakadabra-Befehlen aufräumen ?
Gibt es eine Möglichkeit wxPython zu installieren, ohne in diese Falle zu laufen ?

MfG Kai
Nachtrag: Ich hab eben mal mt hardinfo geschaut, wieviel Memory frei ist. Da werden ca 669 MB frei und ca. 800 MB verfügbar gemeldet. Nominell hat der Raspi 3B+ ca. 1 GB Speicher. Das müßte doch eigentlich reichen, um 68.8 MB komprimierte Files zu expandieren. Wird doch auch normalerweise nicht im Speicher, sondern auf dem Datenträger gemacht, wo einige GB verfügbar sind.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »kaimex« (7. März 2019, 17:57)


Beiträge: 3 751

Registrierungsdatum: 20. Dezember 2015

Wohnort: bei Hamburg

Beruf: Rentner

  • Nachricht senden

36

Donnerstag, 7. März 2019, 18:32

Inzwischen habe ich gefunden, daß man mit
sudo pip --no-cache-dir install wxPython==4.0.4
den MemoryError umschifft.

Das führt soweit, daß die Installation, versucht, wxPython zu erzeugen (build).
Bei den Tests gibt es eine lange Liste mit vielen yes und einigen no beantworteten Einzeltests.
Schließlich wird abgebrochen mit der Meldung, es könne kein gtk+-3.0 gefunden werden.
In der Synaptic-Paketverwaltung sehe ich einige Bestandteile von gtk2+ als installiert markiert.
Es sind auch Files mit gtk3+ zu sehen, alle nicht installiert.
Mir ist jetzt nicht klar, ob es auch mit gtk2+ gehen müßte und nur ein Pfad irgendwo mitzuteilen ist, oder ob ich gtk3+ installieren sollte. Ich weiß aber nicht, welche der gtk+-3.0 Files ich als zu installieren markieren muß.

MfG Kai

Beiträge: 3 751

Registrierungsdatum: 20. Dezember 2015

Wohnort: bei Hamburg

Beruf: Rentner

  • Nachricht senden

37

Donnerstag, 7. März 2019, 19:04

Inzwischen habe ich libgtk-3-dev mit der Synaptic-Paketverwaltung installiert (libgtk-2-dev war bereits installiert).
Erneuter Installationsversuch von wxPython läuft jetzt weiter bis zu einem Abbruch mit der Fehlermeldung:
wxMediaCtrl can't be built because GStreamer is not available
configure : error: wxMediaCtrl was explicitly requested but can't be built
Es gibt demnach irgendwo eine configure option --enable-mediactrl, die man auch abstellen kann.
Alternative wäre, GStreamer 1.0 verfügbar zu machen.

Ich habe diese Namen heute alle zum ersten mal gelesen, weiß deshalb nicht, wo und wie und brauche ich das überhaupt ?

Wer weiß mehr und kann helfen ?

Konkret gefragt: Wie kommt man an die configure-options des Befehls "sudo pip --no-cache-dir install wxPython==4.0.4" ran, um "--enable-mediactrl" wegzulassen ?

MfG Kai
(der sich fühlt wie einer, der auszog, das Gruseln zu lernen)

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »kaimex« (7. März 2019, 20:10)


Beiträge: 13 148

Registrierungsdatum: 4. April 2004

Wohnort: Meerbusch (bei Düsseldorf)

Beruf: Softwareentwickler

  • Nachricht senden

38

Donnerstag, 7. März 2019, 21:18


Es gibt demnach irgendwo eine configure option --enable-mediactrl, die man auch abstellen kann.
Alternative wäre, GStreamer 1.0 verfügbar zu machen.


Hallo Kai,

wxWidgets ist ein universelles Applikations-Framework, das primär für C++ entwickelt wurde (nutze ich selber gerne für meine privaten Programmierprojekte). wxPython ist die Python-Anbindung dafür.

Ich denke mal, wenn Du wxPython über pip installierst, wird auch versucht, wxWidgets zu bauen, was aber wegen der fehlenden Abhängigkeit nicht gelingt. "--enable-mediactrl" ist ein Parameter des configure-Scripts von wxWidgets. Ob man den von pip aus irgendwie "durchreichen" kann, weiß ich leider nicht (aber starke Tendenz zu "Geht nicht").

Was man machen könnte:

- Versuchen, wxWidgets selber aus dem Quelltext zu bauen (dann kannst Du den Parameter direkt an das Configure-Script übergeben)
- Wenn die passende Version von wxWidgets im Raspian-Repository enthalten ist: Selbige installieren.
- Wie Du schon selber schreibst: Die fehlende Abhängigkeit auflösen, also GStreamer installieren

Alles ohne Gewähr. :)

Gruß,
Timo

Beiträge: 3 751

Registrierungsdatum: 20. Dezember 2015

Wohnort: bei Hamburg

Beruf: Rentner

  • Nachricht senden

39

Donnerstag, 7. März 2019, 22:10

Hallo timo,

es ist so, wie du vermutest:
Vor der langen Liste der configure checks wird in einer Zeile gemeldet:
wxWidgets build options: ['--wxpython', '--umicode', 'gtk3']
configure options: [....eine sehr lange Zeile, die unter anderem --enable-mediactrl enthält.....]
/tmp/pip-build--Smf0ej/wxPython/ext/wxWidgets/configure ....hier steht noch mal die gleiche Optionsliste ohne Anführungsstriche, Kommas & eckige Klammern....
und dann kommt einen ellenlange Liste über mehrere Seiten mit checking Meldungen.
Wenn es gelänge, bei den configure options das --enable-mediactrl wegzulassen, würde garnicht nach GStreamer gecheckt.
Das GStreamer Paket ist irgendwas für die Verarbeitung von Video-Streams, was ich sicherlich nicht brauche. Bei einem 69 MB großen komprimierten Grafik-Paket habe ich ohnehin den Verdacht, daß da massenweise Zeugs drin ist, was ich nicht brauchen werde.
Wenn du noch eine Idee hast, wie/was ich downloaden müßte und wie man die Installation in einzelne Schritte zerlegen könnte, sodaß dabei einmal Zugriff auf diese configure-options entsteht, würde ich das gerne ausprobieren. Ansonsten habe ich dieses Buch erstmal beiseite gelegt und blättere jetzt eines der anderen drei durch auf der Suche nach der Erlösung von dem Übel...

MfG Kai

40

Donnerstag, 7. März 2019, 22:19

Hallo Kai,

ich würde im "Makefile" nach "--enable-mediactrl" suchen und den String löschen. Also ordentlich vorher Makefile nach Makefile.orig kopieren, dann suchen und löschen ;)

Gruß
Michael

Beiträge: 3 751

Registrierungsdatum: 20. Dezember 2015

Wohnort: bei Hamburg

Beruf: Rentner

  • Nachricht senden

41

Freitag, 8. März 2019, 00:00

Hallo Mchael,

würd ich gerne tun.
Wie lade ich dazu aber erstmal alles runter, ohne die Installation anzuschmeißen und wie werfe ich die Installation nach Modifikation dann an ?
Damit bin ich ja bislang nicht vertraut als Nicht-Linuxer.
Irgendwo stand was von wget .... und einer anderen Möglichkeit.
Aber wenn man das bisher fast noch nie gemacht hat, würde man lieber eine Schritt für Schritt-Anleitung abarbeiten als ins Ungewisse zu stolpern.

MfG Kai

Beiträge: 3 751

Registrierungsdatum: 20. Dezember 2015

Wohnort: bei Hamburg

Beruf: Rentner

  • Nachricht senden

42

Freitag, 8. März 2019, 00:51

Gerade hatte ich mich entschlossen, lieber etwas Überflüssiges wie GSTreamer 1.0 zu installieren, als in eine komplexe Installation einzugreifen.
Also habe ich die Synaptic-Paketverwaltung gestartet und nach gstreamer suchen lassen.
Gefunden wurde einges bereits Installiertes von gestreamer 0.10 und zu meiner großen Verwunderung auch Installertes von gstreamer 1.0 und in der Form libgstreamer 1.0. Allerdings gibt es auch etliche gstreamer 1.0 items, die nicht als installiert markiert sind.
Es könnte also sein, daß gstreamer 1.0 installiert ist, aber von der Installationsroutine von wxWidgets bzw. wxPython nicht gefunden wird,
Was kann man da tun ?
Kann ich die vermeintliche Installation mit irgendeinem Befehl auf Wirksamkeit überprüfen ?

MfG Kai

Beiträge: 13 148

Registrierungsdatum: 4. April 2004

Wohnort: Meerbusch (bei Düsseldorf)

Beruf: Softwareentwickler

  • Nachricht senden

43

Freitag, 8. März 2019, 09:14

Hallo Kai,

die Debian-basierten Distributionen trennen bei Bibliotheken zwischen Binär- und Entwicklerpaket. Ein "normaler" Anwender braucht nur erstes. Das zweite enthält die Header-Dateie, um selber Quelltext compilieren zu können, der die Bibliotheken nutzt. Dir fehlt wahrscheinlich letztes.

Die Entwicklerpakete tragen das Suffix -dev. Guck' mal, ob es sowas wie libgstreamer-1.0-dev o.Ä. gibt.

Gruß,
Timo

Beiträge: 3 751

Registrierungsdatum: 20. Dezember 2015

Wohnort: bei Hamburg

Beruf: Rentner

  • Nachricht senden

44

Freitag, 8. März 2019, 14:28

Hallo timo,

ich hab mal einen Screenshot aus der Synaptic-Paketverwaltung von allen Einträgen mit libgstreamer gemacht.
Die links grün markierten sind installiert. Die ...-dev sind nicht darunter.

Mir war jetzt nicht klar, ob die beiden unteren markierten Einträge als Installation von gstreamer 0.1 und gstreamer 1.0 zu interpretieren sind und die Voraussetzzungen für erfolgreiche Installation von wxPython/wxWidgets erfüllen sollten.
Für irgendwas wird gstreamer doch anscheinend schon genutzt, sonst hätte man die markierten Teile doch nicht installieren müssen.
Würde ein Test aufschlußreich sein oder hilft hier nur Installation der -dev Versionen ?
Falls letzteres angezeigt ist, was soll ich befehlen ?

MfG Kai

Beiträge: 13 148

Registrierungsdatum: 4. April 2004

Wohnort: Meerbusch (bei Düsseldorf)

Beruf: Softwareentwickler

  • Nachricht senden

45

Freitag, 8. März 2019, 15:03

Probier' mal, die libgstreamer1.0-dev zu instaliieren und dann noch mal zu compilieren. Das Paket ist nicht groß, sind ja nur ein paar .h-Dateien. Kannst Du theoretisch sogar nach der Compilierung wieder deinstallieren.

Beiträge: 3 751

Registrierungsdatum: 20. Dezember 2015

Wohnort: bei Hamburg

Beruf: Rentner

  • Nachricht senden

46

Freitag, 8. März 2019, 16:12

Hallo timo,

hab ich mit der Synaptic-Paketverwaltung gemacht (waren etwas mehr als 8 MB).
Wurde anscheinend erfolgreich durchgeführt.
Danach habe ich wieder
sudo pip --no-cache-dir install wxPython==4.0.4
befohlen.
Es schien zunächst erfolgreicher abzulaufen, nach geraumer Zeit kam jedoch wieder der Abbruch wegen nicht gefundenem GStreamer:
checking for GST... configure: WARNING: GStreamer 1.0 not available, falling back to 0.10
checking for GST... configure: WARNING: GStreamer 0.10 not available, falling back to 0.8
configure: WARNING: wxMediaCtrl can't be built because GStreamer not available
configure: error: wxMediaCtrl was explicitly requested but can't be built.

Fix the problems reported above or don't use --enable-mediactrl configure option.

Error running configure
ERROR: failed building wxWidgets
Traceback (most recent call last):
File "build.py", line 1321, in cmd_build_wx
wxbuild.main(wxDir(), build_options)
File "/tmp/pip-build-v3f6EA/wxPython/buildtools/build_wxwidgets.py", line 375, in main
"Error running configure")
File "/tmp/pip-build-v3f6EA/wxPython/buildtools/build_wxwidgets.py", line 85, in exitIfError
raise builder.BuildError(msg)
BuildError
Finished command: build_wx (1m3.908s)
Finished command: build (1m3.908s)
Command '"/usr/bin/python" -u build.py build' failed with exit code 1.

Sollte ich libgstreamer1.0-dev auf andere Weise installieren ?
Oder kann man einen Pfad so setzen, daß die (wahrscheinlich für mich überflüssige) Installation von wxmediaCtrl es erkennt ?

MfG Kai

Beiträge: 3 751

Registrierungsdatum: 20. Dezember 2015

Wohnort: bei Hamburg

Beruf: Rentner

  • Nachricht senden

47

Freitag, 8. März 2019, 23:24

Da bei wxWiki unter wxMediaCtrl steht:
"To build wxWidgets with wxMediaCtrl enabled on linux (gstreamer 0.10) libgconf2-dev and libgstreamer0.10-dev are required."
habe ich libgconf2-dev und libgstreamer0.10-dev über die Synaptic-Paketverwaltung installiert.
Wo ich schon mal da drin war, hab ich auch noch etwas mit Namen wxPython 3.x installieren lassen 8) .
Das kündigte das erforderliche Runterladen von (nur) 21.4 MB an und hat das schneller gemacht, als normal. Auch die Installation war fast ratzt fatz fertig.
2 Test-Programme aus dem Raspi GPIO Buch brachten allerdings kein Window auf das Display.
Deshalb hab ich nach Grafik-Test-Programmen im Netz gesucht und stattdessen die "wxPyWiki Getting Started" gefunden.
4 Test-Beispiele von da brachten tatsächlich Programm-Windows aufs Display, die allerdings recht schlicht, total flach und unfarbig (nur getönt) aussahen.
Deshalb hab ich gedacht, das muß doch noch etwas schöner gehen. Also nochmal versucht, wxPython 4.0.4 zu installieren.
Vorher allerdings noch"den Hof geputzt" mit
sudo apt-get update
sudo apt-get upgrade (das dauerte ziemlich lange)
sudo apt-get autoclean
sudo apt-get autoremove
und dann wieder
sudo pip --no-cache-dir install wxPython==4.0.4
Die Routine meldete bald danach: found existing installation 3.0.2.0
not uninstalling....
und brach dann nach einiger Zeit wieder ab wegen fehlendem GStreamer 1.0 und 0.1 .
Da steckt also irgendwo der Wurm drin. Aber immerhin sieht es so aus, als sei nun wxPython 3.0.2.0 installiert.

MfG Kai

Beiträge: 415

Registrierungsdatum: 25. Mai 2007

Wohnort: Landau/Pf.

Beruf: Physiker

  • Nachricht senden

48

Samstag, 9. März 2019, 12:49

Hallo Kai,

ich habe vorhin mal probiert, bei mir (nicht auf dem Raspi, sondern auf dem Desktop-Rechner unter Ubuntu 16.04) wxPython 4.0.4 zu installieren - und hatte ebenfalls keine erfreulichen Erlebnisse.

Nachdem ich über den Paketmanager libgstreamer-1.0-dev und libgstreamer-plugins-base1.0-dev nachinstalliert hatte, war der configure-Vorgang erfolgreich, und der Build hat gestartet. Einige Zeit (>30min) hat er munter vor sich hin compiliert, und ist dann mit einer Fehlermeldung ausgestiegen, die wieder darauf hindeutet, dass dem Linker irgendwo eine Bibliothek fehlt:

Quellcode

1
    /usr/bin/ld: cannot find -lwx_gtk3u_webview-3.0


Auf dem Raspberry Pi hätte das sicher noch deutlich länger gedauert.

Da stellt sich wxPython ganz schön blöd an - normalerweise gibt es ja inzwischen auch für Python-Pakete mit C/C++-Anteil binärpakete als "wheels", die dann einfach nur heruntergeladen werden müssen. Es gibt aber einen länglichen Artikel, warum das in diesem Fall nicht gehen soll: https://wxpython.org/blog/2017-08-17-bui…-pip/index.html. Das Problem scheint ihnen also bewusst zu sein. Naja.

Nächste Möglichkeit (und normalerweise meine bevorzugte) ist, mal beim Paketmanager der Distribution zu schauen. Bei mir (offenbar auch bei Dir) gibt es hier Version 3 (genauer: python-wxgtk3.0). Manchmal gibt es dann noch Fremd-Repositories, wo jemand neuere Software genau für die entsprechende Distribution compiliert hat. Bei Ubuntu heißen die "PPA", oft gibt es auch den Begriff "backport". In meinem Fall (also für Ubuntu) gäbe es das: https://launchpad.net/~swt-techie/+archive/ubuntu/wxpython4. Hab ich nicht ausprobiert, geht aber normal problemlos. Eine Entsprechung für Raspbian habe ich allerdings auf die Schnelle nicht gesehen.

Fazit: Bleib bei Version 3, es wird den Ärger nicht wert sein. Solche Probleme bei der Installation sind auch immer ein guter Grund, sie die Konkurrenz näher anzusehen. In diesem Fall (GUI-Toolkits mit Python-Bindings) wären das sicher QT und GTK. Davon bevorzuge ich letzteres; Geschmacksfrage.

Und noch ein Hinweis: Mir hat damals als Kickstart zum Zurechtfinden in Python mit C++/C/Perl/Basic-Hintergrund, ohne nochmal Programmieren von A-Z erklärt zu bekommen, dieses (online verfügbare) Buch sehr gut gefallen: https://www.diveinto.org/python3/index.html

Viele Grüße
Andreas

Beiträge: 3 751

Registrierungsdatum: 20. Dezember 2015

Wohnort: bei Hamburg

Beruf: Rentner

  • Nachricht senden

49

Samstag, 9. März 2019, 14:53

Hallo Andreas,

bei mir scheiterte es ja noch im configure Vorgang. Es dauerte etwas, waren aber höchstens gefühlte Minuten.
Strapazieren die anderen GUI-Versionen die Raspi CPU deutlich mehr als wx-... ?
Man muß es ja in Sachen 3D-Effekte im Fensterrahmen nicht übertreiben, nur weil man mal in einer GUI eine Kurve plotten will.
Welche Version benutzt du bei deinen python-scripts mit Kurven-Grafik ?
Würde eines davon unter wx-Python laufen ?
Hattest du auch ein UMC202HD (behringer) o.ä. angeschafft ?
Dann würde ich glatt mal prüfen, ob das ohne spezielle Treiber an dem Raspi läuft.

Im Moment versuche ich gerade, die rpi_hal Unit/Bibliothek für FPC/Lazarus zum Laufen zu bringen. Die hat leider einen Stand von vor 2 Jahren. Der Raspi 3B+ ist noch nicht unterstützt. Das versuche ich gerade selbst hinzukriegen, da der Autor sich bislang nicht dazu gemeldet hat.

MfG Kai

Beiträge: 13 148

Registrierungsdatum: 4. April 2004

Wohnort: Meerbusch (bei Düsseldorf)

Beruf: Softwareentwickler

  • Nachricht senden

50

Samstag, 9. März 2019, 20:13

Strapazieren die anderen GUI-Versionen die Raspi CPU deutlich mehr als wx-... ?


Hallo Kai,

eher nicht. wxWidgets bringt normalerweise [*] keine eigenen GUI-Elemente mit, sondern fungiert als Frontend für irgendeine plattformtypische Schnittstelle (also ziemlich genau das, was die LCL von Lazarus auch tut). Unter Unix-artigen Betriebssystemen ist das inzwischen normalerweise gtk2 oder gtk3 (das dürfte also auch auf dem RPi der Fall sein), unter OS X Cocoa, und unter WIndows halt die Windows-API. Somit kann es eigentlich nicht schneller oder ressourcenschonender sein als das, was dahintersteckt.

[*] Es gibt auch eine Variante namens wxUniversal, die eigene Steuerelemente implentiert, aber m.W. kaum eingesetzt wird.

Wenn man unter Python nur Basis-Funktionalität in Sachen Benutzerschnittstelle braucht, tut es eigentlich die De-Facto-Standard-Bibliothek tkinter, die bei Python für Windows sogar immer schon mitinstalliert wird. Obwohl ich eigentlich seit > 15 Jahren unter C++ wxWidgets einsetze, habe ich mich, wenn ich unter Python mal einen Dialog brauchte, immer damit begnügt.

Gruß,
Timo

Beiträge: 3 751

Registrierungsdatum: 20. Dezember 2015

Wohnort: bei Hamburg

Beruf: Rentner

  • Nachricht senden

51

Samstag, 9. März 2019, 22:00

Hallo timo,

Wenn man unter Python nur Basis-Funktionalität in Sachen Benutzerschnittstelle braucht, tut es eigentlich die De-Facto-Standard-Bibliothek tkinter
wie wechselt man dann "mal eben" von zB gtk3 zu tkinter ?
Ist das Sache eines Befehls, einer Installation,
oder eines Bezuges a la tkinter.dialog ?

MfG Kai

Beiträge: 13 148

Registrierungsdatum: 4. April 2004

Wohnort: Meerbusch (bei Düsseldorf)

Beruf: Softwareentwickler

  • Nachricht senden

52

Samstag, 9. März 2019, 23:01

wie wechselt man dann "mal eben" von zB gtk3 zu tkinter ?
Ist das Sache eines Befehls, einer Installation,
oder eines Bezuges a la tkinter.dialog ?i


"Mal eben" geht nicht. Ist halt eine ganz andere Bibliothek, mit anderen Steuerelementen, Klassen und Methoden. Hilft Dir jetzt also nicht weiter.

Beiträge: 415

Registrierungsdatum: 25. Mai 2007

Wohnort: Landau/Pf.

Beruf: Physiker

  • Nachricht senden

53

Sonntag, 10. März 2019, 15:05

Hallo Kai,

Welche Version benutzt du bei deinen python-scripts mit Kurven-Grafik?

da bin ich sehr altmodisch: Meine Skripte erzeugen normalerweise Text-Files mit Messwerten, die ich dann ganz einfach mit gnuplot darstelle. Modernerweise macht man sowas gerne mit der Matplotlib, oder auch in einem Jupyter Notebook (Quasi ein Laborbuch im Browser, mit Code-Schnipseln und Plots als Ergebnissen. Sehr nützlich!).

Interaktive GUI-Anwendungen, die dann gemessene Werte auch noch live plotten, habe ich bisher nicht geschrieben. Es juckt mich aber immer wieder in den Fingern (Aussteuerungsmesser, virtuelles Millivoltmeter als Einmesshilfe, etc.). Dazu würde ich, wie gesagt, am ehesten GTK oder QT verwenden; mangels Erfahrung kann ich aber noch nicht viel dazu sagen. Bisher habe ich nur gesehen, dass man dann die Grafik meistens ganz zu Fuß aus Linien und Punkten erzeugt, z.B. mit Cairo direkt ins Fenster.

Wenn also jemand hier einen guten Hinweis hat, würde er mich sehr interessieren :)

wie wechselt man dann "mal eben" von zB gtk3 zu tkinter?

Schau am besten mal in die verlinkten Tutorials, dann bekommst Du schnell einen Eindruck, wie die Toolkits funktionieren, und was sie unterscheidet. Es gibt sehr viele davon: https://de.wikipedia.org/wiki/Liste_von_GUI-Bibliotheken.

Viele Grüße
Andreas

Beiträge: 3 751

Registrierungsdatum: 20. Dezember 2015

Wohnort: bei Hamburg

Beruf: Rentner

  • Nachricht senden

54

Sonntag, 10. März 2019, 18:33

Wenn es mehr Einarbeitung erfordert, übersteigt es mein momentanes Interesse. Wenn es mit einem "Switch" getan wäre, würde ich es erwägen.
Wenn man all diese Software-Möglichkeiten erkunden wollte, würde man das ursprüngliche Ziel völiig aus dem Auge verlieren.
Das ist im Moment, diverse ADC- & DAC-Bausteine und eventuell mehr (zB DDS) am GPIO des Raspi mit geringem Hardware- und Software-Aufwand zum Laufen zu kriegen, um damit nützliche kleine Meßsysteme zu realisieren

MfG Kai

Beiträge: 13 148

Registrierungsdatum: 4. April 2004

Wohnort: Meerbusch (bei Düsseldorf)

Beruf: Softwareentwickler

  • Nachricht senden

55

Sonntag, 10. März 2019, 18:44

Wenn man all diese Software-Möglichkeiten erkunden wollte, würde man das ursprüngliche Ziel völiig aus dem Auge verlieren.


Schön, daß Du das schreibst. Ich staune schon seit vorgestern, an wie vielen Baustellen Du gleichzeitig werkelst. :)

Hast Du denn schon irgendwas über GPIO gesteuert? Sonst mach' doch erst mal ein kleines Testprogramm ohne GUI. Und wenn Du danach eine kleine Oberfläche brauchst und es nicht unbedingt zu den Beispielen in dem Buch passen muss, dann probier' mal Tkinter. Das ist wirklich ohne Klimmzüge zu installieren, Paket "python-tk" für Python 2.7 bzw. "python3-tk" für Python 3.x mit apt oder Synaptic, und gut ist. Eine Einführung findest Du z.B. hier:

https://www.python-kurs.eu/python_tkinter.php

Beiträge: 3 751

Registrierungsdatum: 20. Dezember 2015

Wohnort: bei Hamburg

Beruf: Rentner

  • Nachricht senden

56

Sonntag, 10. März 2019, 21:16

Ich staune schon seit vorgestern, an wie vielen Baustellen Du gleichzeitig werkelst.
Je mehr ?Eisen man im? Feuer ?man unter dem Hintern? hat, um so weniger langweilig ist es. Außerdem ist es natürlich der Produktion von "Unvollendeten" förderlich. Aber da bin ich Beethoven sowieso schon weit voraus.
Im Moment probiere ich alles, was bei Lazarus über Raspi & GPIO steht, weil mir Pascal & Delphi am vertrautesten snd. Da laß ich auch schon LEDs an und ausgehen, geschaltet und per PWM. Als nächstes sollen ADC-Ergebnisse 16 Bitweise per I2C gelesen werden. Python mach ich nur, wenn es viel einfacher wird. Es gab im vorigen Jahrhundert eine Phase in der Computer-Nutzung, in der sehr auf Interpreter-Sprachen wie Basic herabgesehen wurde. Ein ordentlicher Programmierer benutzte sowas nicht. Zur Zeit gibt es diverse Interpreter-Sprachen, die professionell und mit der Ausrede "Produktivitäts-Tools" benutzt werden. Die seit damals vervielfachte Rechenleistung der Computer macht es möglich, damit auf Geschwindigkeiten ähnlich damals compilierter Sprachen zu kommen. Die Bequemlichkeit der Programmierer und die "Fettleibigkeit"/Überfrachtung der Sprach-Pakete/Bibliotheken mit Dingen, die man vielleicht mal gebrauchen könnte, verbrennt die hohe Verarbeitungsgeschwindigkeit moderner PCs in beträchtlichem Umfang.
Ich hab verdutzt geguckt, als ein kleines mit Lazarus erzeugtes Programm auf der Disk ca. 23 MB in Beschlag nahm. In den letzten Jahren mit Delphi 7 erstellte deutlich umfangreichere Audio- oder Foto-Tools blieben bislang in der 1 MB Region. Wenn ich "Smart-Linking" aktivere, schrumpt das Programm auf ca. 17 MB, wenn ich sämtlichen Debug-Code abschalte, sind es noch 2,4 MB. Besonders smart scheint das Linking immer noch nicht zu sein.
Wahrscheinlich wieder eine Folge der Bequemlichkeit von Compiler und Linker Programmierern nach dem Motto, Speicher ist doch genug da.
Bevor es mir vor Monaten nach etlichen Mühen gelang, mein (recht) altes MATLAB auf dem neuesten PC unter Windows 7 zu installieren, hab ich darauf einige Zeit lang Octave benutzt. Unter anderem auch zur Bearbeitung von Audio-Files oder zum Test von Algorithmen, bevor ich sie in Delphi programmiert habe. Da fiel mir auf, daß das Einlesen größerer Audio-Files (in Blöcken a 8 oder 16 K) unter Octave etwa 100-mal langsamer war als unter MATLAB auf einem Windows XP LapTop. Ein File von CD-Größe führte nach geraumer Zeit immer zu Abbruch-Meldungen. Es stellte sich schließlich als Ursache heraus, daß MATLAB tatsächlich immer nur die bestellte Blockgröße einlas, während Octave jedesmal den ganzen File in den Speicher lud und zwar wie unter MATLAB üblich, jedes Sample als double-float. Das ging bei 700 MB Originalgröße natürlich nicht gut. Es kostete mich einige Überzeugungsarbeit, den Bearbeitern der Bugreports bei Octave den Unfug klar zu machen. Begeisterung und Dank schlugen mir nicht entgegen.

MfG Kai

Beiträge: 13 148

Registrierungsdatum: 4. April 2004

Wohnort: Meerbusch (bei Düsseldorf)

Beruf: Softwareentwickler

  • Nachricht senden

57

Montag, 11. März 2019, 22:26

Es gab im vorigen Jahrhundert eine Phase in der Computer-Nutzung, in der sehr auf Interpreter-Sprachen wie Basic herabgesehen wurde. Ein ordentlicher Programmierer benutzte sowas nicht.


Mir war der Gedanke, Code wieder interpretieren statt compilieren zu lassen, auch lange Zeit suspekt. Irgendwie war das in meinem Empfinden ein Rückfall in das düstere Heimcomputer-Zeitalter. Allerdings habe ich mich inzwischen der Einsicht gebeugt, daß es für Anwendungen, wo Ausführungsgeschwindigkeit keine besondere Priorität hat und der Code nicht vor Einsicht geschützt werden muss, mitunter einfach praktischer ist. Man spart bei der Entwicklung Zeit und ist plattformunabhängig.

Zitat

Wahrscheinlich wieder eine Folge der Bequemlichkeit von Compiler und Linker Programmierern nach dem Motto, Speicher ist doch genug da.


Na ja, die Entwicklerkapazitäten von FreePascal und Lazarus sind vermutlich im Vergleich zu denen von gcc oder llvm/clang sehr begrenzt, da muss man Prioritäten setzen. Es ist nun mal tatsächlich so, daß die Größe der Compilate ja nicht mehr so ein kritischer Faktor ist, deswegen steht das wahrscheinlich eher unten auf der Liste.

Beiträge: 3 751

Registrierungsdatum: 20. Dezember 2015

Wohnort: bei Hamburg

Beruf: Rentner

  • Nachricht senden

58

Freitag, 15. März 2019, 14:27

Kennt sich jermand gut mit den diversen System-Takten auf den neueren Raspi Versionen aus ?

Ich habe die befremdliche Beobachtung gemacht, daß der Clock des I2C-Bus abhängig ist vom dem dynamisch gestalteten CPU-Clock (oder einem anderen System-Clock).
Default-mäßig soll der I2C Takt 100 kBaud sein. Ich messe bei niedriger CPU-Last eine Takt-Perioden-Dauer von 16 us (~ 60 kBaud). Der cpuinfo_cur_freq Befehl meldet dann 600 MHz. Wird die CPU-Last höher ( zB durch ein zu scrollendes Window oder eine per Browser betrachtete Live-Web-Cam oder ein YouTube-Video) meldet cpuinfo_cur_freq 1400 MHz und ich messe eine I2C Takt Periode von nur noch 10 us (100 kBaud). 1400/600=2.333 während 16/10=1.6, ist also nicht ganz dasselbe. Konfiguriere ich die Baudrate in /boot/config.txt auf 200000, dann messe ich 8 us (125 kBaud) bei kleiner CPU-Last und 5 us (200 kBaud) bei höherer CPU-Last. Wenn eine Baudrate von 400000 "bestellt" ist, messe ich 4 us (250 kBaud) bzw. 2.5 us (400 kBaud). Es bleibt also immer bei dem Verhältnis von 1.6 (= 8/5 bzw 4/2.5).
Man hat hier also den unerwarteten Effekt, das eine hohe CPU-Last in einem anderen Thread I2C-Transfers beschleunigt.
Gibt es einen System-Takt, der gerade um dieses Verhältnis geändert wird ?
Kann man irgendwo einstellen, daß der I2C-Takt immer gleich dem nominellen Wert ist, auch wenn der CPU-Takt dynamisch verwaltet wird ?

MfG Kai

Beiträge: 3 751

Registrierungsdatum: 20. Dezember 2015

Wohnort: bei Hamburg

Beruf: Rentner

  • Nachricht senden

59

Samstag, 16. März 2019, 13:15

Nach etwas Wühlerei im Netz hab ich dies gefunden:
https://haydenjames.io/raspberry-pi-3-overclock/
Zitat:
The default idle config for the Raspberry Pi 3 board is arm_freq=600 and core_freq=250.
....
max defaults which are arm_freq=1200 and core_freq=400."

Danach läuft beim Raspberry Pi 3B+ unter "idle conditions" (nicht viel zu tun) , die ARM CPU mit 600 MHz und die GPU mit 250 MHz.
Ab einer gewissen CPU/GPU-Last wird auf arm_freq = 1400 MHz umgeschaltet und core_freq (GPU) auf 400 MHz.
Wenn die CPU einen gesetzten Temperatur-Limit überschreitet, wird ihr Takt wieder herabgesetzt auf 1200 MHz oder weniger.
1400/600 = 2,333 , 400/250=1.6.
Demnach sieht es so aus, als wäre der I2C-Takt mit einem festen Faktor an die core_freq gekoppelt.
So steht es auch in dem Dokument "BCM2835-ARM-Peripherals.pdf". Allerdings wir dort ein "core clock" von 150 MHz genannt. Das bezieht sich aber wohl auf eine ältere Raspi Version.

MfG Kai
Nachtrag: Inzwischen habe ich gefunden, daß es einen (Over- ) clocking parameter namens "core_freq_min" gibt. Vermutlich läßt sich konstante I/O-Geschwindigkeit (UART, SPI, I2C) erreichen, indem man in /boot/config.txt core_freq_min auf den Wert von core_freq setzt (Default ist 400 beim Raspi 3B+). Unklar ist, ob man dadurch die Garantie für den Prozessor verliert.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »kaimex« (16. März 2019, 19:20)