Forum: Mikrocontroller und Digitale Elektronik Paritäts-Prüfung in Assembler


von M. Kaminski (Gast)


Lesenswert?

Ich habe vor mit Hilfe eines DCF-Empfängers eine Funkuhr zu basteln. Für
den korrekten Empfang will ich auch ein Paritäts-Prüfung machen.
Allerdings habe ich im Moment keine Ahnung wie ich da vorgehen soll.

Hat da von euch jemand Tipps?

von A.K. (Gast)


Lesenswert?

Womit? Bei 8051-ern gibt's das beispielsweise gratis. Ansonsten fang
mal hat zu recherchieren, was das eigentlich ist. Daraus sollte sich
der erste einfache Lösungsansatz von selbst ergeben.

von M. Kaminski (Gast)


Lesenswert?

Ich verwende einen 80535 also ein 8051-Ableger.

Was eine Paritäts-Prüfung weiß ich, einfach gesagt, es wird im
Binärcode nachgeschaut ob eine gerade oder ungerade Anzahl von Bits auf
1 gesetzt sind.

Als Lösungsansatz fällt mir spontan ein, den Binaercode nach rechts
verschieben, das Carryflag überprüfen und bei einer 1 ein Register
abwechselnd Inkrementieren und Dekrementieren.

Aber wie du gerade angedeutet hast geht es wohl etwas einfacher,
allerdings finde ich da gerade keinen Befehl.

von A.K. (Gast)


Lesenswert?

Experten für die Kiste mögen mich korrigieren, aber nach kurzem Scan
über einen AT89 Overview fand sich das Parity-Flag in Bit 0 vom
Statusregister. Womit JB/JNB naheliegende Kandidaten sind, Bit 0xD0
oder so.

von crazy horse (Gast)


Lesenswert?

alle 8051er haben das parity-Bit im PSW (Bit0). Der Zustand des
parity-Bits bezieht sich immer auf den Akku. Alle Befehle, die den Akku
verändern, beeinflussen das parity-Bit, auch transfer-Befehle.
Gesamtzahl der "Einsen" im Akku und parity ist immer gerade (gerade
Anzahl im Akku -> Bit ist 0, sonst 1.

von M. Kaminski (Gast)


Lesenswert?

Okay Leute lasst die Steine stecken ;).

Bei nährer Betrachtung der Dokus ist mit aufgefallen das es bei den
80535 ein Parity-Bit gibt.

Aber meine kleine Schleife würde auch funktionieren :D

Also vergesst diesen Thread ganz schnell wieder!!!

von Hagen (Gast)


Lesenswert?

@crasy horse:

"Alle Befehle, die den Akku
verändern, beeinflussen das parity-Bit, auch transfer-Befehle"

Bist du dir sicher ? Das wäre ja zur Intelreihe x286,x386... ein
gravierender Unterschied ?

Ich meine damit das die Transferbefehle das Parityflag beeinflussen.

Gruß Hagen

von Läubi (Gast)


Lesenswert?

Lustig ist: so ein Programm mußte wir gerade im Studium in Assembler
programmieren :)

von crazy horse (Gast)


Lesenswert?

da bin ich mir ziemlich sicher.
Mit 286 und aufwärts habe ich mich noch nicht auf Bitebene beschäftigt
und glaube auch nicht, dass ich das jemals tun werde.
Kann aber gut sein, dass da Unterschiede sind, warum nicht?

von Hagen (Gast)


Lesenswert?

Und ich komme aus der anderen Richtung, deshalb meine Frage.

Warum nicht ? Ganz einfach weil ein Transferbefehl der das Parityflag
modifiziert somit effektiv verhindert das man eine Parity über einen
ganzen Speicherbereich auf einfache Weise berechnen kann. Unter x86
Systeme lädt man ein beliebiges Register aus dem Speicher, XOR verküpft
es zb. mit dem Akku und lädt dann das nächste Byte aus dem Speicher, in
einer Schleife halt. So kann man die Parity über Speicherbereich
berechen. Das Parity-flag würde nun nur durch die XOR Operation
beeinflusst.

In deinem Szenario müsste man dann anders vorgehen, es wäre ja immer
noch möglich. Es sei denn nur die Trasferbefehle in den Akkumulator
ändern die Parity, Transferbefehle in andere Register würden es nicht
ändern. Ist dies so ?

Gruß Hagen

von Thomas X. (Gast)


Lesenswert?

<ot>
tatsächlich ist es bei vielen prozessoren üblich, dass transferbefehle
die flags beeinflussen.

die idee ist die, dass man zum beispiel einen wert aus dem speicher
lesen kann, und dann ohne noch irgendwelche vergleichs- oder sonstige
operationen auszuführen feststellen kann, ob der wert null ist, was für
eine parität er hat etc.

am schönsten ists natürlich immer noch mit ARM prozessoren, wo man
angeben kann (mit einigen wenigen ausnahmen) ob ein befehl die flags
modifizieren soll oder nicht =)
</ot>

von crazy horse (Gast)


Lesenswert?

das P-Flag ist fest an den Akku gekopelt, dementsprechend kann nur die
Parität des Akkus angezeigt werden.

von Peter D. (peda)


Lesenswert?

@Hagen

warum soll das nicht gehen:

        mov     r0, #start_addr
        clr     a
loop:   xrl     a, @r0
        inc     r0
        cjne    r0, #end_addr, loop
        jb      P, odd_parity
...
odd_parity:
...


Peter

von Hagen (Gast)


Lesenswert?

Aah man lernt nie aus, XOR mit impliziertem Speicherzugriff, naja hätt
ich selber drauf kommen müssen, danke :)

Gruß Hagen

von Thomas X. (Gast)


Lesenswert?

achja, ich möcht noch anmerken, dass die x86 überhaupt keine referenz
sind. bestenfalls dienen sie als negativbeispiel für prozessordesigner
=)

von Hagen (Gast)


Lesenswert?

tja tut aber nichts zur Sache, als professioneller Programmierer
verdiene ich eben mein Geld mit x86 Systemen. Ist mir aber auch Brust
worauf ich programmiere, Hauptsache ich darf es und verdiene noch Geld
dabei :)

Meine Frage war eher weil ich stutzig geworden bin, ich wusste einfach
nicht das das Parityflag tatsächlich durch Transferbefehle modifiziert
wird. Ich habe darauf einfach nie geachtet, und das wurmt mich viel
mehr !

Gruß Hagen

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.