In diversen Foren liest man immer wieder recht widersprüchliche Aussagen zur sogenannten „MCU“ in den Naviceivern – deshalb hier einige Gedanken dazu:
Eigentlich ist es bei dieser Thematik völlig irrelevant, ob es sich um ein „generisches Android“ oder ein WinCE Gerät handelt – im Grunde sind beide Varianten eine Ansammlung verschiedener Systeme, die zusammen arbeiten sollen um sie über ein einzelnes Interface bedienen zu können. Es ist wichtig diese Komponenten und ihre Zusammenarbeit zu kennen, um daraus resultierende Probleme und Vorteile erklären zu können.
Die Ausgangslage
Immer wieder liest man „die halten sich nicht an den „Androidstandard“, „wieso funktioniert Bluetooth nicht so und so“ etc. Der erste Gedanke wäre doch: Wieso schnalle ich nicht mein Tablet ins Auto? Hier habe ich die notwendige Rechenpower, ein Touchscreen und unzählige Apps?
Das ist natürlich möglich und haben auch schon viele gemacht – aber abgesehen von ästhetischen Gründen ist dies mit einigen teils lästigen Einschränkungen verbunden.
- Soundkontrolle: Wir sind gewöhnt an Fader, Balance, Verstärkeraus- und eingänge etc. Wir benötigen die hierfür notwendigen Anschlüsse und deren Signalsteuerung zum Soundprozessor TDA7419
- Videosignale: Eingang der Rückfahrkamera, Ausgänge für eigene Bildschirme für die Quälgeister der 2. Bank, DVD Signal etc. Auch hier wieder: Anschlüsse und deren Steuerung
- DVD / CD Wiedergabe: Derzeit nicht nativ in Android unterstützt!
- Bluetooth: Während die meisten Androidgeräte wie Telefone die notwendigen Bluetoothprofile als CLIENT unterstützen, benötigen wir hier hingegen einen „Host“ Modus. Aus diesem Grund sind wir auf zusätzliche Bluetooth-Hardware angewiesen, welche seriell mit Android kommuniziert und daher nicht wie gewohnt „sichtbar“ ist.
- CAN Integration für Lenkradtasten usw.
- Hardware-Tasten samt Beleuchtung muss gesteuert werden
- Iphone/Ipod Interfaces
- Einschaltverhalten in Bezug auf Zündung etc. muss gesteuert werden
- Radio-Tuner: Ein paar wenige werden von Android direkt unterstützt
Die MCU
Die MCU ist ein Mikrokontroller um die oben genannten Funktionen zu steuern – im AV7 ein STM32F100 mit 24Mhz und einem Flashspeicher (hierher wird beim MCU Update die letou_mcu.bin geschrieben).
Dieses Programm (letou_mcu) kümmert sich um die Steuerung der einzelnen Komponenten – das Androidsystem als „Frontend“ ist eines davon. Somit registriert beispielsweise die MCU den Tastendruck eines Hardwarebuttons und meldet dies an ein Androidprogramm weiter, welches dann die Aktion innerhalb Android ausführt.
Die MCU kümmert sich auch im die Umschaltung der verschiedenen Eingangs- und Ausgangsignale… z.b. beim Rückwärtsgang liegt ein 12V Signal an -> MCU schaltet den Grafikchip des Bildschirms auf den externen Eingang der Rückfahrkamera an und schaltet den Lautsprecherausgang des Soundchips TDA7419 leise. So ist zu erklären, dass die Rückfahrkamera „sofort“ nach Stromzufuhr zur Verfügung steht während das Betriebsystem Android noch hochfährt.
Analog verhält es sich mit dem oben erwähnten Bluetoothmodul – auch deshalb ist die Freisprechfunktion „sofort“ verfügbar – mit dem Nachteil, dass die Bluetoothfunktion wegen der Hostfunktionen der Profile praktisch „extern“ via Seriell gesteuert werden muss und nicht wie man es zb. am Handy gewohnt ist.
Da die MCU auch wesentlich weniger Strom verbraucht wie das Android/WinCE System bleibt dieses auch bis zur Busruhe „eingeschalten“ und kann auf Einschaltsignale des CAN Bus hören.
Auch die Kommunikation zum Radiochip TEF6624T übernimmt die MCU und „vermittelt“ die gewünschte Frequenz dem Radiochip und meldet z.b. RDS Daten retour.
Bedenkt man nun dieses notwendige Zusammenspiel zwischen „externen“ Kompententen -> MCU -> Android via Kerneltreiber oder Systemapp, so ergibt sich nun ein wesentlich besserer Blick auf gewisse Einschränkungen und Vorteile in der Benutzung.
Somit dürfte klar sein, wieso zB Bluetooth „nicht wie gewohnt“ funktioniert sondern auf anderem Wege implementiert werden musste, wieso nicht eine x-beliebige Radioapp funktioniert etc.
Schreibe einen Kommentar