Beiträge von PhreakShow

Das Display wehrt sich immer noch mit Händen und Füßen. Zwischendurch etwas bodenständigeres: Ein Wechsel auf id6 mit nbt evo und atm.

IMG_8294.JPGIMG_8295.JPG

Für die Verbindung zwischen HU und ATM habe ich mir Adapter gebaut, um bei Bedarf wieder auf das NBT wechseln zu können. Ethernet schicke ich durch die alte HSD-Leitung, die vorher für USB zur TCB benutzt wurde.
Der 26-polige TCB-Stecker wird auf zwei sechspolige und einen 20-poligen Nano MQS verteilt. Nano MQS ist echt nicht schön zu crimpen, das Zeug ist so windig...

Ich hab ein "Bild". Der Signalweg über Displayport vom Notebook, HDMI vom Adapterboard über APIX zum HUD funktioniert also. Aber da stimmen wohl die Parameter noch nicht.

Man muss ja nicht nur die aktive Auflösung einstellen, sondern auch noch zig andere Optionen. Ich probiere es weiter...

IMG_8282.JPG

Edit: das "Bild" ist weniger kacke geworden, und mit ein wenig Phantasie erkennt man das Windows 10 Standardhintergrundbild

IMG_8283.JPG

IMG_8279.JPG

Ich habe einen APIX-Link. Endlich! Jetzt muss ich "nur" noch die korrekten Parameter fürs Display finden, und dem Indigo sagen dass er es anzeigen soll. Außerdem weiß ich aus den Datenblättern, dass da noch ein Watchdog sein Unwesen treiben könnte.

Also ohne Witz, so heftig wie sich das HUD wehrt, könnt man meinen da ist irgendwas im Busch. Ich krieg mit dem Board von oben ums Verrecken keinen Link hin, deswegen ein neuer Ansatz:

Das HUD hat, wie auch das CID, einen Indigo-Chip drauf. Im Prinzip ist das anscheinend ein Demultiplexer, oder De-Serializer. Aus dem APIX-Datenstrom werden Bilddaten, Steuerungsinfos für Hintergrundbeleuchtung, etc, entpackt und an die einzelnen Teilnehmer verteilt. Wenn ich einen Sender einstellen will, dass er mit dem Indigo reden kann, müssen beide das gleiche Protokoll sprechen. Das will ich nun rausfinden.

IMG_8271.JPG

Hier ein Foto der HUD-Platine. Links der Indigo, mittig der HSD-Anschluss. Nach was suchen wir?

Im Entwicklungsprozess muss es vmtl möglich gewesen sein, die Dinger zu debuggen, bevor es überhaupt einen Link zur Serie geben kann. Also suchen wir Lötpads, die unbestückt sind und mindestens eine handvoll Leitungen anbinden. Laut Datenblatt des Indigo ist die Verbindung per SPI möglich. Für SPI brauchen wir sinnvoll mindestens:

MOSI (Master out Slave in)
MISO (Master in Slave out)
Masse
Takt

Und oft noch Chipselect, damit der Teilnehmer weiß dass er gemeint ist. Also mindestens fünf Signale, wovon eines quasi überall auf der Platine verfügbar ist...

IMG_8275.jpg

Guck an, was haben wir da? Der Anordnung nach ist das der vorgesehene Platz für ein Widerstandsnetzwerk, wie man drumrum einige sieht. Ergibt auch Sinn, zur Sicherheit und Strombegrenzung kann man das mal machen.
Hinter dem rechten Kringel ist der gesuchte, unbestückte Header auf der Platine.

Was mich echt viel Zeit (mind. einen Tag) gekostet hat, war die korrekte Beschaltung mit Widerständen... nur in der Konfiguration bekomme ich hin und wieder Antworten vom Indigo:

IMG_8276.JPG

Ich hatte kein Netzwerk, deswegen habe ich zwei Pullups manuell eingelötet. Der eine hätte vmtl genügt, der zieht die ChipSelect-Leitung im Ruhezustand nach 5V, und wird von der Master-Gegenstelle bei Kommunikation nach Masse gezogen. Dann weiß der Indigo, dass er jetzt gemeint ist und ab gehts... jetzt hätt ich gern ein Abbild des Flashes, und ne Doku was wo steht

Würde TV in den Headunit-Optionen einschalten und das Videobild am CVBS-Eingang anschließen, da gibts sicher Adapter. Danach der HU noch "sagen" dass ein TV-Modul verbaut ist, und ab gehts.

