Serieller Ausgabesalat

André Xxx schrieb:

> Dies tritt nicht auf wenn ich das damals erstellte Hex-File verwende, am
> Quellcode wurde nichts verändert.

Das sagen sie alle.
Und trotzdem stellt sich dann immer wieder heraus, dass am Quellcode 
doch irgendetwas gemacht wurde. Vor Monaten, nur zu Testzwecken, was 
dann nicht am Controller gelandet ist und Murks war. Aber nie rückgängig 
gemacht wurde. Und so kommt es, dass dieser Murks dann Monate später in 
einem Programm wieder auftaucht, in dem 'nie irgendetwas verändert 
wurde' :-)

Taktrate (Quarz+Fuses)?

Bin zwar nen Bastler aber den Quellcode hab ich auf Cd gesichert, sollte 
sich nichts verändert haben. Ich überprüfe aber nochmals die 
Projekteinstellungen.

Durch aufspielen des alten Hex-Files ändert sich nichts an den Fuses, 
das das alte geht und das neu erstellte nicht, also würde ich die Fuses 
ausschließen.

Werde mal den Quarz durch messen, mal sehen was das Oszillo sagt.

Mit der Bautrate habe ich auch schon gespielt leider ohne Erfolg. bin 
runter bis auf 9600. Normal läuft es ohne nennenswerte Fehler mit 
115200.

Danke schonmal für die Anregungen, da geht nichts vergessen.

Bei der Gelegenheit kann man vielleicht gleich mit dem Oszi mal das
RS232-Signal anschauen und die tatsächliche Baudrate ausrechnen.

Ist/war die Controller Taktfrequenz evtl. nur in den Projectsettings 
eingestellt und nicht im Quellcode?
Wenn dann für die Baudratenberechnung ein falscher Wert hergenommen 
wird, ists klar das nur Käse rauskommt.

Die Bautrate ist im Quellcode drin, allerdings hab ich mal die Hex-files 
verglichen. Aufällig ist das das neu compilte File länger ist und sich 
nur am Anfang und ende unterscheidet. Jetzt frag ich mich was sich da 
dazu geschummelt haben kann.
Werde das RS232- Signal mal prüfen, wobei ich mal schauen muss wie die 
Rechnung nochmal genau war, hoffe es ist nur ein so kleines Übel, wenn 
es das ist beiß ich auch freiwillig in den Tisch.

Nochmals danke für die schnellen Antworten.

Einen Fehler ausmerzen können, mein eigentliches Problem löst es 
allerdings nicht. Scheint wohl doch noch Markel an der Hardware zu 
haben. Meine Ausgabe schaut jetzt wie folgt aus:

1

 <\0><\0>000000001;9;    0000;<\r><\n>000402;000000000;

2

         000018;000237;0;000000008;000000038;   

3

      00035;                   <\0><\0><\0><\0><\0><\0><\0><\0><\0><\0>

4

<\0><\0><\0><\0><\0><\0><\0><\0><\0><\0><\0><\0><\0><\0>

5

<\0><\0>00003;000000002;0;                   <\0><\0><\0><\0><\0><\0>

6

<\0><\0><\0>

Da sind jetzt die Werte drin welche ich Ausgebe, nur wo kommt der ganze 
andere Zeichensalat her? Habe TXD mit RXD mal kurzgeschlossen und 
Terminal zeigt mir das es an dem Kabel nicht liegen kann. Habe auch ein 
anderes Hex-File ausprobiert was die serielle Leitung nutzt und es 
tauchten keine Störzeichen auf. Hier ein Auszug aus meinem Code:

1

static void serialChar(uint8_t c)

2

{

3

  while((UCSR0A & (1 << UDRE0)) == 0){;}

4

  UDR0 = c;

5

}

6

7

static void serialString_P(char* s)

8

{

9

  while(pgm_read_byte(s))

10

  {

11

    serialChar(pgm_read_byte(s));

12

    ++s;

13

  }

14

}

Vielleicht sieht jemand wo es sich überschlägt oder mist baut. Werde 
selber weiter daran grübeln.

das wäre dann natürlich in der Tat ein HW-Problem...

Ein einfacher Aufruf zur Ausgabe von einem String mit Variablen sieht 
bei mir so aus:

1

serialString_P(PSTR("Steurungswert:  "));

2

serialNumberDigits(parameter.a, 1);

3

serialString_P(PSTR(";"));

wie kann ich das den Prüfen und worin besteht das das Problem, sprich wo 
kommen die falsch ausgegebenen Zeichen für den Fall her?

Übrigens, wenn es verschiedene Compilerversionen sind, mit denen das 
alte und neue Hexfile erstellt wurde, dann ist es ganz normal dass sich 
die Hexfiles etwas unterscheiden. Das hat also nicht viel zu sagen.

Um wirklich was an den Hexfiles erkennen zu können, müsstest du es durch 
nen Dissasembler schicken. Und und dann die Funktion des Asm Codes 
vergleichen, was zusätzlich durch die Optimierung erschwert ist. Das ist 
so aufwändig, das solltest du gar nicht erst versuchen ;)

@ Da Dieter : Danke für den Hinweis mit dem Hex-file, es durch einen 
Dissasembler zu hauen liegt mir auch fern.

@holger : hat leider keinen Unterschied gemacht ob mit oder ohne 
Optimierung, die Ausgabe bleibt gleich falsch.

Ich habe jetzt Fragmente übernommen von meinem Programm und nur eine 
kleine Ausgabe gemacht von Strings. Läuft ohne Auffälligkeiten bis ich 
die Ausgabe von Zahlen als String mit reingebracht habe. Erster 
Durchlauf geht ohne Porbleme doch dann hängt sich das ganze auf bei 
serialChar(uint8_t chr)

1

 ... while((UCSR0A & (1 << UDRE0)) == 0)  ...

die Ausgabe welche im Terminal erscheint ist:

Stringausgabetest->1234567890;  0;
Stringausgabetest->1234567890;

Hoffentlich komme ich so dem eigentlichen Fehler auf die Sprünge. 
Arbeite auf einem ATmega88 mit 20MHz externem Quarz. Danke für Eure 
Ausdauer mir weiter zu helfen.

so danke für die Hilfe, habe mich mal ganz tief bis in den Ass-code 
gewühlt. Dort gab es eine Schlaufe die den Buffer mit wahrlosen Zeichen 
füllt, und es lag doch an der Optimierung -Os und an dem gnu89 nutz jetz 
gnu 99 und alles will ^^ thx

> wahrlosen

hm...  grübel   Also unwahre Zeichen? Zeichen ohne Wahrheit? Imaginäre 
Zeichen?

oder verwahrloste? Oder wehrlose (in der Schlaufe gefangen)?