ein Überlegung von mir:
Du verwendest ja nicht alle 8-Bit-Farben. Wenn Du die Farben indizierst, sozusagen einen Software-CLUT ( color lookup table ) nimmst, dann müssten eigentlich ordentliche Grafiken auf dem Display rauskommen.

was mir noch auffiel:
Du verwendest ja nur sehr wenige Farben, Rot, Gelb und Schwarz.

Eigentlich könntest Du bei 8-bit-Speicherung wenige Bits für die Farbe nutzen, die restlichen Bits für die zugeordnete Helligkeit.
Dann umrechnen auf den von der Hardware benötigten Table.
Damit wäre auch der Welcome-Bildschirm mit den verschiedenen Rot- und Gelbtönen möglich, der besteht ja nur aus Rot-, Gelb- und Grautöne ( Hintergrundbild ).

Oder habe ich da einen Denkfehler ?

Das Problem ist nicht, 16-bit-Bitmaps zu verwenden für jede einzelne Ziffer die man darstellen möchte. Die Hexadezimal-Arrays für jedes einzelne Zeichen kann man ja mit ner Konvertierungs-Software erstellen. Und ich brauch eh nur die Ziffern von 1 bis 9, weil ich nur Zahlenwerte darstellen will. Das System ist mit 16-bit auch keineswegs überfordert.

Das Problem ist, dass es eben an "fertigen" Libraries fast nur "8-bit monochrom"-Libraries gibt. Und selbst die nicht-monochromen Libraries, wo man dann in den Hex-Arrays der einzelnen Zeichen auch mal was anderes sieht als 0x00 (schwarz) oder 0xff (weiß), sehen am Ende sch... aus. Weil ihnen einfach die Farbtiefe und das Anti-Aliasing fehlt.

Ich muss also so oder so eigene Libraries erstellen, und da kann ich die Zeichen dann auch gleich in 16-bit RGB565 darstellen. Dauert etwas länger zu coden, aber wird sich lohnen.



Man hat halt bei diesen TFT-Displays maximal einen 16-bit-Farbraum zur Verfügung, nämlich das RGB565-Modell. Klar kann man die vier Farben die ich verwende auch in 8-bit darstellen. Nur eben hab ich versucht, die Farbschattierungen so aufeinander abzustimmen, dass sie miteinander harmonieren. Das sind im einzelnen ein bestimmtes gelb (RGB 255 204 0), dann MG-rot (RGB 143 10 10), ein ganz bestimmtes mittelgrau (RGB 129 129 129), und schwarz (RGB 0 0 0). Dadurch dass die auch in RGB565 konvertiert werden müssen, geht natürlich schon etwas Farbtreue verloren. Aber bei 8-bit hätte ich dann zwar auch irgendein gelb, rot, grau und schwarz. Nur eben mit dem Unterschied, dass das einfach nur "irgendwelche" Gelb-, Rot- usw. -töne wären, und nicht in etwa das, was ich mir in meinem Grafikprogramm an Farbtönen zusammengesucht habe.

Und was für die Ziffern gilt, das gilt halt am Ende auch für die ganzen Grafiken... ein gutes Anti-Aliasing und somit schön abgerundete Kanten kriegt nur mit ner höheren Farbtiefe hin. Dem Display ist das am Ende egal... auch der Chip verfügt über genug Ressourcen um das darstellen zu können, und für alle Grafiken die zu groß sind für den Flash-Speicher des Chips hat ja das Display auf der Rückseite sein eigenes MicroSDHC-Laufwerk.

Ahh.. ok, ist also kein Speicherproblem, sondern die verfügbaren Libraries sind der "Engpass".

Die letzten Tage wieder Audi A3 8P gefahren, der ein dunkles Display in der Tachomitte hat.
Eventuell müsste man mal testen, inwieweit ein heller Hintergrund nachts zu einem Blendeffekt führen könnte,
nicht dass man dann nach dem Blick auf das Display einen folgenden "geblendeten" Fleck auf der Straße hat.
Die geplante Dimmung des Displays ist mir bekannt, mit der Dimmung lässt aber auch der Kontrast stark nach.

Ein dunkles Nachtbild habe ich mal auf die Schnelle ausprobiert.
nur so eine Überlegung.

...find ich gut!

Ich find die Idee mit dem Nacht-Design auch gut

