globale Variable mit einem assembler befehl auslesen

[obamoa (Gast)]

Hallo,

ich habe eine kurze Frage. Ich möchte gern eine globale Variabe in einer 
Funktion auslesen.

uint32_t getUsTime(void)
{   
    uint32_t tempOverflows;
    uint16_t tempCounter;
    
    tempCounter = TIM_GetCounter(TIM_US_TIMER);
    tempOverflows = publicUsTimerOverflows;

    return ( (tempOverflows * 0x0000FFFF) + (uint32_t)tempCounter);
}

Jetzt habe ich aber gesehen das das Auslesen der globalen Variable 
publicUsTimerOverflows nicht mit einem Assemberbefehl funktioniert. 
Damit würde ich wahrscheinlich Probleme mit der ISR bekommen die die 
globale Variable beschreibt. Die ISR deaktivieren möchte ich nicht.

Hier der vom Compiler erzeugte Code der Funktion:

            getUsTime:
0x0800bbe8:   push {r7, lr}
0x0800bbea:   sub sp, #8
0x0800bbec:   add r7, sp, #0
131             tempCounter = TIM_GetCounter(TIM_US_TIMER);
0x0800bbee:   ldr r0, [pc, #40]       ; (0x800bc18 <getUsTime+48>)
0x0800bbf0:   bl 0x8000bcc <TIM_GetCounter>
0x0800bbf4:   mov r3, r0
0x0800bbf6:   strh r3, [r7, #6]
132             tempOverflows = publicUsTimerOverflows;
0x0800bbf8:   ldr r3, [pc, #32]       ; (0x800bc1c <getUsTime+52>)
0x0800bbfa:   ldr r3, [r3, #0]
0x0800bbfc:   str r3, [r7, #0]
134             return ( (tempOverflows * 0x0000FFFF) + (uint32_t)tempCounter);
0x0800bbfe:   ldr r2, [r7, #0]
0x0800bc00:   mov r3, r2
0x0800bc02:   mov.w r3, r3, lsl #16
0x0800bc06:   subs r2, r3, r2
0x0800bc08:   ldrh r3, [r7, #6]
0x0800bc0a:   adds r3, r2, r3
135         }

Meine Frage ist nun ist es möglich den Wert der globalen Variable 
publicUsTimerOverflows in die lokale Variable tempOverflows mit einem 
Assablerbefehl zu kopieren und wie würde das aussehen.

PS: Mit Assemblerprogrammierung kenne ich mich leider nur sehr schlecht 
aus und hoffe daher auf eure Hilfe.

[Daniel V. (danvet)]

Schau mal hier:

http://www.mikrocontroller.net/articles/Interrupt#Interruptfeste_Programmierung

[obamoa (Gast)]

Ach ja das hab ich ganz vergessen, es handelt sich dabei um einen STM32 
also ARM-Cortex M3.

[Peter D. (peda)]

obamoa schrieb:
> Die ISR deaktivieren möchte ich nicht.

Dann möchtest Du auch nicht wirklich programmieren lernen.
Gleich mit unsauberen Tricks anfangen zu wollen, zerstört Deinen 
Programmierstil nachhaltig.

Atomare Abschnitte gehören zum Programmieren einfach dazu.
Und je größer die Programme werden, umso mehr solcher Abschnitte sind 
notwendig.


Peter

[e in anderen S (Gast)]

>möglich den Wert der globalen Variable
>publicUsTimerOverflows in die lokale Variable tempOverflows mit einem
>Assablerbefehl zu kopieren und wie würde das aussehen.

Das steht hier:


132             tempOverflows = publicUsTimerOverflows;
0x0800bbf8:   ldr r3, [pc, #32]       ; (0x800bc1c <getUsTime+52>)
0x0800bbfa:   ldr r3, [r3, #0]
0x0800bbfc:   str r3, [r7, #0]

[e in anderen S (Gast)]

>Damit würde ich wahrscheinlich Probleme mit der ISR bekommen die die
>globale Variable beschreibt.

Aus welchem Grund meinst Du das?

[obamoa (Gast)]

Nach jedem Assemblerbefehl wird überprüft ob ein Interrupt aufgetretten 
ist. Wird nun ein Interrupt zwischen den 3 Assemblerbefehlen der zum 
auslesen der globalen Variablen erkannt wird dieser ausgefüht bevor die 
Daten komplett ausgelesen konnten.

[Daniel V. (danvet)]

obamoa schrieb:
> Ach ja das hab ich ganz vergessen, es handelt sich dabei um einen STM32
> also ARM-Cortex M3.

Macht nix, das Prinzip bleibt das Gleiche.

[obamoa (Gast)]

Meine Frage ist ja ob es möglich ist aus den drei Befehlen einen zu 
machen und so die Probleme mit einer ISR zu vermeiden.

[(prx) A. K. (prx)]

Das Prinzip schon, die Praxis nicht. Der STM32 läd 16- und 32-Bit 
Variablen in einem einzigen Befehl, der Zugriff ist hier also 
automatisch atomar. Anders beim AVR.

[Peter D. (peda)]

Wenn Du einen Timer in SW erweiterst, hast Du ein ganz anderes Problem. 
Der HW-Timer und SW-Timer werden zu unterschiedlichen Zeiten gezählt, 
sie sind also nicht jederzeit gültig.

Dafür gibt es eine einfache Lösung:
Beitrag "AVR Timer mit 32 Bit"


Peter

[e in anderen S (Gast)]

>Nach jedem Assemblerbefehl wird überprüft ob ein Interrupt aufgetretten
>ist. Wird nun ein Interrupt zwischen den 3 Assemblerbefehlen der zum
>auslesen der globalen Variablen erkannt wird dieser ausgefüht bevor die
>Daten komplett ausgelesen konnten.

...

>Meine Frage ist ja ob es möglich ist aus den drei Befehlen einen zu
>machen und so die Probleme mit einer ISR zu vermeiden.

Nicht notwendig, da ist gar kein Prob.

Wie von PeDa bemerkt,  steckt das Prob hier:


>    tempCounter = TIM_GetCounter(TIM_US_TIMER);

>    tempOverflows = publicUsTimerOverflows;

>    return ( (tempOverflows * 0x0000FFFF) + (uint32_t)tempCounter);
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

die temp* könnten inkonsistent sein, wenn ein Interrupt dazwischenfunkt.

[obamoa (Gast)]

Ich habe die Funktion nach PeDa Vorbild angepasst:

uint32_t getUsTime(void)
{   
    uint32_t tempOverflows;
    uint16_t tempCounter;
    ITStatus waitingForIsr;
    
    tempCounter = TIM_GetCounter(TIM_US_TIMER);
    tempOverflows = publicUsTimerOverflows;
    waitingForIsr = TIM_GetITStatus(TIM_US_TIMER, TIM_IT_Update);

    if((waitingForIsr == SET) && !(0x8000 & tempCounter))
    {
        tempOverflows++;
    }

    return ( (tempOverflows * 0x0000FFFF) + (uint32_t)tempCounter);
}

Mir ist nur nicht ganz klar ob ich jetzt den Timeroverflow-Interrupt 
während der Auslesevorgänge deaktivieren muss.

[Karl H. (kbuchegg)]

obamoa schrieb:

> Mir ist nur nicht ganz klar ob ich jetzt den Timeroverflow-Interrupt
> während der Auslesevorgänge deaktivieren muss.

Mir ist nicht klar, wavor du dich eigentlich fürchtest, wenn du die 
Interrupts mal ganz kurz deaktivierst. Die Interrupts gehen ja deswegen 
nicht verloren, sie werden einfach nur um ein bischen was später 
ausgeführt. Viel wichtiger ist aber, dass du beim Auslesen der Variablen 
einen konsistenten Zustand ausliest.

[Peter D. (peda)]

obamoa schrieb:
> Mir ist nur nicht ganz klar ob ich jetzt den Timeroverflow-Interrupt
> während der Auslesevorgänge deaktivieren muss.

Ja klar!
Das Lesen von HW-Timer, SW-Timer, Interruptflag muß zusammen ein 
atomarer Block sein.


Peter

[obamoa (Gast)]

Ich hab den Interrupt wärend des auslesens der Daten deaktivert.

uint32_t getUsTime(void)
{   
    uint32_t tempOverflows;
    uint16_t tempCounter;
    ITStatus waitingForIsr;
    
    // Disable the Selected IRQ Channels -------------------------------------
    NVIC->ICER[TIM_US_TIMER_IRQn >> 0x05] = (uint32_t)0x01 << (TIM_US_TIMER_IRQn & (uint8_t)0x1F);

    tempCounter = TIM_GetCounter(TIM_US_TIMER);
    tempOverflows = publicUsTimerOverflows;
    waitingForIsr = TIM_GetITStatus(TIM_US_TIMER, TIM_IT_Update);

    // Enable the Selected IRQ Channels --------------------------------------
    NVIC->ISER[TIM_US_TIMER_IRQn >> 0x05] = (uint32_t)0x01 << (TIM_US_TIMER_IRQn & (uint8_t)0x1F);

    //Überprüfen der Daten auf konsistenz
    // Wenn Overflow dedektiert wurde aber ISR noch nicht ausgeführt wurde (Interrupt Status auf SET) und der
    // Überlauf vor dem Auslesen des Timerwerts war (höchstwertiges Bit des Timers ist 0),
    // muss dieser Überlauf auch noch mit berücksichtigt werden!
    if((waitingForIsr == SET) && !(0x8000 & tempCounter))
    {
        tempOverflows++;
    }

    return ( (tempOverflows * 0x0000FFFF) + (uint32_t)tempCounter);
}

Ich hab die Funtktion auch gerade getestet. Funktioniert alles so weit 
fehlerfrei.

Das mit den konsistenten Daten war mir vorher nicht bewusst.

@kbuchegg
Du hast natürlich recht. Ich hab mich da in was verrant.

Danke für eure Hilfe!!

[Peter D. (peda)]

obamoa schrieb:
> return ( (tempOverflows * 0x0000FFFF) +
>
> Ich hab die Funtktion auch gerade getestet. Funktioniert alles so weit
> fehlerfrei.

Nö.
Entweder << 16 oder * 0x10000.


Peter

[Peter D. (peda)]

Es ist keine gute Idee, nur den einen Interrupt zu sperren.
Es kann dadurch zu einer Prioritätsumkehr kommen, da ja ein niederer, 
lange dauernder Interrupt nun unterbrechen darf.
D.h. die Sperre kann erheblich länger dauern, als erwartet.

Eine globale Interruptsperre sperrt dagegen definiert und nur die 
kürzest mögliche Zeit.


Peter

[obamoa (Gast)]

@Peter:
Du hast recht! Danke für den Tipp und die Erklärung!

Hier meine neu Funktion:

uint32_t getUsTime(void)
{   
    uint32_t tempOverflows;
    uint16_t tempCounter;
    ITStatus waitingForIsr;
    
    //Interrupts global sperren
    __disable_irq();

    //Atomic Code section START
    tempCounter = TIM_GetCounter(TIM_US_TIMER);
    tempOverflows = publicUsTimerOverflows;
    waitingForIsr = TIM_GetITStatus(TIM_US_TIMER, TIM_IT_Update);
    //Atomic Code section STOP

    //Interrupts global freigeben
    __enable_irq();

    //Überprüfen der Daten auf konsistenz
    // Wenn Overflow dedektiert wurde aber ISR noch nicht ausgeführt wurde (Interrupt Status auf SET) und der
    // Überlauf vor dem Auslesen des Timerwerts war (höchstwertiges Bit des Timers ist 0),
    // muss dieser Überlauf auch noch mit berücksichtigt werden!
    if((waitingForIsr == SET) && !(0x8000 & tempCounter))
    {
        tempOverflows++;
    }

    return ( (tempOverflows * 0x00010000) + (uint32_t)tempCounter);
}

[Klaus (Gast)]

Als ich noch Assembler gemacht habe, war üblich, sich den 
Interruptstatus zu merken, dann zu disablen und am Ende den alten Status 
wiederherzustellen,

Ich hab noch sowas im Kopf:

PUSH PSW
DI
.
.
POP PSW

MfG Klaus

[(prx) A. K. (prx)]

Peter Dannegger schrieb:
> Eine globale Interruptsperre sperrt dagegen definiert und nur die
> kürzest mögliche Zeit.

Bei den Cortex-M kann man in solchen Fällen an Stelle einer totalen 
Interrupt-Sperre die Interrupt-Priorität so setzen, dass nur höher 
priorisierte Interrupts durchkommen. Sinngemäss:

saved_prio = BASEPRI;
BASEPRI = Prio_vom_Timer_Interrupt;
...
BASEPRI = saved_prio;

Perfekt wird es, wenn man sicherstellt, dass BASEPRI nicht versehentlich 
reduziert wird, wenn verschachtelt aufgerufen.

[Peter D. (peda)]

A. K. schrieb:
> Bei den Cortex-M sollte man in solchen Fällen an Stelle einer totalen
> Interrupt-Sperre die Interrupt-Priorität so setzen, dass nur höher
> priorisierte Interrupts durchkommen (=> BASEPRI).

Warum?

Popelige 3 Variablen atomar zu lesen geht bestimmt schneller, als das 
ganze Interrupt-Prolog-Epilog-Brimborium. D.h. niemand merkt diese 
kleine Verzögerung von ein paar Zyklen.
Es gibt also keinen Grund für eine unnötig komlizierte andere Lösung.

Vermutlich wird das Umschalten der Priorität sogar selber unter 
Interruptsperre erfolgen müssen. Man spart also garnichts aber hat 
zusätzlichen Code.


Peter

[(prx) A. K. (prx)]

Peter Dannegger schrieb:
> Popelige 3 Variablen atomar zu lesen geht bestimmt schneller,

Wenns nur das ist - in seinem letzten Code sind aber 2 Aufrufe aus der 
STM32 Lib drin. Die sind mitunter deutlich aufwendiger implementiert.

Ausserdem ging es mir eher darum, das generelle Prinzip zu zeigen. Die 
Sache mit BASEPRI scheint nicht allgemein bekannt zu sein.

> Vermutlich wird das Umschalten der Priorität sogar selber unter
> Interruptsperre erfolgen müssen.

Ich wüsste nicht weshalb.

[(prx) A. K. (prx)]

A. K. schrieb:
> Perfekt wird es, wenn man sicherstellt, dass BASEPRI nicht versehentlich
> reduziert wird, wenn verschachtelt aufgerufen.

=> BASEPRI_MAX. Wurde im CMSIS aber wohl vergessen.