Abfrage auf Null oder "Nicht"!?

[Mure (Gast)]

Hallo!

Kurze Frage:
Welche Codeausführung ist schneller und warum?

unsigned char i;

...

void Variante1()
{
  if(i == 0)
   {
     i = 1;
     /* Code ausführen */
     i = 0;
   }
}


void Variante2()
{
  if(!i)
   {
     i = 1;
     /* Code ausführen */
     i = 0;
   }
}


void Variante3()
{
  if(i != 0)
   {
     i = 1;
     /* Code ausführen */
     i = 0;
   }
}


void Variante4()
{
  if(i > 0)
   {
     i = 1;
     /* Code ausführen */
     i = 0;
   }
}


void Variante5()
{
  if(i)
   {
     return;
   }

  i = 1;
  /* Code ausführen */
  i = 0;
}

void Variante6()
{
  if(i == 1)
   {
     return;
   }

  i = 1;
  /* Code ausführen */
  i = 0;
}

Die jeweilige Funktion VarianteX, kann durch Interrupts mehrfach 
aufgerufen werden. Des Wegen die Sperre.

Danke.

Gruß
Mure

[Peter II (Gast)]

Variante 1 und Variante 2 machen verschiende dinge, da macht ein 
vergleich keinen sinn.

Schau dir doch selber den ASM code an.

[Stefan E. (sternst)]

Mure schrieb:
> Welche Codeausführung ist schneller und warum?

Wie wäre es mit einfach ausprobieren?
Ich würde allerdings wetten, dass keine Variante irgendwie schneller 
wäre, und die meisten (zumindest 1-4) sogar absolut identischen Code 
erzeugen.

Mure schrieb:
> Die jeweilige Funktion VarianteX, kann durch Interrupts mehrfach
> aufgerufen werden. Des Wegen die Sperre.

Da hilft dir deine Sperre aber nicht wirklich. Was, wenn der Interrupt 
zwischen dem "if" und dem "i = 1;" auftritt?

[Stefan E. (sternst)]

Peter II schrieb:
> Variante 1 und Variante 2 machen verschiende dinge

Nö. "!i" und "i == 0" sind identisch.

Edit: Allerdings machen Variante 3 und 4 was anderes. Die sollten wohl 
eher nach dem Muster wie 5 und 6 aufgebaut sein.

[Doof (Gast)]

Mure schrieb:
> Die jeweilige Funktion VarianteX, kann durch Interrupts mehrfach
> aufgerufen werden. Des Wegen die Sperre.

Du hast in diesem Zusammenhang hoffentlich an einen Cache-Flush gedacht, 
oder?

[Mure (Gast)]

Stefan Ernst schrieb:
> Was, wenn der Interrupt
> zwischen dem "if" und dem "i = 1;" auftritt?

Äh. Gute Frage! - Nächste Frage! Wie löse ich das Problem?

Stefan Ernst schrieb:
> Edit: Allerdings machen Variante 3 und 4 was anderes.

Nochmal Äh! - Richtig erkannt. Falsch von mir getippt!

void Variante3()
{
  if(i != 1)
   {
     i = 1;
     /* Code ausführen */
     i = 0;
   }
}


void Variante4()
{
  if(i > 0)
   {
     return;
   }

  i = 1;
  /* Code ausführen */
  i = 0;
}

Doof schrieb:
> Du hast in diesem Zusammenhang hoffentlich an einen Cache-Flush gedacht,
> oder?

Ein was!? - Nö! Bin wohl doofer als du...

[HildeK (Gast)]

Stefan Ernst schrieb:
>> Variante 1 und Variante 2 machen verschiende dinge
>
> Nö. "!i" und "i == 0" sind identisch.

Das stimmt schon, aber es trotzdem Varianten dabei, die nicht dasselbe 
tun.

Beispiele:

> void Variante4()
> {
>   if(i > 0)
>    {
>      i = 1;
>      /* Code ausführen */
>      i = 0;
>    }
> }
hier wird bei i>0, also auch bei i==1 der Code ausgeführt,
und

> void Variante6()
> {
>   if(i == 1)
>    {
>      return;
>    }
>
>   i = 1;
>   /* Code ausführen */
>   i = 0;
> }

hier kommt bei i==1 'return' und der Code wird nicht ausgeführt.

[P. M. (o-o)]

Es dürften alle gleich sein, so lange der Instruktionssatz 
Vergleichsoperationen für Grösser-/Kleiner-/Gleich hat.

Achja: Deine Sperre ist keine gute Implementation für das Problem. 
Einerseits kann, wie bereits gesagt wurde, der Interrupt genau in die 
Änderung von i reinfunken. Klingt unwahscheinlich, wird in der Praxis 
aber sicher passieren und kaum zu findende Fehler auslösen. Andererseits 
weist die Sperre darauf hin, dass deine Interruptroutine lang im 
Verhältnis zum Aufrufinterval ist. Alternativ könntest du auch ein Flag 
setzen, das dann in einer Hauptschleife ausgewertet und abgearbeitet 
wird. Oder zumindest die Sperre sauber implementieren, Stichwort: 
http://de.wikipedia.org/wiki/Semaphor_%28Informatik%29

[Stefan E. (sternst)]

HildeK schrieb:
> Stefan Ernst schrieb:
>>> Variante 1 und Variante 2 machen verschiende dinge
>>
>> Nö. "!i" und "i == 0" sind identisch.
>
> Das stimmt schon, aber es trotzdem Varianten dabei, die nicht dasselbe
> tun.

Was ich in meinen Post ja auch ergänzt hatte. ;-)

[Mure (Gast)]

Ja aber eine Semaphore und Mutex macht doch auch nichts anderes, als 
sich ein Flag zu setzten ... Mein Flag ist halt "i = 1".
Ich sehe hier den unterschied nicht.

[Stefan E. (sternst)]

Mure schrieb:
> Ja aber eine Semaphore und Mutex macht doch auch nichts anderes, als
> sich ein Flag zu setzten ... Mein Flag ist halt "i = 1".
> Ich sehe hier den unterschied nicht.

Der springende Punkt ist, dass das "test-and-set" atomar sein muss.

[Mure (Gast)]

Hm. Kurz nachgedacht. - Wäre dann:

void Variante7()
{
 i++;
 if(i == 1)
  {
    /* Code ausführen */
  }
 i--;

 return;
}

besser!?

[Mure (Gast)]

Dann müsste man noch i als volatile definieren, dass auch bei der 
if-Abfrage diese neu eingelesen werden muss:

volatile unsigned char i;
void Variante7()
{
 i++;
 if(i == 1)
  {
    /* Code ausführen */
  }
 i--;

 return;
}

[HildeK (Gast)]

Stefan Ernst schrieb:
> Was ich in meinen Post ja auch ergänzt hatte. ;-)

Jaja, nachdem ich meinen geschrieben hatte ... :-)

[Stefan E. (sternst)]

Mure schrieb:
> besser!?

Nein, weil hier i++ nicht atomar ist.

[Oliver (Gast)]

Mure schrieb:
> Dann müsste man noch i als volatile definieren

Solange i++ nicht mit einer atomaren Operation errechnet werden kann, 
nutzt volatile überhaupt nichts, denn dann kann da immer noch ein 
Interrupt dazwischenfunken.

Es nutzt nichts, da muust du die Doku zu deinem Compiler und deinem 
Prozessor lesen, und dafür sorgen, daß i++ oder i=1, oder was auch 
immer, nicht unterbrochen werden kann.

Oliver

[Mure (Gast)]

Oliver schrieb:
> Es nutzt nichts, da muust du die Doku zu deinem Compiler und deinem
> Prozessor lesen, und dafür sorgen, daß i++ oder i=1, oder was auch
> immer, nicht unterbrochen werden kann.

Ich google schon wie blöde. Finde aber für nen MSP430 keinen Code für ne 
Mutex...

[Stefan E. (sternst)]

