Am einfachsten anfangen ?

[PICture]

Hallo!

Ich habe das im vorherigen Beitrag DB von ATtiny24/44/84 weiter aufmerksam gelesen, jedoch auf der Seite 18 war für mich schon Ende, weil ich in "Essembly Code Example" auf einen Befehl gestossen bin, wo in ein Register für mich unbekannte Zahl geladen wird: ldi r16,(0 << EEPM1) | (0 << EEPM0). Im darauf folgenden "C Code Example" kommt identische Zahl vor.

Deshalb meine wahrscheinlich letzte Frage: ist es überhaupt möglich AVR's ausschliesslich nur mit normalen Hexzahlen, wie bei allen bisherigen Prozessoren und µC's, in ASM zu programmieren ?

Ich möchte gleich sagen, dass ich C schon vor zig Jahren erfolgslos erlernen versucht und negativ für immer abgehackt habe. Es freut mich, das ich die AVR's näher kennenzulernen versucht habe, aber fast sicher muss ich anderen µC mit niedriger Referenzspannung für ADC nehmen oder beim PIC als Referenz den LM385-Z1,2 anwenden.

[Besserwessi]

Klar kann man auch für die AVRs direkt die Zahlen hinschreiben. Es ist aber meist einfacher und besser verständlich wenn man die Symbolischen Namen benutzt. Bei einigen Registern wie z.B. ADMUX oder zur Einstellung des AD Teilers mache ich das auch, zumindest teilweise.

Die Schreibweise aus dem Beispiel ist halt wirklich an C angelehnt und etwas gewöhnungsbedürftig. Besonders mit der 0 ist es auch nicht so verbreitet, denn (0 << EEPM1) ist schließlich nichts anderes als eine umständliche Schreibweise für 0. Gängiger ist (1 << EEPM1) um das Bit mit dem Namen EEPM1 zu setzen. Sinnvoll halte ich die Version mit der 0 an Stellen wo man ab und zu mal was ändern muss und um zu zeigen das man das Bit explizit löscht.

Wenn man einen Macroassembler nutzt kann man sich auch ein Markro definieren für den Bitwert. Also z.B. BW(x) für (1 << x).
Das macht man zum Teil auch in C, z.B. wenn man von den ganzen << einen Linksdrall bekommt.

[Searcher]

Hallo PICture,

die im Datasheet gebrauchten Assembleranweisungem scheinen mir im AVR-Assembler geschrieben. Dazu habe ich bisher kein anderes als dieses http://www.atmel.com/dyn/resources/p...ts/DOC1022.PDF User Guide gefunden.

Dort ist zB in Kapitel 4.6.3.8 das << erklärt.


Gruß
Searcher

[PICture]

Hallo!

Vielen Dank für Eure Hilfe und verständliche Erklärungen.

Leider ist für mich komplizierte Denkweise unannehmbar, weil ich als Minimalist geboren bin. Ich werde sicher nie "ldi r16,(0 << EEPM1) | (0 << EEPM0)" anstatt "ldi r16,0" schreiben können. Das verwirrt mich so, das ich, wie gewöhnt, nur mit Befehlsatz und Registerliste für Prozessor/µC auf dem Tisch vor mir, sicher nie mein PAD in Quellcode übersetzen kann.

Beim Macroassembler scheint mir leider jeder Macro ein zuaätzlicher Befehl zu sein, den man sich merken muss. Bei mehreren Programmen wird es mich auch sicher zu Verwirrung und unnötiger Zeitverlust führen, wenn ich nach ein paar Jahren eine Kleinigkeit im Programm ändern möchte.

Deshalb bleibt mir nur mich herzlich bei allen Helfer zu bedanken übrig und weiterhin mit Spass PIC's in ASM programmieren. Jetzt ist mir aber ganz klar, das die Fa. ATMEL die AVR's nicht für mich herstellt.

[Besserwessi]

Die Schreibweise für die Bits ist eigentlich unabhängig von Prozessor - das sollte auch beim PIC, ARM, PowerPC, 8086, Z80, 68000 und anderen genau so gehen. Beim 4004 hatte man ggf. die Schreibweise noch nicht und musste zu Fuß die Zahlen zusammenstellen. Im Prinzip könnte man es aber auch da genau so machen. Die Schreibweise sollte als dsa kleinste Problem beim Umstieg vom PIC zum AVR sein.

Der Atmel Assembler hat sogar schon _BV(x) als (1<<x) definiert. Man kann also die Umrechnung von Bit Nummer in Bitwert auch damit machen. Nur die 0 muss man dann wohl als 0 schreiben oder als 0*x.

[PICture]

Hallo Besserwessi !

Es tut mir leid, falls ich dich enttäuscht habe, aber ich hatte nie auf AVR's umsteigen wollen, sondern nur bisher geglaubt habe, dass sich meine mit Spass gebaute Spielzeuge mit AVR's hardwaremässig einfacher aufbauen und auch mit Spass in ASM programmieren lassen. Ich habe etwas neues nicht zum ersten mal im Leben versucht und mit negativen (für mich eben immer positiven) Ergebnis rechtzeitig verworfen. Es ist für mich ganz normales und kein frustierendes Vorgehen.

Hoffentlich wird dieser Thread trotzdem für jemanden nützlich.

[Besserwessi]

Von der Hardware Seite nehmen sich die PICs und AVRs vermutlich nicht viel - mal geht der eine mal der andere etwas besser, und oft geht es gleich gut mit beiden. Bei der Peripherie scheinen die PICs sogar eher mehr Auswahl zu haben, da sind die AVRs doch alle sehr ähnlich - was für die Programmierung aber wieder an Vorteil ist. Wenn man den einen kennt, braucht man den anderen eher nicht. Da wäre dann eher eine Nummer Leistungsfähiger (z.B. dsPic33 oder ARM ) interessant.

Bei der Progammierung in ASM macht es die einfachere Struktur bei den AVRs es aber eher einfacher. Nach etwas Gewöhnung sind die 32 fast gleichwertigen Register eine echte Erleichterung. Mir viel das eventuell besonders leicht, weil ich davor etwas mit dem 68000 (mit 16 universellen Registern wenn ich mich richtig erinnere) gemacht hatte. Für kleine Programme kann man sogar das RAM ganz (außer für den Stack) unbenutzt gelassen und alles in den Registern halten.

[Richard]

"ldi r16,(0 << EEPM1) | (0 << EEPM0)"

Ist ja auch etwas "krank" diese Schreibweise. Zumindest auf einer Deutschen Tastaturt bei der die benötigten Tasten ewas weit auseinander liegen..."ldi r16,0" ist da weitaus bequemer / Anwender freundlicher. -) Andererseits, ist das aber beinahe immer so wenn der Prozessor Typ gewechselt wird. Andere Syntax, andere Register, andere Speicher Verwaltung u.s.w. Da muss (?) man halt durch. Ich habe da auch keinen Bock drauf, PIC's habe ic nur in ASM Programmiert die AVR jetzt nur noch in Basic. Zur Not mit inline ASM wenn es denn sein muss. Damals als noch der gute alte c-64 mein Hauptrechner war, hatte ich mir eine extra minni Zusatz Tastatur für solche Eingaben wie hex Zahlen u.s.w. gebaut. Die konnte mit einem Tastendruck Sonderzeichen, Hex, Bin auf dem Bildschirm "zaubern".

Gruß Richard