Mikorocontroller Atmel ATMEGA1284

Ich stehe irgendwie auf dem Schlauch. Ich mache eben ein paar Aufwärmübungen mit dem im Betreff genannten Controller, da gibt es etwas, was ich nicht auf die Reihe bekomme:

Der Arbeitsspeicher ist ja nun 128K groß, also braucht man, um ihn byteweise zu adressieren, genau 17 Bit für die Adresse. Der ELPM-Befehl, den es beim ATMEGA128, ATMEGA1280 und ATMEGA1281 gab, gibt es hier aber nicht mehr, genauso wie das Register RAMPZ, in dem das 17. Bit abgelegt wird. Was übersehe ich?

--
Mit freundlichen Grüßen
Andreas Graebe
--. .-. .- . -... . .--.-. -... .... - -....- -... . .-. .-.. .. -. .-.-.- -.. .
Reply to
Andreas Graebe
Loading thread data ...

Am 04.11.2010 13:49, schrieb Andreas Graebe:

Obwohl die IO-Map des 1284 kein RAMPZ angibt, ist in der AVR-libc include RAMPZ auf 0x3b definiert, wie man's erwartet (das AVR Datenblatt sagt dazu "Reserved"). Die AVR-libc-includes werden IIRC aus den Atmel-Device-XMLs automatisch erzeugt, sollten also korrekt sein. Hast du probiert, ob's mit RAMPZ geht? Ich würde vermuten das ist im Datenblatt einfach vergessen worden.

Viele Grüße, Johannes

--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
 - Karl Kaos über Rüdiger Thomas in dsa
Reply to
Johannes Bauer

Andreas Graebe schrieb:

Wenn ich mir das Datenblatt [1] ansehe, tauchen dort doch ELPM und RAMPZ auf, z.B. in der "Instruction Set Summary".

Christian [1]

--
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x6DA025CA
Reply to
Christian Zietz

Johannes Bauer schrieb:

Danke, das ging ja superschnell. Du meinst also, es existieren sowohl RAMPZ als auch der Befehl ELPM, und Atmel hat es nur nicht ins Datenblatt geschrieben? Das ist eine schlüssige Erklärung, ich werde das mal testen.

Was mich übrigens beim Datenblatt auch gewundert hat, ist, daß diesmal nicht das Wort "preliminary" auftaucht ;-)

--
Mit freundlichen Grüßen
Andreas Graebe
--. .-. .- . -... . .--.-. -... .... - -....- -... . .-. .-.. .. -. .-.-.- -.. .
Reply to
Andreas Graebe

Christian Zietz schrieb:

Ja, tatsächlich, in diesem Datenblatt steht es. Ich hatte ein anderes von Atmel heruntergeladen, nannte sich doc8272, dort steht es anders drin. In dem von Dir genannten steht auch wieder das allseits beliebte "preliminary" drin, jetzt ist meine Welt wieder in Ordnung.

Vielen Dank!

--
Mit freundlichen Grüßen
Andreas Graebe
--. .-. .- . -... . .--.-. -... .... - -....- -... . .-. .-.. .. -. .-.-.- -.. .
Reply to
Andreas Graebe

Andreas Graebe schrieb:

In der Tat. Da wäre imho ein Bugreport an Atmel fällig.

Christian

--
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x6DA025CA
Reply to
Christian Zietz

Andreas Graebe schrieb:

Ich mach mal die Ingrid: Die falschen Angaben sind neuer (8272A?AVR?01/10) als die korrekten (8059D AVR?11/09). Da ist wohl irgendwas bei Atmel durcheinandergeraten.

--
Mit freundlichen Grüßen
Andreas Graebe
--. .-. .- . -... . .--.-. -... .... - -....- -... . .-. .-.. .. -. .-.-.- -.. .
Reply to
Andreas Graebe

