Linksammlung - Projekte & Hilfe beim Programmieren für Carrera Digital

  • Moin zusammen!


    Ich selbst bin 2013 dem Forum beigetreten und brachte bereits ein bisschen Know-How in Elektronik und Programmieren von Mikrocontrollern (µC oder uC abgekürzt) mit. Zur damaligen Zeit waren schon etliche dabei, die Funktionsweisen von Carrera Digital Komponenten aufzudröseln, um eigene Projekte. Ganz oben natürlich der Fahrzeugdecoder. Mich freut es sehr, dass ich nach meiner langen Pause noch viele alte und neue Hasen sehe, die sich mit allerhand Projekten beschäftigen. Selbst habe ich allerhand angefangen und auch im Einsatz gehabt. Und immer wieder werde ich gefragt, wie man zum Beispiel den Manchester-Code aufschlüsselt. Da will ich gerne meine Erfahrung teilen und meine Sourcecodes bereitstellen.


    Worum soll es hier also gehen?
    Sofern ich die Zeit finde möchte ich fortlaufend eine Art Liste/Nachschlagwerk zusammenstellen. Etliche Dinge wiederholen sich ja und eine zentrale Anlaufstelle für Projekte wäre sicherlich hilfreich.


    Wer hat was gemacht?

    Wie programmiere ich was?



    Es klingt erstmal so, als passen die beiden Blöcke nicht ganz zusammen. Aber gerade im Hinblick auf die Entwicklung von digitalen Komponenten kann man sich so recht schnell Anregung und Hilfe holen.


    Cheers
    René

    2 Mal editiert, zuletzt von unrene ()

  • ebay Werbung
  • Der Manchester-Code
    ---------------------------
    Info: Carrera sendet alle möglichen Infos über die Bahn an die Slotcars, Weichen, Driver Displays, Startampel und so weiter. Dazu wird das Signal auf der (+)-Bahn modelliert und zwar im Manchester-Code. Dessen Decodierung ist also ein recht wichtiger Baustein in fast jedem Projekt. Warum wurde gerade der Manchester-Code gewählt? Er hat den Vorteil, dass egal ob eine "1" oder eine "0" gesendet wird, das Signal immer zu einer Hälfte "AN" und einer Hälfte "AUS" ist. Im Detail bedeutet das bei Carrera "AN"-"AUS" für eine "1" und "AUS"-"AN" für eine "0". Selbst wenn zehn Mal "0" gesendet wird, liegt in der Hälfte der Zeit die volle Spannung an, schließlich sollen die Slotcars nicht ungewollt stehen bleiben.


    Timings:
    - Takt: 50us
    - Bit "0": 50us LOW, dann 50us HIGH
    - Bit "1": 50us HIGH, dann 50us LOW


    Protokoll:
    - ein Startbit "1"
    - 7, 9 oder 12 Datenbits
    - Pitlane-Bit 150us LOW (Sonderfall in der Boxengasse, dient zum Tanken mit der Black Blox)
    - kein Stoppbit


    Überlegung:
    - Interrupts verwenden, INT0 + 8 Bit Timer mit 1us Takt
    - INT0 sensibel auf Flankenwechsel (fallend und steigend), dient zum Aufzeichnen der Bits
    - Timer Overflow dient zum Beenden der Aufzeichnung


    Ich habe so viel kommentiert, wie es geht. Im Code selbst wird viel mit Defines gearbeitet. Das hat den Vorteil, dass der Code leicht adaptierbar ist. Oben finden sich sich die verwendeten Defines. Weiterhin wird der Status der Aufzeichnung per Flags in der Ga_Data_Flags Variable hinterlegt. Dieser Code ist recht schlank, schnell und soweit auch ziemlich robust. Der Timer-Overflow wird nicht nur benutzt, das Ende der Aufzeichnung zu markieren, sondern auch zur Überprüfung eines Abflugs (TRACK_LOW für >10ms). Das nur so am Rande.



    In der MAIN-LOOP kann man dann auf Ga_Data_Flags (Status der Aufzeichnung), Ga_Data_Cnt (Länge des Datenworts) und Ga_Data (das aufgezeichnete Datenwort) zugreifen.
    Ist die Prüfung auf das Flag DATA_COMPLETE positiv, kann man das Datenwort auswerten. Dazu kann man den Typ anhand von Ga_Data_Cnt identifizieren. Es kann durchaus sein, dass die Aufzeichnung inmitten eines Datenworts anfängt (nach Weichenüberfahrt oder Abflug). Ein Programmierwort könnte dann als Reglerwort interpretiert werden. Wenn man auf Nummer sicher gehen will, dann kann man das erste Datenwort nach einer Unterbrechung sicherheitshalber ignorieren. Ich selbst hatte aber noch nie derartige Probleme festgestellt.



    Einmal editiert, zuletzt von unrene ()

  • Danke für den Thread!
    Das hilft sicher vielen die sich reintigern wollen, und vielleicht erwächst daraus ja das eine oder andere Community Projekt.

    Better-Faster, Innovation

    Einmal editiert, zuletzt von automated () aus folgendem Grund: Geänderte Rahmenbedingungen

  • Google Werbung
  • Mal wieder hoch damit!

    Schöne Link-Sammlung, möchte noch


    https://github.com/tkem/carreralib - Python Library zur Ansteuerung der Carrera Digital Control Unit


    und


    https://github.com/tkem/CarreraDigitalControlUnit - Carrera(R) Digital 124/132 interface library for Arduino and mbed OS


    beisteuern, auch wenn letztere ein wenig vernachlässigt ist..

  • Hallo,

    ich versuche mich gerade daran eine Programmier Box/Station für die Carrera Digital Autos auf Basis von einem Arduino Mega mit einem 3,8" tft touch zu basteln.


    WIe macht das die CU mit Speed und Brake? Wenn ich z.B. Speed verstelle, geht das an alle Autos auf der Bahn. Schickt dann die CU das Programmierdatenwort an jedes Fahrzeug d.h. 6 mal Programmierdatenwort mit jeweils einer ID von 1 bis 6?


    Gruß

  • Auf der Seite von slotbaer ist das Protokoll ausführlich beschrieben.
    Die Werte lassen sich für jedes Auto, bzw. jeden Regler separat schreiben. SmartRace macht das z.B so.
    Die CU schickt dann wohl 6 Nachrichten, da sie ja nur einen Knopf hat. (Ich habe es nicht nachgemessen, bin mir aber recht sicher.)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!