Hallo, Ich hab da ein kleines Programm geschrieben, dass Daten vom UART einliest, ins SRAM schreibt und dann, sobald 0x13 (Enter) gesendet wurde, wieder raussendet. Allerdings sendet es nur Dreck - hauptsaechlich Beistriche. Interessanterweise funktioniert es aber im Simulator (AVR Studio 4) ganz richtig, soweit ich das beurteilen kann. Vielleicht koennt Ihr mir den entscheidenden Hinweis geben...? Danke schon fuer Eure Muehe! Gruesse, johannes
Hallo Johannes! Ich bin ja nun absolut kein avr-Programmierer, aber mir fällt auf, daß hier: STARTSENDBUFFER: ldi XL, bufferstart nur der low-byte-Teil von X gesetzt wird, später aber: RECEIVE: in temp, UDR ; read byte from UART out PORTB, temp ; and write it to PORTB (LEDs) st X+, temp ; store byte in SRAM und: SENDBUFFER: ; send SRAM buffer back to uart ld temp, X+ ; read byte from SRAM and increment SRAM pointer rcall TRANSMIT das ganze X-Register verwendet wird?! Bist Du sicher, daß das so richtig ist? Gruß Uwe
Hallo Uwe, Danke fuer Deine Antwort! Nein, sicher, dass es richtig ist, bin ich keinesfalls ;-) Das mit dem X-Register. Nun, ich dachte mir, ich ignorier das high byte davon, lass es immer auf 0x00, dafuer kann ich eben einen maximal 255 Zeichen langen Buffer im SRAM haben. Das wuerde mir fuer's erste reichen - so dachte ich zumindest. Jetzt hab ich es aber ausprobiert, auch das high byte von X explizit immer auf 0x00 zu setzen und siehe da - es geht. :) Scheint also doch daran gelegen zu haben. Das muss ich mir wohl noch einmal durchdenken. Dank Dir fuer Deinen hilfreichen Hinweis! Gruesse, johannes
Ein SRAM besteht aus vielen FlipFlops. Die müssen beim Reset nicht zwingend auf einem definierten Pegel liegen. Du musst also jede Speicherstelle erst einmal beschrieben haben, bevor du sie ausliest, sonst kommt es eben zu unvorhersehbaren Effekten wie diesen hier.
Johannes, schön, daß es jetzt funktioniert. Vielleicht wende ich mich doch noch dem AVR zu. ;-) Zum Verstehen: Du solltest Deine Schaltung nochmals anschauen. Vermutlich wird das obere Byte ebenfalls für die Adreßdekodierung verwendet. @Christof Die SRAM-Plätze werden auf jeden Fall vorher beschrieben. (nämlich mit den empfangenen Daten)
Hallo Christof, Ja, da lag wohl mein Fehler. Ich dachte, dass im SRAM an sich alles einmal auf 0x00 steht. (wie bei den ports?) (eigentlich bloed von mir, immerhin steht im Simulator alles auf 0xFF, IIRC). Habe jetzt ein ldi ZH, 0x00 in den RESET-Block dazugeschrieben, jetzt geht's planmaessig. Gruesse & Dank! johannes
@Uwe: Hab nen kleinen Denkfehler gemacht. In diesem Fall war ja das Register X nicht initialisiert worden. Da dies aber auch aus FlipFlops besteht, ändert sich der Kern der Aussage nicht g
Oh, da habe ich Deinen Denkfehler mitgemacht, Christof. :) Man sollte sich also auch keinesfalls darauf verlassen, dass die Register am Anfang alle auf 0 stehen? Komisch, bilde mir ein, das wo gelesen zu haben. Scheint aber wohl nur eine Einbildung zu sein... Gruesse! johannes
Kann natürlich sein, dass das bestimmte Controller machen, aber so lange ich die Stelle im Datenblatt nicht kenne, setze ich das lieber vorher manuell. PS: Wenn UWE nicht wäre, wäre der Denkfehler niemanden aufgefallen. Pfui Uwe!
> Man sollte sich also auch keinesfalls darauf verlassen, dass die Register am Anfang alle auf 0 stehen? Johannes, dazu kenne ich den/die AVR nicht gut genug. Ich habe allerdings mal in grauer Vorzeit gelernt, daß man seine Programm-Variablen grundsätzlich vollständig initialisieren sollte. :-) @Christof Ausrede akzeptiert. ;-)
Schade eigentlich, das man sich andererseits auch nicht darauf verlassen kann, das die Register am Start keinen definierten Wert (also einen zufälligen) haben, sonst könnte man das ja prima als Startwert für einen Zufallszahlengenerator nehmen :-)
Bitte 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.