FAQ zum iRadio

[kaloschke]

Hallo noch mal.
Bin doch wieder dran. Stand ist:
1. VLC läuft stabil
2. Gesture Sensor funktioniert - manchmal. In der Mehrzahl der Fälle klappt es leider nicht. Ich habe in PAJ7620U2.c mal testweise die Delays erhöht (auf 100). Leider ohne
sichtbaren Erfolg. Ein in PAJ7620U2_init() eingefügtes printf gibt im Nichterfolgsfall den Fehlercode 255 zurück.
3. Das fltk-Beispiel läuft in einem Windows-X11-Fenster, wie weiter oben beschrieben.

[kaloschke]

Ups. Sorry. War noch nicht fertig.

4. Auf dem Display des Pimoroni läuft (Dank an saarfranzose: DMA muss auch bei mir abgestellt werden) die Konsolenausgabe. Nicht lesbar, da dessen Auflösung ja nur 240 x 240 beträgt.

Meine Fragen:
Gibt es eine Lösung zu 2.?
Wie schaffe ich es, die Ausgabe von gui.c (angepasst auf 240 x 240 ist sie schon) auf das Display zu bekommen?

[kaloschke]

Und noch zur Erinnerung: bei mir läuft nur ein Lite

[saarfranzose]

Hallo kaloschke,

schön dass du weitermachst!

ehrlich gesagt verstehe ich die Frage nicht richtig. Meinst du mit gui.c die x11 Oberfläche, also den Desktop? Der wird doch von fbcp-ili9341 genauso gespiegelt wie die textconsole. Dadurch dass der Raspberry in die console startet und x11 in der rc.local aufgerufen wird mit der Applikation als Parameter tritt x11 in den Hintergrund und nur die Applikation ist auf dem display zu sehen. Und deren Auflösung passt ja zum display. Lässt man den Parameter weg spiegelt sich x11 mit der komletten eingestellten HDMI-Auflösung auf dem kleinen display. Das wird dann natürlich chaotisch und nicht mehr lesbar. Aber es funktioniert.

Beachte auch die Feineinstellungen die ich in einem extra thread dokumentiert habe:

iRadio mit Pimoroni Pirate Audio HAT

zum gesture-Sensor kann ich nichts sagen.

[kaloschke]

Für dass Du die Frage nicht verstehst, hast Du sie gut beantwortet  
Ich kannte Deinen Beitrag zum Pimoroni nicht.

Code:

hdmi_group=2
hdmi_mode=87
hdmi_cvt=240 240 60 1 0 0 0

Das sind genau die Infos, die ich seit Tagen suche. Habe jetzt ein paar Stichpunkte, die mich schlauer machen werden. Mein Pimoroni läuft übrigens auch mit -DSPI_BUS_CLOCK_DIVISOR=4 stabil.

Mit gui.cxx (nicht gui.c, sorry) meinte ich das Beispielprogramm für fltk, was Bernhard  seinerzeit freundlicherweise beigelegt hatte.

Mit startx kann ich es nun starten und es wird im Display angezeigt. Großartig! Vielen Dank.

Zwei  kleine (?) Fragen bleiben:
 -  wie lautet der Parameter für den Buildstring?
 -  Du hast das Display offensichtlich um 90 Grad gedreht. Wie klappt das? Dazu hatte ich keine Infos gefunden. 

[saarfranzose]

ja, ich wollte nicht dass der Testaufbau in der großen Masse der FAQ untergeht.

den build-string hab ich im pimoroni-thread angegeben:

cmake -DPIRATE_AUDIO_ST7789_HAT=ON -DSPI_BUS_CLOCK_DIVISOR=6 -DSTATISTICS=0 -DUSE_DMA_TRANSFERS=OFF ..

bekannterweise sind die beiden Punkte am Ende der Zeile wichtig!

In der Tat ist das display um 90° gedreht. Ich hätte es gerne auf 0° gedreht analog zum pirate-Schriftzug. Aber diese Schraube hab ich leider auch noch nicht gefunden. Man kann als workaround seine Grafik so aufbauen daß die Drehung kompensiert wird.

[Bernhard45]

2. Gesture Sensor funktioniert - manchmal. 
In der Mehrzahl der Fälle klappt es leider nicht.

Das liegt daran, dass Du die Gesten noch nicht sauber genug oder im Focus-Bereich (5-15cm, 60°Erfassungsbereich) des Sensors ausführst. Das ging mir zunächst ähnlich. Die Gesten müssen wirklich sauber und eindeutig gemacht werden. Von links nach rechts (oder andersrum) bzw. hoch und runter darf es auch keine Tiefenveränderung der Hand geben.

Dauert etwas bis man das drauf hat, aber dann geht es sehr zuverlässig. Siehe auch mein Demovideo zum Umbau einer ITT Viola 350

Ich habe in PAJ7620U2.c  mal testweise die Delays erhöht (auf 100). Leider ohne
    sichtbaren Erfolg.

