26.08.2020, 20:14
ich hatte ja angedroht dass mein nächster Umbau wieder eine Lorenz C2 Skalensimulation erhalten soll. Dies bin ich nun grade am Umsetzen. Fertig ist der Umbau noch nicht. Ich musste ein paarmal umdisponieren, hab neue Erkenntnisse gewonnen und im Moment stecke ich grad etwas fest. Den Weg bis jetzt will ich dann mal aufzeigen.
das ist der elegante Radiowecker, hier ist das 3,5"-Display allerdings schon montiert:
[attachment=79314]
an Druckteilen waren nötig: 2 Blenden um das Display in den ursprünglichen Uhrenausschnitt einzupassen und 4 Halterungen welche die Blenden und das Display mitsamt dem aufgesteckten Raspberry zusammenhalten.
[attachment=79315]
und dann noch 2 seitliche eingeleimte Führungen für das Display damit es auch zur Seite fixiert ist:
[attachment=79316]
Die Blenden haben auf der Innenseite eingeschmolzene M3 Gewindeeinsätze an denen die Halteklammern verschraubt sind.
So sah mein erstes Konzept aus. Ein Raspberry zero mit USB-Adapterpeitsche und USB-Soundkarte. Passt alles wunderbar ins Gehäuse, das Display konnte ohne Rotation der Darstellung betrieben werden:
[attachment=79317]
[attachment=79318]
Mit diesem Aufbau installierte ich also nun die Lorenz C2 Simulation. Das Display wurde mittels LCD-show eingebunden. Jetzt blieb erst mal der Bildschirm dunkel. Ich hatte erst keine Erklärung, beschäftigte mich noch mit anderen Dingen, als nach ca. einer halben Stunde plötzlich die Lorenzskala erschien. Aber... sie bewegte sich nicht. Und dann wurde mir klar, ich hab hier ein massives Zeitproblem. Die testweise Installation anderer Skalensimulationen bestätigte dass die Simulation extrem langsam lief. Die Zeigerbewegung um eine Schrittweiten-Einheit dauert fast 10 Minuten!
Ich verglich mit meinen vergangenen Projekten. Tatsächlich hatten alle X11-Simulationen und alle iTV bis jetzt einen HDMI-Bildschirm. Ein SPI-Display ist für den Zweck (zumindest ohne proprietären Treiber) einfach unbrauchbar.
Hier die Beschreibung zum Display:
[attachment=79320]
[attachment=79321]
Nächster Schritt und nächstes Problem: Ich entlieh mir aus meiner Bayern-Uhr ein 3,5"-HDMI Display.
Hier ein Vergleich der beiden Einheiten:
[attachment=79319]
Jetzt war der zero nicht mehr einsetzbar, weil die HDMI-Buchsen nicht zusammenfinden:
[attachment=79322]
Also ersetzte ich den zero gegen einen 3B. Damit dessen USB-Anschlüsse nach innen zeigen war jetzt doch eine Softwaredrehung des Bildschirmes nötig. Fatalerweise kopierte ich eine ergoogelte Zeile in die /boot/config.txt, bei der sich später herausstellte dass sie KEINE Leerzeichen beinhalten darf, aber mit Leerzeichen rechts und links des Gleichheitszeichens angegeben war:
display_rotate=2
Nun gut, da kam ich dann auch noch dahinter.
Die Simulation (mit Fake-KMS-Treiber, der eigentliche KMS-Treiber lässt ja keine Rotation zu) hatte ich nun eine schnelle, flüssige Animation.
Aber jetzt kommt der HAMMER!
Mein Blick fiel auf die 3,5" Klinkenbuchse auf dem Display. Ich hatte mir in all den Jahren noch nie Gedanken gemacht welchen Sinn diese Buchse hat. Ich hatte einen Verdacht .. und testete aus. Tatsächlich, das Display hat einen DAC für HDMI onboard! Ich ärgere mich jahrelang über das Gebrabbel an der Raspberry Jack, und hätte zumindest bei diesen Displays nur umstecken brauchen!
An meinem ITT CR220 entfällt nun wieder die USB-Soundkarte und weil ich keinen der seitlichen Anschlüsse mehr benötige kann ich die Raspberry Einheit wieder rumdrehen und den richtigen KMS-Treiber benutzen. Ein tolles, schlüssiges Konzept, das hart erarbeitet ist.
Eine Hürde gibt es aber noch. Und das ist die Skalierung des Display:
[attachment=79323]
Anpassungen am Betriebssystem (HDMI-Mode) verändern das zu kleine Bildchen nicht. Ich muss hier entweder am wrapper oder am vlc ansetzen, oder vielleicht auch an den Grafiken.
Wenn ich in der sdlskale.cxx die Werte für Breite und Höhe der Simulation:
#define SKALE_HOEHE 480
#define SKALE_BREITE 800
auf 1280 x 768 ändere erhalte ich zumindest mal dieses Bild:
[attachment=79324]
aber das wird nicht der richtige Weg sein. Dann wären ja sämtliche Positionsangaben, auch die der Uhrenzeiger, neu zu ermitteln. Deshalb an dieser Stelle meine Frage an Bernhard: wie soll ich vorgehen?
das ist der elegante Radiowecker, hier ist das 3,5"-Display allerdings schon montiert:
[attachment=79314]
an Druckteilen waren nötig: 2 Blenden um das Display in den ursprünglichen Uhrenausschnitt einzupassen und 4 Halterungen welche die Blenden und das Display mitsamt dem aufgesteckten Raspberry zusammenhalten.
[attachment=79315]
und dann noch 2 seitliche eingeleimte Führungen für das Display damit es auch zur Seite fixiert ist:
[attachment=79316]
Die Blenden haben auf der Innenseite eingeschmolzene M3 Gewindeeinsätze an denen die Halteklammern verschraubt sind.
So sah mein erstes Konzept aus. Ein Raspberry zero mit USB-Adapterpeitsche und USB-Soundkarte. Passt alles wunderbar ins Gehäuse, das Display konnte ohne Rotation der Darstellung betrieben werden:
[attachment=79317]
[attachment=79318]
Mit diesem Aufbau installierte ich also nun die Lorenz C2 Simulation. Das Display wurde mittels LCD-show eingebunden. Jetzt blieb erst mal der Bildschirm dunkel. Ich hatte erst keine Erklärung, beschäftigte mich noch mit anderen Dingen, als nach ca. einer halben Stunde plötzlich die Lorenzskala erschien. Aber... sie bewegte sich nicht. Und dann wurde mir klar, ich hab hier ein massives Zeitproblem. Die testweise Installation anderer Skalensimulationen bestätigte dass die Simulation extrem langsam lief. Die Zeigerbewegung um eine Schrittweiten-Einheit dauert fast 10 Minuten!
Ich verglich mit meinen vergangenen Projekten. Tatsächlich hatten alle X11-Simulationen und alle iTV bis jetzt einen HDMI-Bildschirm. Ein SPI-Display ist für den Zweck (zumindest ohne proprietären Treiber) einfach unbrauchbar.
Hier die Beschreibung zum Display:
[attachment=79320]
[attachment=79321]
Nächster Schritt und nächstes Problem: Ich entlieh mir aus meiner Bayern-Uhr ein 3,5"-HDMI Display.
Hier ein Vergleich der beiden Einheiten:
[attachment=79319]
Jetzt war der zero nicht mehr einsetzbar, weil die HDMI-Buchsen nicht zusammenfinden:
[attachment=79322]
Also ersetzte ich den zero gegen einen 3B. Damit dessen USB-Anschlüsse nach innen zeigen war jetzt doch eine Softwaredrehung des Bildschirmes nötig. Fatalerweise kopierte ich eine ergoogelte Zeile in die /boot/config.txt, bei der sich später herausstellte dass sie KEINE Leerzeichen beinhalten darf, aber mit Leerzeichen rechts und links des Gleichheitszeichens angegeben war:
display_rotate=2
Nun gut, da kam ich dann auch noch dahinter.
Die Simulation (mit Fake-KMS-Treiber, der eigentliche KMS-Treiber lässt ja keine Rotation zu) hatte ich nun eine schnelle, flüssige Animation.
Aber jetzt kommt der HAMMER!
Mein Blick fiel auf die 3,5" Klinkenbuchse auf dem Display. Ich hatte mir in all den Jahren noch nie Gedanken gemacht welchen Sinn diese Buchse hat. Ich hatte einen Verdacht .. und testete aus. Tatsächlich, das Display hat einen DAC für HDMI onboard! Ich ärgere mich jahrelang über das Gebrabbel an der Raspberry Jack, und hätte zumindest bei diesen Displays nur umstecken brauchen!
An meinem ITT CR220 entfällt nun wieder die USB-Soundkarte und weil ich keinen der seitlichen Anschlüsse mehr benötige kann ich die Raspberry Einheit wieder rumdrehen und den richtigen KMS-Treiber benutzen. Ein tolles, schlüssiges Konzept, das hart erarbeitet ist.
Eine Hürde gibt es aber noch. Und das ist die Skalierung des Display:
[attachment=79323]
Anpassungen am Betriebssystem (HDMI-Mode) verändern das zu kleine Bildchen nicht. Ich muss hier entweder am wrapper oder am vlc ansetzen, oder vielleicht auch an den Grafiken.
Wenn ich in der sdlskale.cxx die Werte für Breite und Höhe der Simulation:
#define SKALE_HOEHE 480
#define SKALE_BREITE 800
auf 1280 x 768 ändere erhalte ich zumindest mal dieses Bild:
[attachment=79324]
aber das wird nicht der richtige Weg sein. Dann wären ja sämtliche Positionsangaben, auch die der Uhrenzeiger, neu zu ermitteln. Deshalb an dieser Stelle meine Frage an Bernhard: wie soll ich vorgehen?