Variablen setzen sich auf 0

[Lisa (Gast)]

Hallo,

Mein Programm setzt alle Variablen, die ich in einer If-Bedingung setze, 
damit andere if Bedingung beim erneuten Durchlauf der while-Schleife 
durchlaufen werden, jedes mal zu Beginn der while-Schleife auf 0.
Damit keine andere Funktion auf die Variable zugreift habe ich eine 
Testvariable deklariert und setze diese einmal in meinem Programm auf 1 
und verändere diese anschließend nicht mehr. Trotzdem wird auch diese 
immer wieder auf 0 gesetzt. Ob diese Variable überhaupt gesetzt wurde 
hab ich mit dem Debugger bereits überprüft.
Woran kann es liegen, dass meine Variablen jedes mal auf 0 gesetzt 
werden?

Gruß
Lisa

[klon (Gast)]

Lisa schrieb:
> Woran kann es liegen, dass meine Variablen jedes mal auf 0 gesetzt
> werden?

Sehr wahrscheinlich am nicht geposteten Programm in Zeile 42.

[Dr. Sommer (Gast)]

Fehler in Zeile 42. Im Debugger Watchpoint auf die Variable setzen und 
damit die Stelle mit dem Buffer Overflow oder dangling Pointer finden, 
die wild in den Speicher schreibt.

[Jim M. (turboj)]

Dr. Sommer schrieb:
> Im Debugger Watchpoint auf die Variable setzen

Sowas modernes hat nicht jeder µC in der Featureliste.

Und der OP schrieb nix zur Umgebung oder dem verwendeten Controller. 
Noch besser wäre allerdings das konkrete Programm geeignet zur 
Fehlersuche, meine Glaskugel ist in Reparatur.

[R. M. (n_a_n)]

Variablen setzen sich gerne auf die 0, weil die so weich ist.

[Thomas E. (picalic)]

Vielleicht hilft es auch, die Variablen außerhalb der while-Schleife zu 
deklarieren. Sonst werden sie bei jedem Durchlauf neu angelegt und damit 
auch initialisiert.

[Kalli L. (knl)]

Hallo Lisa,
was meine Vorposter meinen,
ist dass du mal dein Programm posten solltest.
Dann ist der Fehler einfacher zu finden.
Gruß, Knut.

[Lisa (Gast)]

Tut mir leid, dass ich das Programm nicht hier reinschreiben darf, da 
ich in einem Unternehmen meine Bachelorarbeit schreibe und anschließend 
dann wahrscheinlich meinen eigenen Code zitieren muss, da er bereits im 
Internet steht.
Ich habe gehofft, dass es vielleicht ein gängiges Problem ist, welches 
ich nicht kenne. Die Programmierung von Microcontrollern ist für mich 
Neuland.

Ich kann es einmal mit Beschreibung des Codes probieren, die für die 
Variable relevant sind.



Variablendeklaration global

Eine ISR empfängt Zeichen und speichert die in einem String

int main ()
{
while (true)
{ 
if( Neue Zeichenkette wurde empfangen)  
 {
   if (r=1)
      Schalte die LED ein;
   if (erstes Zeichen der Zeichenkette = !)
      r=1;
   
 }
else
 //Sende Fehler
 
}
}

Ungefähr so sieht das Programm aus. Die Bedingung r=1 wird nie 
aufgerufen.

[Wegstaben V. (wegstabenverbuchsler)]

wo wird denn der Wert von r geändert?

[Kein Gast (Gast)]

Wegstaben V. schrieb:
> wo wird denn der Wert von r geändert?



Lisa schrieb:
> if (r=1)

[Ingo L. (corrtexx)]

Lisa schrieb:
> if (erstes Zeichen der Zeichenkette = !)
Dann liegt hier der Fehler vor

[Lisa (Gast)]

Jim M. schrieb:
> Und der OP schrieb nix zur Umgebung oder dem verwendeten Controller

Ich verwende einen ATmega32A und programmiere den in AtmelStudio 7.0. 
Zum Debuggen verwende ich einen Atmel ICE über die JTAG Schnittstelle.

[Ingo L. (corrtexx)]

Kein Gast schrieb:
>> if (r=1)
Es sollte sicher if (r==1) heissen. Compilerwarnungen sollte man nicht 
missachten

[Lisa (Gast)]

Ingo L. schrieb:
> Dann liegt hier der Fehler vor

Entschuldigung ich habe in der If Bedingung r==1 und nichr r=1 
geschrieben.

[Ingo L. (corrtexx)]

Naja, dann ist doch der Fehler weiterhin offensichtlich:

Ingo L. schrieb:
> Dann liegt hier der Fehler vor

[Dr. Sommer (Gast)]

Thomas E. schrieb:
> Vielleicht hilft es auch, die Variablen außerhalb der while-Schleife zu
> deklarieren. Sonst werden sie bei jedem Durchlauf neu angelegt und damit
> auch initialisiert.
Kennst du irgendeinen Compiler der das nicht auf jeder Einstellung 
wegoptimiert und nicht alles am Anfang der Funktion anlegt?

Jim M. schrieb:
> Sowas modernes hat nicht jeder µC in der Featureliste.
Achja, man muss ja unbedingt alte Gammel-Technik nutzen. Zum Glück haben 
Cortex-M das.

Solche Fehler sind selbst mit Code schwierig zu finden, ohne Code kann 
man das vergessen. Watchpoints, Valgrind (am PC) o.ä. können helfen. Ein 
scharfer Blick auf alle Array & Pointer-Zugriffe, ob da nur auf das 
richtige zugegriffen wird, ist auch eine gute Idee.

[Lisa (Gast)]

Ingo L. schrieb:
> Es sollte sicher if (r==1) heissen. Compilerwarnungen sollte man nicht
> missachten

In meinem Orginalprogramm gibt es keine Compilerwarnungen, weshalb ich 
mittlerweile echt ratlos bin.

[Ingo L. (corrtexx)]

Lisa schrieb:
> weshalb ich
> mittlerweile echt ratlos bin.
Dann zeig doch mal den vollständigen Code. Oft ist es eine Banalität die 
man selbst nicht sieht.

[Dr. Sommer (Gast)]

Lisa schrieb:
> In meinem Orginalprogramm gibt es keine Compilerwarnungen
Gib mal "-Wall -Wextra" an den Compiler, vielleicht kommen dann doch 
noch welche.

[Lisa (Gast)]

Dr. Sommer schrieb:
> Solche Fehler sind selbst mit Code schwierig zu finden, ohne Code kann
> man das vergessen. Watchpoints, Valgrind (am PC) o.ä. können helfen. Ein
> scharfer Blick auf alle Array & Pointer-Zugriffe, ob da nur auf das
> richtige zugegriffen wird, ist auch eine gute Idee.

Vielen Dank, für diese Antwort. Verstehen tu ich diese auch, jedoch wie 
ich das genau mache und letzendlich die Zugriffe verändere weiß ich 
nicht, aber ich kann ja in diese Richtung mich nun weiter informieren.

[Lisa (Gast)]

Ingo L. schrieb:
> Dann zeig doch mal den vollständigen Code. Oft ist es eine Banalität die
> man selbst nicht sieht.

Ich würde gern den kompletten Code posten, jedoch findet auch mein 
Professor diesen dann im Internet und kann diesen nicht mir zuordnen, 
weshalb dieser dann denkt, ich hätte ihn nur kopiert.