In diesem Codebereich kannst Du die Erkennungsqualität auch nicht verändern. Der Sensor arbeitet quasi autark und liefert in Registerwerten nur das zurück, was er selbst erkannt hat.  Der delay-Wert in der Endlosschleife gibt nur an, wie oft im Pollingverfahren nachgeschaut wird, ob der Sensor eine Geste erkannt hat und wenn ja welche. Bei delay(50) also wird das 20x pro Sekunde geprüft, bei 100 halt 10x pro Sekunde. Alternativ kann der Sensor auch im Interrupt-Betrieb gefahren werden, braucht dann aber halt eine zusätzliche Leitung und Pin.

In gewissen Grenzen hat man über Register des Sensors einen Einfluss auf die Aufnahmequalität der Kamera. Siehe dazu das Datenblatt: https://github.com/BM45/iRadio/blob/mast...002AEN.pdf

Die Adressen in den Registerbänken sind in der PAJ7620U2.h entsprechend des Datenblatts drin, ebenso die Werte die bei der Initialisierung des Sensors übertragen werden.

Ein in  PAJ7620U2_init() eingefügtes printf gibt im Nichterfolgsfall den Fehlercode 255 zurück.

Was soll das printf bringen in PAJ7620U2_init() ? 
PAJ7620U2_init() wird doch nur ein einziges Mal aufgerufen und nicht nach jeder Geste!

Die Auswertung von PAJ7620U2_init() erfolgt dann durch

if(!PAJ7620U2_init())
{ printf("\nGesture Sensor Error\n");
return 0;
}

Danach kommt PAJ7620U2_init() doch gar nicht mehr ins Spiel. Wenn PAJ7620U2_init() "failt", dann konnte der Sensor gar nicht richtig initialisiert werden zum Beispiel weil er nicht richtig angeschlossen ist.

Zur gui.cxx:

Die Größe des Programms legst Du im Konstruktor der Klasse Fl_Window fest. Im Code  Fl_Window *window = new Fl_Window(480,290,"iRadio");  480px breit, 290px hoch

Natürlich musst Du die restlichen Elemente einer solchen FLTK-GUI koordinatenmäßig an dein Display anpassen. Du willst da ja sicher deine eigenen Oberfläche designen.


Gruß
Bernhard

[kaloschke]

Hallo Bernhard,
da habe ich mich unklar ausgedrückt. Die Erkennung der Gesten funktioniert innerhalb meiner Erwartungen recht gut. Ich meinte wirklich den Sensor an sich.
Er wird oft nicht erkannt und es gibt in den meisten Fällen eine entsprechende Fehlermeldung. Ich denke schon, dass ich ihn richtig angeschlossen habe. Schließlich funktioniert es in knapp der Hälfte der Fälle. Vielleicht hat der Sensor eine Macke.

Da ich kein C-Programmierer bin und den Code nur sehr begrenzt verstehe, habe ich halt im Rahmen meiner Möglichkeiten versucht, etwas auszuprobieren.

Was gui.cxx anbelangt, habe ich ja schon oben geschrieben, dass ich es angepasst habe. Mein Problem war lediglich die Ausgabe auf das Display, aber das hat Jupp la schon geklärt.

[kaloschke]

Hallo Jupp,
danke für Info.
Was die Drehung anbelangt, versuche mal, in der Datei /home/pi/fbcp-ili9341/fbcp-ili9341/config.h die Einstellung
DISPLAY_OUTPUT_LANDSCAPE zu aktivieren.
Sie macht genau das Gegenteil von seiner Beschreibung. Aktiviert, dreht es auf 90 Grad, also Portrait.
Bei anderen Displays mag es ja passen.

[Bernhard45]

Ich meinte wirklich den Sensor an sich.
Er wird oft nicht erkannt und es gibt in den meisten Fällen eine entsprechende Fehlermeldung. Ich denke schon, dass ich ihn richtig angeschlossen habe. Schließlich funktioniert es in knapp der Hälfte der Fälle. Vielleicht hat der Sensor eine Macke.

Das ist möglich. Wir haben bei I2C aber auch schon viele Fälle gesehen, wo die Verkabelung selbst das Problem war. Ungünstige Verlegung, übersprechen auf Datenleitung (auch von anderen Bussen -> Display oder gar WLAN), ...   Wenn das passiert, ist das Verhalten der Teilnehmer auf dem Bus unbestimmt.

Hier würde ich ansetzen.

Gruß
Bernhard

[kaloschke]

Korrektur:
DISPLAY_ROTATE_180_DEGREES muss für 0 Grad aktiv sein, DISPLAY_OUTPUT_LANDSCAPE nicht aktiv.
Wenn beide aktiv sind, wird (bei mir) um 90 Grad gedreht.

[kaloschke]

Hallo Bernhard,

Hier würde ich ansetzen.

Schwer für mich. Ich habe fürs Testen einfach ein 15 cm Flachbandkabel von den Pins zum Sensor geführt.
Habe alles mal abgezogen und wieder neu aufgesteckt - keine Änderung
Ich wüste nicht, was ich sonst noch machen kann.
Werde mir bei Gelegenheit mal ein anderes Modell bestellen, kostet ja nicht die Welt.

[Bernhard45]

Hallo,

ich würde (ohne weiteren Messmitteleinsatz) im einfachsten Fall mal rund um die Daten und Takt-Leitung im Flachbandkabel eine Masseleitung führen.

Also ungefähr so im Flachbandkabel:

... | GND | DATA | GND | CLK | GND | ... -> Die GND Leitungen müssen natürlich gemeinsam auf dem Pi auf GND liegen und nicht in der Luft hängen.

Möglichst alles weit weg von anderer Peripherie wie Display oder WIFI-Antenne , ... verlegen.

Vielleicht reicht das schon aus.

Eine andere Idee wäre, daß da noch eine andere Softwarekomponente einen GPIO des I2C haben will und quasi dazwischen funkt. Vielleicht unbewusst beim Ausprobieren installiert?
Solche "Busprobleme" sieht man natürlich am Besten über ein Mehrkanal-Speicheroszi mit Protokolldekoder (bei Bastlern sind ja die 250-300 Euro Rigols beliebt, die das auch können), für den Anfang kann auch schon ein USB Logic-Analyzer für 10-20 Euro ein wertvolles Debugmittel sein. Aber ich vermute Du hast beides nicht und wir müssen das durch "Trial & Error" finden.

Gruß
Bernhard

[saarfranzose]

..Eine andere Idee wäre, daß da noch eine andere Softwarekomponente einen GPIO des I2C haben will und quasi dazwischen funkt. ..

kann es nicht auch ein Performance-Problem des zero sein? Er packt es ja schon nicht mal richtig die gui zuverlässig zu starten.

[Bernhard45]

Das habe ich bei so etwas einfachen wie I2C noch nicht erlebt Jupp. I2C packt selbst ein einfacher ATmega mit interner Taktversorgung in Software so ganz nebenbei. Zumal bei Performanceengpässen ja der Busmaster den Takt sowieso nachführt. Von der Seite sehe ich da keine Probleme. Problematisch wird es erst wenn die Pulse elektrisch nicht sauber und mit "Spikes" verseucht auf dem Bus sind. Das passiert schnell und ist für die Kommunikation tödlich. Sieht man aber am Oszi, sofern man hat.
Eine GUI bzw. X11 dagegen ist bei dem Zero, der ja leistungstechnisch fast einem Ur-Pi gleicht (Singlecore 700 zu 900 MHz) ein anderes Kaliber. Hier muss ja richtig gerechnet werden um Bilder zu rendern und keine HW-Schnittstelle mit ein paar Bits getrieben werden. Was wird denn in den Log von X11 geschrieben, wenn deine Skale mal nicht auf einem Zero hochfährt bzw. X11 wieder terminiert wird?

[saarfranzose]

ich hab die /home/pi/.local/share/xorg/Xorg.0.log hier angefügt:


  Xorg.0.log.zip (Größe: 4,13 KB / Downloads: 1)

ich will aber nicht das Thema jetzt umbiegen und eine Endlos-Diskussion draus machen.

[saarfranzose]

Korrektur:
DISPLAY_ROTATE_180_DEGREES muss für 0 Grad aktiv sein,  DISPLAY_OUTPUT_LANDSCAPE nicht aktiv.
Wenn beide aktiv sind, wird (bei mir) um 90 Grad gedreht.

danke, kaloschke. Mit der config.h bekomme ich die Drehung wirklich in den Griff. Bei einer Änderung muss natürlich fbcp-ili9341 neu gebaut werden. Dummerweise ist die Bildschirmausgabe aber auch noch gespiegelt. Die Ursache suche ich noch.

   

[Bernhard45]

Hallo Jupp,

das X11 wird wohl ganz normal durch die GUI terminiert! Ein Desktop läuft ja nicht im Hintergrund, deshalb ist X11 dann direkt nach der Beendigung der Anwendung auch wieder weg und man steht in der Console. Ausstiegspunkte sind im Code überall da wo return .... Anweisungen sind, man kommt also gar nicht bis zur Endlosschleife/Daemonbetrieb. Gründe für den Ausstieg müsste man durch die Ausgaben auf stderr sehen können. Alternativ hinter jeder Anweisung eine Consoleausgabe "bin in Zeile ..." setzten, compilieren, und beim nächsten Fehlstart schauen bis zur welchen Zeile die Anwendung gekommen ist.

Vielleicht sollte man noch bei den SDL-Skalen eine Exitstrategie während des Initteils integrieren, um ggf. Memoryleaks zu vermeiden. Allerdings wird man die GUI wohl nicht so oft neu Starten bis kein Arbeitsspeicher mehr vorhanden ist, sondern viel eher eine kompletten reboot machen. Bei jedem Neustart der Anwendung dürften ja nur ein paar kB "gesperrt" sein.

Gruß
Bernhard

[saarfranzose]

danke für die Auswertung, Bernhard. Wenn ich HAT und SD-Karte auf einen Raspi3 umstecke startet die Animation ganz normal. Grade wieder probiert. Deshalb kam ich auf Zeit/Performance-Probleme.

[Bernhard45]

Spuckt denn der SDL2-Init Teil irgendwelche konkrete Meldungen bei Fehlstarts aus?