TX-Pi, Raspberry Pi Community-Controller

Community-Firmware (cfw), Selbstbaucontroller (TX-Pi, ftduino, usw.), usw.
Forumsregeln
Bitte beachte die Forumsregeln!
Benutzeravatar
PHabermehl
Beiträge: 1907
Registriert: 20 Dez 2014, 22:59
Wohnort: Bad Hersfeld

Re: TX-Pi, Raspberry Pi Community-Controller

Beitrag von PHabermehl » 01 Sep 2020, 22:58

https://www.MINTronics.de -- der ftDuino & TX-Pi Shop!

viele Grüße
Peter

tintenfisch
Beiträge: 186
Registriert: 03 Jan 2018, 22:04

Re: TX-Pi, Raspberry Pi Community-Controller

Beitrag von tintenfisch » 02 Sep 2020, 07:47

PHabermehl hat geschrieben:
01 Sep 2020, 22:58
Hier das issue in GitLab: https://gitlab.com/Humpelstilzchen/libr ... -/issues/4
Sollte nun funktionieren (nicht ausprobiert, aber sieht gut aus):

https://gitlab.com/Humpelstilzchen/libr ... 004acd4f2c

Viele Grüße
Lars

kräml
Beiträge: 33
Registriert: 14 Aug 2020, 06:47

Re: TX-Pi, Raspberry Pi Community-Controller

Beitrag von kräml » 03 Sep 2020, 16:35

Hallo,

danke für das Issue. Hab es auch gerade endeckt. Der Build-Prozess läuft bei mir durch und das FT-Skript ist ok. :D

Einen Vorschlag hätte ich noch zum Deaktivieren "wait for network" in den Boot Options. Mit folgende Code

Code: Alles auswählen

sudo raspi-config nonint do_boot_wait 1
kann das wait for network deaktiviert werden. Dann braucht man dies nicht mehr mit raspi-config einstellen. Oder anders ausgedrückt, der User kann dies nicht mehr vergessen.

Übrigens mit

Code: Alles auswählen

sudo raspi-config nonint do_hostname tx-pi
kann auch der Hostname gesetzt werden. Dies wäre gut, wenn man das Image vollautomatisch erstellen möchte.

Weitere raspi-config hacks findet man hier

https://raspberrypi.stackexchange.com/q ... nfig-setup

Gruß kraeml

tintenfisch
Beiträge: 186
Registriert: 03 Jan 2018, 22:04

Re: TX-Pi, Raspberry Pi Community-Controller

Beitrag von tintenfisch » 03 Sep 2020, 19:44

Hallo,
kräml hat geschrieben:
03 Sep 2020, 16:35
[...]
Einen Vorschlag hätte ich noch zum Deaktivieren "wait for network" in den Boot Options. Mit folgende Code

Code: Alles auswählen

sudo raspi-config nonint do_boot_wait 1
Das ist eine gute Idee, wir hatten das auch mal auf der ToDo-Liste, ist jedoch irgendwie hintenüber gefallen.

kräml hat geschrieben:
03 Sep 2020, 16:35
[...]

Code: Alles auswählen

sudo raspi-config nonint do_hostname tx-pi
kann auch der Hostname gesetzt werden. Dies wäre gut, wenn man das Image vollautomatisch erstellen möchte.
Ich bin nicht 100% überzeugt, dass das eine gute Idee ist. Zumindest sollten wir zuvor überprüfen, ob der Hostname bereits geändert wurde,
bevor wir so eine Änderung, die u.a. Konsequenzen für ein Netzwerk haben kann, machen und die Anwender damit nicht "überraschen".
Über die Config-App können die Anwender den Hostname leicht ändern. M.E. ist das ausreichend; aber wir zanken, äh, diskutieren das hinter den Kulissen. ;)

Viele Grüße
Lars

kräml
Beiträge: 33
Registriert: 14 Aug 2020, 06:47

Re: TX-Pi, Raspberry Pi Community-Controller

Beitrag von kräml » 15 Sep 2020, 10:11

Hallo,

hab soeben das TX-PI Gehäuse ausgedruckt. Bin jetzt auf der Suche nach den Senkkopfschrauben hierzu. Wollte heute mal im Baumarkt schauen ob es dort 2,6mm Holzschrauben gibt.

Wie habt ihr das Gehäuse verschraubt? Will das gute Teil nicht gleich kaputt machen.

Gruß Kräml

Benutzeravatar
PHabermehl
Beiträge: 1907
Registriert: 20 Dez 2014, 22:59
Wohnort: Bad Hersfeld

Re: TX-Pi, Raspberry Pi Community-Controller

