hans schrieb:> Sobald die while schleife augerufen wird ändenr sich die werte des> pu8Data Feldes auf unerklärliche Weise. Hat jemand eien Idee hierzu?
Du machst ja permanent was mit dem pu8Data - warum wundert es dich, dass
sich das Array ändert. Die switch wird ja mit jedem Durchlauf des
Main-Programms bearbeitet.
Kannst du deinen Code nicht erst mal ein wenig bereinigen?
Diese Copy&Paste Programmierung ist doch unüberschaubar!
ZB
vereinfacht sich das hier
1
case'D':
2
{
3
switch(u8Cursor)
4
{
5
case0:
6
{
7
pu8Data[0]=pu8Data[0]-0x10;
8
LCD_Goto(0,0);
9
sprintf(&cMACbyte,"%02x",pu8Data[0]);
10
LCD_PutS(&cMACbyte);
11
LCD_Goto(0,u8Cursor);
12
break;
13
}
14
case1:
15
{
16
pu8Data[0]=pu8Data[0]-0x01;
17
LCD_Goto(0,0);
18
sprintf(&cMACbyte,"%02x",pu8Data[0]);
19
LCD_PutS(&cMACbyte);
20
LCD_Goto(0,u8Cursor);
21
break;
22
}
23
case2:
24
{
25
pu8Data[1]=pu8Data[1]-0x10;
26
LCD_Goto(0,2);
27
sprintf(&cMACbyte,"%02x",pu8Data[1]);
28
LCD_PutS(&cMACbyte);
29
LCD_Goto(0,u8Cursor);
30
break;
31
}
32
case3:
33
{
34
pu8Data[1]=pu8Data[1]-0x01;
35
LCD_Goto(0,2);
36
sprintf(&cMACbyte,"%02x",pu8Data[1]);
37
LCD_PutS(&cMACbyte);
38
LCD_Goto(0,u8Cursor);
39
break;
40
}
zu dem hier
1
case'D':
2
{
3
if(u8Cursor%2==0)
4
offset=0x10;
5
else
6
offset=0x01;
7
8
index=u8Cursor/2;
9
10
pu8Data[index]=pu8Data[index]-offset;
11
LCD_Goto(0,0);
12
sprintf(cMACbyte,"%02x",pu8Data[index]);
13
LCD_PutS(cMACbyte);
14
LCD_Goto(0,u8Cursor);
15
}
Ich hab jetzt nur die Fälle bis 3 durchgesehen, die restlichen hab ich
nicht weiter genauer untersucht, aber beim schnellen hinschauen sind
auch sie alle mit den paar Zeilen Code abgedeckt und wenn nicht müsste
man sich ein kleines Array machen, welches zum Umsetzen des u8Cursor in
die richtige Indexnummer benutzt wird.
Auf jeden Fall: Deine 25-tausend Seiten Code kann man auf ein paar
wenige Zeilen eindampfen. Und dann verliert man auch nicht so schnell
die Übersicht.
Dann das Programm auf Stackoverflow abprüfen. Dein Code ruft viele
"fette" Unterfunktionen auf, die den Stack in den Keller treiben können,
d.h. in die Nähe von DATA und BSS Variablen.
Ein Hinweis ist die Anzeige des statischen SRAM-Bedarfs nach dem
Kompilieren. Wenn das in Richtung 75% des vorhandenen SRAM geht, sollte
eine Alarmglocke läuten.
Du könntest z.B. eine Kanarienvogel-Variable hinter deinen regulären
Variablen platzieren, diese zyklisch prüfen und Alarm geben, wenn deren
Inhalt verändert wird.
ADD: Geh dem Hinweis von Karl Heinz zuerst nach. Sieht
vielversprechender aus!
@karl heiz danke für den tipp mit dem verkleinern des codes.
die variabel ist so deklariert: char cMACbyte;
irgendwie ändert sich pu8Data schon bei wenn ich die anderen fälle
rauslasse.
hans schrieb:> @karl heiz danke für den tipp mit dem verkleinern des codes.>> die variabel ist so deklariert: char cMACbyte;
Dachte ich mirs doch.
Und wie stellst du dir vor, dass zb ein String mit 3 Zeichen in so eine
einsame klitzekleine char Variable mit gerade mal 8 Bit passt?
Zum Speichern von Strings benötigt man Arrays!
http://www.mikrocontroller.net/articles/FAQ#Wie_funktioniert_String-Verarbeitung_in_C.3F> irgendwie ändert sich pu8Data schon bei wenn ich die anderen> fälle rauslasse.
Wer weiß, wo du sonst noch überall Arrays überläufst.
hans schrieb:> ok aber was ändert das daran das sich pu8Data ändert?
Du jubelst dem System eine einsame char Variabel als Array unter.
zb versucht sprintf dort 3 oder mehr Zeichen abzulegen. Die Variable hat
aber nicht den Platz dafür. sprintf schreibt aber trotzdem. Es schreibt
dann einfach beginnend mit der Startadresse die du angegeben hast im
Speicher weiter. Und was immer dort im Speicher war .... wird
überschrieben. Ohne Rücksicht auf Verluste.
Sei froh dass du jetzt drauf gekommen bist. Das hätte alles auch noch
viel schlimmer ausgehen können, wenn du den Stack niedergebügelt
hättest.
http://www.mikrocontroller.net/articles/FAQ#Wie_funktioniert_String-Verarbeitung_in_C.3F
hans schrieb:> ja cool jetzt hab ich verstanden danke für die schnelle kompetente> hilfe!
Das muss allerdings nicht das einzige Problem gewesen sein.
Daher ist es meistens nicht sehr schlau wenn man Code schreibt, und Code
schreibt und Code schreibt ... und nie zwischendurch mal testet.
Denn dann steht man am Ende mit einem Haufen Code da der nicht
funktioniert. Und das ist so sicher wie das Amen im Gebet.
Wie gross ist cMAC?
Nur damit das klar ist:
Es ist dein Bier dafür zu sorgen, dass die Arrays groß genug sind. Da
gibt es kein Netz und keinen doppelten Boden, der dich hier schützt.
ja eigentlich hab ich es zwischendurch getestet und hatte schon so
komische phänomene aber als anfänger kommt man schwer darauf das
irgendwo speicher überschrieben wird.
hans schrieb:> cMAC ist jetzt 16 byte groß das war das problem vorher hatte ich es auf> 6 byte
OK.
Lektion:
Solche Arrays definiert man nie zu knapp und niemals auf Knirsch!
Hier gilt die Devise: Nicht kleckern, klotzen!
Mach es 80 Byte groß
Karl heinz Buchegger schrieb:> hans schrieb:>> cMAC ist jetzt 16 byte groß das war das problem vorher hatte ich es auf>> 6 byte>> OK.> Lektion:> Solche Arrays definiert man nie zu knapp und niemals auf Knirsch!>> Hier gilt die Devise: Nicht kleckern, klotzen!>> Mach es 80 Byte groß
ps: 16 ist schon wieder zu klein
%02x%02x.%02x.%02x.%02x.%02x
braucht 17 Bytes. Du hast auf das abschliessende \0 Byte vergessen.
Aber wie gesagt: Ordentlich überdimensionieren, damit dir bei der
nächsten Formatänderung nicht schon wieder alles um die Ohren fliegt.
Der nächste macht daraus:
weil ihm das besser gefällt, und schon sind deine 17 Bytes schon wieder
zu klein.
Und nein: Man braucht nicht für jeden String ein neues Array. SO wie du
das hast, kannst du alle sprintf über denselben Buffer (dasselbe char
Array) abwickeln. Und das dann dafür reichlich groß dimensionieren.
Und auch mal über den Einsatz von snprintf nachdenken.
Thread beobachten
Seitenaufteilung abschalten