Vielleicht könnte man das ja an das sanfte Orange der Digitalanzeige angleichen, in dem sie erscheint wenn das Licht an ist. Die Dimm-Funktion würde ich aber trotzdem beibehalten. Wäre halt einfach ein ganz nettes zusätzliches Feature. Die Dimmung ist zudem "adaptiv", das heißt, sie hängt nicht nur davon ab ob das Licht an ist oder nicht (also Tag- und Nacht-Modus), sondern es wird auch die Spannung gemessen die an der Cockpit-Beleuchtung anliegt, und somit ist die Helligkeit zusätzlich über den Drehregler einstellbar. Man könnte das dann vielleicht einfach ergänzen indem man sagt, wenn Spannung anliegt, dann soll auf Nacht-Design umgeschaltet werden.

Ich hab zuhause ein Kombiinstrument von nem TF liegen. Hab neulich schon mal versucht die Cockpit-Beleuchtung an dem Ding zum Leben zu erwecken, aber mein 600mA-Netzteil hat leider nicht ganz ausgereicht...

Was den Speicherplatz angeht, ich verwende ja für das Display-Modul einen Atmel Atmega1284P, wahrscheinlich in PDIP-40-Ausführung (möglicherweise aber in der Endversion in SMD-Ausführung um Platz zu sparen). Der hat 128 KB eingebauten Flash-Speicherplatz. Davon sind bis zu 64KB nutzbar für solche Sachen wie Bitmap-Zeichensätze und Icons. Ein Zeichensatz der Ziffern von 0-9 (und nem "Punkt" für Komma-Werte) braucht in 16-bit ungefähr 8 bis 9 KB. Dazu kommen dann noch die kleinen Icons die immer links neben den Werten stehen und so. Das müsste eigentlich hinhauen. Alles andere, wie zum Beispiel die Warnmeldungen, der welcome screen und die Menü-Header, wird auf dem MicroSDHC-Laufwerk gespeichert das hinten drauf auf dem Display aufgelötet ist.

Hier übrigens mal ein Bild, wie es auf meinem Schreibtisch zuhause inzwischen aussieht...



1 - Head Unit-Modul mit Atmega1284P-PU und Adafruit 1.44'' TFT
2 - Motordaten-Messmodul mit Atmega 328P-PU
2a - Kurbelwellensensor - Messer (ist in "2" mit drin), mit Attiny85-20PU. Tut nix anderes als das Kurbelwellen-Signal zu messen und daraus die Motordrehzahl zu errechnen.
3 - Komfortmodul mit Atmega328P-PU (für Funktionen wie Wischwasser, Lampenkontrolle vorn, Innen- und Außentemperatur etc.)
4 - Verdeckkontroll-Modul mit Attiny85-20PU
5 - Lampenkontrollgerät hinten mit Attiny85-20PU

6 - Simulator-Modul Nr. 1 für Motordaten (simuliert Einspritzung, Geschwindigkeit und Kurbelwelle)
7 - Simulator-Modul Nr. 2 für Motordaten (simuliert Öl- und Kühlwassertemperatur, Tankinhalt und analoge Referenzspannung)
8 - Arduino Uno-Board
9 - Arduino Uno-Board
10 - Adafruit FTDI Friend
11 - DS18B20-Temperatursensoren für Innen- und Außentemperatur


Mit allen Vorarbeiten ist das schon jetzt das Resultat von einem halben Jahr Entwicklung. Die einzelnen Module existieren bislang nur auf Steckplatinen, allerdings sind die Schaltungen im Grunde jetzt schon zu 80-90 Prozent fertig konzipiert. Der Code für alle Module zusammen ist insgesamt um die 80 Prozent fertig (um die 1500 Zeilen bislang... ). Das Head Unit-Modul wird wahrscheinlich noch ein Vierteljahr brauchen, weil der Code halt sehr viel komplexer sein wird als bei den anderen Modulen. Nicht nur wird die Head Unit die ganze Grafik machen für das TFT-Modul, sondern eben auch alle Sensordaten der anderen Module aufbereiten und damit Berechnungen ausführen.

Und wenn der Code und die Schaltungen annähernd fertig sind, geht's an den Bau eines Prototyps, der dann im Wagen getestet wird. Momentan schätze ich, dass dieser Prototyp im Februar oder März einbaufertig sein wird.

