mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Problem mit Mega48 - Nur Wirrwarr im RAM


Autor: Dennis Strehl (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

ich hab da ein Problem mit meinem AtMega48 das ich alleine nicht gelöst
bekomme.
Ich hab ein Programm, das einen haufen Variablen (9*6 Stück) aus dem
EEprom auslesen soll. Diese liegen im Eeprom von Addresse 0x00-0x5F
(Ich hab den Eeprom in 16-Byte-Blöcke aufgeteilt, in jedem liegen je 9
Variablen. Das angehängte Programm soll diese zunächst in einer
Schleife einlesen und im SRAM speichern. Danach werden die ersten 9
Werte in Register übertragen. Zwischendurch werden die Werte auch noch
per USART ausgegeben. In der Simulation funktioniert es nun endlich,
nachdem ich herausgefunden habe, dass man das Eeprom-Image manuell
einfügen muss. Jedes Register hat den korrekten Wert. In der Realität
sieht das "ein wenig" anders aus. Die Register enthalten jedes Mal
Zufallszahlen.
Am Eeprom scheint es nicht zu liegen, ich hab das Programm jetzt einmal
laufen lassen und danach nochmal über den Programmer das Eeprom-Image
überprüft. Außerdem werden in der Schleife die Werte, die ausgelesen
worden sind, ausgegeben -> alles korrekt
Auch am AtMega scheint es nicht zu liegen, ich hab jetzt nochmal einen
anderen ausprobiert und es passiert das gleiche.
Das blödeste ist, dass es in der Simulation läuft und real nicht.
An den Initialisierungen am Anfang (USART und CLKPR) liegt es meiner
Meinung nach auch nicht.

Irgendwer ne Idee?

Autor: Dennis Strehl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab noch was vergessen was ich eigentlich noch schreiben wollte:

Die Taktquelle ist ein externer 18,432 MHz-Oszillator, geteilt durch 32
per CLKPR.
Programmiert wird der Controller per Avreal
(http://ln.com.ua/~real/avreal/index_e.html), aber ich denke eigentlich
nicht dass das was ausmachen kann. Oder?

Autor: mr.chip (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Ohne jetzt den Code genauer angeschaut zu haben ein paar Denkanstösse:

Kontrolliere das EEPROM nochmals ;-) (Ich habe damit schon seltsame
Dinge erlebt, ging dann allerdings um Schreibzugriffe.)

Da du von Zufallszahlen sprichst: Das SRAM weist nach dem Reset
zufällige Werte auf. Es könnte also sein...

...dass dein Programm gar nicht wirklich etwas in das SRAM schreibt,
und du folglich auch nur die ursprünglichen Zufallszahlen bekommst.

...dass du eine Variable im SRAM nicht initialisierst sondern einfach
als 0 annimmst, allerdings hat diese dann einen zufälligen Wert. Wenn
es sich bei dieser Variable um einen Pointer handelt, sicher ziemlich
lustig.

(Ich tippe auf einen Fehler in dieser Richtung, da die zufällige
Initialisierung des SRAMs eigentlich der einzige Unterschied zur
Simulation ist.)

Oder sind es irgendwelche Timing-Probleme mit dem EEPROM? Also wenn du
das Register schon ins SRAM verfrachtest, bevor es richtig gelesen
wurde?

Gruss

Michael

Autor: Dennis Strehl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Kontrolliere das EEPROM nochmals

Die Werte die ausgelesen werden, werden auch per USART ausgegeben, und
da stimmen sie definitiv.

>...dass dein Programm gar nicht wirklich etwas in das SRAM schreibt,
und du folglich auch nur die ursprünglichen Zufallszahlen bekommst.

Glaube ich nicht, da das "st Z+, tmph" in der Schleife im Grunde
immer ausgefürt wird / werden müsste

>...dass du eine Variable im SRAM nicht initialisierst sondern einfach
als 0 annimmst, allerdings hat diese dann einen zufälligen Wert. Wenn
es sich bei dieser Variable um einen Pointer handelt, sicher ziemlich
lustig.

Pointer im RAM hab ich keine... aber die Register haben doch als
Startwert 0 oder?

>Oder sind es irgendwelche Timing-Probleme mit dem EEPROM? Also wenn
du
das Register schon ins SRAM verfrachtest, bevor es richtig gelesen
wurde?

Also wenn ich das im Datenblatt richtig gelesen habe, dann stehen die
gelesenen Daten sofort zur Verfügung (abgesehen davon, dass die CPU
dafür 4 Takte lang angehalten wird).

Autor: Dennis Strehl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fehler gelöst...

>>...dass du eine Variable im SRAM nicht initialisierst sondern
einfach
>>als 0 annimmst, allerdings hat diese dann einen zufälligen Wert.
Wenn
>>es sich bei dieser Variable um einen Pointer handelt, sicher
ziemlich
>>lustig.

>Pointer im RAM hab ich keine... aber die Register haben doch als
>Startwert 0 oder?

Hmhmhmhmhm... Eben nicht. Ich hab jetzt am Anfang noch das ZL-Register
auf 0 gesetzt. Das der Datenspeicher nicht standardmäßig auf 0 liegt
war mir ja bekannt, aber dass die Register nach nem Reset nicht auf 0
sind ist mir neu. Naja, Problem gelöst und wieder was dazugelernt.

Bis dann

Autor: mr.chip (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Da hab ich auch gerade was gelernt ;-)

IMMER mit einem sinnvollen Wert INITIALISIEREN!

Ist ja eigentlich logisch, dass sich die Register gleich wie das SRAM
verhalten, schliesslich dürfte die Technologie die selbe sein.

Gruss

Michael

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ausserdem würdest Du Dich schön beschweren, wenn
nach einem Watchdog-Reset die Register alle gelöscht
wären.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.