Hallo zusammen, bin gerade darüber gestolpert, dass der EEProm-Zugriff via eeprom_read_block(), etc. aus der AVR-libc bei der DA-Familie (scheinbar) nicht korrekt funktioniert. Zumindest funktioniert Code für den mega4808 auf dem avr128da32 nicht mehr korrekt. Hat das jemand schon mit Erfolg getestet? Danke!
Wilhelm M. schrieb: > Zumindest funktioniert Code für den mega4808 auf dem avr128da32 nicht > mehr korrekt. Warum sollte er auch? Ist ja ein anderer uC.
Beitrag #6563489 wurde von einem Moderator gelöscht.
Gast
#6563529
Zu C kann ich nichts sagen, aber aus Assembler-Sicht höchst simpel: - lesen: wie SRAM auch, mit ld (0x1400..15FF) - schreiben: z.B. NVMCTRL_CTRLA mit 0x13 (EEERWR: EEPROM Erase and Write Enable) laden, danach mit st byte-weise schreiben
Interessant ist, das die avr-libc für die avrmega0-Serie (4808) funktioniert, und für die DA nicht. Der NVMCTRL ist doch gleich ... aber wohl nur fast.
Gast
#6563558
> Der NVMCTRL ist doch gleich ... aber wohl nur fast.
Die Tabelle für NVMCTRL_CTRLA ist doch völlig anders.
Gast
#6563570
Nachtrag
Jupp, danke! Wo Du Recht hast, hast Du Recht! Das habe ich übersehen ...
Eine template-spezialisierung weiter hat die DA/DB/(DD) nun wieder dieselbe Schnittstelle ;-) Schade nur, dass die avr-libc auch an dieser Stelle veraltet.
Hallo, darf man fragen was an der avr-libc veraltet sein soll?
Veit D. schrieb: > darf man fragen was an der avr-libc veraltet sein soll? Nichts. Er nennt das nur so. Weil er sich nicht vorstellen kann, daß manche Leute anderes (und wichtigeres) zu tun haben, als in ihrer Freizeit und ehrenamtlich Unterstützung für den neuesten ScheiXX in die avr-libc zu hacken. Deshalb liest er auch nicht die Dokumentation (zumindest die unterstützten µC).
Gast
#6714543
S. Landolt schrieb: > Zu C kann ich nichts sagen, aber aus Assembler-Sicht höchst > simpel: > > lesen: wie SRAM auch, mit ld (0x1400..15FF) Kannst Du mir sagen wo das offiziell vermerkt ist? Bin das Datenblatt rauf und runter aber finde zu diesem EEPROM-Lesezugriff keinen Beleg!
Gast
#6714679
Zum Beispiel: http://ww1.microchip.com/downloads/en/Appnotes/Migration-from-megaAVR-to-AVR-DxMCU-Fam-DS00003731A.pdf '2.3.2 SRAM and EEPROM Memories': The EEPROM is located in the Data space for the AVR Dx devices. That allows a linear addressing of the entire area and faster access using the LD/ST instructions:
Gast
#6714709
> ... wo das offiziell vermerkt ist? Bin das Datenblatt ...
Ob das irgendwo explizit im Datenblatt 'AVR® DA Family' steht, kann ich
auf die Schnelle nicht sagen.
Implizit folgt es aus '7.2 Memory Map' unter 'Data space' und 'AVR®
Instruction Set Manual' unter z.B. 'LD – Load Indirect from Data Space'
&c.
Beitrag #6715067 wurde von einem Moderator gelöscht.
Gast
#6715089
> ...?...?...?...?...
Das sind mir denn doch zu viele Fragen auf einmal - ich schlage vor, es
selbst auszuprobieren.
Nur so viel: "Cycle time for data memory access assumes internal RAM
access, and are not valid for access to NVM. A minimum of one extra
cycle must be added when accessing NVM. The additional time varies
dependent on the NVM module implementation. See the NVMCTRL section in
the specific devices data sheet for more information" aus dem 'AVR®
Instruction Set Manual' unter 'LD'.
Gast
#6715141
Danke für die Info zur Zugriffszeit! Also ist der EEPROM Lesezugriff etwas langsamer. S. Landolt schrieb: > ich schlage vor, es selbst auszuprobieren Habe leider gerade nicht die Möglichkeit dazu. Das System mit den (in den Datenraum eingeblendeten) richtigen EEPROM Adressen zu verstehen wär mal recht aufschlussreich. Denn zwischen Mega, XMega und AVR128 gibts da wohl gewisse Unterschiede. Da der (Lese-)Zugriff beim AVR128Dx nun maximal vereinfacht wurde kann man hoffentlich davon ausgehen, daß die Adresse nun ebenso simpel wie beim .DSEG SRAM verwendet wird.
Gast
#6715308
> Beitrag #6715067 wurde von einem Moderator gelöscht. Nanu? Warum das denn? Lesen von EEPROM: ld 3, lds 4 Takte. > Eventuell ist ja für die Daten im .ESEG Segment > noch ein .org 1400$ fällig? Ja, das scheint so zu sein; falls da jemand eine gute Lösung weiß, wäre ich dankbar (auch wenn ich das EEPROM sehr selten nutze):
1 | |
2 | |
3 | |
4 | |
5 | |
bringt zwei Warnungen "... beyond end of memory at 0x1ff" mit avrasm2
('AVR macro assembler 2.2.8).
Gast
#6715320
PS: Und dies funktioniert eben nicht (im Gegensatz zu .dseg):
1 | |
2 | |
3 | |
4 | |
5 | |
Gast
#6715395
S. Landolt schrieb: > bringt zwei Warnungen "... beyond end of memory at 0x1ff" Vor allem aber lässt es sich mit dem AS7 Device Programming so nicht ins EEPROM programmieren: "File contents does not map to any valid device memory for programming EEPROM" Die funktionierende Lösung ist so umständlich wie zuvor: Man muß zu den Adressen im .ESEG jeweils EEPROM_START addieren um sie dann via LDx richtig anzusprechen. Ich verstehe nicht warum das weiter so unintuitiv und anders als im .DSEG SRAM gehandhabt wird.
Gast
#6715407
> ... AS7 ... Nun, dies tangiert mich nicht, da ich (festhalten) mit dem AVR Studio 4.11 arbeite; und mit den maximal zwei Warnungen kann ich leben. > Ich verstehe nicht ... Da sind wir schon zu zweit.
Gast
#6715419
S. Landolt schrieb: > da ich (festhalten) mit dem AVR Studio 4.11 arbeite Erstaunlich. Da hätte ich Bedenken, daß die neuesten AVRs nicht mehr (vollumfänglich) unterstützt werden!
Gast
#6715430
? Benötigt man als Assemblerprogrammierer mehr als den neuesten Assembler? Und auch den nur, wenn die Warnung "Unrecognized core version: V4S" stört.
Gast
#6715592
S. Landolt schrieb: > Ja, das scheint so zu sein; falls da jemand eine gute Lösung weiß, wäre > ich dankbar (auch wenn ich das EEPROM sehr selten nutze): Hoffe, das hilft.
Gast
#6715794
Prima - vielen Dank, c-hater!
Gast
#6715869
c-hater schrieb: > Hoffe, das hilft. Ja ganz nett mit EEMAP Macro Krücke für dieses theorerisch besser lösbare Problem. Bin aber absolut kein Freund solcher Macro-Programmierung weil sie meist Code in Gänze schwerer durchschaubar macht und neue Fehler provoziert. Mir ist die Extra-Zeile .ESEG EE_VAR .DB 7,8,9 ... .EQU EEMM_VAR = EE_VAR+EEPROM_START ... zum LDx Zugriff wesentlich lieber (MM= MemoryMapped). Zumal das nicht die Zeilenanzahl erhöht da die Macro-Variante zusätzlich zu ihrer Definition auch 2 Zeilen pro .ESEG Variablendefinition benötigt. EEWAIT ist leider auch nicht der Weisheit letzter Schluss, zumal in Interrupts. Code kann ja während dem EEPROM-Schreiben weiterlaufen.
Gast
#6715879
Berichtigung: Hinter EE_VAR fehlte der Doppelpunkt .ESEG EE_VAR: .DB 7,8,9
Gast
#6715908
Tom schrieb: > Mir ist die Extra-Zeile > zum LDx Zugriff wesentlich lieber Dann mach's so. Es wird ja niemand gezwungen, meine Macros zu verwenden. > Zumal das nicht > die Zeilenanzahl erhöht da die Macro-Variante zusätzlich zu ihrer > Definition auch 2 Zeilen pro .ESEG Variablendefinition benötigt. Wenn das dein ganzes Problem ist: Man könnte das Macro auch ändern, das ist ja nicht in Granit gemeisselt.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
EEWAIT > ist leider auch nicht der Weisheit letzter Schluss, zumal in Interrupts. > Code kann ja während dem EEPROM-Schreiben weiterlaufen.
Gast
#6715915
c-hater schrieb: > EEWAIT >> ist leider auch nicht der Weisheit letzter Schluss, zumal in Interrupts. >> Code kann ja während dem EEPROM-Schreiben weiterlaufen. Hier war ich noch nicht fertig. Die Sache hier ist: EEWAIT stellt erst sicher, dass er weiterläuft. Ein Schreibzugriff auf's EEPROM bei einem noch laufenden vorigen Schreibzugriff hält ihn nämlich komplett an, u.U. für etliche ms. Siehe Datenblatt... Wenn man das interruptbasiert abwickelt, benutzt man das Macro einfach nicht und gut isses.
Gast
#6715946
Egal ob Interrupt oder im Hauptprogramm: EEWAIT hält den Programmlauf grundsätzlich unnötig auf wenn noch ein Schreibzugriff läuft. Das lässt sich schlauer programmieren- am besten mit EEREADY Interrupt, denn wozu ist der da?! c-hater schrieb: > Man könnte das Macro auch ändern, das ist ja nicht in Granit gemeisselt. Gut. Das schaut so schon etwas besser aus.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.