-         

Ergebnis 1 bis 10 von 10

Thema: Multiplikation in ass

  1. #1
    Benutzer Stammmitglied
    Registriert seit
    03.03.2006
    Ort
    München
    Beiträge
    32

    Multiplikation in ass

    Anzeige

    Hallo
    Bei meinem assemblerprogramm rechnet mir der mul Befehl falsch (oder liegt der Fehler bei mir?)
    bei
    mul r23,r24
    push r0
    .
    .
    .
    pop r23
    weiter....
    Ich rechne nur mit r21 - r24, habe keine calls oder so was den Stack betrifft.
    Es geht zwar im Bascom - Simulator aber im richtigen Leben steht in r0 nur Null drin,
    Kann man da überhaupt was falsch machen?
    Günther

  2. #2
    Erfahrener Benutzer Robotik Einstein Avatar von SprinterSB
    Registriert seit
    09.06.2005
    Ort
    An der Saar
    Beiträge
    2.801
    -- Deine push-pop Reihenfolge stimmt nicht?
    -- Du verwendest das Programm auf einem AVR, der keine Multiplikation kann ?
    -- Da hast den Stackpointer nicht richtig initialisiert?
    -- Dein Heap überlappt sich mit dem Stack?
    Disclaimer: none. Sue me.

  3. #3
    Benutzer Stammmitglied
    Registriert seit
    03.03.2006
    Ort
    München
    Beiträge
    32
    @ SprinterSB
    push - pop stimmen. Ich lade und schiebe dazwischen nur einige Register
    der 8535 kann multiplizieren
    Zum Rest:
    ich verwende den assembler als Unterprogramm in Bascom . Stack und Heap werden da schon richtig verwaltet (hoffentlich)
    Ich bin ratlos
    Günther

  4. #4
    Benutzer Stammmitglied
    Registriert seit
    03.03.2006
    Ort
    München
    Beiträge
    32
    @ SprinterSB
    Ich hab auf Deiner Seite gesehen,dass Du mit dem dcf77 schon was gemacht hast.
    Dann ist Dir mein Problem sicher bekannt.
    Minuten=bit 21-24
    Stunden=bit 25-27
    Um die Stunden mit 10 zu multiplizieren und dann mit den Minuten zu addieren hab ich ein Unterprogramm in ass geschrieben.
    Weil der mul Befehl nicht geht hab ichs mit lsl-pop und add befehlen gelöst, was aber Umständlich ist

  5. #5
    Erfahrener Benutzer Robotik Einstein Avatar von wkrug
    Registriert seit
    17.08.2006
    Ort
    Dietfurt
    Beiträge
    1.892
    Wenn Du 2x 8 Bit Zahlen multiplizierst kann doch dabei ein 16 Bit Ergebnis rauskommen ?
    Hast Du unter Umständen das 2te Byte ignoriert ?

    Ich bin mir jetzt nicht ganz sicher ob für den MUL Befehl alle Register als Quell - und Zielregister zulässig sind.

    Das sollte sich aber mit dem Datenblatt des jeweiligen Controllers ermitteln lassen.
    Das würde auch die Funktion im Simulator erklären, obwohl es im Ziel Controller nicht geht.

  6. #6
    Benutzer Stammmitglied
    Registriert seit
    03.03.2006
    Ort
    München
    Beiträge
    32
    @ wkrug
    Es könnte natürlich > 256 rauskommen. Ich mul aber nur max dec8 mit 10 (bei dcf77 = Jahreszehner) also max dec 80.
    Beim 8535 sind zur mul die reg 0 bis 31 zulässig, ich benutze die reg 21-24.
    Geht aber doch nicht
    Günther

  7. #7
    Erfahrener Benutzer Robotik Einstein Avatar von SprinterSB
    Registriert seit
    09.06.2005
    Ort
    An der Saar
    Beiträge
    2.801
    Hmmm

    Ich sehe jetzt nicht, wo man bei der DCF77-Decodierung multiplizieren müsste.

    Mein DCF77-Decoder (in C) ist noch nicht fertig dokumentiert.
    http://freenet-homepage.de/gjl/pub/c-code/dcf77.html

    Die BCD-Decodierung mache ich ohne zu multiplizieren, weil ich kleinen Code haben will (nicht jede Maschine kann multiplizieren)
    Code:
    // Avoid Multiplication
    unsigned char decode_BCD (unsigned char x)
    {
        unsigned char y = x & 0xf0;
        x &= 0xf;
        x += y >> 1;
        x += y >> 3;
        return x;
    }


    AFAIK gibt es hier von Al Bundy eine DCF-Decoder-Lib für BASCOM.
    Disclaimer: none. Sue me.

  8. #8
    Benutzer Stammmitglied
    Registriert seit
    03.03.2006
    Ort
    München
    Beiträge
    32
    Ich habs so gelöst (Minutendekodierung)
    Code:
       lds r22,{dcfbit+26}
       lsl r22
    
       lds r23,{dcfbit+25}
       add r23,r22
       lsl r23
    
       lds r22,{dcfbit+24}
       add r22,r23
    
       !Call Mul10                                              'in R23 = ZehnerMinute
        push r22
       '*** bis hier sind die Minuten - Zehner berechnet jetzt kommen die Einer dran
    
       lds r22,{dcfbit+23}
       lsl r22
    
       lds r23,{dcfbit+22}
       add r23,r22
       lsl r23
    
       lds r22,{dcfbit+21}
       add r22,r23
       lsl r22
    
       lds r23,{dcfbit+20}
       add r23,r22
    
       pop r22
       add r23,r22
       sts {Minute},r23
    Gehts einfacher? (mul10 = multiplikation mit 10)

  9. #9
    Erfahrener Benutzer Robotik Einstein Avatar von SprinterSB
    Registriert seit
    09.06.2005
    Ort
    An der Saar
    Beiträge
    2.801
    Die Frage ist, was "einfach" ist

    Einfach ist in erster Linie das, was du gut nachvollziehen kannst -- auch noch in 3 Monaten.

    DCF-Auswertung ist mE schon etwas aufwändiger, ich brauche schon rund 500 Bytes Code dafür (DCF-Auswertung, Parity-Check, Zeit weiterlaufen lassen, wenn kein DCF-Signal da ist, Integritätscheck des Signals, ...)

    Wichtig ist ja erst mal daß es funktioniert.

    Vielleicht ist besser, die Bits nicht in einzelnen Bytes zu speichern, sondern direkt in die richtigen Bitpositionen innerhalb des zu empfangenden Wertes? Dazu brauchst du dann allerdings eine Tabelle, wieviel Bits jeder einzelne Wert hat (7 für Minute, 3 für Wochentag, ...) Die BCD-Decodierung ginge dann in einer Funktion.
    Disclaimer: none. Sue me.

  10. #10
    Benutzer Stammmitglied
    Registriert seit
    03.03.2006
    Ort
    München
    Beiträge
    32
    Das ist natürlich aufwendiger.
    Eleganter gehts natürlich auch.
    Die dcf77 Uhr ist Teil einer Heizungssteuerung und die läuft auch.
    Bisher war die dekodierung ein Unterprogramm in Bascom die ich einfach mal in ass programmieren wollte, praktisch learning by doing. Deshalb muss ich mich an die vorgegebene Programmstruktur halten.
    der mil Befehl sollte aber dennoch funktionieren
    Günther

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •