Ganz kurz, nur damit ich weiß, dass ich es richtig verstanden habe: URSEL hat in der m8def.inc den Wert 7 UCSZ0 den Wert 1 1<<URSEL bedeutet dass ich eine 1 um sieben Bits nach links schiebe. Also habe ich die 1000 0000 3<<UCSZ0 bedeutet dass ich die Zahl drei, die also die letzten beiden Bits als 1 haben um eine Stelle nach links schiebe. Also habe ich die 0000 0110 Diese beiden Werte werden verodert. Also habe ich die 1000 0110. Man hätte auch ldi temp, (1<<URSEL)|(1<<UCSZ0)|(1<<UCSZ1) schreiben können man hätte auch gleich schreiben können ldi temp, 0b10000110 Man tut das aber nicht, weil man an den komischen Konstanten (URSEL, UCSZ0 usw) erkennen kann, was hier genau gemacht werden soll. (Falls man die nötiger Erfahrung hat, auswendig zu wissen, was diese Kürzel bedeuten) Ist das so korrekt?
Hallo, Karl-alfred Römer schrieb: > Ganz kurz, nur damit ich weiß, dass ich es richtig verstanden > habe: > > URSEL hat in der m8def.inc den Wert 7 > UCSZ0 den Wert 1 > > 1<<URSEL bedeutet dass ich eine 1 um sieben Bits nach links schiebe. > Also habe ich die 1000 0000 > > 3<<UCSZ0 bedeutet dass ich die Zahl drei, die also die letzten beiden > Bits als 1 haben um eine Stelle nach links schiebe. > Also habe ich die 0000 0110 > > Diese beiden Werte werden verodert. > Also habe ich die 1000 0110. Ja, alles korrekt so. > Man hätte auch > > ldi temp, (1<<URSEL)|(1<<UCSZ0)|(1<<UCSZ1) schreiben können Und so schreibe ich es in meinen Programmen. > man hätte auch gleich schreiben können > ldi temp, 0b10000110 > > Man tut das aber nicht, weil man an den komischen Konstanten > (URSEL, UCSZ0 usw) erkennen kann, was hier genau gemacht werden > soll. (Falls man die nötiger Erfahrung hat, auswendig zu wissen, > was diese Kürzel bedeuten) > > Ist das so korrekt? Die Bitnamen findet man im Datenblatt, einige merkt man sich, es gibt auch ein gewisses Sytem bei den Kürzeln. Bei mir ist vieles dann Copy&Paste aus existierenden Sourcen, da tippt man später sowieso nicht jedesmal alles neu. Entscheidener ist jedoch: die Bits müssen nicht bei allen AVR-Typen an der gleichen Position im Register sitzen... Wenn man jetzt von einem AVR auf einen anderen portiert, macht es wenig Spaß, dutzende 0b10001111 zusammenzusuchen und da dann z.B. 0b01001111 draus zu machen. Fehler wären da garantiert. Bei den symbolischen Namen weiß aber der Assembler aus dem Typ-Include, wo eben URSEL gelandet ist oder mault, weil es das auf diesem Typ garnicht gibt. Gruß aus Berlin Michael
Danke Michael, es gibt mir Sicherheit, zu wissen, dass ich das jetzt richtig verstanden habe. Dein Aspekt mit dem Portieren auf andere AVRs ist auch ein wichtiger Grund, der FÜR diese seltsamen Bezeichner spricht. Habe daran noch garnicht gedacht. Vielleicht auch, weil mir nicht bewusst war, dass die Bits sich bei den unterschiedlichen Controllern des gleichen Herstellers an unterschiedlichen Stellen sitzen. Dann muss ich mich demnächst an die Arbeit machen, das System hinter den Kürzeln herauszufinden. VG und Danke nochmals Karl
Das wie und warum die symbolischen Namen sinnvoll sind, wurde ja schon erklärt. Allerdings bin ich der Meinung, dass man nicht (3<<UCSZ0) schreiben sollte, sondern (1<<UCSZ0)|(1<<UCSZ1), weil sich sonst der ganze Sinn wieder verwässert. Leider schreibt Atmel selbst in den Datenblättern den Unfug mit der 3 :-/
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.