HildeK schrieb:
> Stefan Ernst schrieb:
>> Was ich in meinen Post ja auch ergänzt hatte. ;-)
>
> Jaja, nachdem ich meinen geschrieben hatte ... :-)

Nö, denn man kann einen Post nicht mehr editieren, wenn bereits ein 
weiterer in dem Thread ist. Mein Edit war also mindestens 5 Minuten vor 
deinen Post da. ;-)

[P. M. (o-o)]

Mure schrieb:
> Ich google schon wie blöde. Finde aber für nen MSP430 keinen Code für ne
> Mutex...

Kann man recht einfach auch selber schreiben. Oder mache die Zuweisung 
an i einfach atomar, indem du Interrupts kurz ausschaltest. Das sollte 
auf dem MSP430 wohl ähnlich funktionieren wie auf einem AVR.

[Bronco (Gast)]

Du bräuchtest eine Konstruktion wie diese

void funktion(...)
{
  Disable_Interrupts();
  if (lock == 0)
  {
    lock = 1;
    Enable_Interrupts();
    // Dein Code
    lock = 0;
    return;
  }
  Enable_Interrupts();
  // return
}

Setzt voraus, daß die Zuweisung

    lock = 0;

atomar abläuft.

[Mure (Gast)]

P. M. schrieb:
> Kann man recht einfach auch selber schreiben.

Wenn man weiß wie's geht. Assembler kann ich leider nicht ...


P. M. schrieb:
> der mache die Zuweisung
> an i einfach atomar, indem du Interrupts kurz ausschaltest.

Quasi so was:

#define EnterMutex(_myMutex)   _DINT(); /* Disable Global interrupt */ \
                               _myMutex++; \
                               if(_myMutex != 1){ \
                                  goto _LeaveMutex; \
                               } \
                               _EINT(); /* Enable Global interrupt */\

#define LeaveMutex(_myMutex)   _DINT(); /* Disable Global interrupt */ \
                               _myMutex--; \
                               _EINT(); /* Enable Global interrupt */\
                                                

unsigned char i;
void Variante7()
{
  EnterMutex(i);
  /* Code ausführen */
  LeaveMutex(i);

 return;
}

Aber streng genommen müsste ich den Zustand von Global Interrupt Flag 
abfragen, bevor ich es setze. Ich glaube es ist möglich, das die Mutex 
betreten wird (Main-Loop), wenn der globale Interrupt deaktiviert ist.

[Mure (Gast)]

Bronco schrieb:
> Du bräuchtest eine Konstruktion wie diese ...

Sieht eigentlich wie meine aus.

[Mure (Gast)]

Mure schrieb:
> Bronco schrieb:
>> Du bräuchtest eine Konstruktion wie diese ...
>
> Sieht eigentlich wie meine aus.

Ah! - Da fehlt das Label!

#define LeaveMutex(_myMutex) _LeaveMutex: 
                                _DINT(); /* Disable Global interrupt */ \
                                _myMutex--; \
                                _EINT(); /* Enable Global interrupt */\

[Mure (Gast)]

Wieso ist es jetzt hier plötzlich so "still"?!?

[Bronco (Gast)]

Mure schrieb:
> Bronco schrieb:
>> Du bräuchtest eine Konstruktion wie diese ...
> Sieht eigentlich wie meine aus.
Mure schrieb:
> goto _LeaveMutex; \


Nein, in meiner Konstruktion wäre ganz gewiß kein GOTO!

[Kan a. (Firma: Basta) (kanasta)]

Ich weiß ne Lösung!

Der C-Chef sagt, so geht das:
(i == 0) ? i = 1 : i = 0;

Eine Zeile, ein Befehl, alles atomar.

[Sven P. (Gast)]

Kan asta schrieb:
> Ich weiß ne Lösung!
>
> Der C-Chef sagt, so geht das:
> (i == 0) ? i = 1 : i = 0;
>
> Eine Zeile, ein Befehl, alles atomar.
Das ist aber gelogen...

