mikrocontroller.net

Forum: Compiler & IDEs Alptraum jedes Programmierer: Code kompilierbar aber doch ein Denkfehler drin wer sieht´s?


Autor: Michal (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

ihr alle kennt sicher dieses Gefühl, ganz nah an der Lösung zu sein und 
trotzdem wie blind keinen Fehler finden zu können? Hier bin ich eben 
angelangt.

Die Variablen BDHighestFailureByte und CCHighestFailureByte sollen sich 
nur erhöhen und niemals senken können (Maximum-Tracer)...
Die gehen jedoch entsprechend mit BDStableFailureByte bzw. 
CCStableFailureByte mit, nicht nur rauf, auch runter!!!?

In den Funktionen, die ich hier aus Übersichtlichkeit-Gründen nicht 
beigefügt habe, werden sie nicht verarbeitet; könnten auch nicht weil 
sie ja nur in main deklariert sind.
Im gesamten Programm werden auch keine Pointer benützt.

Also ich finde hier keine Operation, die die BDHighestFailureByte und 
CCHighestFailureByte Variablen erniedrigen können, egal was immer mit 
allen anderen Variablen passieren

würde.

Und ihr?

Danke voraus für die Hilfe!






int main (void)

{  //############################################# Main program begin 
#############################################


unsigned char EqualFailuresCounter=0x00;      //   For checking if the 
failure is stable
unsigned char BDPreviousSingleFailureByte=0xFF;    //   For recording 
the previous single failure byte
unsigned char CCPreviousSingleFailureByte=0xFF;    //   For recording 
the previous single failure byte
unsigned char BDStableFailureByte=0x00;    //   Stable failure is 
recorded when the single failure did not change 30 times
unsigned char CCStableFailureByte=0x00;    //   Stable failure is 
recorded when the single failure did not change 30 times
unsigned char BDPreviousStableFailureByte=0xFF;    //   For recording 
the previous stable failure byte
unsigned char CCPreviousStableFailureByte=0xFF;    //   For recording 
the previous stable failure byte
unsigned char BDHighestFailureByte=0x00;      //  The highest failure 
byte ever observed
unsigned char CCHighestFailureByte=0x00;      //  The highest failure 
byte ever observed

OutputsInputsConfiguration ();

for(;;)  {  //############################ Endless loop begin 
############################

TestPattern ();
LEDsFailureSignalisation ();




    // Check if the single failure bytes changed since the last test 
pattern loop run

 if 
((BDPreviousSingleFailureByte==BDSingleFailureByte)&(CCPreviousSingleFai 
lureByte==CCSingleFailureByte))

  {EqualFailuresCounter++;}    // Increase the counter if the single 
failure bytes did not change

 else

  {EqualFailuresCounter=0;}    // Reset the counter if the single 
failure bytes changed

BDPreviousSingleFailureByte=BDSingleFailureByte;  //   Record the 
previous single failure byte for the next comparison
CCPreviousSingleFailureByte=CCSingleFailureByte;  //   Record the 
previous single failure byte for the next comparison




if (EqualFailuresCounter>30)    //   If the single failure did not 
change during the last 30 test pattern loop run...

  {
    EqualFailuresCounter=0;        //  Reset the counter
    BDStableFailureByte=BDSingleFailureByte;  //   Take over the failure 
as stable
    CCStableFailureByte=CCSingleFailureByte;  //   Take over the failure 
as stable
  }

          // Beep only once at a change of the stable failure, else too 
loud:

if 
((BDPreviousStableFailureByte!=BDStableFailureByte)|(CCPreviousStableFai 
lureByte!=CCStableFailureByte))

  {  //  Do not beep at the highest failure byte

    if 
((BDStableFailureByte<BDHighestFailureByte)|(CCStableFailureByte<CCHighe 
stFailureByte))

        BeepForPassOrFail ();  // Beep type is choosen inside of this 
function due to the global variables BD- and CCSingleFailureByte

  }

else   _delay_ms(10);                //  Do not beep at equal stable 
failures




BDPreviousStableFailureByte=BDStableFailureByte;  //   Record the 
previous stable failure byte for the next comparison
CCPreviousStableFailureByte=CCStableFailureByte;  //   Record the 
previous stable failure byte for the next comparison




if (BDStableFailureByte>BDHighestFailureByte)      //  Find out the 
highest BDFailureByte ever seen

  {BDHighestFailureByte=BDStableFailureByte;}    //  Find out the 
highest BDFailureByte ever seen

if (CCStableFailureByte>CCHighestFailureByte)      //  Find out the 
highest CCFailureByte ever seen

  {CCHighestFailureByte=CCStableFailureByte;}    //  Find out the 
highest CCFailureByte ever seen



PORTB=BDHighestFailureByte;          //  For debugging
_delay_ms(100);
PORTB=0x00;
_delay_ms(100);
PORTB=BDHighestFailureByte;
_delay_ms(100);
PORTB=0x00;
_delay_ms(100);
PORTB=BDHighestFailureByte;
_delay_ms(100);
PORTB=0x00;
_delay_ms(100);




  }  //############################ Endless loop end 
############################




}  //############################################# Main program end 
#############################################

Autor: Michal (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Natürlich, bitte, danke!

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du für's Debugging nur einen Wert ausgibst, den aber dreimal, woher 
kennst du dann die anderen Werte?

Erkennst du an irgendwas, dass das Programm neu gestartet wurde? Das ist 
nämlich auch ein Weg, den Wert zu verringern.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
& oder && ?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist zwar ein bischen verkehrt, aber nicht wirklich falsch und für das 
Problem nicht relevant.

Autor: Michal (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ja, andere Werte verfolge ich jetzt nicht, aber wie geschrieben, egal 
wie die anderen wären, können die besagten Variablen nicht erniedrigt 
werden.
Der Rest vom Programm ist übrigens funktional ok.

& oder &&, was soll ich nehmen für diesen if? Sollte auch für die Frage 
nicht relevant sein...

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michal schrieb:

> ja, andere Werte verfolge ich jetzt nicht, aber wie geschrieben, egal
> wie die anderen wären, können die besagten Variablen nicht erniedrigt
> werden.

Möglicherweise durch irgendwie ausgelösten aber nicht erkannten 
Neustart.

Sind Interrupts im Spiel?

> & oder &&, was soll ich nehmen für diesen if? Sollte auch für die Frage
> nicht relevant sein...

& | für Bitoperationen
&& || für logische Operationen wie hier.

Autor: Michal (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Neustart vom Programm, das geht durch Reset z.B. durch Unterspannung?
Kaum vorstellbar...

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oder durch Programmfehler wie beispielsweise einen eingeschalteten aber 
nicht definierten Interrupt, durch Stacküberlauf,...

Solltest irgendeine Erkennung dafür einbauen, um sicher zu gehen. 
Beispielsweise am Anfang kurz mit anderer Frequenz blinken oder so.

Autor: Der Micha (steinadler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kommentier doch einfach mal die Zuweisungen wie "CCHighestFailureByte = 
... " aus und schau, was die Werte austuen.

Kannst auch versuchen, Interrupts gezielt zu sperren, beim AVR geht das 
mit CLI.

Um was für einen Prozessortyp handelt es sich? 8Bit?
Welcher Compiler?

Autor: Michal (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich verwende keine Interrupts.

Möchte euch das lesen vom ganzen Programm ersparen, oder wollt ihr euch 
doch durchkämpfen?

Es ist ein Tester mehradrigen Kabel auf Open, Short und Verwechslung.

Ich programmiere einen ATmega8 mit einem AVRISP mkII vom AVRStudio mit 
AVR GCC Plug-In.

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michal schrieb:
> Neustart vom Programm, das geht durch Reset z.B. durch Unterspannung?
> Kaum vorstellbar...

Watchdog schon kontrolliert?

Gibt es irgendwelche Funktionen (außer main), die mit lokalen Variablen 
arbeiten, insbesondere Arrays?

Autor: Michal (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

da ich vor halbem Jahr angefangen habe, programmiere ich noch am 
einfachsten wie möglich.

Kein Watchdog, keine Interrupts, keine Pointer, nur elementares 
"Blinken".

Hier der ganze Code für interessierte...

Die Frage ist: gibt es irgendwo eine Operation die BDHighestFailureByte 
und
CCHighestFailureByte erniedrigen könnte?

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Omg,
das du bei solchem Source irgendwo ne Macke reinhaust ist fast schon 
vorprogrammiert. Rück als erstes mal alles vernünftig ein, benutz keine 
kilometerlangen Variablennamen sonderen kurze Selbsterklärende und 
schmeiss die sinnfreien Kommentare raus, dann findest du den Fehler 
bestimmt selber.
So wie du jetzt schreibst ist dein Quelltext schon bei so einem Witz 
Programm unlesbar...

Autor: X. H. (shadow0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lange Variablennamen können auch ganz gut selbsterklärend sein. Ich 
möchte mir aber manchmal Tipparbeit sparen und schreibe dann in den 
Kommentar, was ich mit einem kryptischen Kürzel meinte:

unsigned char bdhfb; //BDHighestFailureByte

alternativ könnte man das Kürzel später mit "Suchen und Ersetzen" wieder 
"lang machen".

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Gast: Stilfragen sind so eine Sache. Man neigt dazu,den eigenen Stil zu 
bevorzugen und findet fremde Programme oft schaurig.

So schlimm finde ich den übrigens nicht, schon garnicht die Variablen. 
Den Operatoren würden ein paar Blanks nicht schaden und der eine oder 
andere Kommentar wäre als Block statt endloser Wurst am Ende der Zeile 
besser, aber was soll's.

Spitzenklasse ist allerdings der Filename.

Autor: Michal (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Die selbsterklärenden langen Variablennamen erleichten dem Anfänger das 
Leben.
Um meine Tipparbeit kümmere ich mich selbst, meistens durch Copy und 
Paste...
Strukturiert ist das ganze übersichtlich in Funktionen.
Abstände bei Operatoren und Kommentare nicht in lange Zeilen ziehen: das 
lege ich mir ans Herz.

Also ausser Rüge habt ihr mich auf ein Gedanke gebracht.

Im gesanten Code gibt es nur eine einzige Zuweisung für diese Variable, 
die sie durch die eingebaute Bedingung nur erhöhen könnte:

if (BDStableFailureByte>BDHighestFailureByte)
{BDHighestFailureByte=BDStableFailureByte;}

Ein Reset gibt es ja nur am Anfang von main, bei den 
Variablen-Deklarationen:

BDHighestFailureByte=0x00

Das heisst, mein Programm MUSS von neu gestartet gewesen sein.

Aber wie kriege ich das raus? Meine Versorgungsspannung ist perfekt, die 
restliche Logik hat - bevor ich anfangen habe den BDHighestFailureByte 
zu überwachen - tadellos funktioniert, Interrupts und Watchdogs sind 
keine im Spiel.

Mal durchschlafen. Gute Nacht da drüben!

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michal schrieb:
> Hallo,
>
> Die selbsterklärenden langen Variablennamen erleichten dem Anfänger das
> Leben.

Man kann alles übertreiben

So was
if
((BDPreviousSingleFailureByte==BDSingleFailureByte)&(CCPreviousSingleFailureByte==CCSingleFailureByte))

ist einfach nur bescheuert. Du musst 10 Sekunden die Zeile anstarren um 
überhaupt erst mal die einzelnen Worte zu finden
  if( ( BD_PrevSingleFB == BD_SingleFB ) &&
      ( CC_PrevSingleFB == CC_SingleFB ) )

(was auch immer das BD und CC bedeuten mag.)

Zum Problem: Sind irgendwelche Arrays im Spiel?
Das Programm jetzt genauer zu analysieren tu ich mir nicht an. Nicht 
solange das eine wüste Buchstabensuppe ist

> Das heisst, mein Programm MUSS von neu gestartet gewesen sein.
>
> Aber wie kriege ich das raus?

Schalte am Anfang alle LEDS die du hast für 1 Sekunde ein und danch 
wieder aus. Das kriegst du auf jeden Fall mit, wenn zwischendurch alle 
LEDs immer wieder mal für 1 Sekunde angehen.

Autor: X. H. (shadow0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fällt mir ein: Kann es sich vielleicht um einen Variablen-Überlauf 
handeln?
unsigned char geht ja nur bis 255

So kann der Wert ja auch erniedrigt werden.

Autor: Bernd O. (bitshifter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich empfehle Dir, die Fehlerzähler zu kapseln - und zwar in eine 
Funktion, die eine obere Grenze sicherstellt, also quasi so:

void increment_limited(unsigned char *counter)
{
    if ((*counter) < 255) {
        (*counter)++;
    }
}

Im Code rufst Du dann statt:
  EqualFailuresCounter++;
dieses auf:
  increment_limited(&EqualFailuresCounter);

Gruß,
Bernd

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:

> ist einfach nur bescheuert. Du musst 10 Sekunden die Zeile anstarren um
> überhaupt erst mal die einzelnen Worte zu finden
>
>
>   if( ( BD_PrevSingleFB == BD_SingleFB ) &&
>       ( CC_PrevSingleFB == CC_SingleFB ) )
> 
>
> (was auch immer das BD und CC bedeuten mag.)

Gleiche gilt nun fuer FB - wenn das nicht mal eine bescheuerte 
Abkuerzung ist.

Autor: Noname (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Manchmal ist ein volatile für kleine Wunder gut.
Mit volatile wird die Optimierung des Compilers unterbunden und die 
Variable behält ihre Gültigkeit. Das es sich nur um lokale Variablen 
handelt versucht der Compiler diese registeroptimal zu nutzen.
Da kann es schon mal vorkommen, daß ein Register für mehrere Variablen 
genutzt wird.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noname schrieb:
> Manchmal ist ein volatile für kleine Wunder gut.
> Mit volatile wird die Optimierung des Compilers unterbunden und die
> Variable behält ihre Gültigkeit. Das es sich nur um lokale Variablen
> handelt versucht der Compiler diese registeroptimal zu nutzen.
> Da kann es schon mal vorkommen, daß ein Register für mehrere Variablen
> genutzt wird.

Du willst also sagen, dass es beim C Compiler normal ist, dass ab und zu 
mal lokale Variablen verloren gehen, weil ein Register "schon mal" von 
anderen Variablen belegt wird?

Was ist denn das für ein Unsinn ;)

Autor: Noname (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thematik ist
http://www.imb-jena.de/~gmueller/kurse/c_c++/c_volat.html
ganz hübsch beschrieben.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
gut, das hat aber nichts damit zu tun, daß ein und dasselbe Register
durch die Optimierung nacheinander für mehrere Variablen genutzt
werden kann. Vielmehr verhindert volatile, daß eine Variable
überhaupt in einem Register gepuffert wird zwecks
Beschleunigung.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich muß auch zugeben, daß diese Monstervariablen das Lesen 
erheblich erschweren und erst recht die Monsterzeilen.
Warum machst Du nicht wenigstens noch Leerzeichen, damit man die 
Operatoren erkennen kann?

Und Du machst nen Haufen völlig unnötiger Leerzeilen, die höchstens den 
Scrollfinger trainieren, aber überhaupt nichts lesbarer machen.

Du hast damit bestimmt hier gute Chancen:

http://www.ioccc.org/main.html


Ich hab mühsam rausgekriegt, daß es ein Leitungstester sein soll.

Ich hatte mal nen Tester für 8-poliges Patchkabel gemacht mit nem 8051.
Vielleicht kannst Du ja damit was anfangen:

#include <reg51.h>

#define uchar unsigned char

sbit  xLED_OK = P0^2;
sbit  xLED_ERROR = P0^1;
sbit  xLED_CROSSOVER = P0^0;

#define  LED_ON(x)  (~(x))    // low active: 0 = LED on


void test( void )
{
  uchar code TEST[] = { 0xF1, 0x92, 0xA4, 0x48 };
  uchar code CROSS[] = { 0xD6, 0xB0, 0x83, 0x48 };

  bit error = 0;
  bit crossover = 0;
  uchar i = sizeof(TEST);
  P1 = 0xFF;
  P2 = 0;
  if( P1 != 0xFF ){      // cable connected
    do{
      i--;
      P2 = TEST[i];

      if( crossover || P1 != TEST[i] ){
        if( P1 == CROSS[i] ){
          crossover = 1;
          continue;
        }
        error = 1;      // not or wrong connected
      }
    }while( i );

    xLED_CROSSOVER = LED_ON(  crossover );  // crossover

    xLED_OK        = LED_ON( ~error     );  // o.k.

    xLED_ERROR     = LED_ON(  error     );  // error
    return;
  }
  xLED_CROSSOVER = LED_ON( 1 );      // no cable
  xLED_OK        = LED_ON( 0 );
  xLED_ERROR     = LED_ON( 0 );
}


void main( void )
{
  for(;;){
    test();
  }
}


Peter

Autor: Neugieriger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie gut, dass es der Compiler noch lesen und zuordnen kann. Aber 
vielleicht hat er aus Rache dir einen kleinen Fehler eingebaut.

Autor: Bernd O. (bitshifter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus Wachtler schrieb:
> gut, das hat aber nichts damit zu tun, daß ein und dasselbe Register
> durch die Optimierung nacheinander für mehrere Variablen genutzt
> werden kann. Vielmehr verhindert volatile, daß eine Variable
> überhaupt in einem Register gepuffert wird zwecks
> Beschleunigung.
Das stimmt so nicht. Volatile hat nichts mit Registern zu tun, sondern 
bedeutet, dass der Compiler keinerlei Annahmen über die Variable machen 
darf. Der Compiler muß also davon ausgehen, dass sich die Variable 
jederzeit außerhalb seiner Kontrolle ändern könnte.
Je nach Architektur legt man beispielsweise Speicher von 
Memory-Mapped-HW gerne auf volatile Variablen.

Eine Codestückchen wie dieses:

hdlc_controller_txflag = 1; /* start transmission */

delay_us(100); /* after this time flag should be cleared hy HW */

if(hdlc_controller_txflag) {
    notify_error(TXFLAG_STUCK); /* controller hangs */
}

Läuft Gefahr, dass der Compiler (Optimzier) ohne volatile für 
hdlc_controller_txflag messerscharf schließt:
"Variable wird gesetzt, durch delay_us() mit Sicherheit nicht verändert 
- wozu im nächsten Befehl prüfen, ob die Variable immer noch gesetzt 
ist. Wer hätte sie auch löschen sollen?"

Nach dem Optimzier (ohne volatile) sieht der Code dann so aus:

hdlc_controller_txflag = 1; /* start transmission */

delay_us(100); /* after this time flag should be cleared */

notify_error(TXFLAG_STUCK);

Aus Compilersicht völlig legitim - woher soll der Compiler wissen, dass 
noch jemand anders (out of scope) auf dieser Variablen arbeitet.

Wenn eine volatile-Variable aber beispielsweise als call-by-value in 
einer Funktion landet, dann steht es dem Compiler frei, den Wert vor dem 
Funktionsaufruf in ein Register zu kopieren und zu übergeben (je nach 
ABI).


Gruß,
Bernd

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd O. schrieb:
> Klaus Wachtler schrieb:
>> gut, das hat aber nichts damit zu tun, daß ein und dasselbe Register
>> durch die Optimierung nacheinander für mehrere Variablen genutzt
>> werden kann. Vielmehr verhindert volatile, daß eine Variable
>> überhaupt in einem Register gepuffert wird zwecks
>> Beschleunigung.
> Das stimmt so nicht. Volatile hat nichts mit Registern zu tun, sondern
> bedeutet, dass der Compiler keinerlei Annahmen über die Variable machen
> darf. Der Compiler muß also davon ausgehen, dass sich die Variable
> jederzeit außerhalb seiner Kontrolle ändern könnte.

.. und der Compiler kann sie deshalb zwangsläufig nicht in
einem Register halten.

Du hast natürlich Recht, daß volatile erstmal nichts direkt mit
Registern zu tun hat.
Aber daß eine volatile-Variable nicht in einem Register landet,
ist eine zwangsläufige Folge.

Ich hatte ich insofern ungenau ausgedrückt, daß eine
volatile-Variable natürlich in ein Register kopiert werden kann
(für andere Zwecke).
Aber der nächste Zugriff auf die Variable wird wieder auf das
RAM zugreifen, und nicht auf die Kopie im Register.

(Letztlich wollte ich aber auf etwas anderes hinaus, nämlich daß
volatile nichts mit dem Umstand zu tun hat, daß gelegentlich
ein und dasselbe Register nacheinander für mehrere Variablen
verwendet werden kann.)

> ...
> Wenn eine volatile-Variable aber beispielsweise als call-by-value in
> einer Funktion landet, dann steht es dem Compiler frei, den Wert vor dem
> Funktionsaufruf in ein Register zu kopieren und zu übergeben (je nach
> ABI).

Natürlich, aber dann steht nicht die Variable im Register, sondern
eine Kopie davon, und die ist ja nicht volatile.
Die Variable selbst liegt wie sonst auch im RAM und wird bei ihrer
nächsten Verwendung von dort geholt und nicht aus der Kopie im
Register oder sonstwo.

>
>
> Gruß,
> Bernd

Autor: Michal (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

also da bin ich nochmal. Zurück zum Thema...

Im gesanten Code gibt es nur eine einzige Zuweisung für diese Variable,
die sie durch die eingebaute Bedingung NUR ERHÖHEN könnte 
(Maximum-Tracer):

if ( BDStableFailureByte > BDHighestFailureByte )
{ BDHighestFailureByte = BDStableFailureByte; }

Ein Reset gibt es ja nur am Anfang von main, bei den 
Variablen-Deklarationen:

unsigned char BDHighestFailureByte = 0x00;

Durch charakterisches Blinken am Anfang von main habe ich jetzt 
rausgekriegt, dass mein Programm NICHT immer wieder von neu gestartet 
wird. Trotzdem beobachte ich eine Erniedrigung des BDHighestFailureByte, 
sie geht mit BDStableFailureByte mit. Und immer weiss ich noch nicht 
warum...

Grüße

Michal

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie voll ist dein Speicher? Kann es sein, das bei Funktionaufrufen der 
Stack bis in deinen Variablenbereich wächst, und so Variablen 
überschrieben werden?

Gast

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du denn die ferhlerhaften & und | korrigiert?

Oliver

Autor: Michal (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

mein Speicher ist nur mit 8 % (Programm) und 0,2 % (Data) voll.
Die & und | habe alle auf && und || geändert.

Bin jetzt in der Arbeit, stelle dann das neue Code von zuhause rein.

Grüße

Michal

Autor: Stephan V. (orca)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das mit Codeformatierung und Variablennamen ist wie so vieles 
Geschmackssache, solange du nicht in einer SW Gruppe arbeitest, wo es 
extra Codingconventions gibt ist es im Prinzip dir überlassen wie du 
deinen Code Formatierst, solange DU damit gut zurecht kommst. Allerdings 
haben sich für verschiedene Sprachen unterschiedliche Stile eingebürgert 
(C, C++, Java, ...) und es kann nicht schaden, wenn man sich an die 
etwas anlehnt.

Etwas anderes ist es mit den Operatoren, ich meine hier die logischen 
und bitweisen Operatoren. Hier ist es wichtig, dass dir der unterschied 
von Anfang an  klar ist, und du sie gleich immer richtig verwendest. 
Sonst kommt es schnell zu Fehlern die man gerne tagelang sucht. (Auch 
wenn die Vergliche im aktuellen Bsp. auch bitweise funktionieren 
würden.)

Aber zurück zum eigentlichen Problem:

Wie testest du eigentlich welcher Wert in BDHighestFailureByte bzw. 
CCHighestFailureByte steht? Durch deine blinkenden LEDs an Port B?
Also wenn die nur 1/3 Sekunde lang blinken und dann wieder einen neuen 
Wert anzeigen, würd ich mir nicht zutrauen diesen Wert sicher erkennen 
zu können. Außerdem schaltest du in Zeile 162
  PORTB=BDSingleFailureByte;  //  Red LEDs at the failure bits outputs
einen Fehlerstatus(?) auf's Port B.
Der blinkt dir da auch noch zusätzlich rein.
Erhöh die Anzeigedauer mal auf 1 Sek. damit man die Werte gut erkennt 
und von den Statusanzeigen unterscheiden kann.

Ich hab mal versucht dein Programm durch den Simulator zu jagen.

1) Der Compiler optimiert echt gut :-) (mit den std.Einstellungen von 
AVR Studio)
Der Disassembler zeigt: Nachdem CCHighestFailureByte nirgends mehr 
verwendet (gelesen) wird, wird es einfach weg optimiert. Genau das soll 
ein gut optimierender Compiler auch machen! Was mich zurück zu der Frage 
von oben bringt, wie debuggst du CCHighestFailureByte und 
BDHighestFailureByte?


2) Probier mal das ganze unoptimiert zu testen: Compilerswitch –O0 statt 
–Os
(unter AVR Studio: Menu -> Project -> Configuration Options -> 
Optimization)

Dann passt das Programm allerdings nicht mehr in den Flash. Also hab ich 
die Beepfunktionen auskommentiert, da die IMHO nichts zum eigentlichen 
Kabeltest beitragen – nicht, dass sie nicht trotzdem für den Bug 
verantwortlich sein könnten, aber das kann man dann in einem weiteren 
Schritt abklären.

also die Funktionen: BeepForFail, BeepForPass und BeepForPassOrFail 
auskommentieren
und auch die Zeilen:
  if ((BDStableFailureByte<BDHighestFailureByte)|(CCStableFailureByte<CCHighestFailureByte))
        BeepForPassOrFail ();
Jetzt sollte das Programm wieder richtig compilieren und in den Speicher 
passen.

Tritt der Fehler jetzt immer noch auf, liegt es an der HW, oder der 
Testlogik, oder wir sind alle zu doof einen Alg.Bug in einer 
Maximumsfunktion zu finden ;-)

Hast du jetzt keinen Fehler mehr, ist die HW zu 99.9% OK und die 
prinzipielle Programmlogik ist damit auch verifiziert (nicht nur die 
Maximumsfunktion).


Hoffe, dass hilft dir etwas weiter.

by(e)
Stephan

Autor: Michal (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Stephan,

danke, ich bin sprachlos dass sich jemand die Zeit genommen hat und mein 
elendige Code noch mit dem Simulator getestet hat.

Dadurch hast, nehme ich an, verstanden wie mein Kabeltester genau 
gedacht ist, aus welchen Ports (und Teil-Ports) ich die Testpattern 
schicke und an welchen ich sie empfange.

Ich werde mich mit Deinen wertwolle Tipps, u.a. zum Kompilator (-0s, 
-00) genauer auseinandersetzen.

Was ich nicht verstehe, auch bei -0s sollte der BDHighestFailureByte 
nicht wegoptimiert werden, weil er ja hier für die Entscheidung über die 
Klang-Signalisierung VERWENDET wird:

if 
((BDStableFailureByte<BDHighestFailureByte)|(CCStableFailureByte<CCHighe 
stFailureByte))
        BeepForPassOrFail ();

Es geht darum, dass **HighestFailureByte einem herausgezogenem Stecker 
entspricht und das Ding bei jedem Kabel-Wechsel nicht ärgerlich piepsen 
sollte.

Will Benützer z.B. einen 6-Adrigen Kabel testen, soll er die restlichen 
4 Testports fix verbinden. Das Programm wird dann nach einem Ein- und 
Ausstecken durch diesen Maximum-Tracer "**HighestFailureByte" lernen, 
welcher Fehler einem herausrausgezogenen Stecker entspricht und dabei 
nicht mehr piepsen (nur rote LEDs zeigen).

Das gefragte Blinken habe ich erst jetzt für Debugging eingeführt weil 
mir diese Logik mit dem herausgezogenem Kabel eben nicht funktionieren 
wollte.

Ich lege die vorherige Version bei, die TADELLOS FUNKTIONIERT, aber die 
herausgezogenen Stecker noch nicht erkennt hat, zum Vergleich bei.

Vielen Dank nocheinmal

Michal

Autor: Stephan V. (orca)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich kann natürlich nicht sehen, wie gut das mit dem Blinken 
funktioniert, aber du solltest dir wirklich sicher sein, dass du genau 
weißt wann was angezeigt wird und wie es dann zu interpretieren ist. Und 
gerade wenn du Bitmuster vergleichen willst, würd ich sie mind. 3-5 Sek. 
stehen lassen, um sie zur Not auch mal abschreiben zu können.

Naja, also ehrlich gesagt, hab ich die eigentliche Testfunktion nur grob 
überflogen.
Ich hab's mir jetzt noch mal angeschaut, dabei sind mir folgende Sachen 
aufgefallen, die aber alle nix mit deinem Maximum-Problem zu tun haben.

I/O setzen:
------------
In der Funktion TestPattern() läufst du offensichtlich alle Adern eines 
10-poligen Kabels durch. Dabei verwendest du Port C sowohl als Eingang 
als auch als Ausgang. Das ist vollkommen in Ordnung, nur wenn du ein 
Port gemischt verwendest (sei es auch nur indirekt z.B. über UART, SPI, 
etc.) musst du beim setzen der Bits etwas aufpassen.
PORTC=0x00&CSentUsedBitsMask;

1. 0 & irgendwas  ist immer = 0
Also kannst du gleich schreiben: PORTC = 0x00;

2. Ich glaube aber, was du eigentlich machen wolltest ist: "setze alle 
Bits in CSentUsedBitsMask auf 0" das funktioniert etwas anders. Du musst 
nämlich aufpassen, dass du nur die Output-Bits setzt, und die Input-Bits 
nicht veränderst, sonst löscht du dir event. gesetzte Pull-ups (was du 
mit deinem Code gemacht hast).
Da du nicht direkt auf einzelne Bits eines Ports zugreifen kannst, musst 
du das zwischenbuffern.
tmp = PORTC;
tmp &= ^CSentUsedBitsMask;  // alle Bits in der Maske löschen, die anderen bleiben unberührt
tmp |= data & CSentUsedBitsMask; // Datenbits ausmaskieren und entsprechend setzen
PORTC = tmp;

Dieses Konstrukt musst du auch weiter unten verwenden, bei:
CSentByte=0x01&CSentUsedBitsMask;
PORTC=CSentByte;

In LEDsFailureSignalisation() hast du wieder das gesamte Port C gesetzt. 
Das mag zwar für dein Programm funktionieren, kann aber die Ursache 
einer nie enden wollenden Debug-Orgie werden. Also gewöhn die ab besten 
gleich an: nur die Bits angreifen, die du auch wirklich ändern willst.
PORTC |= (1<<PC5);    // Green LED on 
statt
PORTC = 0x20; // At no failure green LED is lightning from the 00100000 from the port C

In Zeile 161 machst du das richtig:
PORTC &= ~(1<<PC5);    // Green LED off
Aber gleich drauf, setzt du wieder das gesamte PORT.
PORTC = CCSingleFailureByte;  //  Red LEDs at the failure bits 
outputs

Fällt im konkreten Fall nicht auf, da die grüne LED sowieso auf 0 ist. 
Wäre die, grüne LED jetzt aber low-active, würdest du dich wundern, 
warum du einen Fehler hast, und trotzdem grün leuchtet.


Debuggen
-------------
Zum Debuggen, gennerell: Wenn es sich mit deiner HW irgendwie machen 
lässt, führ die UART Schnittstelle raus und verwende irgendeinen UART 
<-> USB Adapter (z.B. FTDI & Co) um Debugmeldungen an den PC zu senden.
Ich wollte mich früher auch immer davor drücken, weil du wieder mehr 
Leitungen hast, dann brauchst wieder eine UART Lib (aber die gibt's ja 
schon fertig), usw. Aber im Endeffekt ist dann doch bei jedem Projekt 
ein UART Stecker drauf gelandet. Es lässt sich damit einfach viel besser 
debuggen als mit LED Morsecode, und ab einer gewissen Komplexität bleibt 
dir sowieso nix anderes mehr übrig.


Abgestecktes Kabel
------------------------
Ok, jetzt hab ich endlich verstanden, was du mit BDHighestFailureByte 
eigentlich bezwecken willst :-)

Ich glaub da ist die Logik etwas suboptimal. Wenn ich dein Programm 
richtig durchschaut habe, brauchst du mal 30 Testzyklen ohne Kabel nur 
mit den Leerbrücken um den Kabeltyp zu lernen. Und wenn du Kabeln 
wechselst, kannst du nur zu mehrpoligen wechseln, und nicht zu weniger 
poligen.

Was hältst du von folgendem Vorschlag. (Der spart dir sogar die 
Drahtbrücken brauchst allerdings einen Resettaster oder Ein/Ausschalter, 
aber der sollte ja eh irgendwo vorhanden sein.)

1.  Beim Einschalten ist ein geprüftes Masterkabel des jeweiligen Typs 
angeschlossen. Das wird als Sollmuster gelernt.
2.  Danach wird der Lernvorgang durch ein Piepsen oder Blinken 
quittiert.
3.  Jetzt kannst du Kabeln dieses Typs ganz normal testen
4.  Soll ein anderer Typ getestet werden: Masterkabel d'ran, Reset bzw. 
Ein-Aus; goto 1

Umsetzung:
1.  Pullups wieder einschalten
2.  Vor der Hauptschleife das aktuelle Muster lernen. Eine Maske 
erstellen, die gleich dem invertierten Muster ist.
3.  in der Hauptschleife alle Fehler mit der Maske ausmaskieren.

Autor: Stephan V. (orca)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ups, das mit dem Optimieren hab ich jezt ganz vergessen.

Du hast natürlich recht, ich hab bei mir alle Beep-Funktionen 
ausgeklammert, daher war auch dir Abfrage nicht drinnen und somit wurde 
BDHighestFailureByte
weg optimiert.

Wenn ich's mit deiner Originalversion durch den Dissassambler schicke, 
bleicht BDHighestFailureByte auch als Register erhalten.

by(e)
Stephan

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.