Steuerung der Becker Indianapolis (PRO) und Pioneer Radios mit BMW Multifunktionslenkrad

Hemi

Aktives Mitglied
Premium Benutzer
30. Nov. 2008
1.103
19
38
Korntal-Münchingen, Germany
Sprachen
  1. ANSI C
  2. C++
  3. PHP
  4. Java
Hallo zusammen,

während der Corona-Krise hat man ja etwas mehr Zeit zum Basteln, also habe ich mich mal hingesetzt und das lange vor mir her geschobene Projekt verwirklicht.

Um was geht es? Es gibt in den älteren BMW Multifunktionslenkräder (MFL) mit denen man das Tempomat und Radio steuern kann. Und es gibt auch Radios die damit gesteuert werden können. Es geht also darum, das BMW MFL mit einem Fremdradio zu verheiraten. Und da ist zwei unterschiedliche Geräte hätte (Pioneer AVIC-X3 ist aktuell drin und ein zeitgenössisches Becker Indianapolis PRO ist im Schrank), habe ich dieses Interface gebaut.

Das Interface beherrscht grundsätzlich zwei Arten der Kommunikation:
  • RS232 (für Becker Traffic Pro High Speed / Traffic Pro / DTM / Indianapolis (PRO) / Cascade und Konsorten)
  • Widerstandswerte (Pioneer / JVC / Sony / Blaupunkt / ...)
Das Interface hat diese Funktionalität:
  • Pioneer Radios steuern (Liste oben)
  • Becker Radios steuern (Liste oben)
  • die Helligkeit der Tasten des MFLs regeln, in Abhängigkeit von dem Regler im Armaturenbrett

Das MFL kummuniziert über IBus mit dem Fahrzeug (bzw. Interface) und weiter geht es über Widerstandswerte, bzw. RS232. Hier habe ich einen Elmos E910.15 Transceiver verwendet, für RS232 einen MAX232 und die Widerstandswerte erzeugt ein Microchip MCP42050 (dual 50k 8bit DigiPot). Den Schaltplan und Layout (Eagle 8.5.1 Projekt) habe ich angehägt und den aktuellen Stand der Firmware (als Atmel Studio 7 Projekt) ebenfalls. Vielleicht kann es jemand gebrauchen.

Die fertige Platine sieht so aus:

1587816489884.png

Es fehlt noch die TVS-Diode und OpAmp für ADC-Puffer (Microchip MCP601), wenn Reichelt nicht so ewig brauchen würde, wären sie schon drauf.
 

Anhänge

  • Radiomodul.zip
    159,5 KB · Aufrufe: 3
  • BeckerPioneerFW.zip
    111,6 KB · Aufrufe: 3
  • Like
  • Love
Reaktionen: Ditron und Dirk
Danke schön Ihr Beide! :)

So gut ist es leider doch nicht. Es ist ein Fehler auf der Platine, ich bin zu doof den MAX232 richtig zu verschalten... ist echt ärgerlich, aber nunja, so ist es halt. Nun glüht der Chip, mit ihm zusammen glüht auch der Spannungsregler... glaube, bei meinen Test hat der MAX232 einen Schlag abbekommen.

Ich habe dann das "Problem" ausgenutzt und ein neues Layout erstellt. Änderungen:

-> MAX232 Beschaltung korrigiert
-> den MCP42050 rausgeschmissen und einen AD5293 verwendet, 10 bit, SPI, ein Kanal, 100k

An der Software auch viel gedreht, viel mit Timer und Semaphoren :)
 

Anhänge

  • Radiomodul.zip
    106,8 KB · Aufrufe: 3
  • BeckerPioneerFW.zip
    117,4 KB · Aufrufe: 4
Nur durch Fehler sammelt man Erfahrungen ;-)

Ein tolles Projekt, wünsche dir viel Erfolg für die nächste Version.
 
Ja, da hast Du schon Recht, auch wenn es doch ätzend ist...

Hab jetzt bei der fehlerhaften Platine den MAX232 runtergelötet und siehe da, sie läuft wieder stabil. So kann ich wenigstens weiterentwickeln, bis die neue kommt. Die Helligkeitsregelung geht jetzt auch, über einen 300ms Scheduler, der die Helligkeit der Tasten setzt. ADC läuft im 8-bit free-run Modus und der Wert wird an die Tasten geschickt. So bleibt die Buslast auch schön niedrig.
 
  • Like
Reaktionen: Ditron
Was war denn das Problem beim MAX? Bei einem der Kanäle die Richtung vertauscht? Da war ich(!) mir immer nicht sicher, deswegen jedesmal ein Blick ins Datenblatt zum Funktionsblock des IC geworfen...
 
So habe ich es gemacht:

1588329010347.png

Und so sollte es sein:

1588328935484.png

Die Werte hätte ich ja noch korrigieren können, aber auch nur die...
 
Die Werte hätte ich ja noch korrigieren können, aber auch nur die...
Also bei meinem MAX232CWE konnte man 100nF nehmen, aber Kerkos tauschen wäre ja machbar...
Als Workaround hätte ich den falschen C9 rausgenommen, und auf die beiden Pads je einen Kerko hochkant gelötet (ggf Kapton-Folie dazwischengeklemmt), und dann von oben mit Drahtbrücken entweder zu C6 oder an die Beine vom MAX selbst (wobei der Kerko wahrscheinlich besser wäre)...
Nur durch Fehler sammelt man Erfahrungen
typischer Fall von … "verdammte Kacke";)
P.S.: mein MAX232CWE
Img_5835a.jpg
 
