Hi, ich bin ratlos und mein Latein ist am Ende, ich arbeite mit einem ATmega88 und erstelle meine hex-Files zu flashen mit AVR Studio. Soweit gab es keinerlei Problemm, bis ich ich letztlich ein altes Projekt ab änder wollte. Ich nutze für das Projelkt noch immer den selben Source Code, selbe Version von AVR, als auch Compiler zur Erstellung des Hex-Files, die Hardware ist ohne Fehler (auch das Serial to UBS Kabel getestet). Spiele ich das alte Hex-File des Programms auf läuft alles einwandfrei, spiele ich das letzlich erstelle Hex-File auf gibt es Murks bei der Ausgabe über die Serielle Schnittstelle. Ich gebe dort lediglich einige Zahlen aus. Der Murks besteht in zahlreichen Störzeichen, hier ein Beispiel: ???<\0>??<\0>?<\0><\0>?????<\0><\0>??<\0><\0>??<\0>???????<\0>??<\0>?? <\0><\0><\0><\0><\0><\0><\0><\0><\0><\0><\0><\0><\0><\0><\0><\0><\0><\0> Dies tritt nicht auf wenn ich das damals erstellte Hex-File verwende, am Quellcode wurde nichts verändert. Kann mir da jemand bitte weiterhelfen, es auf einen Bug oder sonstiges zurückführen? Sicher fehlen noch Info's um mir zu helfen also bitte fragt nach, danke.
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' :-)
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.
serialString_P liest aus dem Flash. Vermutung: Du übergibst einen String aus dem RAM.
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 ;)
Apropo Optimierung: Übersetze doch einmal mit und einmal ohne Optimierung.
Leider sind die Fuses, die die Clocksource bezeichnen nicht Teil eines Projektsource codes, sodern werden extern zum code gesetzt. Falls man nun ploetzlich anstelle eine6MHz externen Quarzes den internen 8MHz Oszillator gewaehlt hat...
@ 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?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.