ELEKTRO FORUM

Hallo,

ich habe das folgende Problem, und es will mir einfach keine Lösung
einfallen:

Ich habe den Timer0 so programmiert, dass er alle 1ms einen Interrupt
auslößt. In der Interrupt-Routine erhöhe ich einen
32-Bit-Zähler um eins
und erzeuge mir so eine Systemzeit. Funktioniert auch prima.

Dann und wann brauche ich aber eine genauere Zeitangabe. Da habe ich mir
gedacht ich kombiniere den 32-Bit-Zähler mit dem TCNT0-Register. Dieses
Register läuft bei mir immer bis 250 (Inhalt von OCR0), dann wird es auf
Null zurückgesetzt und ein Interrupt wird erzeugt.

Wie muß man das Auslesen des TCNT0-Registers und des 32-Bit-Zählers
programmieren, so das man eine korrekte Zeit erhält?

Die Kombination

IN R16,TCNT0
CLI
LDS R17,SYSTEMTIME ; uR17:R18:R19:R20="SystemTime"
LDS R18,SYSTEMTIME+1
LDS R19,SYSTEMTIME+2
LDS R20,SYSTEMTIME+3
SEI

funktioniert am besten. Wie zu erwarten kommt es aber manchmal zu
Problemen. Ich denke diese entstehen, wenn zwischen dem IN und dem CLI
der Zähler auf Null springt und ein Interrupt erzeugt wird. Vertauscht
man die Befehle jedoch gibt es viel häufiger Probleme. Das überrascht

auch nicht, denn der Zähler läuft ja um, egal ob Interrupts erzeugt
werden oder nicht.

Hat schon einmal jemand ein ähnliches Problem gehabt und eine Lösung
ersonnen?

mfg
Helmut

Helmut Neemann schrieb:

[Timer0, alle 1ms einen Interrupt, 32-Bit-Zähler, OCR0%0]

Output Compare Interrupt mit Prescalerd bei 16Mhz?

>Wie muß man das Auslesen des TCNT0-Registers und des
32-Bit-Zählers
>programmieren, so das man eine korrekte Zeit erhält?
>
>Die Kombination
>
> IN R16,TCNT0
> CLI
> LDS R17,SYSTEMTIME ; uR17:R18:R19:R20="SystemTime"
> LDS R18,SYSTEMTIME+1
> LDS R19,SYSTEMTIME+2
> LDS R20,SYSTEMTIME+3
> SEI
>
>funktioniert am besten. Wie zu erwarten kommt es aber manchmal zu
>Problemen. Ich denke diese entstehen, wenn zwischen dem IN und dem CLI
>der Zähler auf Null springt und ein Interrupt erzeugt wird.

Dieser Fehler kann doch nicht so oft vorkommen?
Alle (250*Timer0 Prescale) Zyklen ist so eine kritische Situation.
Diese muss auch noch mit der Abfrage kollidieren.

Mein Vorschlag:

CLI
IN R16, TCNT0
IN temp, TIFR
ANDI temp, 2 ;(1<<OCF0)=2, test for flag
BREQ 1f ;skip next instruction if flag set
SEI
NOP
IN R16, TCNT0 ; "hmm, sollte eigentlich immer 0 sein"
CLI
1:
LDS R17,SYSTEMTIME ; uR17:R18:R19:R20="SystemTime"
LDS R18,SYSTEMTIME+1
LDS R19,SYSTEMTIME+2
LDS R20,SYSTEMTIME+3
SEI

Wenn du einfach nach dem Sichern des TCNT0, das zum Output Compare
Interrupt gehoerige Flag abfragst, kannst du den Reset des TCNT0
abfangen.

Ist OCF0 gesetzt, verwirfst du den gelesenen TCNT0 und laesst
den Output Compare Interrupt ausfuehren und SYSTEMTIME updaten.
Danach muss der TCNT0 und die SYSTEMTIME (fuer 1ms) atomic sein.

Was mit mehreren Interruptsflag mit verschiedenen Prioritaeten
nach dem SEI geschieht, weiss ich momentan nicht. Das NOP ist
notwendig da ein Befehl nach dem SEI auf jeden Fall ausgefuehrt wird.