Auch wenn ich von solchen Sachen praktisch keine Ahnung habe, glaube ich erkennen zu können, daß da eine tolle Sache heranwächst, in die Du viel Arbeit steckst und gesteckt hast. Kann sein, daß so etwas nicht jedermanns Sache ist, aber das ist egal.
Respekt!

bis jetzt ist es ja noch nicht schlimm.

lass uns mal überlegen, was uns noch alles an Funktionen einfällt
dann brauchst Du noch ein paar Kabel mehr, und Weihnachten sieht es so aus.

Ich sag euch, das Zeug hat sein Eigenleben... manchmal denke ich, irgendwann gucke ich hin zu meinem Schreibtisch und der Monitor ist von Kabeln überwuchert...

Momentan spiele ich mit dem Gedanken, vielleicht während der Entwicklung des Codes für die Head Unit gleich Bluetooth mit einzubinden. Wenn man das gleich während der Entwicklung macht, dann kann das mitunter praktischer sein als wenn man es als Addon an den fertigen Code dranpappt.

Es gibt kleine Bluetooth-Platinen für Arduino, mit fertigen Libraries:

https://learn.adafruit.com/getting-star ... troduction

In der Head Unit werden ja jede Menge Daten erhoben und berechnet. Und wenn man die schon mal hat, dann kann man auch andere Sachen damit machen. Auch wenn man noch keine App hat, könnte man zumindest das schon mal so einbinden, dass das Bluetooth-Modul überhaupt irgendwelche Daten ans Smartphone sendet. Und wenn dann der Code für die Head Unit fertig ist (das hat Vorrang), dann könnte man um die gesendeten Daten eine "richtige" Smartphone-App drumherum stricken.

passt das dann alles noch in den Kofferraum?

Ne. Aber in den Anhänger.

So wie hier oder was?

http://www.kalenderblatt.de/index.php?w ... dayisset=1




Ist ja heute ähnlich... wenn man sich anguckt, wie manche Kiddies die ganze Rückbank mit Basslautsprechern zupflastern...

...aber vorne im MG ist doch jede Menge Platz, oder?

also mal ganz im ernst...

Die fertigen Module werden jeweils in etwa die halbe Größe einer Zigarettenschachtel haben. Das Motordaten-Messmodul vielleicht etwas größer als das, weil es immerhin zwei MCs und zwei Optokoppler beherbergen muss.

Und die Platine des Head Unit-Moduls wird ohne Gehäuse von hinten auf den Drehzahlmesser geklebt.

Für den Fall dass man das irgendwann doch mal in ner Kleinserie mit PCB-Platinen herstellt (sehe ich im Moment noch nicht, weil zu teuer), würden die Gehäuse-Größen vermutlich noch kleiner sein.

Unter dem Lenkrad in der Zentralelektrik könnte es etwas eng werden. Dort müssen das vordere Lampenkontrollgerät (mit Relais-Sockeln) und das Komfortmodul untergebracht werden. Da bin ich mir noch nicht ganz im klaren, wie man das am besten befestigt... aber ich hab immerhin schon eine Quelle aufgetan, wo es günstig "Anschlussmaterial" gibt:

http://www.autoteile-plauen.de

Die Module selbst werden wahrscheinlich mit D-Sub-Steckern und -Buchsen an den Bordcomputer-Kabelbaum angeschlossen. Und der Bordcomputer-Kabelbaum wird in einzelne Segmente mit stabilen Steckverbindungen unterteilt werden. Ganz so wie bei "werksseitigen" Kabelbäumen.

Was diese Steckverbindungen angeht, bin ich allerdings noch am suchen... das sollen stabile Flachkontakt-Steckergehäuse mit Sicherungslasche sein bzw. werden, in etwa so wie man sie bei den alten VW und Audi überall hat. Hat da von euch jemand nen "heißen Tip"? Hab zu Test-Zwecken mal ein zwei Flachkontakt-Steckergehäuse bei Conrad gekauft, aber die waren viel zu "labberig"...

War doch nur ein Spass
Ich zieh den Hut vor Dir und dem was Du da machst!
Selbst hab ich nämlich keine Ahnung von Elektrik und Computern... Aber davon jede Menge!

hab ich auch als Spass aufgefasst...

