UART Schleife MC stürzt ab

Hallo,

habe den Vergleich mal an anfang des Programm gesetzt:
Wenn ich die Berechnung ausklammere und über Uart die 250 sende, friert 
das Display ein. Bei 254, geht er aus der Schleife raus und arbeitet 
normal weiter. Sobald die Rechnung in der for Schleife ist startet er 
einfach neu. Was mach ich falsch?
command ist als unsigned char array deklariert

1

   if (command[0] == 250){

2

    int i;

3

    uint16_t ChecksummeBerechnet;

4

    uint16_t ChecksummePC;

5

    for(i = 0; i < 10 ; i++){

6

7

//addierwert = command[i];

8

ChecksummeBerechnet = ChecksummeBerechnet +                    command[i]          

9

}

10

i = 0;

11

12

13

ChecksummePC = make_u16(command[10],command[11]);  // Checksumme zusammensetzen

14

15

  if (ChecksummePC == ChecksummeBerechnet){

16

       uart_putc(249);

17

       uart_putc('W');

18

       uart_putc('W');

19

    }

20

    else {

21

     uart_putc(249);

22

       uart_putc('S');

23

       uart_putc('S');

24

    }

25

  command[0] = 0;

26

  ChecksummeBerechnet = 0;

27

  }

Philipp P. schrieb:
> i = 0;

für was ist das gut?
checksum wird nicht initialisiert und
das Programm stürzt in make_u16 ab

Walter schrieb:
> checksum wird nicht initialisiert und
> das Programm stürzt in make_u16 ab

jede Variable hat irgendeinen wert. Egal ob initialisiert oder nicht. 
Wenn es nicht gerade ein Zeiger ist, ist das wohl kein Grund für ein 
Absturz.

Vieleicht ist ja einfach nur das RAM voll.

Hallo,

danke schonmal für die Antworten, im Anhang das derzeitige Programm.
Ich hab versucht das wichtigste zu kommentieren.
Manche kleine Fehler sehe ich noch nicht direkt.

MfG Philipp P.

Hallo,

messwerte[20] hab ich auf 21 geändert ;)
Das andere Array ist buffer[10] -> hat bis jetzt immer funktioniert.
Und das mit command[ci+1] = '\0'; wird auch entfernt weil ich es nicht 
brauche. Die command[21] werden auch nicht voll weil ich maximal 13Bytes 
hintereinander sende.

MfG Philipp

Ok stimmt sry, buffer[10] ist ein wenig zu klein für 14 Zeichen am Lcd.
Das habe ich jetzt auch vergrößert. Er hängt sich trozdem auf oder 
startet neu -.-


MfG Philipp

Peter II schrieb:
> jede Variable hat irgendeinen wert. Egal ob initialisiert oder nicht.
> Wenn es nicht gerade ein Zeiger ist, ist das wohl kein Grund für ein
> Absturz.

habe ich nicht behauptet, aber es ist ein Fehler der sich noch bemerkbar 
machen wird

Hallo,

@ Walter ja, den Fehler in der for Schleife habe ich entfernt


Hab jetzt die ganze Vergleichsroutine nochmal raus genommen bis auf:
Nach der Eingabe von 250 friert das Display ein. Dann nach 254 wirds 
dunkel und er verabschiedet sich.... Mit debuggen habe ich mich noch 
nicht auseinander gesetzt.

1

   ci = 0;

2

   c = uart_getc();

3

4

   if( c != UART_NO_DATA  && c == 250){          //Startbedingung für alle Eingehenden Daten, wenn 250 gesendet wird und Daten vorhanden

5

6

7

  while( c != 254 ){                                // Lese solange, bis von der anderen Seite 254 als Endbedingung kommt!

8

9

         if( c != UART_NO_DATA ) {

10

             command[ci++] = c;

11

             c = uart_getc();

12

    uart_putc(c);    // überprüfen am terminal

13

         }

14

15

        }

16

17

    command[ci+1] = '\0';

18

    }

Joe F. schrieb:
> Überlege mal, was passiert wenn c == UART_NO_DATA ist.
> Dann läuft die while Schleife ewig.

