Decoder für D143 - Entwicklungsversuch!

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Na dann....

      Am Anfang gleich eine Info!

      Den Quellcode werde ich nicht als ganzen hier Posten, denn von "Copy & Paste" Code halte ich nichts.

      Allerdings werde ich alle Programmteile beschreiben so das der "geneigte Leser" alles wieder zusammengesetzt bekommt und am Ende auch weiß warum das funktioniert, oder auch nicht...... :huh:


      Etwas Theorie am Anfang.

      1. Alles was man über das Carrera Digitalsystem wissen muss steht hier:
      slotbaer.de/carrera-digital-12…9-cu-daten-protokoll.html

      2. Eine erste Idee wie die Decodierung des Bahnsignals funktionieren könnte, findet man hier:
      wasserstoffe.de/carrera-hacks/manchester-decode/index.html


      3. Auch sehr interessant ist dies hier, wenn auch die Software für einen anderen µC - Typ ist:

      redlichelectronics.de/datenuebertragung.html



      Mit den Infos von diesen Seiten kommt man schnell zu einem ersten Erfolg. Besonders der Arduino-Quellcode von Peter Niehues aus Link Nr.2 funktioniert sofort mit einem Arduino-Uno.

      Wenn man die Variable, die auf dem Seriellen Monitor ausgegeben wird, mit einer Switch --> Case Abfrage filtert und zu den 16 Geschwindigkeitsstufen jeweils ein analogWrite (0 für Stop, 16,32,48..... 255 für Vollgas) auf einen Pin legt, hat man eine funktionierende Drehzahlsteuerung für eine Fahrzeug-ID.


      Das ganze ist aber noch sehr rudimentär. Drückt man die Spurwechseltaste funktioniert es nicht mehr, weil das Datenwort ja als ganzes ausgewertet wird.


      Mein Ansatz ist ja außerdem einen kleinen ATTiny25 zu verwenden, oder wenn der Speicher knapp wird, auch einen 45 oder 85, mit 4 oder 8 kbyte.
      Grund dafür, ich möchte mich zuerst nur auf die Software konzentrieren und das erstellen einer Platine danach angehen. Die Software soll auf den originalen D143 Decodern erprobt werden.
      Somit kann man Hardwareprobleme ausschließen und braucht Fehler nur in der Software zu suchen. Inzwischen hab ich festgestellt das der Decoder recht sensibel auf lange Drähte reagiert.
      Besonders die Leitung vom µC zum Motor-FET ist da sehr kritisch. Ich denke das die recht hohe 30kHz PWM daran Schuld ist.

      Als Konsequenz daraus muss das Programm also ohne die Arduino Funktionen auskommen, da einige Funktionen auf den Tiny´s nicht laufen und wenn doch, zu viel Speicher verbrauchen.
      Ich nutze jetzt das Atmel Studio mit AVR GCC als Compiler und AVRDude zum Übertragen des Programms. Als Programmierhardware habe ich zuerst einen Arduino-Uno mit der "Arduion-ISP" Software genutzt.
      Das ist schnell zurecht gebaut und funktioniert auch im Atmel Studio problemlos. Inzwischen hab ich ein paar USBASP V2 angeschafft. Gibts in der Bucht für 2-3 Euro. Funktionieren gut, hat aber kein Gehäuse und unter Win10 ist die Treiberinstallation etwas umständlich (keine signierten Treiber).

      Wer also bereit ist sich einen USBASP anzuschaffen und einen D143 Decoder zu "opfern" , kann hier sofort mit experimentieren. Dazu werden 5 Stifte auf den Decoder gelötet und einer auf den Pluspol des Elkos.
      Das nach außen führen der Kontakte hat sich letztlich als als nicht gut erwiesen, da es durch die Drähte zu Störungen kommen kann. An den USBASP hab ich zwei Servokabel angelötet. Perfekt wäre in 5poliger und ein 1poliger Stecker.

      USBASP.jpg


      Fortsetzung folgt....

      Gruß
      Enrico



      P.S. Wenn man für den USBASP 4-5 Euro investiert bekommt man ihn aus Deutschland und somit nach 2-3 Tagen. Die ganz billigen kommen direkt aus Fernost!

      The post was edited 1 time, last by ElCheffe ().

    • ....und weiter gehts.

      Nachdem nun klar ist welche Hardware zum Einsatz kommt und wie diese Programmiert wird kommt jetzt die Software dran.

      Wie aus den Links im Beitrag oben zu sehen ist schickt die CU (oder die RedBox) kontinuierlich 10 verschiedene Datenwörter.
      Unser µC soll jetzt diese Datenwörter empfangen und auswerten.

      Dazu ist es zuerst notwendig das sich der µC mit dem Datenstrom der CU synchronisiert, sprich der µC muss den Anfang eines Datenwortes erkennen.
      Auf dem Oszilloskope sieht das so aus. Die Datenworte sind gelb und blau das auf das Startbit synchronisierte Signal des µC.

      VOLTCRAFT109_1.gif


      Damit man weiß was der µC gerade tut schaltet man einen I/O Pin zur rechten Zeit ein und aus. Daraus entsteht die blaue Kurve.

      An der Stelle im Code an dem der µC eine Startbit erkennen soll schalte ich den "Debug-Pin" auf High, beim nächsten Starbit dann auf Low, usw.
      Für diese High/Low Umschaltung gibt es einen eigenen Befehl, der den Pin immer automatisch umschaltet, toggelt.

      DDRB |= (1 << PB2); // Pin B2 wird als Ausgang gesetzt --> Debug Ausgang
      PORTB ^= (1 << PB2); // Pin B2 Toggeln

      Die Schreibweise ist bildlich....

      DDRB --> Datenrichtungsregister 0-Eingang,1-Ausgang
      |= -->logische ODER Verknüpfung
      (1 << PB2) --> in das Bit2 wird eine 1 geschoben

      Als nächstes brauchen wir einen Sync. auf jedes Bit des Datenwortes und zwar immer in der Bitmitte, denn dort sieht man ob das Bit eine 0 oder eine 1 ist.
      Das sieht dann so aus.

      VOLTCRAFT109_2.gif

      Ohne Debug-Ausgang kommt man beim µC Programmieren nicht weit. Die Arduinos haben ja meist eine serielle Schnittstelle so das man wenigstens Daten auf den PC ausgeben kann. Die Tinys hab so was nicht, aber durch das geschickte toggeln eines Ports kann man auch viel mehr Infos bekommen. Ein Oszilloskope braucht man allerdings.

      Jetzt muss man nur noch an der Stelle wo der Debug-Ausgang getoggelt wird dann Pin Abfragen ober er High oder Low ist.


      if (!(PINB & (1 << PB4))){ // wenn der Pin Low ist...
      neuesDatenBit |= 1; } // ist das Bit 1....

      Die Schreibweise mit den logischen Verknüpfungen sieht im erstem Moment etwas kryptisch aus.... 8|
      Das Ergebnis ist 1, wenn der negierte Pin4 ( bei Low ) UND die 1 << beide 1 sind , was ja bei LOW der Fall ist.... :pillepalle:
      Egal, wir nehmen das so hin.

      Jetzt ist es nur noch wichtig den richtigen Zeitpunkt für diese Abfrage zu finden.

      Dafür braucht man Interrupts, um den wechselnden Pegel im Pin zu erkennen und anschließend Timer, um die Zeit zwischen den Flanken zu messen.

      Bis zum nächsten mal...
      Gruß
      Enrico

      P.S. bei Unklarheiten einfach nachfragen...