Aber wo wir grad bei dem Thema waren, dachte ich mir, ich werf das mal ganz ernsthaft so als Info in den Raum...

Das Komfort-Modul interessiert mich schon.

Hab mir nochmal Gedanken gemacht wegen des Nacht-Designs...

Also, im MkII und TF haben wir ja eine orangerote Beleuchtung der LED-Anzeige unten rechts:



Es wäre vielleicht das beste, wenn man das Nacht-Design in etwa daran angleicht. Das heißt, ein oranger Hintergrund im TFT-Display, während die anderen Sachen eigentlich alle gleich bleiben könnten.

Jetzt gibts aber mehrere Probleme.

Zum einen haben die Icon-Bilddateien alle einen weißen Hintergrund. Das würde sich natürlich "beißen" mit einem orangeroten Hintergrund. Also was macht man?

Zwei Möglichkeiten.

Erstens: Entweder, man entwirft einen kompletten zusätzlichen Satz "Nacht-Design"-Icons mit dem orangeroten Hintergrund. Wir haben ja eine MicroSDHC-Speicherkarte, also Speicherplatz im Überfluss. Man könnte einfach die Nachtdesign-Icons da ablegen und genauso wie die anderen auch abrufen.

Aber der Bordcomputer soll auch im "Notlauf" noch bedienbar bleiben. "Notlauf" heißt, was machen wir, wenn die MicroSD-Karte mal versagt (eher unwahrscheinlich, aber kann ja mal sein)? Also speichern wir lieber alle kleinen Menü-Icons im Flash-Speicher im inneren des Chips. Somit stehen sie auch dann noch zur Verfügung, wenn die MicroSD-Karte mal streikt.

Problem ist nur, wir haben beim Atmega1284 nur 64KB der 128KB Flash-Speicherplatz zur Verfügung für Bilddateien. Überschreiten wir das, bootet der Chip nicht mehr. Und bei zwei kompletten Sätzen von Bilddateien, plus Zeichensätzen für die Ziffern, die auch zusätzlich im Nacht-Design abespeichert werden müssten, wird's da massiv eng.

Zweitens: es gibt nen "Trick". Die Darstellung von Bilddateien funktioniert auf dem Display so, dass man dem Display sagt "Schreib den Farbwert sowieso in Pixel XY".

Man könnte an dieser Stelle ganz einfach wenn man die Bilder aus dem Flash-Speicher lädt (wo sie auch nur als Abfolge von Pixel-Farb-Definitionen vorliegen) den Farbwert für weiß (die Hintergrundfarbe der Icons) per string replace mit einem anderen Farbwert ersetzen.

Allerdings sind dabei Grenzen gesetzt, da die Icons alle auf einem weißen Hintergrund gespeichert wurden. Bei der Kantenglättung wurden also für manche Pixel Mittelwerte zwischen Objekt-Farbe und Hintergrund gebildet. Man kann also die Hintergrundfarbe nur in gewissen Grenzen abdunkeln, bevor man helle Ränder um die Objekte in den Icon-Bilddateien sieht.

Ich hab das mal ausprobiert, und hab einen Farbwert gefunden, wo man "gerade soeben" noch keine deutlichen weißen Ränder um die Objekte herum sieht.



Das ist immer noch nen Tick heller als das Display im Auto, aber zusätzlich dazu wird die Display-Helligkeit bei Nachtbetrieb ja nur 75 Prozent der Tages-Helligkeit betragen. Allein dadurch wird es wahrscheinlich noch nen Tick dunkler erscheinen, sodass die Farben einigermassen gut angeglichen wären.

Ich denke, die Variante mit Farbe ersetzen pro Pixel ist die beste.

Momentan hab ich noch genug damit zu tun, überhaupt die Untermenüs zu programmieren. Aber sobald das einigermaßen unter Dach und Fach ist, könnte man das "Nacht-Design" dann mit ein paar zusätzlichen Befehlen implementieren.

Was zu beachten ist,
da durch Antialiasing an den Ziffer und sonstigen Grafik an den Rändern Graufstufen sind ( bei weißem Hintergrund ).
Wenn also nur 100%-weiß gegen orange tauscht wird, sind die erwähnten Ränder sehr unschön.
Bestens Beispiel ist mein quick-n-dirty-Nachtdesign, da sieht man es sehr gut.