fast, wenn c == UART_NO_DATA kommt er gar nicht ins if rein,
er kommt nur rein wenn c == 250 und dann hängt er sich in der Schleife 
auf

Walter schrieb:
> fast, wenn c == UART_NO_DATA kommt er gar nicht ins if rein,
> er kommt nur rein wenn c == 250 und dann hängt er sich in der Schleife
> auf

Ja genau das soll er doch machen, bis mit dem Befehlsbyte mit Wert 254 
die Schleife verlassen wird. Sobald die Schleife verlassen wird macht 
der MC was er will.

Joe F. schrieb:
> In der while Schleife wird 254 allerdings nicht mehr empfangen,
> wenn c
> voher mal UART_NO_DATA wurde...
>
> Du wolltest vermutlich eher sowas machen:  while( c != 254 )
>   {
>     c = uart_getc();
>     if( c != UART_NO_DATA )
>     {
>       command[ci++] = c;
>       uart_putc(c);    // überprüfen am terminal
>     }
>   }

So habe ich gerade versucht, allerdings gibt er wieder den Geist auf 
wenn ich 254 sende.
Baue ich aber delays ein, läuft alles so wie es soll.

1

if( c != UART_NO_DATA  && c == 250){          //Startbedingung für alle Eingehenden Daten, 

2

//wenn 250 gesendet wird und Daten vorhanden

3

4

5

while( c != 254 ){

6

//Lese solange, bis von der anderen Seite 

7

//254 als Endbedingung kommt!

8

9

if(c != UART_NO_DATA) {

10

command[ci++] = c;

11

  _delay_ms(5);

12

c = uart_getc();

13

  _delay_ms(5);

14

uart_putc(c);

15

  _delay_ms(5);  // überprüfen am terminal

16

  }

17

}

18

command[ci+1] = '\0';

19

}

Sry, wollte dich nicht verärgern und das soll auch keine Lösung sein!
Ich habs nochmal umgeschrieben ein, zweimal funktioniert es und dann 
hängt er sich wieder auf beim Schleifen austritt -.-

hier die includefile

Danke nochmal für die Hilfestellung:) Ja, das mit dem Stromimpuls dacht 
ich mir auch schon, aber das einzige was am MC angeschlossen ist, sind 3 
I2C Chips das Display und der UART.
Dann werde ich mir die Tage mal einen AVR Dragon bestellen...

MfG Philipp P.

Kann es sein das UART_NO_DATA zu spät, oder nicht dirkt den Wert zurück 
gibt ob neue Daten vorhanden sind? So bleibt er in der while Schleife 
und erfüllt die if Bedingung und treibt ci in die Höhe und läuft dann 
über?

1

ci = 0;

2

c = uart_getc();

3

if( c != UART_NO_DATA  && c == 250){          //Startbedingung für alle Eingehenden Daten, 

4

//wenn 250 gesendet wird und Daten vorhanden

5

6

7

while( c != 254 ){

8

// Lese solange, bis von der anderen 

9

//Seite 254 als Endbedingung kommt!

10

c = uart_getc();

11

if(c != UART_NO_DATA && ci < 21) {

12

command[ci++] = c;

13

uart_putc(c); // überprüfen am terminal

14

15

         }

16

17

        }

18

19

    command[ci] = '\0';

20

    }

So geht er in die Schleife und wieder raus, sendet aber nichts über 
Uart.

command[21] = '\0';

schreddert dir irgendwas.

So habe vorhind mir ci mal ausgeben lassen NACHDEM die Schleife 
verlassen wurde. Er zählt ci kontinuirlich hoch, mit delays langsamer. 
Mit ci<21 verhindere ich, das er in der if abfrage weiter hoch zählt und 
sich dann aufhängt.

Nun frage ich nur UART_NO_DATA ab und die bleibt immer 0. Die Abfrage 
schaltet mir eine LED an und aus die am PCF hängt. Normal müsste die LED 
doch angehen wenn uart_getc keine neuen Daten bekommt?

Danke fürs formatieren ;)