[Mure (Gast)]

Bronco schrieb:
> Nein, in meiner Konstruktion wäre ganz gewiß kein GOTO!

Richtig, aber was ist daran so schlimm?

Sven P. schrieb:
>> Eine Zeile, ein Befehl, alles atomar.
> Das ist aber gelogen...

Det habe ich mich grad auch gefragt.

[Chris (Gast)]

Mure schrieb:
> Sven P. schrieb:
>>> Eine Zeile, ein Befehl, alles atomar.

Die gilt nur für Basic Interpreter, die arbeiten nähmlich alles Zeile 
für
Zeile ab. Teilweise sogar für Compiler.

[Sven P. (Gast)]

Ach ja klar, bei der Syntax der vorangegagenen Beispiele habe ich auch 
sofort an Basic gedacht... und zwar an genau eines der zehntausend 
verschiedenen Dialekte, welches zeilenweise tut :-)

[Mure (Gast)]

Sven P. schrieb:
> bei der Syntax der vorangegagenen Beispiele habe ich auch
> sofort an Basic gedacht

Jetzt mal ohne SCh***. - Gibt es Basic für die 
Mikrocontroller-Porgrammierung?

[Rufus Τ. F. (rufus)]

Mure schrieb:
> Gibt es Basic für die
> Mikrocontroller-Porgrammierung?

Bascom.

[Mure (Gast)]

Rufus Τ. Firefly schrieb:
> Bascom.

http://www.mcselec.com/index.php?option=com_content&task=view&id=14&Itemid=41
Was es nicht alles gibt ....
Aber Bascom scheint es nur für AVR zu geben.

Gruß
Mure

[Mure (Gast)]

Zurück zum ursprünglichen Problem:
Richtig schlau bin ich jetzt aber noch immer nicht!

Wie macht man jetzt am Besten eine Mutex für den MSP?
Und zwar so, dass ich diese als Funktion oder Makro habe und in beliebig 
vielen Codeabschnitten einsetzen kann?!?

Gruß
Mure

[Bronco (Gast)]

Mure schrieb:
> Sven P. schrieb:
>>> Eine Zeile, ein Befehl, alles atomar.
>> Das ist aber gelogen...
>
> Det habe ich mich grad auch gefragt.

Hey Mure,

falls Du das wirklich nicht weißt:
Atomar bedeutet, daß es für die CPU ein ununterbrechbarer Vorgang ist.
Das sind z.B. einzelne Maschinen/Assembler-Befehle.
C-Code wird vom C-Compiler in Maschinen-Code umgewandelt.
D.h. ein C-Befehl ergibt oft in mehrere Maschinen-Befehle und ist 
damit nicht atomar!

Bsp:
8-Bit Microcontroller macht

uint32_t x:
x++;

Das x++ erzeugt in vier Assembler-Befehle, weil die CPU pro Befehl nur 
jeweils 8 der 32Bit berechnen kann.

So ist es ein sehr typischer Fehler, auf Variablen aus dem Interrupt 
heraus zuzugreifen, dabei solche Befehlsblöcke zu unterbrechnen und 
damit den Variableninhalt zu zerstören.

Falls Du IAR verwendest: lies mal "Monitor"-Funktionen in der Doku nach.

[Mure (Gast)]

Bronco schrieb:
> Atomar bedeutet, daß es für die CPU ein ununterbrechbarer Vorgang ist.

Habe ich inzwischen verstanden. Deswegen wird ja auch der GIE 
deaktiviert.
Aber mit meinem Makro warst du aber nicht zufrieden.

Bronco schrieb:
> Falls Du IAR verwendest

Nein. Habe Code Composer Studio.

[Peter D. (peda)]

Beim AVR-GCC gibt es eine <atomic.h>, die sollte sich an den MSP 
anpassen lassen.


Peter

[Mark B. (markbrandis)]

Oder wie wär's damit:
http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/rtsc/3_22_00_09/exports/docs/cdoc/ti/mcu/msp430/runtime/utils/Atomic.html