Hallo, habe das AVR-Studio 5.1 und ein ATXMega 128 A1 Xpained Board gekauf. soweit komme ich gut zurecht, nur beim EEPROM im AVR, da habe ich doch etwas Probleme... Habe den Code aus dem xeeprom.h von Joachim Rath entnommen. der Compiler zeigt keinen Fehler an, aber finde die Daten nicht im Fenster Memory1 (AVR-Studio) Hab ich da noch etwas übersehen??? Ist der Code so einwandfrei ? Adressierung Richtig ? wäre toll, wenn sich einer sich das anschauen könnte und ggf einen Tipp geben kann Danke schon einmal vorab ; Speichern eines BYtes im EEPROM des AVR ; Abfrage, ob NVM Memory Status Busy ; wenn besachäftigt, dann warten loop1: ldi h2,0x80 lds h3,nvm_status cp h2,h3 breq loop1 ;EEPROM INIT ldi h3,0x08 sts nvm_ctrlb,h3 ;Adresse 0 ldi h3,0x10 sts nvm_addr0,h3 ;Adresse 1 ldi h3,0x10 sts nvm_addr1,h3 ;Adresse 2 ldi h3,0x00 sts nvm_addr2,h3 ;Daten ldi h3,0x01F sts nvm_data0,h3 ;EEPROM-Page löschen/schreiben initialisieren ldi h3,NVM_CMD_ERASE_WRITE_EEPROM_PAGE_gc sts NVM_CMD,h3 ;eine 1 ins CPU-CCP Register ldi h3, CCP_IOREG_gc sts CPU_CCP,h3 ;Löschen/schreiben ausführen ldi h3,1 sts NVM_CTRLA, h3 ;dauert ein paar Durchgänge loop2: ldi h3,0x82 lds h2,nvm_status cp h3,h2 breq loop2 fertisch... aber keine Daten im EEPROM (Memory1 im AVR Studio)
:
Verschoben durch User
Hallo Axel, sorry, wenn ich Dir ein wenig zu nahe treten sollte, aber warum lädst Du nicht einfach die Atmel Studio Version 6.0 herunter und beginst mit einem der ASF NVM Software Examples für das Xplain Board? Es macht in meinen Augen keinen Sinn für solche Banalien, wie EEPROM lesen und schreiben, einen XMega in Assembler zu programmieren, wenn Atmel bereits eine fertige Sofware Library samt Beispiele liefert... Liebe Grüße, Schimmi
Warum sollte er sich wegen "Banalien" erst noch in C und das ASF Monstrum einarbeiten?
HAllo, habe Studio 6 auf dem Rechner, und es hat nichts mehr mit einfachem Programm zu tun, einfach nur Assembler... mehr ist nicht nötig. Arbeite beruflich mit C++ und C#, aber gerade einen AVR programmieren, da ist Assebmler die Sprache überhaupt. Ich habe nur so vollständige Kontrolle über die einzelnen Schritte im Programm. Und Assembler ist eine feine Sache, darauf möchte ich nicht verzichten... Es gibt eben auch die, die ihr Brötchen noch selber schmieren und nicht fertig belegt beim Bäcker kaufen, oder von mama schmieren lassen (konnte ich mir jetzt nicht verkneifen - sorry) in C hat man seine Libs usw, und oft weiss keiner genau, was da im einzelnen abläuft. Das ist nicht meine Welt... Schreiben eines Bytes an eine Speicherstelle im EEPROM Habe etwas probiert, und auch eine Lösung gefunden... e_schreiben: ldi Temp3, NVM_EEMAPEN_bm; Enable EEPROM Memory Mapping sts NVM_CTRLB, Temp3 mov R17,geschw; zu speichernder Wert LDI YH, $10 LDI YL, $00 ST Y, R17 NVM0: LDS Temp3, NVM_STATUS SBRC Temp3, 7 RJMP NVM0 LDI Temp3, $00 STS NVM_ADDR0, Temp3 LDI Temp3, NVM_CMD_ERASE_WRITE_EEPROM_PAGE_gc STS NVM_CMD, Temp3 LDI Temp3, $D8 STS CPU_CCP, Temp3 LDI Temp3, $01 STS NVM_CTRLA, Temp3 NVM1: ; LDS Temp3, NVM_STATUS SBRC Temp3, 7 RJMP NVM1 ret e_lesen: NVM3: LDS Temp3, NVM_STATUS SBRC Temp3, 7 RJMP NVM3 LDI Temp3, 0x06 STS NVM_CMD, Temp3 ldi Temp3, 0; DISEnable EEPROM Memory Mapping sts NVM_CTRLB, Temp3 LDI Temp3, $0 STS NVM_ADDR0, Temp3 LDI Temp3, $0 STS NVM_ADDR1, Temp3 LDI Temp3, $D8 STS CPU_CCP, Temp3 LDI Temp3, $01 STS NVM_CTRLA, Temp3 NVM4: ; wait just for test LDS Temp3, NVM_STATUS SBRC Temp3, 7 RJMP NVM4 LDS geschw,NVM_data0 ret Schön, dass die einzelnen Schritte noch klar zu erkennen sind... Hat etwas gedauert das im einzelnen heraus zu fummeln. WICHTIG: im Studio 5.1 oder 6 wird das beschreiben des EEPROM nicht im Memofenster angezeigt ! Lesen mit vorgegebenen Werten funktioniert. Das hat mir viel Zeit gekostet, solch einen Mangel in der AVR-Studio-Software erst mal zu erkennen. Man sucht sich ja nen Wolf, und denkt beim schreiben, da geht was nicht... Nichts für ungut, aber es geht alles auch in Assembler...
Moby schrieb: > Warum sollte er sich wegen "Banalien" erst noch in C und das ASF > Monstrum einarbeiten? Vielleicht weil wir heute unsere Briefe auch nicht mehr mit Hammer und Meißel auf Steinplatten schreiben... ;) Liebe Grüße, Schimmi
Jürgen Schilling schrieb: > Vielleicht weil wir heute unsere Briefe auch nicht mehr mit Hammer und > Meißel auf Steinplatten schreiben... ;) Zugegeben, der Umgang mit Hammer und Meißel kann manchmal recht mühsam sein. Dafür behält man zu 100% die Kontrolle über-, die tatsächliche 1:1 Ansicht auf- und eine optimale Paßform des Programmcodes. Demgegenüber kommt mir C(++) wie eine große Baggerschaufel vor, die zwar viel (unnützes) Material bewegt, das aber ohne viel Gefühl und stets mit der Gefahr, den kleinen LKW Microcontroller zu überladen :) Mir kommt jedenfalls C nicht ins Haus; wenn es schnell und ohne besondere Ansprüche gehen soll dann meinetwegen Bascom... Moby.
Axel Johannes schrieb: > Nichts für ungut, aber es geht alles auch in Assembler... Moby schrieb: > Mir kommt > jedenfalls C nicht ins Haus; Ha, es gibt sie noch, die echten Programmierer! 100% ACK.
Hab nichts gegen C Programmierung, hab ich den ganzen Arbeitstag lang mit zu tun. Dennoch mag ich beim kleinen Processor auch sehr gerne Assembler. Zudem bei C auch alles mögliche vorab definiert und/oder verstanden werden muss, was nicht unbedingt eine Erleichterung ist. Sätestens dann, wenn ein Code nicht so läuft wie das soll. Beide Sprachen haben ihre Berechtigung. Dennoch möchte ich weiterhin in Asssembler schreiben. da direkter. C ist auch eine zähe Sprache, aber auch in Assembler kann man sich mächtig verzetteln. Und ein ATXMEGA ist da auch schwerer zu beherrschen als ein ATMEGA, was C sicher begründen mag. Was mich beim ATXMEGA und dem AVR-Studio in C oder Assembler richtig nervt ist, dass das EEPROM-Memofenster beim ATXMEGA128A1 nicht beschrieben wird. Es ist keine Kontrolle vorhanden, was ins EEPROM geschrieben wird. Simulation im AVR-Studio gar nicht möglich. Das Problem habe ich bei Version 4,5 und 6. Wenn das notwendig wird zu überprüfen, weil ein Code nicht sauber läuft, dann wird es richtig heftig. Daher die Frage: gibt es einen AVR_X_MEGA, der auch das Memofenster unterstützt? Dass das beschreiben vom EEPROM im AVR-Studio sichtbar wird? Das würde mir richtig helfen.
Axel Johannes schrieb: > derzeit mit dem Studio 5.1 von Atmel Das allein reicht nicht- Du brauchst noch einen Debugger wie ICE3, der dann via PDI angeschlossen wird! Dann kannst Du im Debug-Modus bei gestopptem Programmlauf live in den Xmega reinschauen und auch das EEPROM-Fensterchen dürfte sich dann mit plausiblem Inhalt füllen... Oder hab ich Dein Problem völlig falsch verstanden?
hab keinen derartigen debugger, ist ein Heimprojekt, da muss ich etwás sparsamer sein ;-) Später ma, bislang konnte ich ohne sehr gut zurecht kommen. Es geht um Studio 5.1 oder auch 6 von Atmel, in der Simulation keine Beschreibung des Memo_Fensters bei EEPROM. Aber vielleicht tut es ein anderer ATXMEGA... ???
Mit Debugger sicher jeder AVR (mit JTAG oder PDI Schnittstelle). So wie jetzt hast Du natürlich nur ein simuliertes Memo-Fenster und kannst nicht in echt in den Controller schauen. In der Hilfe zum Simulator des aktuellen Studio 6.0.1938 heißt es: "Writing/erasing Flash (using SPM) and EEPROM from application not yet implemented in ATXmega devices" Damit hast Du mit Deinem Anliegen (vorerst) schlechte Karten.
Axel Johannes schrieb: > C ist auch eine zähe Sprache, aber auch in Assembler kann man sich > mächtig verzetteln. Und ein ATXMEGA ist da auch schwerer zu beherrschen > als ein ATMEGA, was C sicher begründen mag. Ein XMEGA ist rein vom Umgang her ein Mega mit ordentlich Dampf. In Assembler macht das keinen Unterscheid. Die Befehle sind gleich, lediglich die Definitionsfiles des XMEGAs sind deutlich aufgeräumter und man findet alles sehr genau beschrieben und selbsterklärend. Axel Johannes schrieb: > Was mich beim ATXMEGA und dem AVR-Studio in C oder Assembler richtig > nervt ist, dass das EEPROM-Memofenster beim ATXMEGA128A1 nicht > beschrieben wird. Habe ich noch nie gebraucht. Debuggen löse ich mit Pinwackeln (LEDs...)und Ausgaben über genormte Schnittstellen. Das reicht in aller Regel. Ein Speicheroszi erledigt den Rest. Axel Johannes schrieb: > Es ist keine Kontrolle vorhanden, was ins EEPROM > geschrieben wird. Diese Kontrolle sollte beim Programmierer selbst liegen. Die Workarounds für die alten XMEGAs bezüglich EEPROM funktionieren gut und die neuen XMEGAS machen da gar keine Probleme und sind rasant schnell mit EEPROM und FLASH, vergliechen mit den Megas. Die Zugriffe sind auch sehr komfortabel über Kommandos und linearen Speicherbereich eingeichtet.
Nur nochmal zur Sicherheit: Die Errata bzgl. EEPROM und XMega A1 hast du gelesen? Dann is' gut. Im Moment noch kein Problem, aber später wirst du in der EEPROM Schreibroutine die Interrupts sperren müssen. Mir war der Workaround mit Sleepmode usw. zu kompliziert bzw. sicherheitsrelevant, ich benutze deswegen ein externes 93C46.
Einfacher? naja, wenn denn die CPU auch das tun würde was der Code vorgibt... Habe es bislang auch so geschafft das EEPROM zu beschteiben und auszulesen. Dass solch ein Flagschiff von Processor nicht vollständig auch im AVR-Studio unterstützt wird, das finde ich doch schon etwas sehr schade. Einfacher finde ich es nicht einen AT_X_MEGA zu programmieren, ganz im Gegenteil. Die vielen Optionen müssen auch erst einmal verstanden werden. Später sagen, das ist alles viel besser... OK... aber bis dahin ist es ein längerer Weg. Es genügt ja nicht die Register beschreiben zu können, sondern es muss auch verstanden werden, was dahinter steckt. Und das ist deutlich anspruchsvoller als ein ATMEGA. Habe einen Code geschrieben, der das EEPROM vollständig beschreibt und danach auslesen kann - fehlerfrei. Aber in einem anderen Programm diesen Code angewendet, da geht es nicht... Und dann verstehen - warum géht das nicht ??!! Und das ist sicher kein Spaß, ohne genauere Daten zur Kontrolle aus dem ATXMEGA bekommen, den Fehler zu finden. An diesem Problam arbeite ich seit 3 Tagen, und das ist nicht lustig. Für mich ziehe ich da eine Konsequenz... solange es da keine vollständige Unterstützung mit dem AVR-Studio und debuggen gibt, solange werde ich lieber auf die Processoren setzen, die das können. Ich kann auch nicht wirklich nachvollziehen, warum Atmel keine vollständige Unterstützung mit dem AVR-Studio anbieten kann. Aber egal, so werde ich mit dem ATXMEGA mit Sicherheit nicht wirklich glücklich.
Axel Johannes schrieb: > Aber egal, so werde ich mit dem ATXMEGA mit Sicherheit nicht wirklich > glücklich. Bei ASM Programmierung und erst recht mit einem leistungsfähigen Prozessor muß man einfach dranbleiben und hartnäckig sein, dann wird das schon. Anspruchsvoll bedeutet eben auch einen gewissen Zeiteinsatz, um den Bits auf den Grund zu gehen- aber das lohnt sich. Du bist sicher noch am Anfang des Wegs. Das merkt man daran, daß Du Dich so an der fehlenden EEPROM-Unterstützung im Simulator verbeißt. Dieser Mangel ist aktuell sicher kein Ruhmesblatt für Atmel, aber für die Programmentwicklung kein essentielles Hindernis, denn viele Wege führen nach Rom. Axel Johannes schrieb: > Und das ist sicher kein Spaß, ohne genauere Daten zur > Kontrolle aus dem ATXMEGA bekommen, den Fehler zu finden. Wenn Du wirklich ernsthaft und professionell an die Lösung von Programmierproblemen gehen willst und reale Daten aus dem ATXMEGA willst mußt Du Dir wirklich einen Hardware-Debugger anschaffen, denn alles andere ist deutlich umständlicher. Axel Johannes schrieb: > wenn denn die CPU auch das tun würde was der Code > vorgibt... Das tut sie in der Regel auch, wenn man die Errata berücksichtigt. Relativ fehlerfrei sind die neuen U-Typen, z.B. XMegaA4U
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.