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
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.
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
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?
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
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.
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
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
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
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.
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
Bitte 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.