xMega EEPROM Memory-mapped

[Sauger (Gast)]

Nabend,

Hier mal ein Vorschlag wie man das EEPROM der xMegas lesend und 
schreibend ansprechen kann ohne ständig zwischen "I/O-mapped access" und 
"Memory-mapped access" umzuschalten, wie es die Funktionen der clib tun.

MfG

[Jörg W. (dl8dtl) (Moderator)]

Wärst du ggf. bereits, das (auf englisch natürlich) mit den avr-libc-
Entwicklern zu diskutieren und eine Integration in die avr-libc
anzustreben?  Das würde übrigens auch eine Lizenzänderung bedeuten
von GPL zur Lizenz, die von der avr-libc benutzt wird.

[Sauger (Gast)]

Nabend,

Jörg Wunsch schrieb:
> Wärst du ggf. bereits, das (auf englisch natürlich) mit den avr-libc-
> Entwicklern zu diskutieren und eine Integration in die avr-libc
> anzustreben?  Das würde übrigens auch eine Lizenzänderung bedeuten
> von GPL zur Lizenz, die von der avr-libc benutzt wird.

Es gibt einen fetten Grund den obigen Vorschlag nicht mit in die libc zu 
übernehmen:

Die Funktionen der libc biegen sich das Speichermodell vor jedem Zugriff 
passend zurecht und können so eigentlich nicht fehlschlagen. Mein 
Vorschlag geht davon aus das er exklusiv arbeitet und ist damit 
potentiell "unsicher".

ansonsten bin Ich für alles offen.

MfG

[Jörg W. (dl8dtl) (Moderator)]

Kannst du das mal kurz für jemanden übersetzen, der damit noch nicht
so viel gemacht hat?  (Ich habe wenig bis keine Xmega-Erfahrungen.)

Ist dein einziges Problem, die Umschaltung zwischen memory mapped und
zurück zu vermeiden?  Wenn ja, könnte man das eventuell so in die
Bibliothek einarbeiten, dass man durch einen Schalter (irgendein
#define) zwischen beiden Varianten umschalten kann?

[Robert (Gast)]

Hallo, als XMega-Einsteiger hätte ich gern gewußt, welche Gründe es gibt 
überhaupt auf den komfortablen Memory-mapped Access Modus zu verzichten? 
Was hat der normale I/O Zugriff da noch für einen Sinn? Danke.

Gruß Robert

[Sauger (Gast)]

Moin,

Jörg Wunsch schrieb:
> Kannst du das mal kurz für jemanden übersetzen, der damit noch nicht
> so viel gemacht hat?  (Ich habe wenig bis keine Xmega-Erfahrungen.)

werde Ich versuchen, wird gegen Abend/Nacht werden.

@Robert
kommt auf die/das Zugriffsmuster an. Schreibende Zugriffe auf einzelne, 
gut verteilte Bytes, dürften I/O-mapped schneller erledigt sein (so aus 
dem Bauch).

MfG

P.S. eine wie auch immer geartete Umschaltung zwischen mixed und mapped 
Mode ist denkbar.

[Sauger (Gast)]

Moin nochmal,

Ich konnte es nicht lassen, habe mal schnell (ganz schnell) den 
Simulator im AVR Studio angeworfen:

1  Byte lesen / schreiben
MM 143 Takte zu 171 Takte clib
10 Byte lesen / schreiben (Block)
MM 487 Takte zu 1464 Takte clib

man sollte wirklich drüber nachdenken.

und jetzt muss ich weg

[Peter D. (peda)]

Ich habe für mich als beste Lösung gefunden: Es werden überhaupt keine 
Variablen im EEPROM zugegriffen.

Es wird eine Struct im SRAM angelegt, die einmal beim Einschalten mit 
dem EEPROM geladen wird. Dann kann man in den Daten rumschreiben, wie 
man lustig ist.
Und nur auf Anforderung werden die Daten in den EEPROM zurückgeschrieben 
und auch nur geänderte Bytes. Z.B. durch Usereingabe oder durch eine 
Power-Fail-Erkennung.


Peter

[Sauger (Gast)]

immer noch Früstück,

Peter Dannegger schrieb:
> Ich habe für mich als beste Lösung gefunden: Es werden überhaupt keine
> Variablen im EEPROM zugegriffen.

Stimmt, nur wenn der Platz im SRAM knapp wird und überwiegend 
Lesezugriffe auf "ab und zu veränderliche Parameter im EEPROM" erfolgen, 
hat ein Memory-mapped Zugriff aufs EEPROM so seine Reize.

Mal eine ganz andere Frage:
Könnte es sein es sich bei dem als EEPROM bezeichneten Bereich um ein 
Flash im EEPROM-Pelz handelt?


MfG

[Jörg W. (dl8dtl) (Moderator)]

Sauger schrieb:
> Könnte es sein es sich bei dem als EEPROM bezeichneten Bereich um ein
> Flash im EEPROM-Pelz handelt?

Ja, technologisch sind zwischen Flash-ROM und EEPROM nur geringe
Unterschiede.  Wo sollten die auch her kommen?  Beide müssen speichern,
und beide müssen sich elektrisch löschen lassen.

Der wesentliche Unterschied ist zugriffstechnischer Natur: im EEPROM
kann man auch einzelne Bytes neu schreiben, im Flash-ROM immer nur
ganze Seiten.

[Thomas K. (tomk)]

Hi,

> Mal eine ganz andere Frage:
> Könnte es sein es sich bei dem als EEPROM bezeichneten Bereich um ein
> Flash im EEPROM-Pelz handelt?

Getreu Sender Erewan: Im Prinzip ja, aber ... ;-) Aus der Anwendersicht 
scheint dies so zu sein, mit einer (aber durchaus entscheidenden) 
Ausnahme: auf einen EEPROM kannst Du byteweise schreiben ohne vorher 
einen ganzen Block löschen zu müssen. (was auch wieder nicht ganz stimmt 
... weil Du unter bestimmten Umständen - abhängig vom Flash-Typ auch ein 
Byte programmieren kannst ohne vorheriges Löschen, genau dann, wenn das 
Byte/Bit vorher gelöscht war! Aber das ist Advanced ...)

In der Hardware sieht das natürlich dann doch etwas unterschiedlich aus, 
obwohl die physikalischen Grundlagen identisch sind.

Schönen Tag noch, Thomas