Am einfachsten anfangen ?

[Besserwessi]

Wann genau das Interrupt-flag gelöscht wird, ist nicht so wichtig. Die Annahme beim Sprung zum Interruptvector kommt mir auch plausibel vor. Es gibt aber ein paar Ausnahmen wo das Bit gar nicht von der Hardware gelöscht wird und das von Hand gemacht werden muss (z.B. USI ?).

Da man für praktisch jede Interrupt-quelle einen eigenen Interrupt-vektor und damit bei Bedarf eine eigene ISR hat, braucht man die Interruptflags nicht um die Quelle zu erkennen. Gelöscht wird aber immer nur das Flag von der aktuell aufgerufenen ISR. Man könnte also in der ISR von Timer0 immer noch feststellen ob auch das Flag von Timer1 gesetzt ist. Wenn einem der Interupt von Timer1 so wichtig ist, kann man in den anderen ISRs ggf. per SEI weitere Interrupts zulassen. Das reduziert die Verzögerung, verhindert sie aber nicht ganz.

[PICture]

Danke sehr für deine Bestätigung meiner Vermutung.

Wann genau das Interrupt-flag gelöscht wird, ist nicht so wichtig.

Für mich wäre es aber aus Gewöhnheit schon wichtig, aber im Datenbblatt (DB) unauffndbar.

Da man für praktisch jede Interrupt-quelle einen eigenen Interrupt-vektor und damit bei Bedarf eine eigene ISR hat, braucht man die Interruptflags nicht um die Quelle zu erkennen.

Wie auch immer nehme ich es so an, wie es ist, ohne zu fragen warum.

Übrigens, wie genau ich leider bin, könnte folgender von mir zufällig bemerkter Fehler im Datenblatt von ATtiny24/44/84 ( http://www.atmel.com/dyn/resources/p...ts/doc8006.pdf ) bestätigen: 5 Seite, 11 Zeile, 2 Wort. Dort anstatt "disabled" steht "disbaled" ... nach Murphy: "Ein Fehler tritt erst dann auf, nachdem die letzte Kontrolle durchlaufen worden war."

[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.

[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