[Einer K. (Gast)]

Stichworte:
1. volatile
2. ATOMIC

Der Compiler setzt Variablen beim Programmstart auf 0.
Vielleicht folgt ein Reset, dem Anderen.

Ansonsten halte auch ich es für sehr schwierig einen Fehler in einem 
unsichtbaren Code zu finden und zu beheben.

[Dr. Sommer (Gast)]

Arduino F. schrieb:
> Der Compiler setzt Variablen beim Programmstart auf 0.
Nur globale und statische.

Arduino F. schrieb:
> Vielleicht folgt ein Reset, dem Anderen.
Einem Reset folgt automatisch eine Neu-Initialisierung durch die 
C-Library.

[Axel S. (a-za-z0-9)]

Lisa schrieb:
> Ingo L. schrieb:
>> Dann liegt hier der Fehler vor
>
> Entschuldigung ich habe in der If Bedingung r==1 und nichr r=1
> geschrieben.

Genau deswegen sollst du dein Programm zeigen. Und zwar genau(!) das 
Programm, das das fehlerhafte Verhalten zeigt. Wenn du das nicht kannst 
oder willst, dann können wir dir nicht helfen.

Die Chancen stehen 99:1 daß du da irgendwo einen Tippfehler ähnlich wie 
oben untergebracht hast.

[Dr. Sommer (Gast)]

Lisa schrieb:
> Tut mir leid, dass ich das Programm nicht hier reinschreiben darf, da
> ich in einem Unternehmen meine Bachelorarbeit schreibe
Frag deine Hochschul- und Unternehmensbetreuer nach Rat wenn du nicht 
weiterkommst. Wenn die dir nicht helfen können/wollen, frag 
(schriftlich!) ob du im Internet fragen und dabei den Code zeigen 
darfst.

[Lisa (Gast)]

Dr. Sommer schrieb:
> Frag deine Hochschul- und Unternehmensbetreuer nach Rat wenn du nicht
> weiterkommst. Wenn die dir nicht helfen können/wollen, frag
> (schriftlich!) ob du im Internet fragen und dabei den Code zeigen
> darfst.

Mein Betreuer konnte bisher auch nicht helfen, weshalb die schriftliche 
Genehmigung wohl der nächste Schritt sein wird. Bisher hatte ich die 
Hoffnung dass es vielleicht ein Problem ist, welches schon häufiger 
vorgekommen ist, sodass auch ohne Programm eine mögliche Lösung gefunden 
wird.

Danke an alle die trotz meiner gebundenen Hände versucht haben zu 
helfen.

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Dr. Sommer schrieb:
> Gib mal "-Wall -Wextra" an den Compiler, vielleicht kommen dann doch
> noch welche.

Beherzige das wenigstens. Kann etwas nerven, die wichtigen Warnungen von 
unwichtigen zu unterscheiden, aber es schadet auch nichts, alle 
Warnungen zu beseitigen.
Besonders verdächtig sind in deinem Fall Dinge wie 'possibly unwanted 
assigment in <Zeile>)'

[Dr. Sommer (Gast)]

Matthias S. schrieb:
> Kann etwas nerven, die wichtigen Warnungen von
> unwichtigen zu unterscheiden, aber es schadet auch nichts, alle
> Warnungen zu beseitigen.
Ich würde sogar grundsätzlich immer alle Warnungen durch 
Code-Korrekturen beseitigen, damit die wichtigen Warnungen nicht 
zwischen den unwichtigen untergehen, und weil "unwichtige" Warnungen 
auch auf zukünftige potentielle Problem hindeuten können. Wenn man's 
ernt mein nimmt man noch "-pedantic"...

[Fabian H. (hdr)]

In Zeile 42 sieht man, dass dein Interrupt falsch benannt ist. Somit 
springt dein Programm da nie rein, sondern macht ein Reset. Außerdem 
musst Du daran denken, dass r auch als volatile deklariert ist.

[Lisa (Gast)]

Dr. Sommer schrieb:
> Gib mal "-Wall -Wextra" an den Compiler, vielleicht kommen dann doch
> noch welche.

Matthias S. schrieb:
> Beherzige das wenigstens.

Ich habe das damit probiert und bekomme leider immernoch keine Fehler.

[Dr. Sommer (Gast)]

Lisa schrieb:
> Ich habe das damit probiert und bekomme leider immernoch keine Fehler.
Auch keine Warnungen? Es kompiliert ja trotz Warnungen, die muss man 
explizit anschauen. schreib einfach mal "7;" in deine main(), das sollte 
die Warnung "statement with no effect" provozieren. Da wo das steht 
könnten noch mehr Warnungen stehen.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Lisa schrieb:
> Tut mir leid, dass ich das Programm nicht hier reinschreiben darf
Dann mach einen Dreizeiler, der das selbe Problem hat. Den kann man 
anschließend untersuchen. So wie das jetzt läuft ist es nur eine 
brotlose Raterei.
Ich könnte jetzt sicher auch ein paar Tipps geben, die auch nicht 
weiterhelfen...

Lisa schrieb:
> Ich habe das damit probiert und bekomme leider immernoch keine Fehler.
Aber Warnungen?

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Wenn r ein Flag ist und in der ISR gesetzt wird, um main() was 
mitzuteilen, sollte r wirklich als 'volatile' erklärt werden, weil sonst 
der Compiler dazu verleitet wird, r evtl. weg zu optimieren.
Apropos Optimierung, wie stehen denn da die Optionen?

[Lisa (Gast)]

Dr. Sommer schrieb:
> Auch keine Warnungen?

Lothar M. schrieb:
> Aber Warnungen?

Nein auch keine Warnungen. Die hab ich bisher auch immer direkt 
beseitigt.

Lothar M. schrieb:
> Dann mach einen Dreizeiler, der das selbe Problem hat.

Das versuche ich nun mal. Gib mir jedoch 15 min :)

[Lutz H. (luhe)]

Werden die Variablen in den Schleifen zweimal neu definiert?
Diesen Fehler nehme ich gern.

[Lisa (Gast)]

Lutz H. schrieb:
> Werden die Variablen in den Schleifen zweimal neu definiert?

Nein nur einmal global als volatile int

[Thomas E. (picalic)]

Dr. Sommer schrieb:
> Kennst du irgendeinen Compiler der das nicht auf jeder Einstellung
> wegoptimiert und nicht alles am Anfang der Funktion anlegt?

Ja, der ARM-Compiler von Keil z.B. Wenn ich da eine Variable am Anfang 
einer while-Schleife deklariere, wird die auch nur dort angelegt und 
nicht am Anfang der Funktion.

@Lisa: ich vermute, Du musst Deine ggf. in der ISR veränderten Variablen 
(hier: "r"?) zusätzlich als "volatile" deklarieren, sonst kriegt das 
main()-Programm nicht mit, wenn die ISR die Variable verändert!

[Nogger (Gast)]

Volatile und atomic

Das sollte als Suchbegriff ausreichen.

[Lisa (Gast)]

Thomas E. schrieb:
> zusätzlich als "volatile" deklarieren

Ich habe bereits alle Variablen als volatile deklariert, die in der ISR 
oder auch in anderen Funktionen verändert werden. Kann das auch das 
Problem sein?

[Dr. Sommer (Gast)]