Selten so einen Grampf gelesen wie Videos während der Fahrt. NiVi dauert aber noch, das HUD wehrt sich mit Händen und Füßen

Zum Thema Werkzeuge habe ich noch etwas. Wenn ich auf dem HUD endlich mal ein Bild bekomme, möchte ich ja zwischen Serienbild und Nivi-Bild umschalten. Dazu muss ich den APIX-Link trennen und neu verbinden.
Das kann man elektrisch tun über FPGAs und Scheiß, das ist ein riesen Fass das ich nicht öffnen möchte. Meine Hoffnung ist, dass die höchsten wesentlichen Frequenzen im APIX-Datenstrom klein genug sind um den Datenstrom mechanisch, mit einem HF-Relais zu schalten. Dazu muss ich wissen, was da denn so für Frequenzanteile drin ist.

Das kann man entweder über eine Fouriertransformation aller gemessenen Werte tun (wie das manche Oszilloskope können), über mit einem Heterodyn-Spektrumanalysator. Da Oszis über 1GHz sündhaft teuer sind, kommt bei mir letzteres zum Einsatz.

IMG_8267.JPG

Damit möchte ich dem APIX-Link zu Leibe rücken, sobald ich einen passenden Tastkopf habe. Davon hängt dann ab wie penibel ich die Leiterbahn auslegen muss, welche Leiterbahn-Längendifferenzen in Ordnung sind (abhängig von der Wellenlänge der Signale), etc. Aber noch fehlt mir ein APIX-Link...

Mal als Einschub zwischendurch, weil ich immer wieder Nachrichten bekomme in denen Leute fragen, mit welcher Hardware ich die Spielereien auf dem CAN und LIN anstelle:

IMG_8260.JPG

Bisher habe ich immer das obere Teil benutzt, das ist ein chipkit max32 mit dem Network Shield für 2x CAN, die kann man fertig kaufen.

Das hat aber Nachteile: Es sind keine Anschlusskabel dran, es ist riesig und sperrig, es gibt keine vernünftigen Gehäuse, es wird über einen Linearregler versorgt und bei der Menge an Peripherie wird der sauheiß.

Deswegen habe ich die letzten Wochen eine eigene Platine entwickelt, auch mit einem PIC32. Die hat 50mm x 37mm, passt in übliche Gehäuse und hat nur das nötigste drauf.
Zwei CAN-Transceiver (TJA1043 und 1042), erster kann den Linearregler bei Busaktivität einschalten, ansonsten ist alles spannungsfrei und kann an Dauerplus hängen.
Zwei LIN-Transceiver (bzw ein Gehäuse mit zwei integrierten, TJA1021 bzw TLE7268), kann auch bei Busaktivität den Regler wecken.
Ein Vierkanal-Highside-Treiber mit Bums, wenn man mal was schalten will.
Vier ADC-Eingänge zum Einlesen beliebiger Taster.

Das Ding hat zwar auch einen Linearregler, aber da habe ich mich absichtlich für entschieden. Schaltregler sind oft üble Strahlenkanonen und stören u.a. Radio- und GPS-Empfang.
Ich denke den werden wir im Forum noch öfter sehen

Sicherlich unterschiedliche Entwickler, das CID wird vom Alpine gebaut und das HUD schnitzt glaub ich der Conti. "Standard" ist so ne Sache, APIX ist in der Hinsicht wie CAN. Der kann ja auch mit 100kBit/ oder 1MBit/s oder allem dazwischen laufen, und APIX kann iirc 500MBit oder 1Gbit haben, APIX2 dann 3GBit. Aber das ist nicht der einzige Parameter den man braucht.

Danke. Das wird noch spannend

Gestern mal gaudihalber das HUD statt des CID angeschlossen, es kommt nicht mal ein APIX-Link zustande. Irgendeine Einstellung auf dem "physical layer" ist schon falsch.
Das Board hat eine Status-LED, die geht aus wenn der Link steht. Deswegen sieht man die auch nicht in meinem Foto. Beim HUD bleibt die an.

Das gemeine ist, die Firmware vom NBT ist schnell entpackt und durchsucht, weil ein richtiges Dateisystem dahinter steht.
Die Firmware vom Kombi habe entpackt vorliegen, und dort sehe ich einige APIX-relevante Daten, aber nicht die richtigen, wie mir scheint. Das Durchsuchen ist auch wesentlich schwieriger, weil das einfach ein Haufen hexadezimaler Werte in einem Hexeditor ist.