Oh ja, vergrößer ich. Wenn ich die Abfrage mit (!( c & UART_NO_DATA)) 
negiere, leuchtet die LED... Hab mir gerade nochmal die aktuelle Lib 
runtergelden, alte gelöscht und neue rein gemacht. Muss ich in der Lib 
noch etwas eintragen?

Joe F. schrieb:
> Ja, gerne. Du bist allerdings auch echt krass.

Nicht nur krass, der Herr fährt auch zweispurig, ohne es das jeweils 
andere Forum wissen zu lassen:
http://www.roboternetz.de/community/threads/66539-Uart-while-schleife-führt-zu-absturz
Ist einfach mieser Stil, mehrere Foren zu beschäftigen, anstatt die 
Birne anzustrengen und bei einem zu bleiben.

Tatsache so funktionierts und UART_NO_DATA schaltet um und ci zählt 
immer um 1 pro empfangenem Byte hoch. Ganz großes Kino^^
Vielen Vielen Dank

Ich meine iwo im Forum gelesen zu haben das c ein unsigned char sein 
muss,
da sonst uart_getc() nicht richtig funktioniert..

1

if (!(c & UART_NO_DATA)) {          //Startbedingung für alle Eingehenden Daten, 

2

wenn 250 gesendet wird und Daten vorhanden

3

4

while( c != 254 ) {

5

// Lese solange, bis von der anderen 

6

Seite 254 als Endbedingung kommt!

7

c = uart_getc();

8

9

if(!(c & UART_NO_DATA )) {

10

command[ci++] = c;

11

uart_putc(c);

12

uart_putc(ci);

13

pcf_set(0);

14

}

15

else{

16

pcf_clear(0);

17

18

}

19

command[ci] = '\0';

20

}

21

}

Philipp P. schrieb:
> Ich meine iwo im Forum gelesen zu haben das c ein unsigned char sein
> muss,
> da sonst uart_getc() nicht richtig funktioniert..

Bei Peter Fleurys UART-Lib ist doch extra ein Codebeispiel dabei, das 
die korrekte Verwendung zeigt.
Und mit ein bisschen Verständnis für die Lib (und das Verständnis 
sollte man sich aneignen), ist das auch klar, dass das ein uint16 sein 
muss

MWS schrieb:
> Joe F. schrieb:
>> Ja, gerne. Du bist allerdings auch echt krass.
>
> Nicht nur krass, der Herr fährt auch zweispurig, ohne es das jeweils
> andere Forum wissen zu lassen:
> http://www.roboternetz.de/community/threads/66539-...
> Ist einfach mieser Stil, mehrere Foren zu beschäftigen, anstatt die
> Birne anzustrengen und bei einem zu bleiben.

Ja, ich habe vorhind noch in einem anderem Forum gefragt und werde dort 
auch gerne berichten das mir hier sehr gut geholfen wurde.
Und ja ich habe meine Birne angestrengt nur wenn ich nicht weiter weiß 
und den Fehler nicht finde wende ich mich an ein Forum.
Ich denke es ist jedem selbst überlassen zu helfen und wenn meine sich 
meine Programmierkünste verbessert haben bin ich auch bereit anderen zu 
helfen...

C ist Neuland für mich. Trotz fast täglichem lesen und einarbeiten macht 
man da halt Fehler und ist für jede Hilfe Dankbar....

MfG Philipp

Joe F. schrieb:
> Kann er ja machen, ich habe auch mehrere Rechtsanwälte ;-)

Die bezahlst Du auch (sinnvollerweise), freiwillige Helfer werden nicht 
bezahlt, deren Lohn ist bestenfalls ein gewisses Erfolgserlebnis. Das 
nimmt denen aber derjenige, der ohne es allen mitzuteilen, gleich 
mehrere Foren beschäftigt.

> @Philipp P.
> Trauriger finde ich, dass bei dir eine ziemlich ausgeprägte
> Lernverweigerung zu erkennen ist.
> Code formatieren heisst jetzt "ich schiebe einfach alles ganz nach
> links", und ci auf Array-Größe testen fliegt wieder raus. Geht ja
> jetzt...