Beitrag von PHabermehl » 15 Sep 2020, 10:37

kräml hat geschrieben:
15 Sep 2020, 10:11
Hallo,

hab soeben das TX-PI Gehäuse ausgedruckt. Bin jetzt auf der Suche nach den Senkkopfschrauben hierzu. Wollte heute mal im Baumarkt schauen ob es dort 2,6mm Holzschrauben gibt.

Wie habt ihr das Gehäuse verschraubt? Will das gute Teil nicht gleich kaputt machen.

Gruß Kräml
Hallo Kräml,

Schreck lass nach, da sagst Du 'was. Nirgendwo ist das auf der Webpage erwähnt. Wir haben normale M2,5 x 15 Senkkopfschrauben verwendet (wenn ich es noch richtig weiß), jedenfalls für diese Gehäuse keine Holzschrauben.
Ich frage nochmal im Team nach, auch, damit die Information noch auf die Webseite kommt.

Gruß
Peter
https://www.MINTronics.de -- der ftDuino & TX-Pi Shop!

viele Grüße
Peter

Benutzeravatar
PHabermehl
Beiträge: 1907
Registriert: 20 Dez 2014, 22:59
Wohnort: Bad Hersfeld

Re: TX-Pi, Raspberry Pi Community-Controller

Beitrag von PHabermehl » 15 Sep 2020, 11:00

Also, zu den Gehäuseschrauben: M2,5x12 war's

Wird auch auf der HP nachgetragen.
https://www.MINTronics.de -- der ftDuino & TX-Pi Shop!

viele Grüße
Peter

kräml
Beiträge: 33
Registriert: 14 Aug 2020, 06:47

Re: TX-Pi, Raspberry Pi Community-Controller

Beitrag von kräml » 22 Sep 2020, 11:59

Hallo,

das Gehäuse ist fertig und die Schrauben passen.

THX

Kräml

Benutzeravatar
PHabermehl
Beiträge: 1907
Registriert: 20 Dez 2014, 22:59
Wohnort: Bad Hersfeld

Re: TX-Pi, Raspberry Pi Community-Controller

Beitrag von PHabermehl » 22 Sep 2020, 14:37

kräml hat geschrieben:
22 Sep 2020, 11:59
Hallo,

das Gehäuse ist fertig und die Schrauben passen.

THX

Kräml
Fein! Viel Spaß und lass 'was von Dir hören!

Peter
https://www.MINTronics.de -- der ftDuino & TX-Pi Shop!

viele Grüße
Peter

Mahlzeit
Beiträge: 20
Registriert: 06 Sep 2020, 10:40

Re: TX-Pi, Raspberry Pi Community-Controller

Beitrag von Mahlzeit » 22 Okt 2020, 14:49

Kann man i2c-0 (dtparam=i2c_vc=on) nur unter Raspian aktivieren? Ich habe es mit ubuntu 18 und 20 versucht. Pi/userland + raspi-config konnte man noch ohne größere Probleme nachinstallieren, i2c aktivieren und die anderen raspi-config Funktionen nutzen geht auch, aber alles was ich in /boot/config.txt schreibe scheint er zu ignorieren.

Da ich das mit den quaternionen nicht richtig verstanden habe möchte ich gerne statt dem bmx055 einen bno055 einsetzen. Dafür müsste man aber den i2c clock stretching bug umgehen indem man auf dem rpi4 die entsprechenden pins einem der neuen i2c Controller zuweist. dtoverlay=i2c3,pins_2_3 scheint aber nicht zu funktionieren, wahrscheinlich aus dem gleichen Grund wie oben.

Weiß jemand vielleicht näheres zu einem dieser Punkte? Ansonsten muss wohl doch schon der ftduino her und i2c darüber laufen. Den gibts ja seit kurzer Zeit direkt bei Peter (cool!).

tintenfisch
Beiträge: 186
Registriert: 03 Jan 2018, 22:04

Re: TX-Pi, Raspberry Pi Community-Controller

Beitrag von tintenfisch » 22 Okt 2020, 15:43

Mahlzeit Mahlzeit,
Mahlzeit hat geschrieben:
22 Okt 2020, 14:49
Kann man i2c-0 (dtparam=i2c_vc=on) nur unter Raspian aktivieren? Ich habe es mit ubuntu 18 und 20 versucht. Pi/userland + raspi-config konnte man noch ohne größere Probleme nachinstallieren, i2c aktivieren und die anderen raspi-config Funktionen nutzen geht auch, aber alles was ich in /boot/config.txt schreibe scheint er zu ignorieren.
[...]
Wenn ich es richtig verstanden habe, funktioniert alles mit Raspbian / Raspberry OS, nur wenn Du Ubuntu installierst, geht's nicht?
Welche Vorteile bietet denn Ubuntu gegenüber Rasperrby Pi OS und warum bleibst Du nicht bei Raspbian, wenn alles funktioniert hat? In der Sache kann ich Dir leider nicht helfen, weil ich kein Ubuntu auf dem Raspi ausprobiert habe.

