Ich schmeiß mal meine aktuellen Gedanken dazu in den Raum.
Technisch wäre das absolut kein Problem. Als Controller kommt hier ein teensy 4.0 zum einsatz, welcher diverse Anschlüsse von Haus aus mit sich bringt.
Dazu zählen:
3x CAN Bus (1x sogar mit CAN FD)
3x SPI Bus
3x I2C Bus
14x Analoge Inputs
6x Serielle Ports (RS232)
Nicht alle dieser Ports sind gleichzeitig nutzbar, aber das ist kein Problem.
Als Version des MicoKIs nehmen wir für diesen Gedankengang nun mal eine Version, welche nur das nötigste mit sich bringt. Ich habe sie "P1.2 only CAN" genannt und wir haben hier folgende Anschlüsse:
1x CAN (z.B. für den Antriebs CAN vom T5.1)
1x Externe Batterie (z.B. 2. Batterie unterm Sitz)
6x Ausgang für kleine Displays kombiniert mit den Tastern zum weiter schalten.
6 Buttons sind direkt auf der Platine integriert, die externen sind nur optional und nicht nötig zum betreiben von dem ganzen.
(PS: Ja ich weiß, dass das MicroKI falsch geschrieben ist
)
(unten drunter sind die Taster für die LCDs, davon habe ich gerade nur kein Bild)
Schauen wir uns hierzu mal die rein technische Seite an. genau genommen die Belegung am teensy Microcontroller (den gesamten Schaltplan habe ich auch mal angehangen)
Auch ohne viel technisches Verständniss erkennt man schnell, das kaum Pins genutzt werden. Das liegt an folgendem:
Die OLED Displays werden über den I2C Bus angesteuert und haben eine feste I2C Adresse. Man kann diese ändern, aber nicht unlimitiert. Von Haus aus stehen 2 verschiedene Adressen zur verfügung. Und um diese zu ändern, muss man auf der Platine von den LCDs etwas umlöten. Möchte man nun auf 2 verschiedenen Displays etwas unterschiedliches anzeigen lassen, benötigt jedes Display am selben Bus eine individuelle Adresse. Möchte man aber nun mehrere Geräte an einem Bus mit der selben Adresse nutzen, benötigt man etwas das sich "I2C Multiplexer" nennt.
In unserem Beispiel hier ein TCA9548APWR. Dieser kann bis zu 8 Geräte Multiplexen, 6 davon werden aber nur genutzt. Dadurch schaffen wir es, 6 OLED Displays separat mit nur einem I2C Bus an zu steuern ohne auch irgendwas an den Displays umlöten zu müssen.
6 weitere Eingänge am teensy werden für die Taster zum umschalten der angezeigten Informationen genutzt. Diese können aber mit beliebigen Eingängen am Microcontroller verbunden werden. Über die Widerstände liegt ein hier ein ständiges "HIGH" an und beim drücken auf den taster werden diese gegen Masse geschaltet und erzeugen so ein "LOW".
2 weitere Pins gehen für den CAN Bus drauf (Siehe CRX/CTX am teensy). hier hängt ein SN65HVD232QDR Tranceiver dran. Ansonsten benötigen wir noch 4 weitere Pins. 3x Analoge Eingänge zum messen der Hauptbatterie Spannung, Spannung der 2. batterie und als Eingang für den Öl Druck. Letzteres gibts auf dem CAN Bus vom T5 etc. einfach nicht. Der letzte Pin kann wieder frei gewählt werden, er gibt nur die +3,3V für die Displays frei.
Mit diesem Wissen im Hinterkopf schauen wir uns mal die Geschichte mit dem Radio sowie den "verschiedenen" Displays an.
Radio
Hier kommt es drauf an, was verbaut ist. Ich habe z.B. einen T5.1 mit einem Discover Media. Das Discover versteht jedoch die Nachrichten vom Bus nicht, somit muss übersetzt werden. Dafür benötigt es einen zweiten CAN Anschluss am MicroKI. So wie bei meinem MicroBCM, welches aktuell zum testen verbaut ist.
"CAN2" wird am teensy für die Abfrage des Motor CANs (Antriebs CAN) genutzt, bleiben uns also noch 2 weitere. Beide sind auch noch nicht belegt, welchem man nimmt hängt vom Layout der Platine ab. CAN FD brauchen wir eh nicht, also nehmen wir den, der zum Routen einfacher ist.
Andere Displays
Displays wie vom Scangauge machen meiner Meinung nach absolut keinen Sinn. Ich finde die einfach zu Oldschool und vom Design her "störend" für solch ein "modernes" Auto. Aber wie immer Geschmacksache, anderen gefällts.
Aber da das hier ja ein reines "Gedanken rein werfen" von mir ist, machen wir mal weiter.
Oldschool monochrom Displays fallen also raus, nur was dann nehmen? Richtig, moderne TFT LCDs. andere OLEDs wie das aktuell von mir verwendete nehme ich mal raus, viele davon funktionieren bereits am I2C Bus. somit muss man nur die Sachen für die neue Auflösung im Code anpassen und darauf achten, dass die Leistungsaufnahme der LCDs nicht zu groß wird. eventuell muss man die Spannungsversorgung größer dimmensionieren.
TFT Möglichkeit 1
z.B. Touch LCDs mit ILI9341 Treiber (
KLICK MICH HART). Werden über SPI angesteuert, SPI verwenden wir bisher gar nicht vom teensy. Der 3. SPI Bus ist auch komplett unbelegt, kann also problemlos verwendet werden. Einzige Sache ist halt, die programmieren für solch ein Display ist schon nicht zu unterschätzen. Bei dieser Variante kommen nämlich alle Daten vom Microcontroller und müssen auch dementsprechend verarbeitet werden. Alle touch Befehle, alle Grafischen kleinigkeiten etc.
Aber durchaus möglich. Ich brauchs nicht, somit werde ich es auch erstmal nicht machen. Ist einfach brutal aufwendig und kostet sehr viel Zeit. Aber möglich und leicht Hardware technisch zu implementieren.
TFT Möglichkeit 2
Eine Variante welche recht schnell zum Ziel führt und tatsächlich gar nicht mal schlecht funktioniert. Ich habe damit schon mehrere Projekte umgesetzt.
Es ist die rede von Displays des Herstellers "Nextion".
KLICK MICH EBENFALLS RICHTIG HART
Das besondere an diesen Displays ist, dass sie bereits eine eigene "Logik" enthalten. Mit hilfe des Nextion Editors kann man recht schnell und einfach eine grafische Oberfläche erzeugen, ganz wie es einem passt. Jedes Element erhält eine klar zugewiesene ID, welche man ansteuern kann. Die Daten empfängt das Display über Seriell (RS232). Man findet bei Youtube genügend Videos dazu
GUCKST DU Z.B. HIER (Ist nur ein Beispiel, man bekommt die Oberflächen grafisch auch sehr ansprechend hin
). Das ganze natürlich mit Touch.
Hierfür bräuchten wir sogar nur einen Seriellen Port am teensy zu belegen (TX/RX), wovon definitiv noch genug frei sind. Simple, aber effektiv.
So, mein Kopf raucht, bin erstmal raus für heute. Und sorry für Rechtschreibfehler