Das konnte ich schon oft beobachten: diejenigen, die gleich einen ganzen 
Schwung Foren beschäftigten, also versuchten rücksichtslos eigenes Hirn 
durch copy/paste zu ersetzen, zeigten sich meist auch in jeglicher 
anderer Hinsicht rücksichtslos und verständnisbefreit.

Philipp P. schrieb:
> und den Fehler nicht finde wende ich mich an ein Forum.

Du hast Dich nicht an ein, sondern mehrere gewandt.

> Ich denke es ist jedem selbst überlassen zu helfen und wenn meine sich
> meine Programmierkünste verbessert haben bin ich auch bereit anderen zu
> helfen...

Das wäre richtig, wenn Du die Fairness besessen hättest, es dem jeweilig 
anderen Forum zu sagen. Denn dann kann jeder überlegen, ob er Dir helfen 
will, oder lieber wartet, ob woanders bereis ein Ergebnis rauskommt.

Joe F. schrieb:


> @Philipp P.
> Trauriger finde ich, dass bei dir eine ziemlich ausgeprägte
> Lernverweigerung zu erkennen ist.
> Code formatieren heisst jetzt "ich schiebe einfach alles ganz nach
> links", und ci auf Array-Größe testen fliegt wieder raus. Geht ja
> jetzt...

Um die formatierung kümmere ich mich morgen noch ;)
ci wird jetzt hoffentlich richtig abgefragt.

Karl Heinz schrieb:
> formulierst du besser so
>      while( c != 254 && ci < sizeof( command ) > - 1 ) {

Ich würde auch die magische 254 da weghaben wollen und stattdessen ein 
Makro verwenden:

1

#define START  250

2

#define ENDE   254

3

//...

1

    while( c != ENDE && ci < sizeof( command ) > - 1 ) {

Markus F. schrieb:
> ???
>
> Jetzt hast Du's verhunzt.

lol... Ich hatte zuerst den Originaltext zitiert und dann angepasst. 
Dabei gab's einen Zeilenumbruch. Das reine Zitat sah so aus:

Karl Heinz schrieb:
> formulierst du besser so      while( c != 254 && ci < sizeof( command )
> - 1 ) {

Das '>' ist versehentlich drin geblieben.

Joe F. schrieb:
> Man müsste zusätzlich aber auch noch dafür sorgen, dass in "c" zum
> passenden Zeitpunkt etwas anderes drin steht als 254...

Was meinst du damit? Die 254 kann ruhig in dem Array stehen bleiben.
Ich habe meine wirren Code stellen mal durch einen source code formatter 
geschickt, ich hoffe jetzt siehts besser aus.

Karl Heinz schrieb:

> Deine ganze Abfragerei der erhaltenen Werte lässt sich auch so
> zusammenfassen
>    if( c >= 0x32 && c <= 0x39 )
>      pcf_set( c - 0x32 );
>
>    if( c >= 0x40 && c <= 0x47 )
>      pcf_clear( c - 0x40 );

Das is der Knaller da wär ich nie drauf gekommen das es so einfach zu 
formulieren ist ;)

Danke für die Hilfestellungen und Tipps.

MfG

Joe F. schrieb:
> Überlege einfach mal, welchen Inhalt die Variable "c" nach dem
> Verlassen
> der while Schleife hat...

Wenn er die Schleife durch 254 verlässt steht in c die 254 solange bis 
er wieder die uart_getc() aufruft. Jedenfalls gibt er mir so c nach der 
Schleife aus.

MfG Philipp

Joe F. schrieb:
> So ist es. Findste gut so?

Wo drauf möchtest du hinaus? Bis zum nächsten Aufruf kann das c doch 
ruhig 254 bleiben? In dem command Array sollte es nicht stören oder wird 
c vorher nochmal abgefragt? Ich könnte es nach der Schleife 0 setzen?

Achso das stimmt. Gar nicht mehr gesehen..^^ Das werde ich sowieso noch 
anpassen müssen.


MfG Philipp P.