Glaube ich hab jetzt die zündende Idee, wie ich ein Nacht-Design verwirklichen werde.


Das Problem.

Das Grundproblem war/ist ja, dass die meisten Grafiken auf dem Chip des Display-Moduls gespeichert werden sollen. Zumindest alle Ziffern und die kleinen Icons wie die Kopfzeile oder sowas wie Tankinhalt oder Reichweite, was man auf den vorigen Bildern sehen konnte. Das hat einfach den Grund, dass somit sehr viel schneller auf sie zugegriffen werden kann, als wenn sie von dem im TFT-Bildschirm integrierten MicroSD-Laufwerk geladen werden. Habe ich irgendwelche sich sehr schnell ändernden Zahlenwerte auf dem Display darzustellen, dann kann es da regelrecht zu "Datenstau" kommen. Außerdem kann eine SD-Karte versagen, und wenn man dann Lesefehler hat, funktioniert gleich das ganze Bordcomputer-Display nicht mehr.

So weit, so gut. Auf dem Chip selbst stehen aber im Speicher nur 64 KB für soetwas zur Verfügung. Ein Überschreiten dieser Schwelle führt zu Fehlfunktionen. Und mit meinen "Tag-Design"-Grafiken liege ich zusammen schon bei ca. 54 KB. Ein kompletter Satz Nacht-Design-Grafiken nach gleicher Machart hätte darauf schlicht und einfach keinen Platz.

Farbige Pixel sind in der Welt der Computer meistens mit ihren Rot-, Grün- und Blau-Werten definiert. Meine bisherigen Grafiken und Ziffern im "Tag-Design" sind definiert als RGB 565, das ist eine "abgespeckte" Farbdefinition für solche Zwecke wie diesen hier.

Der Farbton jedes einzelnen Pixels ist im Farbschema RGB 565 direkt mit einem zwei Byte bzw. 16 Bit langen Hexadezimalwert definiert. Etwa so:



Man hat mit 16 Bit pro Pixel zwar 65536 mögliche verschiedene Farbtöne, was auf TFTs schon zu sehr nett aussehenden Farbfotos führt (zum Vergleich: Desktop-PCs arbeiten heute meist mit 32 Bit und nicht mit 16) . Aber für ein Display mit wenigen Grundfarben zum überwiegenden Anzeigen von Zahlenwerten braucht man das nicht.

Was also tun? Wir brauchen die Farbwerte in 16-Bit wie in dem obigen Code-Beispiel, um sie auf dem TFT darzustellen, aber wir wollen keine so großen Bilddateien.

Man könnte auch versuchen, einzelne Farbwerte zu ersetzen während ein Pixel auf dem Bildschirm dargestellt wird. Ein weißer Pixel wird dann meinetwegen zu einem schwarzen umgerechnet um von Tag- auf Nacht-Design umzustellen. Das ist aber nicht praktikabel, und wird den Mikrocontroller deutlich verlangsamen. Denn es muss ja quasi bei jedem einzelenen Pixel überprüft werden, bist du ein schwarzer Pixel oder ein weißer Pixel? Und wenn ja, dann muss der komplette Farbwert neu in den Speicher geschrieben werden. Für jeden einzelnen Pixel.


Die Lösung.

Die Lösung ist, eine Farbpalette der am häufigsten vorkommenden Farben eines Bildes zu errechnen. Wir können also - meistens - bis zu 256 Farben definieren, die in einem Bild vorkommen sollen. Ihr kennt das vielleicht von GIF-Bilddateien, die genauso eine reduzierte Farbanzahl mit bis zu 256 Farben haben.

Besonders bei flächigen Grafiken mit wenig verschiedenen Farben bietet sich sowas an. Hier einmal eine Gegenüberstellung:



Wie Sie sehen, sehen Sie nichts... Denkt man dann noch daran, dass TFT-Displays ohnehin oft nicht so kontrastreich sind, wird man nachher auf dem Bildschirm noch weniger einen Unterschied merken.

Wie läuft sowas dann praktisch ab? Wie bekommen wir die 256 Farben dargestellt, die ja für sich genommen immer ein 16 Bit großer Wert sein müssen, obwohl wir Speicherplatz sparen wollen/müssen? Nun, indem wir nicht in jedem Pixel eines Bildes die komplette Farbinformation hinterlegen, sondern nur einen Verweis auf einen Eintrag in einer Farbtabelle.

Das ist in etwa so wie früher in der Schule oder in der Vorlesung. Als Lehrer kann ich entweder einen Sachverhalt bis ins kleinste Detail zehn Mal hintereinander erklären, oder ich sage (nach dem ersten Mal Erklären) nur noch "Lesen Sie das bitte auf Seite 115 im Buch nach". Ich werde mir mit letzterem selber eine Menge Rederei ersparen, aber das Ergebnis ist das gleiche, nämlich dass der Student an Ende die gewünschte Information (hoffentlich ) im Kopf gespeichert hat, ohne dass ich jedesmal wieder neu runterbeten muss was denn nun auf Seite 115 in diesem Buch steht.


Der Code.

Wir legen also in unserem Programmcode eine Farbtabelle fest. Die kann in etwa so aussehen, hier mal stark vereinfacht anhand einer Farbtabelle mit 12 verschiedenen Farben:



Jeder dieser Werte steht für eine bestimmte Farbe, in der ein Pixel wahlweise auf dem Bildschirm dargestellt werden kann.

Und meine Pixel sind dann nur noch definiert als ein Verweis auf einen bestimmten Wert in dieser Farbtabelle. Das kann dann so aussehen:



Jeder Eintrag in dieser Tabelle ist ein Pixel. An dritter Stelle steht wie man sehen kann eine 9. Pixel Nr. 3 verweist also z.B. auf den 9. Farbton in der obigen Tabelle colorTable[], also auf 0xd638. Somit weiß ich als Mikrocontroller, ich soll den Pixel Nr. 3 in 0xd638 darstellen. Aber eben ohne dass mir jedesmal der Farbwert neu gesagt wird, sondern indem ich nachschaue welche Farbe an 12. Stelle in meiner Farbtabelle hinterlegt ist.

Das Ergebnis ist, dass wir eine Menge Speicherplatz im Programmcode sparen. Denn das schöne ist, diese Farbtabelle muss ich im Grunde nur ein einziges Mal für alle meine Grafiken festlegen, und jede meiner Grafiken verweist dann je Pixel einfach nur auf einen bestimmten Wert in der gemeinsamen Farbtabelle.

Das Festlegen dieser Farbtabelle benötigt zwar auch Speicherplatz. Bei 256 Farben haben wir 16 Bit bzw. 2 Byte mal 256 Farben = 512 Byte. Aber die Grafiken selbst benötigen halt nur noch die Hälfte des Speicherplatzes gegenüber der Speicherung mit kompletten Farbwerten, da jeder Wert in dieser Grafik nur zwischen 0 und 255 ist, was einem Byte entspricht anstatt zweien.


Hoffe ich komme dann demnächst dazu, das auch in die Tat umzusetzen. Wird ein ziemlicher Aufwand, alle Grafiken nochmal neu zu layouten fürs Nacht-Design. Deshalb muss ich das erstmal vertagen, so wie den Rest des Projekts.

Hab noch ne Idee für die Dinge, die angezeigt werden sollen.

Ich erhebe mit meinem Motordaten-Messmodul die Drehzahl, aber in Wirklichkeit tue ich nix weiter damit, als diese als Zahl auf dem Display dann so wie sie ist auszugeben. Dafür haben wir aber eigentlich schon den Drehzahlmesser an sich, der die gleiche Information darstellt.

Aber man könnte was anderes damit machen, nämlich die Drehzahl zusammen mit dem Momentan-Spritverbrauch und der gefahrenen Geschwindigkeit nutzen, um daraus eine "Gangschaltungs-Empfehlung" zu machen. Sicher, wenn ich sehe dass ich 14 Liter Momentanverbrauch habe, dann werde ich auch selber darauf kommen, dass ich vielleicht mal nen Gang hoch schalte.

Andererseits, so ne "Schalt-Empfehlung" könnte man schnell mit ein paar kleinen Codezeilen verwirklichen.

Bin mir aber noch nicht sicher, nach welchen Kriterien die Empfehlung dann berechnet werden soll.

Wir haben als Variablen wie gesagt Motordrehzahl, Spritverbrauch und Geschwindigkeit in km/h.