Hi,

ja ja ... der MAX. Da gibt es auch verschiedene Versionen. Manche laufen problemlos mit 100nF und manche benötigen mindestens 1uF. Hängt wohl mit der verwendeten Wandlerfrequenz zusammen.

Das mit den Pufferkondensatoren am Ausgang des Wandlers ist natürlich blöd. So wie LotadaC schon geschrieben hat, hätte man da ein wenig "ferkeln" können um die Platine soweit vollständig zum laufen zu bekommen. Machen die in der Industrie mit den Fädeldrähten ja auch nicht anders :sarcastic:Da gibt es auch öfters frei fliegende Bauteile. Bei vertauschten Pins wär das schon ätzender gewesen.

Gruß
Dino
 
Ja, der MAX ist nervig... ich dachte, aja, MAX ist MAX, ja Pustekuchen...

Ich habe den von TI verwendet und der will eben 1uF Kondensatoren haben, das blöde Ding. Das wäre ja sehr einfach fixbar, wenn der Fehler mit dem C9 nicht wäre. Aber es waren keine Leitungen vertauscht oder sowas, also kein Problem. Auf der fehlerhaften Platine habe ich es ja gefixt, mit THT-Kerkos, es scheint aber den MAX wirklich verblasen zu haben, daher kam ein neuer rein, der auch funktioniert. Einbauen würde ich es so aber nicht, weil Vibrationen und so :)

Ich habe auch den MCP42050 rausgeschmissen, das Ding ist eher ein Schätzeisen... die berechneten Werte liegen weit von den Echten weg. Mal schauen, was der AD5293 dazu sagt.
 
hallo zusammen,

ich brauche mal Eure Hilfe, ich weiß nicht mehr weiter.

Erst einpaar Worte zum "Vorgang":

0. Der DigiPot ist im Shutdown-Mode (per Hardware, also Pin /SHDN ist low), der Widerstand ist unendlich
1. Man drückt auf einen Knopf, sagen wir mal "leiser"
2. das bewirkt, dass beide Register im DigiPot gesetzt werden und der DigiPot den Shutdown-Mode verlässt, Gleichzeitig wird ein Timer aufgezogen, der alle 10ms feuert (TIMER4_OVF_vect, den Zweig _is_in_init bitte wegdenken)
3. Nun wird dieses Interrupt mehrmals angesprungen und dabei die Variable timerEventCounter hochgezählt
4. wenn sie bei 8 angekommen ist, wird ein Befehl ausgeführt (per UART ein String verschickt)
5. wenn sie bei 10 angekommen ist, wird der DigiPot in den Shutdown-Mode versetzt und Timer4 abgeschaltet.

Hier ist die ISR, die das regelt:


CodeBox C
ISR(TIMER4_OVF_vect)
{   
    static uint8_t timerEventCounter = 0;
    static uint8_t msgCounter = 0;
   
    if(_is_in_init)
    {
        if (msgCounter < 8)
        {
            TCNT4 = 34286;
            becker_send_init();
            msgCounter++;
        }
        else
        {
            _is_in_init = false;
            becker_disable_init_timer();
        }
    }
   
    if(_to_be_released)
    {
        TCNT4 = 63036;
        timerEventCounter++;
               
        if (timerEventCounter == 8)
        {
            becker_send_release();
        }
       
        if (timerEventCounter == 10)
        {
            pioneer_send_release();
            _to_be_released = false;
            stop_release_timer();
            timerEventCounter = 0;
        }
    }
}


Nun zu meinem Problem:

--> Wenn ich das Programm im Debugger laufen lasse und die ISR durchsteppe, sieht alles top aus. Die Werte werden in den DigiPot geschrieben, er wird aktiviert, dann wieder deaktiviert, auch wenn mehrere Befehle hintereinander ausgeführt werden, lauter, leister, nächster Sender, alles kein Problem.
-> Wenn ich das Programm einfach flashe, dann wird der Wert in den DigiPot geschrieben und der DigiPot aktiviert. Aber, er wird niemals deaktiviert... und so bleibt er bei einem bestimmten Widerstand stehen...

Ich bin mit meinem Latein am Ende und weiß echt nicht mehr weiter. Die IDE ist Microchip Studio 7.0.

Danke Euch im Voraus!
 
Nochmal langsam:
Im Debugger, mit echter Hardware durchgesteppt gehts, im normalen Durchlauf nicht.

Hast Du die übertragenen Strings mal mit einem Terminal verfolgt, oder besser mit einem LA (um das Timing zu checken?)

Wenn's im Einzelschritt-Debugging geht und sonst nicht, schreit das doch auf den ersten Blick nach einem Timing-Problem...
(also daß das Poti damit überfordert ist)
 
wenn ich das richtig verstehe dann zählt dein Interrupt ja im Hintergrund weiter, bleiben also 20ms um zu senden - was passiert wenn's länger dauert?
kannst du es ändern auf
timerEventCounter >= 10
 

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)