Nach dem Reboot erhälst Du somit kein

Code: Alles auswählen

/dev/i2c-0
Was steht denn in

Code: Alles auswählen

/etc/modprobe.d/raspi-blacklist.conf
?

Viele Grüße
Lars

Benutzeravatar
PHabermehl
Beiträge: 1907
Registriert: 20 Dez 2014, 22:59
Wohnort: Bad Hersfeld

Re: TX-Pi, Raspberry Pi Community-Controller

Beitrag von PHabermehl » 22 Okt 2020, 18:07

Mahlzeit hat geschrieben:
22 Okt 2020, 14:49
Kann man i2c-0 (dtparam=i2c_vc=on) nur unter Raspian aktivieren? Ich habe es mit ubuntu 18 und 20 versucht. Pi/userland + raspi-config konnte man noch ohne größere Probleme nachinstallieren, i2c aktivieren und die anderen raspi-config Funktionen nutzen geht auch, aber alles was ich in /boot/config.txt schreibe scheint er zu ignorieren.

Da ich das mit den quaternionen nicht richtig verstanden habe möchte ich gerne statt dem bmx055 einen bno055 einsetzen. Dafür müsste man aber den i2c clock stretching bug umgehen indem man auf dem rpi4 die entsprechenden pins einem der neuen i2c Controller zuweist. dtoverlay=i2c3,pins_2_3 scheint aber nicht zu funktionieren, wahrscheinlich aus dem gleichen Grund wie oben.

Weiß jemand vielleicht näheres zu einem dieser Punkte? Ansonsten muss wohl doch schon der ftduino her und i2c darüber laufen. Den gibts ja seit kurzer Zeit direkt bei Peter (cool!).

Na Mahlzeit,

da haben wir aber wieder einen Spaß. Eigentlich wollt' ich jetzt nicht antworten, weil ich nicht ganz unvoreingenommen bin. Mein Rat würde aber erstmal dem von Lars folgen. Bleib bei Raspbian auf dem Pi - Du machst Dir das Leben leichter. Natürlich kannst Du auch den Heldentod sterben beim Versuch, ubuntu selbst zu konfigurieren, aber ich sag' mal es wäre schade um Dich.

Gruß
Peter
https://www.MINTronics.de -- der ftDuino & TX-Pi Shop!

viele Grüße
Peter

kräml
Beiträge: 33
Registriert: 14 Aug 2020, 06:47

Re: TX-Pi, Raspberry Pi Community-Controller

Beitrag von kräml » 22 Okt 2020, 21:00

Hallo,

sterbe gerne den Heldentot mit. Ubuntu würde ROS mitbringen und andere Pakete. Wäre schon cool wenn es klappen würde. Werd mich mal umschauen und wenn ich was finde gerne hier posten.

Kräml

Benutzeravatar
PHabermehl
Beiträge: 1907
Registriert: 20 Dez 2014, 22:59
Wohnort: Bad Hersfeld

Re: TX-Pi, Raspberry Pi Community-Controller

Beitrag von PHabermehl » 22 Okt 2020, 21:04

Da spricht nix gegen, außer dass ihr dann bitte einen neuen Thread mit dem Thema "Ubuntu auf dem TX-Pi" aufmacht.

LG Peter
https://www.MINTronics.de -- der ftDuino & TX-Pi Shop!

viele Grüße
Peter

Mahlzeit
Beiträge: 20
Registriert: 06 Sep 2020, 10:40

Re: TX-Pi, Raspberry Pi Community-Controller

Beitrag von Mahlzeit » 23 Okt 2020, 14:14

Ich kam auf Ubuntu weil ich gerne ein SDK/Treiber ausprobieren wollte das/den es im ubuntu repo gibt. Ich hatte versucht das SDK auf dem Raspbian zu installieren, aber da es dort nicht im repo ist, musste man es erst bauen und mit dem cmake gab es da 2 oder 3 (Bildschirme voll mit) Problemchen.. Da dachte ich der Weg i2c auf dem Ubuntu zu konfigurieren wäre bestimmt wesentlich schneller als gegen cmake zu kämpfen. Aber es ist fast alles immer schwieriger als man denkt. Macht ja nix.