Das ist ja auch nicht wirklich ein Datenblatt _eines_ µC, sondern mehr sowas wie eine Übersicht über eine µC-Familie. Da drin steht, konkret gesehen, der kleinste gemeinsame Nenner der Familie, also das, was _alle_ Vertreter der Familie gemeinsam haben. Und insofern passen die Angaben durchaus.

Übrigens: Nicht der Arbeitspeicher ist 128k groß, sondern der Programmspeicher.
Reply to
Heiko Nocon

Heiko Nocon schrieb:

Na ja, es ist mittlerweile dasjenige Datenblatt, das man angeboten bekommt, wenn man nach dem 1284 sucht. Insofern sollte dort auch alles drinstehen, gegebenenfalls mit einer Fußnote.

Richtig, habe ich mich falsch ausgedrückt. Flashrom ist 128K und Ram ist 16K groß.

--
Mit freundlichen Grüßen
Andreas Graebe
--. .-. .- . -... . .--.-. -... .... - -....- -... . .-. .-.. .. -. .-.-.- -.. .
Reply to
Andreas Graebe

Andreas Graebe wrote: [...]

Will man denn byteweise adressieren? Ich dachte der Flash-Speicher bei AVRs wird immer wordweise genutzt?

Gruß, Felix

Reply to
Felix Opatz

Natürlich. Immer dann, wenn du was anderes als Code dort ablegst. Zeichenkettenkonstanten z.B. sind ziemlich typische Anwendungen dafür, Daten in den Codebereich zu legen.

Durch Code schon. Sämtliche Opcodes sind Vielfache von 2 Bytes groß und müssen word-aligned im Programmspeicher liegen, weil der PC nur gerade Adressen ansprechen kann.

Für Daten im Flash gilt das hingegen _eigentlich_ nicht. Nur der Atmel-Assembler ist leider ein bissel zu simpel gestrickt, um das sinnvoll nutzen zu können. Sehr störend z.B. bei der Quelltextrepräsentation "mehrzeiliger" Zeichenkettenkonstanten...

Reply to
Heiko Nocon

Da kann ich nur wie Radio Eriwan antworten: im Prinzip ja, aber...

Wenn im Flashrom nur Code steht, wäre byteweise Adressierung natürlich unsinnig, aber es kommt halt oft mal vor, daß dort Texte abgelegt sind, diese können dann per LPM- oder eben ELPM-Befehl ausgelesen werden. Dieser Befehl liest jeweils nur ein Byte ein. Gäbe es einen Befehl, der zwei Byte aus dem Flash in ein Registerpaar packte, hätten in diesem Fall die 16 Bit für den Zeiger gereicht. Allerdings wäre das nur eine Verschiebung des Problems, bis der nächste Controller mit dem doppelten Flash benötigt wird. Da ist das jetzige Verfahren mit einem weiteren Byte für die Adresse eventuell doch zukunftssicherer. Das reicht bis 16 Megabyte Flashrom.

--
MfG     Andreas
Reply to
Andreas Graebe

Ich schrieb:

FYI: Ich hatte das selber bei Atmel angemerkt und habe mittlerweile die Rückmeldung bekommen, dass das Datenblatt in der nächsten Revision gefixt sein wird.

Christian

--
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x6DA025CA
Reply to
Christian Zietz

Christian Zietz schrieb:

Ich befürchte, das ist vergebene Liebesmüh. Ich bin am verzweifeln mit dem Teil. Scheint echt buggy zu sein. Es gibt zum Beispiel Probleme mit den Statusflags. Die Sequenz

andi Register, Maske breq irgendwohin

funktioniert nicht, aber wenn ich folgendes schreibe:

andi Register, Maske tst Register breq irgendwohin

verhält er sich wie erwartet. Entweder, ich habe zwei Vorserienchips bekommen, oder es sind noch etliche Bugs "implementiert". Programme, die auf den Mega128, Mega1281 und Mega 2561 fast[1] ohne Anpassung liefen, schmieren nachvollziehbar ab. Schade, das wäre aufgrund der Verfügbarkeit als DIL der ideale Lernprozessor für unsere Studenten gewesen.