Vielleicht habt ihr ne Idee.

Auf dem Display könnte das zum Beispiel so aussehen:




Bei modernen Autos sind zusätzlich in der Gangschaltung (auch bei Handschaltung) Sensoren, die per CAN den gerade eingelegten Gang an die Bordelektronik melden, aber sowas sparen wir uns hier...

Wofür brauchst du bei einem MGF/TF eine Schaltempfehlung. Entwerder cruist du gemütlich durch die Gegend oder bist sportlich unterwegs. Bei beidem ist meiner Meinung nach eine Schaltempfehlung überflüssig.
Denke auch das zuviele Infos den BC unübersichtlich machen. Baust du eigentlich ein Menü ein wo man bestimmen kann welche Infos aufs Display kommen?

Ja, es wird ein "Settings"-Menü geben, in dem man zum Beispiel einstellen können wird ob man Kilometer- oder Meilenmodus möchte. Hab ich ja weiter oben schon geschrieben. Die Einstellungen werden dann so auf dem Chip (im EEPROM) gespeichert, dass sie jedesmal beim Starten des Bordcomputers wieder neu ausgelesen werden.

Das ganze kann man theoretisch tatsächlich so weit treiben, dass man sich die Menüs komplett selber zusammen stellen kann. Dass ich meinetwegen sage, ok, auf Seite 1 des "Kraftstoff"-Menüs will ich Momentan-Spritverbrauch und Reichweite haben. Oder Durchschnittsverbrauch und Tank-Restinhalt oder so.

Naja, ich habs halt so programmiert im Motordaten-Modul, dass die Motordrehzahl gemessen wird. War ein ziemlicher Aufwand bis das lief, denn die wird direkt am Kurbelwellensensor gemessen. Und jetzt wo der Teil des Codes fertig ist, wäre es ein bisschen schade, wenn man die Drehzahl nur als "redundante" Größe anzeigt, noch dazu auf einem Display das inmitten des eigentlichen Drehzahlmessers montiert ist

Wenn man sich darauf einigen könnte, wie man aus Geschwindigkeit, Momentanverbrauch und Drehzahl ne Schalt-Empfehlung errechnet, dann wäre die eigentliche Berechnung ne Sache von zehn bis fünfzehn Code-Zeilen. Und am Ende wird dann einfach als Ergebnis der Berechnung gesagt "Gang rauf" oder "Gang runter".

Ich hatte diese Schalt-Empfehlung im Cockpit bei nem VW den ich dieses Jahr im Urlaub als Leihwagen hatte. Ich fands einfach ganz neckisch. Auf den hügeligen Straßen und Autobahnen auf den Kanaren verbraucht man so oder so ne Menge Sprit, egal ob man die Schalt-Empfehlung befolgt oder nicht. Aber ich fand das irgendwie trotzdem ganz nett, sowas zu haben.

Schaltempfehlung hatte der Ersatzwagen für unsern Firmencaddy . Ich fand albern und überflüssig , weil das hör ich selber wann ich Schalten muss, sowas lenkt nur ab. Wenn ich da laufend wegen irgendetwas auf ein Display schauen sollte lieg ich glaub ich eher im Strassengraben als das ich ankomme .

also WENN ich das in den Code einbaue, dann haben sowieso erstmal 1000 andere Sachen Vorrang vor sowas.

Gibt ja eigentlich nur zwei Betriebszustände wo sich rauf- oder runterschalten lohnt. Entweder ich hab nen hohen Verbrauch bei niedriger Drehzahl, dann sollte ich runterschalten. Oder ich hab ne zu hohe Drehzahl und zu hohen Verbrauch, dann muss ich runterschalten.

Werd das trotzdem mal im Hinterkopf behalten. Andere Sachen werden so oder so Vorrang haben erstmal.

Bei zu hoher Drehzahl runterschalten

Hab mal nachgerechnet... ne Schalt-Empfehlung könnte daran scheitern, dass nicht genug Platz im Flash-Speicher des Mikrocontrollers ist. Alle Icons zusammen für Tag- und Nacht-Design würden sich auf etwa 69 KB belaufen. 64 KB ist das absolute Maximum, darüber startet der Mikrocontroller nicht mehr richtig beim Einschalten.