Nogger schrieb:
> Das sollte als Suchbegriff ausreichen.
Und das deckt auch Dinge wie Buffer Overflows, Strict Aliasing, Dangling 
Pointers ab, welche typischer Ursachen für derartiges Verhalten sind?

Thomas E. schrieb:
> Ja, der ARM-Compiler von Keil z.B. Wenn ich da eine Variable am Anfang
> einer while-Schleife deklariere, wird die auch nur dort angelegt und
> nicht am Anfang der Funktion.
Interessant, kannst du dafür ein Beispiel zeigen? z.B. wie das optimiert 
wird:

void test2 (int a) {
  printf ("%d\n", a);
}
void test () {
  int a = 0;
  while (a < 100) {
    int b = 7;
    test2 (a + b);
  }
}

Der GCC macht daraus:

   c:  b508        push  {r3, lr}
   e:  2007        movs  r0, #7
  10:  f7ff fffe   bl  0 <test2>
  14:  e7fb        b.n  e <test+0x2>
  16:  bf00        nop

Die Variable verschwindet hier sogar komplett. In Fällen wo sie nicht 
verschwindet, wird sie sich wohl zwischendurch ändern, und dann ist die 
Neu-Initialisierung sowieso erforderlich.

[Lisa (Gast)]

Lisa schrieb:
> Lothar M. schrieb:
>> Dann mach einen Dreizeiler, der das selbe Problem hat.
>
> Das versuche ich nun mal. Gib mir jedoch 15 min :)

Ich brauche für ein neues ähnliches Programm doch länger, da mein 
Orginal Programm schon viele einzele Kleinigkeiten beachtet, sodass 
umbenennen und rauslöschen sich nicht als einfach erweist.

[Rufus Τ. F. (rufus)]

Lisa schrieb:
> Eine ISR empfängt Zeichen und speichert die in einem String

--> volatile

(nicht, daß das nicht schon mehrfach erwähnt worden wäre)

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Lisa schrieb:
> Ich brauche für ein neues ähnliches Programm doch länger
Hatte ich erwartet.

> da mein Orginal Programm schon viele einzele Kleinigkeiten beachtet,
> sodass umbenennen und rauslöschen sich nicht als einfach erweist.
Und der Nebeneffekt dieser Arbeit könnte sein, dass du den Fehler ganz 
allein findest...

[grundschüler (Gast)]

Schreib den relevanten Programmteil - isr, main, ggf. Unterfunktionen - 
neu und stell ihn hier ein. Das hilft erstens bei der Kontrolle der 
eigenen Gedankengänge, ist zweitens vermutlich ohnehin erforderlich und 
führt drittens mit einiger Wahrscheinlichkeit zur Problemlösung.

[Thomas E. (picalic)]

Dr. Sommer schrieb:
> Die Variable verschwindet hier sogar komplett. In Fällen wo sie nicht
> verschwindet, wird sie sich wohl zwischendurch ändern, und dann ist die
> Neu-Initialisierung sowieso erforderlich.

Wenn die Variable am Anfang der while-Schleife deklariert und auch 
initialisiert wird, ist eh klar, daß sie bei jedem Schleifendurchlauf 
wieder neu initialisiert wird.
Ich meinte aber eher sowas wie hier:

  while(1)
  {
    int test;
    if(test&0x80)
      GPIO_ResetBits(GPIOB, GPIO_Pin_5);
    else
      GPIO_SetBits(GPIOB, GPIO_Pin_5);
    test++;
  }

Man könnte meinen, daß der Port alle 128 Schleifendurchläufe getoggled 
wird, das funktioniert aber nicht, bzw. nur manchmal, je nach 
Optimierungslevel!

[Dr. Sommer (Gast)]

Thomas E. schrieb:
> Wenn die Variable am Anfang der while-Schleife deklariert und auch
> initialisiert wird, ist eh klar, daß sie bei jedem Schleifendurchlauf
> wieder neu initialisiert wird.
Nur wenn sie überhaupt zwischendurch geändert wird, ansonsten wird sie 
als Konstante wegoptimiert.

Thomas E. schrieb:
> das funktioniert aber nicht, bzw. nur manchmal, je nach
> Optimierungslevel!
test ist nicht initialisiert, das ist einfach falscher Code, der wird 
halt kaputtoptimiert... GCC warnt da auch.

Ich meinte sowas:

  while(1)
  {
    int test = 0;
    if(test&0x80)
      GPIO_ResetBits(GPIOB, GPIO_Pin_5);
    else
      GPIO_SetBits(GPIOB, GPIO_Pin_5);
  }

sollte ein identisches Kompilat wie

  int test = 0;
  while(1)
  {
    if(test&0x80)
      GPIO_ResetBits(GPIOB, GPIO_Pin_5);
    else
      GPIO_SetBits(GPIOB, GPIO_Pin_5);
  }

liefern (allerdings ein relativ witzloses).

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Thomas E. schrieb:
> das funktioniert aber nicht, bzw. nur manchmal, je nach Optimierungslevel!
Aber sicher dann, wenn static mit ins Spiel kommt.

[Dr. Sommer (Gast)]

Lothar M. schrieb:
> Aber sicher dann, wenn static mit ins Spiel kommt.
Ja, dann wird's mit 0 initialisiert. Sonst wird /irgendein zufälliger 
Wert/ hineingeschrieben. Es gibt aber keine Garantie über die Verteilung 
der Zufallswerte, die können immer 0, oder immer 42, oder sonst 
irgendwas sein was da gerade im Prozessor&RAM herumliegt.

[Thomas E. (picalic)]

Dr. Sommer schrieb:
> das ist einfach falscher Code,

Das weiß ich doch! ich meinte ganz oben ja auch nur, daß Lisa evtl. eben 
genau solchen falschen Code geschrieben haben könnte (ihren "echten" 
Code kennen wir ja nicht...)

[Lisa (Gast)]

Meine verschiedenen Testvariablen sind entweder direkt am Anfang in der 
Main deklariert oder als globale Variablen als volatile int.

In der while(1) Schleife, die ja schließlich dauerhaft durchlaufen wird, 
werden sie an unterschiedlichen Stellen jeweils einmal in einer If- 
Bedingung aufgerufen und auf 1 gesetzt. Sobald die while Schleife jedoch 
das nächste mal durchläuft sind alle Variablen wieder auf 0 gesetzt und 
wenn ich es als char deklariere wieder auf den "Wert" den ich bei der 
Variablendeklaration festgelegt habe. Also da ja normalerweise die while 
(1) -Schleife nicht verlassen wird, dürfte sich der Wert doch nicht auf 
das ändern was oberhalb der while festgelegt wurde.

Oder gibt es die Möglichkeit, dass aus irgendeinem Grund die 
while-Schleife verlassen wird und das Programm sich neu initialisiert?

[Dietrich L. (dietrichl)]

Lisa schrieb:
> Oder gibt es die Möglichkeit, dass aus irgendeinem Grund die
> while-Schleife verlassen wird und das Programm sich neu initialisiert?

Ja, z.B.
- Interrupt ohne ISR
- HW-Reset durch Störung auf der Reset-Leitung
- Watchdog läuft ab

[Stefan K. (stefan64)]

Benutze doch mal den Debugger, den Du hast. Setze z.B. Breakpoints oder 
nutze den Einzelschritt. Damit sollte sich die Stelle finden lassen, wo 
die Variablen nullgesetzt werden.