Um nicht nur mit der Hardware/Software Schnittstelle zu kämpfen, werde ich jetzt einen ftduino besorgen und dann mit der Kombi pi+ftduino weiter machen und zur Einbindung auf Peters ftduino_direct setzen. Ich habe gesehen, dass man kein pyfirmata oder pyserial braucht und es direkt losgehen kann. Der FTduino wird wohl auch keine Probleme mit i2c clock stretching haben. Das sollte dann doch eigentlich klappen.


Ich sehe jetzt, dass die TX-Pi/Ubuntu Problematik hier am eigentlichen Thema vorbeigeht. Daher nur noch kurz von mir die Rückmeldung zur Frage von Lars bzgl /etc/modprobe.d/raspi-blacklist.conf :

Nutzt man das Ubuntu 20.04 LTS raspi Image dann sind die Dateien:

Code: Alles auswählen

/opt/vc/bin
/etc/modprobe.d/raspi-blacklist.conf
/boot/config.txt
/etc/modules
nach der Installation erstmal alle komplett leer. Trotzdem wird direkt angezeigt:

ls /dev/i2*

Code: Alles auswählen

/dev/i2c-1
ls /dev/spi*

Code: Alles auswählen

/dev/spidev0.0  /dev/spidev0.1
sudo i2cdetect -l

Code: Alles auswählen

i2c-1   i2c             bcm2835 (i2c@7e804000)                  I2C adapter
i2c scheint zu gehen obwohl man nichts dafür getan hat. Wenn man jetzt diese o.g. Dateien irgendwie ändert wie es unter Raspbian möglich ist, bleibt es aber immer bei dem gleichen output der o.g. Befehle. Ubuntu scheint es nicht darauf anzukommen.

Erwartungsgemäß haben die Raspi-config Optionen "enable/disable spi" oder "enable/disable i2c" dann genauso wenig Effekt wie das direkte Ändern der entsprechenden Dateien.

Ich habe auch eine Negativprobe versucht indem ich durch Auskommentieren aller denkbaren i2c settings dann i2c-1 komplett deaktivieren wollte. Auch das hat nicht funktioniert. Egal was ich bisher in die o.g. Dateien geschrieben habe (+reboot), es bleibt immer alles beim Zustand der "out of the box" besteht.

Code: Alles auswählen

modprobe i2c-bcm2708
lsmod zeigt den bcm2708 an. Es scheint alles da zu sein was man braucht.

Mein Gefühl nach 2 Tagen ist, dass das Problem nicht nur mit dem 'device tree' aber auch mit der Diskrepanz zw. upstream/mainline // downstream kernel zu tun haben könnte. Im Mainline Linux Kernel tut sich in Richtung rpi4 etwas. In den Kernel Newsgroups findet neben anderen rpi4 Themen:
Mainline Linux 5.6:
- hwrng: iproc-rng200 - Add support for BCM2711

Mainline Linux 5.7:
- extend pinctrl/gpio driver to support all 58 GPIOs of BCM2711
- add GPIO labels for Raspberry Pi 4 board
VG Dennis

kräml
Beiträge: 33
Registriert: 14 Aug 2020, 06:47

Re: TX-Pi, Raspberry Pi Community-Controller

Beitrag von kräml » 26 Nov 2020, 10:29

Hallo,

wollt nur mitteilen, dass ich den TX-PI-Setup auf einen aktuellen Raspbian-Buster-Image durch geführt habe. Das hat alles gut funktioniert. Das Setupskript läuft durch.

Somit könnte man ggf. eine neues Image für den TX-Pi rausgeben.

Für mich wäre die Frage, kann man das Pinnen des Kernels auf 1.20200512-2 demnächst weg lassen oder muss es wegen dem Display gesetzt werden. Mich würde es freuen, wenn ich auf einen aktuellen Kernel arbeiten könnte. Hat da schon jemand Erfahrung oder kann ich da auf einem "Green Field" anfangen.

OT: Hab den TX-PI als homeassistant und esphome Server eingerichtet. Somit lassen sich FT via WeFish schön im Browser auswerten. Mach hierzu mal einen eigenen Thread auf.

@Mahlzeit. Danke für das posten, das mit Ubuntu werde ich mir auch gerne mal anschauen. Ubuntu 20.10 verwendet das gleiche Setup wie Raspbian. Vielleicht klappt es dann.

Gruß Michl

tintenfisch
Beiträge: 186
Registriert: 03 Jan 2018, 22:04

Re: TX-Pi, Raspberry Pi Community-Controller

Beitrag von tintenfisch » 26 Nov 2020, 11:24