Also wird das tatsächlich erstmal nix werden. Durch Weglassen aller Icons für so ne Schaltempfehlung komm ich wieder unter 64 KB. Was solls, gibt genug anderes zu tun.

Hat wohl damit zu tun, dass solche Daten quasi am Anfang des Flash-Speichers gespeichert werden. Die meisten Libraries die ich hierfür einbinde setzen voraus, dass die Startadresse des eigentlichen Programmcodes unter 64 KB liegt bei diesem Chip. Man müsste also tief in die Libraries reingehen und sich anschauen wie dort adressiert wird. Da ist es einfacher, man bleibt von vornherein unter 64 KB.

EDIT: Möglicherweise werde ich bei meinem Display-Modul-Mikrocontroller aber noch an anderen Stellen an Grenzen stoßen bei dem Projekt so wie ich es mir vorstelle.

Ich habe mal geguckt nach Alternativen mit mehr Speicher. Momentan läuft die Software für das Display auf einem 8-bit Atmel 1284P-PU-Controller. Dieser hat 128 KB Flash-Speicher, wovon halt wie gesagt 64 KB nutzbar sind für Grafiken.

Man könnte das ganze aber auch auf nem 32 Bit-Mikrocontroller machen. Es gibt fertige Boards die sich genauso programmieren lassen wie der gegenwärtige Controller. Die haben dann nen ARM Cortex-Mx-Prozessor. Es gibt Varianten mit bis zu 1MB Flash-Speicher, aber für den Bordcomputer würde wohl ein Cortex M4 mit 256 KB reichen.

Sowas hier zum Beispiel:

https://www.sparkfun.com/products/13736

Diese Boards sind von den Abmessungen her sogar noch kleiner als der 1284P-Controller. Das ist besonders bei Montage im Drehzahlmesser-Gehäuse ein Vorteil. Kostet in etwa 10-15€ mehr als ein 1284P. Bei Alibaba könnte man sogar bei ner Sammelbestellung solche Boards für 1 Euro das Stück bekommen, wenn ich richtig gelesen hab.

Bezüglich der Funktionen die dieser Chip mit sich bringt, schießt man für ein Projekt wie dieses hier eigentlich mit Kanonen auf Spatzen.

Andererseits, man könnte die Features auch einfach nutzen für weitere Bordcomputer-Funktionen. Diese ARM-Prozessoren haben z.B. eine native Digital Audio-Unterstützung. Heißt, man kann (8 Bit Mono-)Audio-Samples direkt auf dem Chip speichern. Warnungen könnte man dann mit einem richtigen "Gong" ausgeben anstatt nur mit einem Piepton. Und sie haben eine eingebaute Echtzeit-Uhr. Man könnte sich also die Fahrtzeit-Länge anzeigen lassen oder so.

Mit ner Taktfrequenz von 72 MHz (gegenüber 16 MHz beim 1284) dürfte es auch absolut keine Lags/Latenzen beim Bildaufbau geben.

Für jemanden der das ganze nachbauen wollen würde bedeutet das keinen zusätzlichen Aufwand. Das wäre ja alles in dem Programmcode "on board", der komplett von mir kommt. Die eigentliche Schaltung die man für das Display-Modul löten müsste würde sich sogar vereinfachen.

Wenn der eine Echtzeituhr drin hat, ist es eine Überlegung das Display an der Stelle der Uhr ins Auto zu bauen. Die Uhrzeit könnte man dann mit dem BC anzeigen.
Das hat den Vorteil das man im Auto nichts einfräßen oder großartig umbauen muss.
In dem BC werden Außentemperatur und Innenraumtemperatur angezeigt. Wäre statt der InnenraumTemperatur nicht eine Motorraumtemparatur nicht sinnvoller?
Sind nur Überlegung von mir.

hm... Motorraum-Temperatursensor? Braucht man den?

Klar, könnte man machen. Am Motordatenmodul sind noch ein paar Pins frei, wo man den dranpappen könnte.

Hier mal ne aktuelle Gesamt-Skizze von den Modulen:



Da müsste man dann aber ein Pt100-Element nehmen. Die Temperatursensoren die die Innen- und Außentemperatur überwachen sollen gehen nur bis 120 °C.

Auf die Idee das Display in die Uhr zu machen bin ich überhaupt noch nicht gekommen...

