Blick's mit dem Timer nicht :(

[Ramones (Gast)]

Mayday, PanPan, Hilde und SOS!!!!!!

Ich stehe bei’m  Timer/Counter total auf dem Schlauch!! (ATmega8)
Berechnen und so ist alles kein Problem, mir ist auch Klar wie er zu 
konfigurieren ist. Aber ich kann mit dem Timer nicht so arbeiten wie ich 
das möchte!!!

Ich möchte, wenn Taster1 (Interrupt) gedrückt wurde, dass eine LED an 
Port-B 5x blinkt.
Klingt ja soweit nicht schwierig! Dachte ich!!!!! Ich bekomme den Timer 
soweit hin, dass er in entsprechendem Tempo die LED blinken lässt.
Aber egal was ich versuche dem Timer ist der Taster egal!?!

Ich vermute, dass der Timer nicht via Interrupt genutzt werden 
soll??!!??
Habe schon massenhaft gelesen und gesucht aber nichts gefunden oder 
wahrscheinlich nur nicht begriffen :)

Kann mit bitte, bitte jemand verständlich erklären wie ich den Timer als 
Counter steuern kann!!

Untenstehend mein Code, soweit wie er funktioniert.

Danke
Ramon

.include        "AVR.H"
;----------------------------------------------------------------------
begin:
    rjmp    main         ; RESET External Pin, Power-on Reset,
    rjmp    Tast1         ; INT0 External Interrupt Request 0
    reti                       ; INT1 External Interrupt Request 1
    reti                       ; TIMER2 COMP Timer/Counter2 Compare Match
    reti                       ; TIMER2 OVF Timer/Counter2 Overflow
    reti                       ; TIMER1 CAPT Timer/Counter1 Capture Event
    reti                       ; TIMER1 COMPA Timer/Counter1 Compare Match A
    reti                       ; TIMER1 COMPB Timer/Counter1 Compare Match B
    reti                       ; TIMER1 OVF Timer/Counter1 Overflow
    rjmp    TC0           ; TIMER0 OVF Timer/Counter0 Overflow
    reti                       ; SPI, STC Serial Transfer Complete
    reti                       ; USART, RXC USART, Rx Complete
    reti                       ; USART, UDRE USART Data Register Empty
    reti                       ; USART, TXC USART, Tx Complete
    reti                       ; ADC ADC Conversion Complete
    reti                       ; EE_RDY EEPROM Ready
    reti                       ; ANA_COMP Analog Comparator
    reti                       ; TWI 2-wire Serial Interface
    reti                       ; SPM_RDY Store Program Memory Ready
;---------------------------------------------------------------------
main:
    ldi r16,hi8(RAMEND)                ; Main program start
    out SPH,r16                        ; Set Stack Pointer to top of RAM
    ldi r16,lo8(RAMEND)
    out SPL,r16
    
    cbi DDRC,2    ; Eingang D.2 (Taster1)
    sbi PORTD,2    ; PullUp D.2
    
    sbi DDRB,1    ; Ausgang LED
    
    
    ldi r16,0b00000101  ; Mask. Timer-Int
    out TCCR0,r16    ;
    ldi r16,0b00000001  ; Timer Konfig.
    out TIMSK,r16    ; 
    
    ldi r16,0            ; Startwert
    sei
    
;------------------------------------------------------------------------------
mainloop:  
    
    rjmp  mainloop
;------------------------------------------------------------------------------
TC0:            ; Counter0
  
  com r16
  out PORTB,r16
  ldi r17,95
  out TCNT0,r17  
reti
;------------------------------------------------------------------------------  
Tast1:      ; Taster1


reti

[Peter D. (peda)]

Ramones schrieb:
> Aber egal was ich versuche dem Timer ist der Taster egal!?!

Ohne Code wird das auch so bleiben.
Woher soll der arme AVR denn wissen, was Du beim Tastendruck gemacht 
haben willst, wenn Du es ihm nirgends sagst. Hellsehen kann er nicht.

