Forum: Mikrocontroller und Digitale Elektronik ARM7_LPC2368: Timer beim Debuggen


von D. S. (forack)


Lesenswert?

Hi!

Ich hab ne frage zum ARM7 Timer Modul.

Ausgangssituation:
ARM7 LPC2368
Interrupt mit Timer0 wenn TC == MC.
Das geht so weit & stellt auch kein Problem dar.

Vorhaben:
Dann in der ISR beim debuggen nen Haltepunkt setzen, auf RUN drücken & 
schauen was der TC macht. Also wieviel Clocks gezählt werden, bis er 
wieder an die Stelle kommt.

Erwartung:
TC's fast immer im gleichen Bereich. Naja, pi*mal daumen zumindest, da 
er zwischendrin eigentlich net viel zu tun hat ausser einmal ne 
ad-wandlung zu machen.

Ist:
Die TC-Werte sind extrem unterschiedlich.

Frage:
 - Warum?
Dachte eigentlich im Debug-Mode werden die Schritte einzeln 
durchgetaktet & da der PCLK ja eigentlich konstant ist & das TC-Register 
ja nur die PCLK Flanken zählt, hätte ich eher gleichbleibende werte 
erwartet.

- Was passiert, wenn der Debug-Mode aus ist & der ohne zu debuggen 
takten kann. Wird das dann einheitlicher oder ist das immer eher 
'willkürlich' ??

von let (Gast)


Lesenswert?

Huhu,

die Kombination Timer + Debugging ist eine einzige Katastrophe
beim ARM. Wenn der Kern gestoppt wird laufen die Timer ganz
normal weiter. Timer und CPU sind also völlig asynchron, da
kann alles Mögliche passieren.

Ich verwende üblicherweise den Timer0 im freilaufenden Modus
(d. h. der TC wird nie zurückgesetzt) und arbeite mit Zeit-
stempeln. Ein Breakpoint bringt das vollkommen durcheinander,
sodaß sich das Programm anschließend nicht mehr mit 'continue'
fortsetzen läßt. Rein technisch geht das natürlich, dadurch
das der TC aber zwischenzeitlich lustig weitergelaufen ist
funktioniert das Programm dann aber nicht mehr richtig.

Oder habe ich deine Frage falsch verstanden?

von D. S. (forack)


Lesenswert?

let wrote:

> Oder habe ich deine Frage falsch verstanden?


Nö.
Hast schon richtig verstanden!
Gut zu wissen, das das net an meinem Quellcode oder was anderem liegt.

Dank' dir!!

Zwei fragen hätte ich aber noch.
Und zwar:

1) wenn der dann ohne Debug läuft, dann müsste das doch alles normal 
laufen, oder ??

2)
Wie arbeitest du/man mit den Zeitstempeln??
So ganz versteh ich das mit denen nicht, weil doch irgendwann nen ewig 
langen Wert als Zeit bekommst. Oder versteh ich da was falsch???
Nimmst dann immer die Ticks & hängst die einfach an den Wert dran, oder 
wie ??? Und was machst, wenn die Daten dann verschicken willst???

Weil Zeitstempel okay. Nur wenn jetzt 2-3h lang alle Millisekunde nen 
Wert nimmst, dann hat man doch mehr Daten an Zeitstempeln, denn an 
brauchbaren Daten. Oder nicht???

von let (Gast)


Lesenswert?

>wenn der dann ohne Debug läuft, dann müsste das doch alles normal
laufen, oder ??
So sollte es sein. Ich habe es zwar nie genau gemessen aber
ich gehe davon aus das die ISR immer wieder um einige Takte
versetzt aufgerufen wird, je nachdem wann der Interrupt zuschlägt.

>Wie arbeitest du/man mit den Zeitstempeln??
Ich hole mir zum Zeitpunkt x den aktuellen Wert vom TC
und bilde zum Zeitpunkt y die Differenz zum aktuellen TC.

Beispiel:
1
uint32_t time;
2
3
time = currentTimer();
4
for (;;) {
5
   if (elapsedTime(time) >= 250) {
6
      time = currentTimer();
7
      TOGGLEPIN(P_LED);
8
   }
9
10
   ...
11
}

currentTimer() liefert den aktuellen TC Wert und elapsedTime()
bildet die Differenz (TC - time). Der Timer wird etwa jede Milli-
sekunde erhöht.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.