Hat irgendjemand schon Erfahrungen mit dem Teil gemacht?

[1] soll heißen, Quellcode wird mit anderen Parametern übersetzt.
--
Mit freundlichen Grüßen
Andreas Graebe
--. .-. .- . -... . .--.-. -... .... - -....- -... . .-. .-.. .. -. .-.-.- -.. .
Reply to
Andreas Graebe

Andreas Graebe schrieb:

Dann mach doch bitte die entsprechenden Bugreports beim Atmel Support, damit die Fehler in die Errata aufgenommen oder in späteren HW-Revisionen gefixt werden.

Christian

--
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x6DA025CA
Reply to
Christian Zietz

Christian Zietz schrieb:

Ich bin mir allerdings noch nicht ganz sicher, was im einzelnen passiert. Anscheinend muß ich mir wohl mal einen Debugger besorgen, mit dem ich Einzelschritte machen kann und die Statusflags auslesen kann. Zur Zeit mache ich das alles wie früher(TM), schreiben, übersetzen, hochladen, Ergebnis ansehen und interpretieren. Hardware ist teuer...

--
Mit freundlichen Grüßen
Andreas Graebe
--. .-. .- . -... . .--.-. -... .... - -....- -... . .-. .-.. .. -. .-.-.- -.. .
Reply to
Andreas Graebe

Ja, das solltest du mal genauer anschauen. Ein Bug im CPU-Kern waere jetzt doch ziemlich ungewoehnlich, so ein Errata gab es bei den AVRs IIRC seit dem ATmega103 nicht mehr. Normal betrafen bisher die Erratas fast ausschliesslich die Peripherie oder das externe Speicherinterface (das beim mega1284 gar nicht vorhanden ist).

Micha

Reply to
Michael Baeuerle

Ist eine ganz merkwürdige Geschichte: Ich hatte den Auftrag, einen kleinen (< 512 Byte) Bootloader für den Mega128 zu schreiben, der lief auch auf Anhieb. Dann sollte ich ihn auf Mega1281 und Mega2561 erweitern, hat dann beim Test mit dem 2561 auch sofort funktioniert. Nun das ganze für den 1284P (DIL), und nix geht. Unerklärliche Effekte, ständige Abstürze (= Neustart), dann per Zufall den Effekt mit dem "andi" und den Flags gefunden, aber noch lange kein voller Erfolg. Nach ein paar tausend Bytes schmiert der Bootloader ab, das finde mal ohne Debugger. Der Algorithmus scheint ja zu funktionieren, denn bei den anderen Megas läuft das ja alles ohne Probleme und zuverlässig. Da wird der Flash schon mal bis 512 Byte vor dem Ende beschrieben, alles paletti.

Muß ich die Tage wohl noch etliche Testroutinen einbauen, ich habe keine gesteigerte Lust, mir deswegen einen Debugger zuzulegen, ganz abgesehen davon, daß ich den bestimmt nicht genehmigt bekomme.

Übertaktet ist jedenfalls nichts, der Prozessor läuft mit einem Quarz 18,432 MHz und ist bis 20 MHz spezifiziert. Die Tatsache, daß im Datenblatt beim Thema Quarzoszillator nur bis 16 MHz angegeben ist, habe ich erst einmal nicht so tragisch gesehen, ist halt ein klassischer "copy- and-paste" - Fehler. Solche sind meiner Erfahrung nach in Atmels Datenblättern nicht eben selten.
--
MfG     Andreas
Reply to
Andreas Graebe

Andreas Graebe schrieb:

Ein AVR Dragon müsste eigentlich auch mit dem ATMEGA1284 funktionieren und liegt preislich in einem Rahmen, bei dem Chefs in der Regel nicht so viele Bauchschmerzen bekommen.

Christian

--
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x6DA025CA
Reply to
Christian Zietz

Ich kann ja mal antesten, ob er die 50 Euronen spendiert. So teuer ist das ja wirklich nicht.

--
MfG     Andreas
Reply to
Andreas Graebe

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.