[c-hater (Gast)]

Ramones schrieb:

> .include        "AVR.H"

Huch?! Was ist das denn für ein Assembler?

>     cbi DDRC,2    ; Eingang D.2 (Taster1)
>     sbi PORTD,2    ; PullUp D.2

Du mußt schon bei einem Port bleiben, wenn das funktionieren soll.

Außerdem fehlt die Initialisierung für den INT0, der wird also niemals 
ausgelöst werden. Und wenn das durch irgendein Wunder doch passieren 
sollte...

> Tast1:      ; Taster1
>
> reti

...würde es trotzdem nix bewirken, weil die ISR leer ist.

>     ldi r16,0b00000101  ; Mask. Timer-Int
>     out TCCR0,r16    ;
>     ldi r16,0b00000001  ; Timer Konfig.
>     out TIMSK,r16    ;

Das ist unleserlich, zumal du uns nicht einmal verraten hast, um welchen 
AVR es eigentlich geht.


> TC0:            ; Counter0
>
>   com r16
>   out PORTB,r16
>   ldi r17,95
>   out TCNT0,r17
> reti

Das ist wenig elegant. Wolltest du wirklich den kompletten PortB wackeln 
lassen oder nur ein Pin des Ports?

Außerdem ist es gewöhnlich Unsinn, das Zählregister eines Timers in 
einer ISR neu zu laden. Das kann der Timer selber sehr viel besser. 
Siehe CTC-Modus.

Last, but not least: dein Programm enthält nix, was bis 5 zählt. Selbst 
wenn du den INT0 funktionsfähig gebacken bekommst, würde es trotzdem 
niemals so funktionieren, wie du lt. deiner Funktionsbeschreibung 
wolltest.

[Ramones (Gast)]

Hey ist ja echt nett hier!!

Habe nicht verraten um was für einen AVR es sich handelt!?
Sorry!! Ich dachte Spezialisten wie Ihr können mit der Bezeichnung 
„ATmega8“ was anfangen.
Also Es handelt sich um einen Mikrocontroler der Firma Atmel Typ: mega8 
(ATmega8)

Eingangsport ist natürlich D.2 nicht C.2 (vertippt)

INT0 wird auch initialisiert!!!
Was soll da unleserlich sein??

Habe den Code für die „bis fünf Zählung“ absichtlich leer gelassen da ja 
meine Frage oder
Vermutung war, dass der Timer nicht via Interrupt genutzt werden soll 
!!??

Elegant oder nicht, sinnvoll oder nicht war doch auch gar nicht die 
Frage!!

[c-hater (Gast)]

Ramones schrieb:

> INT0 wird auch initialisiert!!!

Wo genau?

[Ramon L. (ramones)]

c-hater schrieb:
> Ramones schrieb:
>
>> INT0 wird auch initialisiert!!!
>
> Wo genau?

Kennst Du am ATmega8 den PortD.2??

[c-hater (Gast)]

Ramon Lehmann schrieb:
> c-hater schrieb:
>> Ramones schrieb:
>>
>>> INT0 wird auch initialisiert!!!
>>
>> Wo genau?
>
> Kennst Du am ATmega8 den PortD.2??

Sicher.

Aber damit der den INT0 auslösen kann, muß er entsprechend initialisiert 
werden.

Es genügt nicht, ihn als Eingang zu konfigurieren und seinen Pullup 
einzuschalten. Damit wird er einfach nur zu einem Eingang mit Pullup, 
aber noch nicht zu einer Interruptquelle.

Siehe Datenblatt->externe Interrupts.

[Ramon L. (ramones)]

das ist mir klar!!

fünfte Zeile im Code, dort wird der Int0 Aktiviert.
In nutze Sisy zum proggen.

[c-hater (Gast)]

Ramon Lehmann schrieb:
> das ist mir klar!!

Nein, ganz offensichtlich ist dir das nicht klar.

> fünfte Zeile im Code, dort wird der Int0 Aktiviert.