servus thomas
«
--
Die 4. Österreichische Fan-Convention zum Thema Japanische Popkultur
** AniNite 2004 ** 20.-22.August 2004 ** http://www.aninite.at/ **
Anime & Manga * J-Pop Bar * Cosplay * Videogames * Go * DDR * AMV *
Manga Workshop * Quiz * Trading Cards * Vortraege * Origami * Kyudo *

Hallo

Du vergleichst am Ende nochmal TCNT0 mit R16. Wenn TCNT0 kleiner ist, weisst
du, dass inzwischen ein Overflow stattgefunden hat und du springst einfach
zurück und lädst alles nochmal. CLI und SEI können ganz
entfallen.

Georg




"Helmut Neemann" <hneemann@despammed.com> schrieb im
Newsbeitrag
news:2klvanF3vfofU1@uni-berlin.de...
> Hallo,
>
> ich habe das folgende Problem, und es will mir einfach keine Lösung
> einfallen:
>
> Ich habe den Timer0 so programmiert, dass er alle 1ms einen Interrupt
> auslößt. In der Interrupt-Routine erhöhe ich einen
32-Bit-Zähler um eins
> und erzeuge mir so eine Systemzeit. Funktioniert auch prima.
>
> Dann und wann brauche ich aber eine genauere Zeitangabe. Da habe ich mir
> gedacht ich kombiniere den 32-Bit-Zähler mit dem TCNT0-Register.
Dieses
> Register läuft bei mir immer bis 250 (Inhalt von OCR0), dann wird es
auf
> Null zurückgesetzt und ein Interrupt wird erzeugt.
>
> Wie muß man das Auslesen des TCNT0-Registers und des
32-Bit-Zählers
> programmieren, so das man eine korrekte Zeit erhält?
>
> Die Kombination
>
> IN R16,TCNT0
> CLI LDS R17,SYSTEMTIME ; uR17:R18:R19:R20="SystemTime"
> LDS R18,SYSTEMTIME+1
> LDS R19,SYSTEMTIME+2
> LDS R20,SYSTEMTIME+3
> SEI
>
> funktioniert am besten. Wie zu erwarten kommt es aber manchmal zu
> Problemen. Ich denke diese entstehen, wenn zwischen dem IN und dem CLI der

> Zähler auf Null springt und ein Interrupt erzeugt wird. Vertauscht
man die
> Befehle jedoch gibt es viel häufiger Probleme. Das überrascht
auch nicht,
> denn der Zähler läuft ja um, egal ob Interrupts erzeugt werden
oder nicht.
>
> Hat schon einmal jemand ein ähnliches Problem gehabt und eine
Lösung
> ersonnen?
>
> mfg
> Helmut

> CLI
> IN R16, TCNT0
> IN temp, TIFR
> ANDI temp, 2 ;(1<<OCF0)=2, test for flag
> BREQ 1f ;skip next instruction if flag set
> SEI
> NOP
> IN R16, TCNT0 ; "hmm, sollte eigentlich immer 0 sein"
> CLI
> 1:
> LDS R17,SYSTEMTIME ; uR17:R18:R19:R20="SystemTime"
> LDS R18,SYSTEMTIME+1
> LDS R19,SYSTEMTIME+2
> LDS R20,SYSTEMTIME+3
> SEI


Ich denke der Vorschlag hat das gleiche Problem. Der Overflow kann immer
noch nach dem Lesen von TIFR erfolgen und wird dann nicht bemerkt.

Georg

Georg Meister schrieb:

>> CLI
>> IN R16, TCNT0
>> IN temp, TIFR
>> ANDI temp, 2 ;(1<<OCF0)=2, test for flag
>> BREQ 1f ;skip next instruction if flag set
>> SEI
>> NOP
>> IN R16, TCNT0 ; "hmm, sollte eigentlich immer 0 sein"
>> CLI
>> 1:
>> LDS R17,SYSTEMTIME ; uR17:R18:R19:R20="SystemTime"
>> LDS R18,SYSTEMTIME+1
>> LDS R19,SYSTEMTIME+2
>> LDS R20,SYSTEMTIME+3
>> SEI
>
>Ich denke der Vorschlag hat das gleiche Problem. Der Overflow kann immer
>noch nach dem Lesen von TIFR erfolgen und wird dann nicht bemerkt.