Hi Michl,
kräml hat geschrieben:
26 Nov 2020, 10:29
[...]
Für mich wäre die Frage, kann man das Pinnen des Kernels auf 1.20200512-2 demnächst weg lassen oder muss es wegen dem Display gesetzt werden. Mich würde es freuen, wenn ich auf einen aktuellen Kernel arbeiten könnte. Hat da schon jemand Erfahrung oder kann ich da auf einem "Green Field" anfangen.
Du könntest das Anpinnen herausnehmen und versuchen, ob das mit einem neueren Kernel funktioniert. Wir hatten mit dem damals aktuellen Kernel Probleme mit den Touchdisplays (einige reagierten nicht mehr), darum haben wir das auf den letzten funktionierenden Kernel festgesetzt.

Ich sehe im Moment keine Notwendigkeit das zu ändern, aber wenn Du es ausprobieren und evtl. Patches einreichen möchtest, kannst Du das gerne machen. Die Touchdisplays werden dabei nicht beschädigt, somit ist das alles auch "ungefährlich".

Den VNC-Server hatten wir auf Jessie angepinnt, weil der unter Buster einige Schriften verzerrt dargestellt hat. Da kann man aber sorglos zu der Buster-Version wechseln, wenn einem die Darstellungsprobleme nicht stören.

Wie geschrieben, ist meine Motivation, den Kernel zu aktualisieren, Richtung Null, weil das ein ziemlicher Testaufwand ist (3.2", 3.5" A, 3.5" B, 3.5" IPS, 4", …) und zudem Bullseye vor der Tür steht und wir dann solche Dinge eh angehen müssen, resp. weitere Anpassungen und Tests vor uns haben.

Viele Grüße
Lars

kräml
Beiträge: 33
Registriert: 14 Aug 2020, 06:47

Re: TX-Pi, Raspberry Pi Community-Controller

Beitrag von kräml » 26 Nov 2020, 12:00

Hallo Lars,

danke für die schnelle Antwort.

Ja bin dabei mich mit dem Wavashares auseinander zu setzen.

Im Skript steht, dass GH repro erzeugt Probleme bei 3.5 Rev. 2. Welche sind/waren die Probleme?

Wegen Testen, ja das ist der booring stuff. Kann man diesen evtl. automatisieren? Wie schauen die Tests aus? Kann man dabei helfen?

Gruß Michl

kräml
Beiträge: 33
Registriert: 14 Aug 2020, 06:47

Re: TX-Pi, Raspberry Pi Community-Controller

Beitrag von kräml » 26 Nov 2020, 12:09

Hallo,

bin gerade auf GH https://github.com/ftCommunity/tx-pi/issues/38. Da sind die angesprochenen Dinge als Issue offen. Werde mich dann dort melden.

Michl

tintenfisch
Beiträge: 186
Registriert: 03 Jan 2018, 22:04

Re: TX-Pi, Raspberry Pi Community-Controller

Beitrag von tintenfisch » 26 Nov 2020, 14:10

Hi Michl,
kräml hat geschrieben:
26 Nov 2020, 12:00
[...]
Im Skript steht, dass GH repro erzeugt Probleme bei 3.5 Rev. 2. Welche sind/waren die Probleme?
Das Display zeigt keine Ausgabe, vermutlich sind die Treiber zu alt, damals gab es das 3.5 Rev.2 noch nicht, siehe auch
https://github.com/ftCommunity/tx-pi/issues/37

Darum holen wir uns den Treiber dann gesondert aus dem Waveshare-Repository, welches jedoch nicht gänzlich mit dem Setup-Script kompatibel ist, weil sich u.a. die Definitionen der Rotatation etc. signifikant unterscheiden. Darum verwenden wir standardmäßig die älteren Treiber. Außerdem scheint WS nicht sonderlich aktiv bei der Entwicklung zu sein, evtl. wäre das Repository https://github.com/goodtft/LCD-show/ (siehe auch Issue #38) eine bessere Alternative.

kräml hat geschrieben:
26 Nov 2020, 12:00
[...]
Wegen Testen, ja das ist der booring stuff. Kann man diesen evtl. automatisieren? Wie schauen die Tests aus? Kann man dabei helfen?
Tja, wie sieht das Testen aus? :) Jeder von uns Dreien sitzt zu Hause, mit einer Reihe verschiedener Raspberry-Pi Generationen und Touchdisplays und probiert div. Raspi/Display-Kombinationen aus :)

Ob sich das automatisieren läßt, wage ich zu bezweifeln, da man ja auch immer überprüfen muß, dass man nicht nur eine Anzeige bekommt, sondern das Display auch auf Touch-Ergeignisse reagiert.

Viele Grüße
Lars

Antworten