Das soll dann wohl diese sein:

    cbi DDRC,2    ; Eingang D.2 (Taster1)

Nein, die konfiguriert nur den Pin als Eingang, das ist alles, was diese 
Zeile tut. Steht eigentlich auch so in deinem eigenen (?) Kommentar.

> In nutze Sisy zum proggen.

Das ändert daran auch nichts.

[T.roll (Gast)]

c-hater schrieb:
> Das soll dann wohl diese sein:
>
>     cbi DDRC,2    ; Eingang D.2 (Taster1)

Das mit dem Zählen üben wir aber nochmal.

Das ist die 5. Zeile der main:

Die 5. Zeile des Programms ist:

rjmp    Tast1         ; INT0 External Interrupt Request 0

[Ramon L. (ramones)]

>> fünfte Zeile im Code, dort wird der Int0 Aktiviert.
>
> Das soll dann wohl diese sein:
>
>     cbi DDRC,2    ; Eingang D.2 (Taster1)

Du solltest mal zählen lernen!
was bei dir fünf ist ist bei mir 30!!!

[c-hater (Gast)]

T.roll schrieb:

> Die 5. Zeile des Programms ist:
> rjmp    Tast1         ; INT0 External Interrupt Request 0

Auch eine Sprunganweisung in einem Interruptvektor schaltet keinen 
Interrupt frei.

[Ramon L. (ramones)]

@c-hater
t.roll hat's erkannt.
und ich hatte auch erwähnt, dass ich mit Sisy progge!!!! Dort reicht es 
aus das reti zu ersetzen!!!!!!

@c-hater bitte nicht weiter antworten!!! ich möchte mich hier lieber mit 
den Timern beschäftigen, und nicht damit was du für sinnvoll, elegant 
oder sons was hältst.
danke dir aber für deine bemühungen.

[c-hater (Gast)]

Ramon Lehmann schrieb:

> und ich hatte auch erwähnt, dass ich mit Sisy progge!!!! Dort reicht es
> aus das reti zu ersetzen!!!!!!

Bestimmt nicht. Den Timerinterrupt muß man ja offensichtlich auch "von 
Hand" konfigurieren, warum sollte das beim Int0 anders sein?

> Ich möchte mich hier lieber mit
> den Timern beschäftigen

Ich dachte, du willst den Interrupt für den Taster zum Laufen bekommen? 
Der hat mit dem Timer überhaupt nichts zu schaffen.

[Herr M. (herrmueller)]

Wie initialisiert denn dein Sisy den INT0?

Low Level an PinD,2 löst IR aus?
Level Änderung an PinD,2 löst IR aus?
Fallende Flanke an PinD,2 löst IR aus?
Steigende Flanke an PinD,2 löst IR aus?

Wird das External Interrupt Request Enable Flag gesetzt,damit der IR 
Vektor angesprungen wird oder muss man das External Interrupt Flag 0 
extra abfragen?

Wenn das Sisy alles automatisch macht, ist man sehr eingeschränkt und 
sollte wissen, was gemacht wurde - sehr unwahrscheinlich!!!!!!!!!!!!!!

(Die Ausrufezeichen hab ich von dir geklaut, ich hoffe, du hast nun 
keine mehr)

[Andreas H. (ahz)]

Ramon Lehmann schrieb:
> und ich hatte auch erwähnt, dass ich mit Sisy progge!!!! Dort reicht es
> aus das reti zu ersetzen!!!!!!

<irony>
Wow, was ist das den für ein schicker Progger ?

Setzt automatisch das MCUCR und das GICR ?  Und weiss auch noch 
automatisch ob Du Edge/Level triggern willst und auf welchen 
Level/Flanke.

Beeindruckend^^

Oder hat c-hater vielleicht doch recht und Du musst das selber machen ?
</irony>

Sagen Dir die Register MCUCR und GICR irgendwas ?

bored

[Andreas H. (ahz)]