Gruß Stefan

[Lisa (Gast)]

Hier ist die while Schleife. Ein paar definitiv nicht relevante Teile 
habe ich rausgelassen. Die Variable "test" wurde global als volatile int 
definiert. Beim debuggen von Zeile zu Zeile habe ich festgestellt, dass 
ide Variable in der while gesetzt wird, jedoch sobald die while Schleife 
oben wieder beginnt wieder auf 0 gesetzt wird. Auch die Variablen get, 
set, und status werden nach jedem Durchlauf auf 0 gesetzt.

while (1)
  {
    if (complete && start == 1 )            //Überprüfen ob kompletter String erhalten wurde
    {
      
      str_len=0;
      //Länge des Strings zählen
      while(rx_str[str_len]!='\0')
      {
          str_len++;
          test=1;
      }
        
      if (rx_str[0]=='!')            
      {...}
      
      else if (rx_str[0]=='R')                      
      {
        if (status==0)
        {
                                    ...
          if (get == 1)
          {
            set_relais();
            set=1;
          }
          
        }
        
      }
      
      else if (rx_str[0]=='S')    
      {
        if (set == 1)
        {
        status = get_status ((char*)rx_str,str_len);      
          
          if (status==1)                      
          {
            Transmits ("901");              
          }
          else
            Transmits ("902");              
        }
        else
        {
           status=0;
           Transmits("906");              
        }
      }
      
      Transmits("END");
      start=0;
      
    }
    else
    {    
       if (status==1)                        
      {
        PORTB &= ~(1<<PORTB4);    
        while (n<1)
        {
          Transmits("905");                  
          n++;
        }
      }
      
      else
        {
        PORTB |= (1<<PORTB4);  
        n=0;
        }
    }

[R. M. (n_a_n)]

Lisa schrieb:
> while(rx_str[str_len]!='\0')  <-- sicher das der String nullterminiert ist ?

[Viktor B. (coldlogic)]

In der geposteten While-Schleife fehlt eine }, kann das sein?

[Lisa (Gast)]

R. M. schrieb:
> sicher das der String nullterminiert ist ?

Ja da bin ich mir recht sicher, da alles andere in meinem Programm 
funktioniert, also die entsprechenen Funktionen aufgerufen werden. Ich 
setze in meiner ISR sobald ich ein \n oder \r erhalten habe das \0. Und 
beim Debuggen wurde auch angezeigt, dass die Variable auf 1 gesetzt 
wurde.

[Lisa (Gast)]

Viktor B. schrieb:
> In der geposteten While-Schleife fehlt eine }, kann das sein?

Ja das ist gut möglich. Hab im richtigen Programm nachgezählt und da 
passt es.

[R. M. (n_a_n)]

Ich würde als erstes ausschliessen das der Fehler nicht in der while 
Loop
liegt.
z.B.
die ISR ganz ausschalten.
in den rx_str buffer etwas sinnvolles schreiben (was das musst du 
wissen)
und dann im Einzelschritt die while Loop debuggen.

[Lisa (Gast)]

R. M. schrieb:
> Ich würde als erstes ausschliessen das der Fehler nicht in der while
> Loop
> liegt.

Danke, das werde ich morgen versuchen. Jetzt habe ich leider erst noch 
ein Meeting.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Lisa schrieb:
> Die Variable "test" wurde global als volatile int definiert.
Welchen Sinn hat diese Variable?
Die wird ja nur 1x auf 1 gesetzt und sie wird nirgends verwendet...

> Hier ist die while Schleife. Ein paar definitiv nicht relevante Teile
> habe ich rausgelassen. Die Variable "test" wurde global als volatile int
> definiert. Beim debuggen von Zeile zu Zeile habe ich festgestellt, dass
> ide Variable in der while gesetzt wird
Genau mit diesem Code?
Denn das soll der Sinn des "Dreizeilers" sein: dass dort in wenigen 
Zeilen nachvollziehbar der Fehler mit drin sitzt.

[J. T. (chaoskind)]

Lisa schrieb:
> werden sie an unterschiedlichen Stellen jeweils einmal in einer If-
> Bedingung aufgerufen und auf 1 gesetzt

Ist denn die if-Bedingung überhaupt erfüllt? Nicht dass doe Variablen 
gar nicht gesetzt werden....

[Patrick J. (ho-bit-hun-ter)]

Hi

Lisa schrieb:
> beim Debuggen wurde auch angezeigt, dass die Variable auf 1 gesetzt
> wurde.

Liest sich so, daß die 'test'-Variable auf 1 gesetzt wird.

Wenn das Problem in diesem Code ebenfalls auftritt, dürfte dort keine 
Klammer fehlen, da der Code ja compiliert und geprüft wurde, wo der 
erneut auftretende Fehler erkannt wurde.
Da doch eine Klammer fehlt, wurde irgendwo 'geschludert' ;)

Nutzt Du 'test' noch irgendwo anders?
Funkt dort vll. immer ein Timer-Interrupt dazwischen, der Test immer 
wieder auf Null setzt?

MfG

[Lisa (Gast)]

Guten Morgen,

Lothar M. schrieb:
> Genau mit diesem Code?

Nein ich habe das nicht genau mit diesem Code gemacht. Ich habe bei dem 
Code den ich gepostet habe Funktionsaufrufe gelöscht, von 
void-Funktionen, die definitiv nicht relevant sind, da dort 
beispielsweise nur der String ausgegeben oder verarbeitet wird, aber 
nicht auf die Variablen zugegriffen wird, die sich jedes mal auf 0 
setzen.

Patrick J. schrieb:
> Nutzt Du 'test' noch irgendwo anders?
die Variable "test" habe ich nur ergänzt, damit ich eine Variable habe, 
die in keinem anderen Teil des Programms verwendet wird, damit ich 
aussichließen kann, dass die irgendwo von meinem Programm aus auf 0 
gesetzt wird.

Ich habe heute morgen oberhalb der while Funktion eine Textausgabe 
hinzugefügt, die scheinbar die ganze Zeit ausgegeben wird, obwohl sie in 
keiner while Funktion steht.
Warum startet mein Programm denn ständig neu? Kann das auch ein 
Hardwarefehler sein?

[grundschüler (Gast)]

Lisa schrieb:
> Kann das auch ein Hardwarefehler sein?

Wenn man denn die Hardware kennen würde. Relevanten Teil des Programms 
für sichere Hardware - z.B. M328 uno - umschreiben und testen.

[Lisa (Gast)]

grundschüler schrieb:
> Wenn man denn die Hardware kennen würde

Ich benutze einen ATmega32A, von dem ich die Beschaltung selbst nach 
Datenblatt entworfen habe.

[HildeK (Gast)]

Lisa schrieb:
> Warum startet mein Programm denn ständig neu?

Hast du einen Interrupt aktiviert, ohne Interrupt Service Routine dazu 
zu haben?

[Thomas (kosmos)]

Läuft deine Variable vielleicht über? 1+1, 2+1, 3+1....254+1, 255+1, 
0+1.... oder vielleicht erst bei 65535?

[Georg G. (df2au)]

Lisa schrieb:
> Warum startet mein Programm denn ständig neu?

Die gängigsten Fußangeln:
- Watchdog aktiv
- Interrupt Service Routine mit falschem Namen (und Warnung übersehen)
- return() in main()

[Frank M. (ukw) (Moderator)]

Georg G. schrieb:
> - return() in main()

Ziemlich unwahrscheinlich. Ein AVR klebt in einer Endlosschleife, sobald 
main per return verlassen wird.

[Lisa (Gast)]

Ich habe die Lösung nun gefunden.

Mein Programm hatte Probleme damit, dass alle ISR aktiviert werden durch 
die sei() Funktion. Ich kenne die Aktivierung von meiner Hochschule und 
in den Programmen hat das auch immer funktioniert. So wie ich das 
verstanden habe verhindert eine Ergänzung um folgende ISR, dass ständig 
ein "Reset" ausgefürt wird und mein Programm, inkl. Initialisierungen, 
neu gestartet wird.

ISR(BADISR_vect)
{

}

Danke nochmal für die vielen Tipps, die letzendlich zur Lösung führten.

[Frank M. (ukw) (Moderator)]

Lisa schrieb:
> Ich habe die Lösung nun gefunden.

Deine Lösung doktert nur an den Symptomen und behebt nicht die 
eigentliche Ursache:

Das avrlibc-Manual sagt zu BADISR_vect:

"This is a vector which is aliased to __vector_default, the vector 
executed when an ISR fires with no accompanying ISR handler. This may be 
used along with the ISR() macro to create a catch-all for undefined but 
used ISRs for debugging purposes."

> Mein Programm hatte Probleme damit, dass alle ISR aktiviert werden durch
> die sei() Funktion.

sei() alleine bewirkt erstmal nur, dass die von Dir vorher aktivierten 
Interrupts freigeschaltet werden. Wenn Du vorher keine Interrupts 
aktiviert hast, bewirkt sei() überhaupt nichts.

Fazit:
Du musst für sämtliche aktivierten Interrupts auch eine ISR() 
definieren. Entweder hast Du da zu viele Interrupts versehentlich 
aktiviert oder Du hast mindestens eine ISR() vergessen.

Mit der Definition von ISR(BADISR_vect) verdeckst Du nur den Fehler.

[HildeK (Gast)]

Lisa schrieb:
> Mein Programm hatte Probleme damit, dass alle ISR aktiviert werden durch
> die sei() Funktion.

Mit sei() (global interrupt enable) werden nicht alle Interrupts 
aktiviert, sondern nur freigeschaltete.
Um einen Interrupt zu aktivieren, muss noch zusätzlich jeder einzelne 
freigegeben werden und dann auch eine ISR haben.
Z.B.:
WDIE für den Watchdog Interrupt
PCIE für den Pin Change Interrupt
usw.
Du hast also irgendwo so ein IE für einen einzelnen Interrupt aktiviert, 
aber keine ISR dazu installiert.

[Lisa (Gast)]

Das hab ich noch nicht ganz verstanden. Wo aktiviere ich genau die 
Interrupts?

Das Folgende steht in meinem Code, was mit Interrupts zu tun hat.

#include <avr/interrupt.h>

ISR (USART_RXC_vect)
{
...
}

und das
sei()
in der Main

[Frank M. (ukw) (Moderator)]

Frank M. schrieb:
> Mit der Definition von ISR(BADISR_vect) verdeckst Du nur den Fehler.

Ich gehe sogar noch weiter, weil das Programm ja offenbar zu Deiner 
Bachelor-Arbeit gehört: Wenn ein Prüfer Deine "Lösung" liest und weiß, 
dass BADISR_vect nur eine Notlösung ist, um einen Programmfehler zu 
kaschieren, dann wirkt sich das gewiss negativ auf die Bewertung Deiner 
Arbeit aus.

Ich persönlich als Leser so eines Codes würde jedenfalls sofort denken: 
"Da weiß einer nicht, was er macht".

[Der Andere (Gast)]

Langsam keimt in mir der Verdacht es geht um eine Batchelorarbeit in 
Kunst.

[Lisa (Gast)]

Frank M. schrieb:
> "Da weiß einer nicht, was er macht"

Ja das kann ich verstehen und so wirklich weiß ich mittlerweile wirklich 
nicht mehr was ich da mache.

Bin gerade dabei nochmal im Datenblatt zu lesen, ob ich da etwas finde, 
was mir beim Verständis hilft.

[Frank M. (ukw) (Moderator)]

Lisa schrieb:
> Das hab ich noch nicht ganz verstanden. Wo aktiviere ich genau die
> Interrupts?
> Das Folgende steht in meinem Code, was mit Interrupts zu tun hat.
> #include <avr/interrupt.h>
>  ISR (USART_RXC_vect)
> {
> ...
> }

Den USART_RXC-Interrupt aktivierst Du mit dem Setzen des RXCIE0-Bits im 
USART Control-and-Status Register B – UCSRB. Suche mal danach in Deinem 
Code! :-)

Aber dafür hast Du ja eine ISR definiert. Irgendwo hast Du noch einen 
weiteren Interrupt versehentlich aktiviert - vermutlich durch Kupfern 
irgendwelcher anderen Initialisierungsroutinen.

[Cyblord -. (cyblord)]

Frank M. schrieb:
> Aber dafür hast Du ja eine ISR definiert. Irgendwo hast Du noch einen
> weiteren Interrupt versehentlich aktiviert - vermutlich durch Kupfern
> irgendwelcher anderen Initialisierungsroutinen.

Pfui, wird hier angedeutet diese Koryphäe würde Code per Copy&Paste 
übernehmen?

[Lisa (Gast)]

Frank M. schrieb:
> Den USART_RXC-Interrupt aktivierst Du mit dem Setzen des RXCIE0-Bits im
> USART Control-and-Status Register B – UCSRB. Suche mal danach in Deinem
> Code! :-)
>
> Aber dafür hast Du ja eine ISR. Irgendwo hast Du noch einen weiteren
> Interrupt versehentlich aktiviert - vermutlich durch Kupfern
> irgendwelcher anderen Initialisierungsroutinen.

Danke, das hat geholfen, wo cih genau suchen muss!
Jetzt habe ich den Fehler.
Ich habe den TX-Interrupt ausversehen mit aktiviert.

[Der Andere (Gast)]

Lisa schrieb:
> Bin gerade dabei nochmal im Datenblatt zu lesen

Du solltest eher mal allgeime Grundlagen zur µC Programmierung lesen.

Damit ich hier nicht nur dumm rumschwalle:

Lisa schrieb:
> Das hab ich noch nicht ganz verstanden. Wo aktiviere ich genau die
> Interrupts?

https://www.mikrocontroller.net/articles/AVR-Tutorial:_Interrupts
https://www.mikrocontroller.net/articles/Interrupt
http://www.avr-tutorials.com/interrupts/about-avr-8-bit-microcontrollers-interrupts

Oder als Stichworte:
"interrupt enable register"

[Frank M. (ukw) (Moderator)]

Hier die Interrupt-Vektor-Tabelle eines ATmega32:

$000 jmp RESET ; Reset Handler
$002 jmp EXT_INT0 ; IRQ0 Handler
$004 jmp EXT_INT1 ; IRQ1 Handler
$006 jmp EXT_INT2 ; IRQ2 Handler
$008 jmp TIM2_COMP ; Timer2 Compare Handler
$00A jmp TIM2_OVF ; Timer2 Overflow Handler
$00C jmp TIM1_CAPT ; Timer1 Capture Handler
$00E jmp TIM1_COMPA ; Timer1 CompareA Handler
$010 jmp TIM1_COMPB ; Timer1 CompareB Handler
$012 jmp TIM1_OVF ; Timer1 Overflow Handler
$014 jmp TIM0_COMP ; Timer0 Compare Handler
$016 jmp TIM0_OVF ; Timer0 Overflow Handler
$018 jmp SPI_STC ; SPI Transfer Complete Handler
$01A jmp USART_RXC ; USART RX Complete Handler
$01C jmp USART_UDRE ; UDR Empty Handler
$01E jmp USART_TXC ; USART TX Complete Handler
$020 jmp ADC ; ADC Conversion Complete Handler
$022 jmp EE_RDY ; EEPROM Ready Handler
$024 jmp ANA_COMP ; Analog Comparator Handler
$026 jmp TWI ; Two-wire Serial Interface Handler
$028 jmp SPM_RDY ; Store Program Memory Ready Handler
;

Einen dieser Interrupts aktivierst Du versehentlich. Ich tippe mal auf 
USART_TXC. Diesen aktivierst Du durch Setzen vom TXCIE-bit in UCSRB. 
Suche mal danach und kommentiere diese Stelle aus. Ebenso natürlich die 
Definition von BADISR_vect().

Wenn das Programm dann nicht mehr fortlaufend neustartet, hast Du die 
Ursache gefunden.

EDIT:

Gerade gelesen:

Lisa schrieb:
> Jetzt habe ich den Fehler. Ich habe den TX-Interrupt ausversehen mit
> aktiviert.

Da war mein Tipp ja goldrichtig :-)

Denke daran, BADISR_vect() wieder rauszunehmen.

[HildeK (Gast)]

Lisa schrieb:
> Das hab ich noch nicht ganz verstanden. Wo aktiviere ich genau die
> Interrupts?

Schau dir mal im DB die Tabelle "Interrupt Vectors in ATmega32" an.
Das sind die möglichen Interrupts und für jeden gibt es ein Bit in einem 
Register, mit dem du ihn aktivieren kannst - im entsprechenden Abschnitt 
zu der Funktion beschrieben. Diese Bits heißen meist xxIE.
Für USARTs sind z.B. drei Interrupts möglich (UDR, RXC, TXC). Wenn alle 
drei Bits im Register UCSRB aktiviert sind, dann müssen auch drei ISRs 
vorhanden sein.

[Lisa (Gast)]

So ich danke nun allen nochmal, die mir geholfen haben! DANKE!

Leider waren auch viele dazwischen, die sich gerne darüber lustig 
machen, dass man etwas nicht so gut kann wie die Person selbst. Ich weiß 
selbst, dass Programmieren nicht meine Stärke ist, weshalb ich auch 
nicht Informatik studiere. Die Programmierung ist nicht meine 
Hauptaufgabe in der Bachelorarbeit. Zudem bin ich in einem Unternehmen, 
in dem die Programmierung normalerweise von externen Firmen übernommen 
wird, sodass ich hier leider nicht so viel Hilfe bekommen konnte. Ich 
bin schon stolz darauf, dass ich es geschafft habe überhaupt ein (bis 
auf den einen Fehler mit dem Interupt) funktionierendes Programm zu 
schreiben. Das war viel Arbeit mit Durcharbeiten der Tutorials und des 
Datenblattes, sodass es halt, wie gerade bei den Interrupts, dazu kommen 
konnte, dass ich ein Detail nicht mehr wusste.

Denkt beim Schreiben auch mal daran, dass jeder seine Schwächen hat. Ich 
weiß welche ich habe, weshalb ich mich auch nicht von den Kommentaren 
habe entmutigen lasse, weiter zu machen.
Schließlich funktioniert mein Programm jetzt, nachdem ich das eine Bit 
geändert habe :)

[Cyblord -. (cyblord)]

Lisa schrieb:
> Leider waren auch viele dazwischen, die sich gerne darüber lustig
> machen, dass man etwas nicht so gut kann wie die Person selbst. Ich weiß
> selbst, dass Programmieren nicht meine Stärke ist, weshalb ich auch
> nicht Informatik studiere. Die Programmierung ist nicht meine
> Hauptaufgabe in der Bachelorarbeit.

Was studierst du denn und was ist deine Hauptaufgabe?

> Denkt beim Schreiben auch mal daran, dass jeder seine Schwächen hat. Ich
> weiß welche ich habe, weshalb ich mich auch nicht von den Kommentaren
> habe entmutigen lasse, weiter zu machen.

Bevor mir hier die Tränen in die Augen schießen, denke ich bei solchen 
Kommentaren immer: Was wenn ein angehender Chirurg oder Pilot o.ä. diese 
Zeilen schreiben würde? Und ich vielleicht bald mal unter dessen Messer 
liege oder in dessen Flugzeug ich sitzen muss und dann verschwindet mein 
Mitleid plötzlich und wird durch große Wut ersetzt, denn anscheinend 
legt heute niemand mehr Wert auf WISSEN und KÖNNEN sondern man findet 
immer eine Ausrede warum jetzt gerade zufällig DAS EINE nicht so gut 
kann (obwohl man doch gerade eine Abschlussarbeit damit macht also so 
weit weg von der angestrebten Profession kann es nicht sein).

Und dann fragt man sich wie schmal manche Leute ihr Fachgebiet 
definieren und ob es überhaupt einen Bereich gibt in dem ein exzellentes 
Verständnis der Materie und eine sichere Anwendung derselben gegeben 
sind. Oder ob einfach jede Aufgabe nicht 100% passt und man deshalb 
irgendwas hinschludert.

[Frank M. (ukw) (Moderator)]

Cyblord -. schrieb:
> Und ich vielleicht bald mal unter dessen Messer liege oder in dessen
> Flugzeug ich sitzen muss

Hör mal auf zu heulen. Es wird nicht dazu kommen, dass ein 
Bachelor-Student Dich operieren wird oder das Flugzeug steuert, in dem 
Du sitzt. Von daher ist Deine Argumentation vollkommen überzogen.

[Frank M. (ukw) (Moderator)]

Lisa schrieb:
> Die Programmierung ist nicht meine Hauptaufgabe in der Bachelorarbeit.

Ich wünsche Dir gutes Gelingen.

[Cyblord -. (cyblord)]

Frank M. schrieb:
> Cyblord -. schrieb:
>> Und ich vielleicht bald mal unter dessen Messer liege oder in dessen
>> Flugzeug ich sitzen muss
>
> Hör mal auf zu heulen. Es wird nicht dazu kommen, dass ein
> Bachelor-Student Dich operieren wird oder das Flugzeug steuert, in dem
> Du sitzt. Von daher ist Deine Argumentation vollkommen überzogen.

Aber was ein Vergleich ist, ist dir klar Frank oder? Schlag mal nach 
wenn nicht.

[Dr. Sommer (Gast)]

Sollte im Debugger nicht sofort auffallen dass da nicht einfach nur 
Variablen auf 0 gesetzt werden, sondern sich gleich der ganze Controller 
resettet? Das ergibt ja eine völlig andere Stelle an der man suchen 
muss...

[Cyblord -. (cyblord)]

Frank M. schrieb:
> Lisa schrieb:
>> Die Programmierung ist nicht meine Hauptaufgabe in der Bachelorarbeit.
>
> Ich wünsche Dir gutes Gelingen.

Letze Worte des Passagiers an den Piloten kurz vorm einsteigen, nach dem 
der Pilot erklärt hat, Landungen seien nicht so seins, aber Starts gehen 
für voll Knorke.

[Lisa (Gast)]

Frank M. schrieb:
> Ich wünsche Dir gutes Gelingen.

Danke!

PS: Meine Hauptaufgabe war die Hardwareentwicklung

[Frank M. (ukw) (Moderator)]

Cyblord -. schrieb:
> Aber was ein Vergleich ist, ist dir klar Frank oder?

Ja natürlich. Trotzdem musst Du zwischen einem angehendem Bachelor und 
einem fertig ausgebildeten Menschen durchaus unterscheiden.

Ein angehender Bachelor ist in der Regel ein noch sehr junger Mensch, 
welcher in der Ausbildung ist und lernt. Und auch Du weisst, dass man 
beim Lernen Fehler machen kann (und auch muss!). Gerade durch die Fehler 
lernt man.

Was ich Lisa hoch anrechne: Sie hat sich mit ihrer vermeintlichen 
"Lösung" der Definition von BADISR_vect() nach Erklärung unsererseits 
nicht zufriedengegeben, sondern hat versucht, den eigentlichen Fehler 
doch noch auszumerzen. Gerade das unterscheidet diejenigen, die sich 
im Leben durchbeißen von den Sesselpupsern, die später nichts auf die 
Reihe bekommen.

Von daher sehe ich bei Lisa einer etwaigen Piloten- oder 
Chirurgen-Karriere gelassen entgegen.

[Lisa (Gast)]

Dr. Sommer schrieb:
> Sollte im Debugger nicht sofort auffallen dass da nicht einfach nur
> Variablen auf 0 gesetzt werden, sondern sich gleich der ganze Controller
> resettet? Das ergibt ja eine völlig andere Stelle an der man suchen
> muss...

Leider war mir das beim Debuggen nicht aufgefallen, da ich in meiner 
Main nur eine while Schleife habe. Wahrscheinlich habe ich beim Debuggen 
auch etwas falsch gemacht.

[Cyblord -. (cyblord)]

Frank M. schrieb:
> Ja natürlich. Trotzdem musst Du zwischen einem angehendem Bachelor und
> einem fertig ausgebildeten Menschen durchaus unterscheiden.

Naja es ist ein ABSCHLUSS. Natürlich bin ich der Meinung der Bachelor 
sollte das nicht sein, aber die Mehrheit hier sieht das doch meist 
anders. Also Fertig ist Fertig aus meiner Sicht.

> Von daher sehe ich bei Lisa einer etwaigen Piloten- oder
> Chirurgen-Karriere gelassen entgegen.

Ich sehe das als ein Prinzip. Beim Chirurg wird's halt den meisten klar, 
aber natürlich sollte jeder gut und sorgfältig für seinen Beruf 
ausgebildet sein, egal ob nun direkt Menschenleben dranhängen oder 
nicht. Und gerade bei Ings. ist es doch nicht ganz unwahrscheinlich dass 
auch Sicherheitskritische Dinge entwickelt werden sollen.

Von daher ist mir deine relativierende Haltung hier nicht ganz 
einleuchtend.

[Dr. Sommer (Gast)]

Lisa schrieb:
> Leider war mir das beim Debuggen nicht aufgefallen, da ich in meiner
> Main nur eine while Schleife habe.
Hmm. Fürs nächste Mal: Benutz in solchen Fällen den 
Single-Instruction-Modus. Da sollte es beim Reset plötzlich in eine 
völlig andere Stelle springen, den Startup-Code, welcher eben die 
Variablen neu initialisiert.

[Felix F. (wiesel8)]

Dr. Sommer schrieb:
> Sollte im Debugger nicht sofort auffallen dass da nicht einfach nur
> Variablen auf 0 gesetzt werden, sondern sich gleich der ganze Controller
> resettet? Das ergibt ja eine völlig andere Stelle an der man suchen
> muss...
Ohne hier jemanden schlecht zu reden, aber einen Debugger muss man auch 
korrekt bedienen können.

Ich persönliche gebe am Anfang immer eine Startup Message per UART aus. 
Das erleichtert das Leben deutlich. Wobei das eigentlich nicht mehr 
relevant ist, da ARMs eh immer im Hardfault landen.

mfg

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Cyblord -. schrieb:
> und wird durch große Wut ersetzt ...
> und man deshalb irgendwas hinschludert.
Den Eindruck habe ich bei deinem Post insgesamt auch irgendwie. Aber es 
ist schön zu wissen, dass es einen sonst fehlerfreien Menschen gibt, der 
Anderen selbstverständlich laufend solche Vorhaltungen machen darf.

Cyblord -. schrieb:
> Aber was ein Vergleich ist, ist dir klar Frank oder?
Aber nicht alles was hinkt ist automatisch gleich ein Vergleich...

Lisa schrieb:
> Lothar M. schrieb:
>> Genau mit diesem Code?
> Nein ich habe das nicht genau mit diesem Code gemacht. Ich habe bei dem
> Code den ich gepostet habe Funktionsaufrufe gelöscht, von
> void-Funktionen, die definitiv nicht relevant sind
Es war mein Verdacht, dass diese im Code nicht sichtbaren Funktionen 
eben doch relevant sind. Und deshalb die Nachfrage nach einem kurzen 
Codeabschnitt, der den Fehler nachvollziehbar noch aufweist.
Und deshalb mein Hinweis, dass du bei der Reduzierung des Programms auf 
diesen Dreizeiler den Fehler selber finden wirst. Nämlich genau in dem 
Augenblick, wo du die "eigentlich nicht relevante" Zeile herauslöschst, 
wo der einsprechende Interrupt aktiviert wird.

BTW: ich hatte den Watchdog im Verdacht. Der kann solche laufenden 
Neustarts auch auslösen. Naja, knapp daneben... ;-)

[Frank M. (ukw) (Moderator)]

Cyblord -. schrieb:
> Frank M. schrieb:
>> Ja natürlich. Trotzdem musst Du zwischen einem angehendem Bachelor und
>> einem fertig ausgebildeten Menschen durchaus unterscheiden.
>
> Naja es ist ein ABSCHLUSS.

Du solltest genauer lesen. Ein angehender Bachelor hat bis dato 
überhaupt keinen Abschluss. Nichts anderes habe ich die ganze Zeit 
geschrieben.

[Cyblord -. (cyblord)]

Lothar M. schrieb:
> Cyblord -. schrieb:
>> und wird durch große Wut ersetzt ...
>> und man deshalb irgendwas hinschludert.
> Den Eindruck habe ich bei deinem Post insgesamt auch irgendwie. Aber es
> ist schön zu wissen, dass es einen sonst fehlerfreien Menschen gibt, der
> Anderen selbstverständlich laufend solche Vorhaltungen machen darf.
>
> Cyblord -. schrieb:
>> Aber was ein Vergleich ist, ist dir klar Frank oder?
> Aber nicht alles was hinkt ist automatisch gleich ein Vergleich...

Billige Polemik. Fällt dir nichts besseres ein?

> Du solltest genauer lesen. Ein angehender Bachelor hat bis dato
> überhaupt keinen Abschluss. Nichts anderes habe ich die ganze Zeit
> geschrieben.