Klar, könnte man machen. Und auf dem Display könnte man außerdem eine Analoguhr "nachahmen". Da gibt es schon fix und fertig Programmcode für, wie zum Beispiel auf dem Bild hier:



In das Gehäuse würde sogar das komplette Board mit dem ARM-Prozessor drauf reinpassen was ich oben in dem Link gezeigt hab. Und man könnte statt dem kleinen 1,44-Zoll-Display mit 128x128 Bildpunkten was ich jetzt verwende sogar ein 1,8''-Display mit 160x128 Pixeln verwenden. Das wiederum vereinfacht den Programmcode etwas, da sich in der jetzigen Version bestimmte Anzeige-Elemente quasi wechselnd durch ein- und ausblenden den Platz auf dem Display teilen müssen. Bei 160 Pixeln wäre das nicht nötig.

Durch den leistungsfähigeren Mikrocontroller und den Einbauort im Uhren-Gehäuse mit dem größeren Display könnte sich der komplette Entwicklungsaufwand verringern. Das Projekt wird damit nicht komplizierter, sondern einfacher.

Wie hieß es früher beim A-Team immer...

Durch den Einbau anstelle der Uhr gibt es noch einen Vorteil. Durch die zurückliegende Einbauposition in dem Schacht hat man auch bei geöffnetem Dach eine gute Lesbarkeit des Displays.

Glaube ich hab die beste Lösung gefunden.

https://eckstein-shop.de/Espressif-ESP-WROOM-32

Das ist ein 32-bit 240 MHz Dual Core- Prozessor mit 16 MB Flash-Speicher.

Für den Bordcomputer hier wäre das gigantisch und um mehrere Grössenordnungen mehr als wir brauchen.

Andererseits, da hat man wirklich alles erdenkliche on board. Selbst ein Bluetooth-Modul, falls es wirklich mal eine App geben wird für den Bordcomputer. Und das ganze kostet mit 6-10 Euro weniger als andere Boards. Man müsste quasi nur noch ein paar Kabel anlöten für Stromversorgung, Datenleitung von den anderen beiden Modulen, und ein paar Kabel rüber zum eigentlichen Display. Wäre somit auch sehr "nachbau-freundlich". Und von den Abmessungen her winzig. Das Board ist nur etwas grösser als ne Briefmarke...

In Sachen "bang for your buck" eigentlich kaum zu schlagen. Und mit 16 MB Flash-Speicher könnte ich mich noch um einiges mehr austoben mit schönen bunten Grafiken...

13.11.: Nachtdesign

16.11.: Schaltpunktanzeige

18.11.: Neustart mit anderer Systemhardware …

Lässt dich einfach nicht los, oder, Gerrit? Dieser MG-Mod Virus ist echt unheilbar. Selbst die rein elektronische Mutation.

gut aufgepasst...

Wirklich vorangetrieben hab ich das Projekt in den letzten paar Tagen aber trotzdem nicht. Nur kurz mal ein paar Sachen ausprobiert und überlegt wie's weitergehen könnte. "Faktisch" hat das Projekt trotzdem Pause. Der MG steht auch gerade schön mollig eingepackt im Parkhaus und hält Winterschlaf...

Mit 32-Bit kann man übrigens bei der Menügestaltung ganz andere Wege gehen. Da sind zum Beispiel animierte Screens möglich und so.

Hab grad mal mein altes Flash MX auf meinen Rechner gemacht und bei nem Kaffee ne halbe Stunde mit Animationen gedaddelt...

Sowas wie hier:




...but that's a story for another time...

Wenn das Display anstatt der Uhr eingebaut wird, könnte man dann nicht gleich ein rundes Display verwenden? Oder würde das den Code sprengen? Bei Alibaba gibts die in verschiedenen Größen und Auflösungen

Die Animation ist cool

Das Problem werden die Treiber sein für die Displays. Hab heute mal im Internet geguckt danach, anscheinend haben die Leute reihenweise Probleme damit, dass es keine Dokumentationen zu den Displays gibt, und dass die Treiber die sie dann doch irgendwo im Internet gefunden haben dann nicht funktioniert haben. Und die Anzeigequalität an sich soll auch mau sein. TFT ist halt nicht gleich TFT.