c-hater schrieb:
> Bestimmt nicht. Den Timerinterrupt muß man ja offensichtlich auch "von
> Hand" konfigurieren, warum sollte das beim Int0 anders sein?

Herr Mueller schrieb:
> Wenn das Sisy alles automatisch macht, ist man sehr eingeschränkt und
> sollte wissen, was gemacht wurde - sehr unwahrscheinlich!!!!!!!!!!!!!!

Macht Sisy nicht.

Alexander Huwald (?), der Autor von Sisy, hatte vor ein paar Jahren in 
der ELV mal ein paar Artikel über Programmierung mit Sisy geschrieben.

Hab grad mal nachgeschaut:
http://www.elv-downloads.de/service/manuals_hw/67696_myavr_journalbericht.pdf

Und ER hat die Inits im Code drin ;-)

Grüße
Andreas

[Peter D. (peda)]

Beim OP scheint ein erheblichen Mißverständnis über die Arbeitsweise von 
MCs zu bestehen.
Dabei ist es ganz einfach so:
Was im Code nicht drinsteht, kann auch nicht ausgeführt werden.
Insbesondere leere Interrupthandler sind vollkommen sinnfrei (außer im 
Sleepmode).

[Justus S. (jussa)]

Peter Dannegger schrieb:
> Beim OP scheint ein erheblichen Mißverständnis über die Arbeitsweise von
> MCs zu bestehen.

vor allem aber bestehen erhebliche Mißverständnisse über das angemessene 
Verhalten in Foren...

[Georg G. (df2au)]

Justus Skorps schrieb:
> das angemessene Verhalten in Foren...

wobei dieses Forum wirklich etwas ähmmm speziell ist.

[c-hater (Gast)]

Peter Dannegger schrieb:

> Beim OP scheint ein erheblichen Mißverständnis über die
> Arbeitsweise von
> MCs zu bestehen.

Das kann man wohl kaum bestreiten ;o)

Außerdem scheint er auch noch ein Problem beim Gebrauch von Satzzeichen 
in seiner Muttersprache zu haben. Das läßt nicht hoffen, daß er jemals 
eine Fremdsprache lernen kann. Und sei es auch nur eine syntaktisch so 
einfache und durch und durch logische wie Assembler...

> Dabei ist es ganz einfach so:
> Was im Code nicht drinsteht, kann auch nicht ausgeführt werden.

Das allerdings ist nur bedingt korrekt. Das hängt vom Abstraktionsgrad 
der verwendeten Programmiersprache ab. Hier wird allerdings Assembler 
verwendet, wo nichts (oder nahezu nichts) abstrahiert wird und insofern 
hast du natürlich vollkommen recht. Was nicht da steht, wird hier im 
Allgemeinen auch nicht passieren.

> Insbesondere leere Interrupthandler sind vollkommen sinnfrei (außer im
> Sleepmode).

Nö, das stimmt nicht unbedingt. Ich habe zumindest ein Projekt, in dem 
es eine "leere" ISR auch für den ganz normalen Betrieb gibt (bestehend 
aus einem reti auf dem Interruptvektor).
Deren einzige Aufgabe ist das Zurücksetzen des auslösenden 
Interruptflags mit einer gewissen Verzögerung (min. 4 Takte). Das 
Gesamtwerk funktioniert wie geplant, würde das aber nicht tun ohne eben 
diesen Mechanismus.

Hört sich etwas schräg an, war aber tatsächlich im konkreten Fall die 
effizenteste Implementierung des Gesamtproblems. OK, ich gebe gerne zu, 
daß sowas nur in sehr speziellen Fällen sinnvoll ist. Aber auch solche 
seltenen Sonderfälle zeigen halt, daß man sich mit verallgemeinernden 
Aussagen wie "leere Interrupthandler sind vollkommen sinnfrei" etwas 
zurückhalten sollte. Immer relativieren. Jedenfalls solange das Problem 
nicht im ganzen Umfang mit allen Eckdaten bekannt ist.