Aber die Arbeit soll doch gerade der Nachweis für die Eignung und damit 
für den Abschluss sein.

[Pandur S. (jetztnicht)]

> Lisa ..
>Danke!
>
>PS: Meine Hauptaufgabe war die Hardwareentwicklung
>

Die Firmware schreiben zu koennen gehoert zur Hardwareentwicklung. Egal 
wer auch immer was anderes eraehlt. Denn sonst steht man irgendwann an 
einer Stelle wo ein Fehler zwischen Hardware und Software hin und 
hergeschoben wird. Keiner findet ihn weil er denkt, der Andere hat den 
Fehler gemacht.

[HildeK (Gast)]

Lisa schrieb:
> Leider waren auch viele dazwischen, die sich gerne darüber lustig
> machen, dass man etwas nicht so gut kann wie die Person selbst.

Naja, ich empfand das Bashing in diesem Thread sehr moderat - im 
Vergleich zu manch anderen Stellen hier im Forum. Wenn du hier unterwegs 
bist, darfst du nicht sehr empfindlich sein und brauchst dich erst recht 
nicht entmutigen zu lassen. Man muss ja nicht auf alles reagieren ...
Mich hat sogar gewundert, dass du nicht härter angegangen wurdest, weil 
du den fehlerhafte Code nicht gepostet hast bzw. ein auf das Problem 
reduziertes Beispiel.

Manche haben offenbar vergessen, dass sie auch mal angefangen haben und 
Fehler gemacht haben.

[Uwe B. (boerge)]

Cyblord -. schrieb:
>
> Aber die Arbeit soll doch gerade der Nachweis für die Eignung und damit
> für den Abschluss sein.

...und genau das hat sie getan! Sie hat sich nicht mit etwas 
"dahingewurschtelten" zufrieden gegeben, sondern, recht hartneckig, nach 
den Ursachen geforscht und, als sie nicht mehr weiter wusste, Fachleute 
gefragt. Gernau das sollst du mit einem akademischen Abschluss beweisen! 
...und nicht wissen, welches Bit, auf welcher krusten Hardwareplattform 
im Detail für was verantwortlich ist. Das steht irgendwo geschrieben und 
ändert sich jeden Monat!

[Frank M. (ukw) (Moderator)]

Cyblord -. schrieb:
> Aber die Arbeit soll doch gerade der Nachweis für die Eignung und damit
> für den Abschluss sein.

Ich wiederhole mich: Du solltest genauer lesen:

Lisa schrieb:
> Die Programmierung ist nicht meine Hauptaufgabe in der Bachelorarbeit.

Damit ist diese Arbeit ganz klar nicht hauptsächlich der Nachweis für 
die Eignung und damit für den Abschluss. Trotzdem hat sie diese Aufgabe 
gemeistert!

@cyblord:

Du tust immer noch so, als ob Dein persönliches Leben von der Lösung 
dieser Programmieraufgabe abhängt. Dann sei doch froh, dass das Forum 
Dir hier Deinen Arsch gerettet hat! ;-)

Dein Flugzeug wird landen! Und Du wirst die Operation, die Du während 
des Fluges im Gepäckabteil des Fliegers durchgestanden hast, auch 
überleben ;-)

[Cyblord -. (cyblord)]

Sapperlot W. schrieb:
>> Lisa ..
>>Danke!
>>
>>PS: Meine Hauptaufgabe war die Hardwareentwicklung
>>
>
> Die Firmware schreiben zu koennen gehoert zur Hardwareentwicklung.

Völlig Richtig. Vor allem bei reinen Digitalschaltungen. Denn wo liegt 
hier bitte überhaupt eine "Hardwareentwicklung"? Ein paar Controller und 
Digitalzeug verbinden und routen ist doch billigst. Darauf kann man sich 
doch heute nicht mehr zurückziehen.

Oder reden wir hier Tatsächlich von einem 10GHz Gerät für welches du die 
HW entwickelst hast? Oder nen 100kW Netzteil. Ich meine da gibt es schon 
potential für anspruchsvolle HW Entwicklung die den Namen verdient. Aber 
daran glaube ich in dem Fall nicht so recht.

Und genau DAS meine ich doch weiter oben. Man pfuscht unwissend die 
Software hin, weil man ja nur HW macht? Also das ist eben keine gute 
Einstellung.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Cyblord -. schrieb:
> Billige Polemik.
Gleiches mit Gleichem.

> Fällt dir nichts besseres ein?
Dazu nicht, nein. Auf jeden Fall nichts was es wert wäre, daraufhin 
gesagt zu werden...

BTW: hast du in diesem Thread eigentlich irgendwas zur Sache 
beigetragen? Oder nur von der Seite hereingeplärrt wie Waldorf und 
Statler bei der Muppet Show?

[Lisa (Gast)]

Cyblord -. schrieb:
> Aber die Arbeit soll doch gerade der Nachweis für die Eignung und damit
> für den Abschluss sein.

Bei meiner Bachelorarbeit muss ich immernoch weiter lernen, denn das was 
ich für meine BA bisher gemacht habe, habe ich im Studium nur 
ansatzweise gelernt.
Ich glaube nicht, dass mir der Fehler mit den Interrupts nochmal 
passieren wird, denn aus Fehlern lernt man bekanntlich am besten.

[Cyblord -. (cyblord)]

Frank M. schrieb:
> Damit ist diese Arbeit ganz klar nicht hauptsächlich der Nachweis für
> die Eignung und damit für den Abschluss. Trotzdem hat sie diese Aufgabe
> gemeistert!

Wenn du meine Posts auch mal lesen würdest, statt nur pseudo-lustige 
Antworten darauf zu geben, hättest du erkannt das ich genau diese 
Einstellung kritisiere und ich habe, sogar mit Beispielen, dargelegt 
warum.

Wer allerdings nur Sprüche macht, kann sich auf die Sache natürlich 
nicht mehr ganz so gut konzentrieren.

[Uwe B. (boerge)]

Cyblord -. schrieb:
> Ein paar Controller und
> Digitalzeug verbinden und routen ist doch billigst. Darauf kann man sich
> doch heute nicht mehr zurückziehen.

...och jetzt würde ich gern den Teil deiner Vita hören, wie du mit dem 
Hard-/Softwar-Zeugs angefangen hast...

[Frank M. (ukw) (Moderator)]

Cyblord -. schrieb:
> Wer allerdings nur Sprüche macht, kann sich auf die Sache natürlich
> nicht mehr ganz so gut konzentrieren.

Ich war jedenfalls konzentriert genug, um Lisa mit der Nase 
draufzustupsen. Ich muss mich aber nicht konzentrieren, um einem cyblord 
zu antworten, der mit völlig überzogenen Argumenten kommt. Das ist 
verlorene Zeit.

Ein Pilot in der Ausbildung fliegt Dich nicht. Ein Chirurg in der 
Ausbildung operiert Dich nicht. Ein Bachelor in der Ausbildung baut auch 
keine sicherheitsrelevante Elektronik.

Und damit schließe ich den Thread. Es wurde alles gesagt.

[Tuvalu (Gast)]

HildeK schrieb:
> Manche haben offenbar vergessen, dass sie auch mal angefangen haben und
> Fehler gemacht haben.

zum Beispiel der "Möchtegern-Blaublütige" :-)