Zitat von
avr_racer
Also nochmal meinen ersten POST LESEN UND VERSTEHEN was die INT_VECTORS_SIZE aussagt nur das es 10 Vectoren gibt nicht mehr und nicht weniger.
Simuliert im AS 4.19 und was passiert er fängt das Programm direkt von vorn an abzuarbeiten wenn man auf PB0 den INT0 auslöst, weil der Sprungverweis per RJMP zur ISR fehlt, weil du meinst
so ein BOCKMIST zu machen
Code:
.CSEG ;Was ab hier folgt kommt in den FLASH-Speicher
.ORG $0000 ;Programm beginnt an der FLASH-Adresse 0x0000..
rjmp reset ;..mit der RESET-Vectortabelle
.ORG INT_VECTORS_SIZE ;Programmadresse nach den ganzen IRQ-Vektoren
Hausaufgabe 1
Setze die Sprungmarken für die ISR richtig das die ISR's auch angesprungen werden können!
Hausaufgabe 2
Lerne den Unterschied zwischen Spaghetticode und das arbeiten mit Unterprogrammen(UP) kennen und nutze den Vorteil von UP's die mit dem StackPointer arbeiten.
Hausaufgabe 3
Wenn du UP's verstanden hast, fange an dein Gesamtprogramm strukturiert mit UP's aufzubauen. Es gibt Pogrammteile die du immer wiederbrauchst und nur 1 mal schreiben musst z.B. die SleepRoutine.
Versteh zwar nicht wie dies passieren konnte, dass die wesentliche ( .include "IRQt13.inc" ;Restliche Interrupt Vektortabelle ) fehlt !
In meinem Eröffnungspost ist dies auf jeden Fall mit drinn, deshalb denke ich dass Hausaufgabe 1 erledigt ist 
https://www.roboternetz.de/community...l=1#post659203
Zu HA2 :
UP's nutze ich meistens nur, wenn ein und die selbe Codesequenz öfters benutzt werden soll. Halte mich aber nicht sklavisch daran ( siehe Hauptprogrammschleife -> SLEEP deaktivieren ).
Ich finde, es ist halt eine Sache des Programmierstils, den ich wahrscheinlich nicht mehr verändern werde.
Zu HA3 :
Ich habe sie verstanden, aber ist halt nicht mein Stil. Um die Struktur besser zu erkennen, benutze ich lieber den PAP.
Verstehe einfach nicht, wieso ~186µs mehr entstehen ( 969 - 783 ~ 186µs bzw. ~76 Takte )?
Ich verstehe zwar immer noch nicht warum diese Diskrepanz entsteht und glaube auch nicht dass sich irgendjemand durch meinen " Spaghetticode " arbeiten wird, um der Ursache auf den Grund zu gehen.
Deswegen arbeite ich jetzt mal mit der OC0A-Interrupt. Dort kann man dann wenigstens mittels Änderung des TOP-Wertes ( OC0RA ) im CTC-Mode bestimmen, wann genau die OC0A-IRQ auftreten soll.
Falls es überhaupt jemandem aufgefallen ist, habe ich erstens - a in ia geändert und zweitens cli & sei weggelassen, da ich mich ja hier in einer ISR befinde, die nicht unterbrochen wird.
ISR.inc -> Interrupt Service Routinen ( ISR ) :
Code:
;
;Systemtakt ( 4,8MHz ) durch 8 teilen ( 600kHz = 1,666µs )
;
cli ;Alle globalen Interrupts sperren
in ia,CLKPR ;Clock Prescaler Register laden..
sbr ia,1<<CLKPCE ;..Sicherheitsprozedur..
cbr ia,1<CLKPS3|1<<CLKPS2|1<<CLKPS1|1<<CLKPS0;..
out CLKPR,ia ;..durchfuehren..
in a,CLKPR ;Clock Prescaler Register laden..
cbr ia,1<<CLKPCE ;..jetzt den Teiler..
sbr ia,1<<CLKPS1|1<<CLKPS0 ;..neu einstellen..
out CLKPR,ia ;..und ueberschreiben
sei ;Alle globalen Interrupts wieder freigeben
Bernd_Stein
- - - Aktualisiert - - -
Ach, mal wieder was zum Simulator im Atmel Studio 7 ( AS7 ).
Ich bin ja leider ein wenig Lernresistent bei den Befehlen CBR & SBR und dann kommt noch dieser Simulator hinzu und schon ist die Verwirrung perfekt.
Beim SFR-CLKPR und noch so anderen SFR's sollte ich mir abgewöhnen RMW ( Read Modify Write ) per CBR & SBR zu realisieren, denn damit verarsche ich mich regelmäßig selbst.
Siehe hier :
https://www.edv-dompteur.de/forum/in...=4034#post4034
Bernd_Stein
Zitieren
Lesezeichen