Das hat jedoch wenig Effekt auf die Gueltigkeit von TCNT0 und SYSTEMTIME.
SYSTEMTIME wird nicht zwischenzeitlich upgedated (Interrupt gesperrt) und
gilt fuer den gelesenen TCNT0.

servus thomas
«
--
Die 4. Österreichische Fan-Convention zum Thema Japanische Popkultur
** AniNite 2004 ** 20.-22.August 2004 ** http://www.aninite.at/ **
Anime & Manga * J-Pop Bar * Cosplay * Videogames * Go * DDR * AMV *
Manga Workshop * Quiz * Trading Cards * Vortraege * Origami * Kyudo *

Georg Meister schrieb:
>
>Du vergleichst am Ende nochmal TCNT0 mit R16. Wenn TCNT0 kleiner
>ist, weisst du, dass inzwischen ein Overflow stattgefunden hat und
>du springst einfach zurück und lädst alles nochmal.
>CLI und SEI können ganz entfallen.

Stimmt. Ist die eleganteste Loesung.

servus thomas
«
--
Die 4. Österreichische Fan-Convention zum Thema Japanische Popkultur
** AniNite 2004 ** 20.-22.August 2004 ** http://www.aninite.at/ **
Anime & Manga * J-Pop Bar * Cosplay * Videogames * Go * DDR * AMV *
Manga Workshop * Quiz * Trading Cards * Vortraege * Origami * Kyudo *

>>> CLI
>>> IN R16, TCNT0
>>> IN temp, TIFR
>>> ANDI temp, 2 ;(1<<OCF0)=2, test for flag
>>> BREQ 1f ;skip next instruction if flag set
>>> SEI
>>> NOP
>>> IN R16, TCNT0 ; "hmm, sollte eigentlich immer 0 sein"
>>> CLI
>>> 1:
>>> LDS R17,SYSTEMTIME ; uR17:R18:R19:R20="SystemTime"
>>> LDS R18,SYSTEMTIME+1
>>> LDS R19,SYSTEMTIME+2
>>> LDS R20,SYSTEMTIME+3
>>> SEI
>>
>>Ich denke der Vorschlag hat das gleiche Problem. Der Overflow kann
immer
>>noch nach dem Lesen von TIFR erfolgen und wird dann nicht bemerkt.
>
> Das hat jedoch wenig Effekt auf die Gueltigkeit von TCNT0 und SYSTEMTIME.
> SYSTEMTIME wird nicht zwischenzeitlich upgedated (Interrupt gesperrt) und
> gilt fuer den gelesenen TCNT0.


Ja richtig. Hatte ich nicht gesehen.

Georg

Hallo,

das hört sich richtig gut an, liefert aber das gleiche Ergebnis wie die
Simpelimplementierung aus meinem ersten Posting.

Ich habe folgenden Code getestet:

hs1: IN R3,TCNT0
LDS R17,SYSTEMTIME
LDS R18,SYSTEMTIME+1
LDS R19,SYSTEMTIME+2
LDS R20,SYSTEMTIME+3
IN R4,TCNT0
CP R4,R3
BRLO hs1

Bei einem Versuch ist in R3=9 zu finden und SYSTEMTIME wurde noch nicht
erhöht. Aufgefallen ist mir jedoch, dass das Problem nur auftritt, wenn
externe Interrupts, die ja eine höhere Priorität haben als der Timer,

ausgelößt werden. Die Interrupts kommen aber nur mit 100Hz,
können also
nicht den Timer-Int auf Dauer lahmlegen.

Gruss vom ratlosen
Helmut

Georg Meister wrote:
> Hallo
>
> Du vergleichst am Ende nochmal TCNT0 mit R16. Wenn TCNT0 kleiner ist,
weisst
> du, dass inzwischen ein Overflow stattgefunden hat und du springst einfach

> zurück und lädst alles nochmal. CLI und SEI können ganz
entfallen.
>
> Georg
>
>
>
>
> "Helmut Neemann" <hneemann@despammed.com> schrieb im
Newsbeitrag
> news:2klvanF3vfofU1@uni-berlin.de...
>
>>
>>IN R16,TCNT0
>>CLI LDS R17,SYSTEMTIME ; uR17:R18:R19:R20="SystemTime"
>>LDS R18,SYSTEMTIME+1
>>LDS R19,SYSTEMTIME+2
>>LDS R20,SYSTEMTIME+3
>>SEI
>>