Am besten wird es wirklich sein, ein rechteckiges 128x160-Display von Adafruit zu nehmen. Adafruit ist ein seriöser Hersteller, wo so ein Display dann zwar 20 Euro kostet, aber man kriegt ne komplette Doku dazu, alle (funktionierenden!) Treiber und jede Menge Anwendungsbeispiele. Und die Anzeigequalität der Displays ist auch sehr in Ordnung. Ich hab ja hier das 128x128-Display aus der gleichen Baureihe. Die 14-15 Euro ist es echt wert, damit man nicht tagelang Zeit verschwendet um irgendwas Undokumentiertes zum laufen zu bekommen.

https://www.adafruit.com/product/358

Hier dann übrigens nochmal ne andere Startbildschirm-Animation...



Hab mir vor x Jahren mal ne Flash MX-Lizenz gekauft... im Web ist Flash zwar zu recht auf dem Rückzug, aber für so einfache Animationen taugt es noch.

Das Anzeige-Modul auf einer 32-Bit-Platform zu betreiben wird einiges an Arbeit sparen, denn der 8-Bit-Controller auf dem ich die Sache angefangen hab bedeutet jede Menge Mehraufwand für eine "hübsche" grafische Darstellung der Anzeigen. Alles was ich ganz oben auf dieser Thread-Seite geschrieben habe zur Errechnung einer gemeinsamen Farbtabelle um Speicherplatz zu sparen wird völlig egal mit nem 32-Bit-Board. Ich kann einfach so viele Vollfarb-Bitmaps wie ich will im 16MB großen Onboard-Speicher ablegen, und sie werden blitzschnell ohne Verzögerung auf dem Bildschirm dargestellt.

Der Code den ich bisher für das Anzeigemodul geschrieben hab war trozdem nicht umsonst, das meiste davon lässt sich 1:1 auf den 32-Bit-Chip portieren.

Wird dann wohl sowas hier werden:

https://www.ebay.de/itm/ESP-WROOM-32-ESP32-ESP32S-IoT-Wifi-Wlan-BLE-Module-Adapter-Board/272589254007?hash=item3f7795ed77:m:mUIu5sORTtGwhJgX6UnRhaA

Da das Board ja gleich Bluetooth mit dabei hat, werde ich wohl auch gleich die Bluetooth-App mit entwickeln. Ist für mich Neuland, hab noch nie ne App gemacht, aber gibt ja jede Menge Tutorials dafür online...

Naja und wie gesagt wird durch so ein hoch integriertes Board die ganze Sache sehr viel "nachbau-freundlicher". Und bei 5-10 Euro pro Board halten sich auch die Kosten im Rahmen.

Bis das Board aus China geliefert wird, werden so an die zwei Wochen vergehen. Und in den zwei Wochen werde ich jetzt WIRKLICH mal das Projekt liegenlassen. Jetzt wirklich mal...

Ha, die Chinesen liefern teilweise schneller, als ich Ware aus manchen Ecken in Deutschland bekomme. Problem ist 'nur' der Zoll.

Viel Spaß in der Pause

gruss kai

Wenn du Lust hast mir zuzuarbeiten, könntest du mal gucken wie eine Öltemperaturanzeige vom F/TF von innen ausieht

Für den Umbau ist es wohl am besten, zusätzlich ne F/TF-Öltemp-Anzeige von eBay zu holen. Von der kann man nämlich die Plexiglas-Abdeckung gleich für das Display nehmen (die von der Uhr hat ja ein Loch in der Mitte für die Zeigereinstellung). Außerdem werden die Öltemp-Anzeigen bei eBay für 15 Euro gehandelt. Möglicherweise kriegt man sie aus England noch billiger. Ne neue Uhr scheint um die 50 Euo gebraucht zu kosten, falls man irgendwann doch mal wieder rückrüsten will.

So ein ESP32-Board hat nach dem was ich gefunden hab als Abmessungen so ca. 55 x 28 x 12 mm. Wäre natürlich ideal, wenn man das Board einfach so in die Öltemp-Anzeige einbauen könnte. Halt die Elektrik der Temp-Anzeige ausbauen und das Board dafür einbauen.

Falls also von euch wer ne Öltemp-Anzeige ausgebaut rumliegen hat, wäre nett wenn ihr mal ein paar Fotos machen könntet inklusive Maßband