Flash beschreiben ATmega

Hallo,

wenn ich das Datenblatt des ATmega128 richtig verstanden habe, müsste es möglich sein, das Programmflash vom Programm aus zu beschreiben. Aus reiner Faulheit frage ich hier mal ganz dreist nach Codeschnippseln. Möglichst für WINAVR.

Ich möchte z.B. 64K des Programmspeichers zur Speicherung von Messdaten verwenden um diese später über die serielle Schnittstelle an einen PC zu übertragen.

Das soll im Prinzip ein Ringpuffer werden. Die aktuelle Speicheradresse möchte ich in einem I2C CMOS Uhrenbaustein mit RAM ablegen.

Das interne EEPROM kann ich ansprechen. Aber die 4K reichen für meine Anwendung nicht aus. Alternativ könnte ich natürlich ein größeres I2C EEProm verwenden, aber wenn man das Programmflash dafür missbrauchen kann, wäre das nicht schlecht.

Gruß

Stefan DF9BI

Reply to
Stefan Brörring
Loading thread data ...

Stefan Brörring schrieb:

Nimm lieber exteren EEPROM. Denn die Programmierung des FLASH ist kniffelig. Dazu muss der Code in der Bootloadersektion liegen. Aus dem normalen Programm heraus geht das nicht.

MfG Falk

Reply to
Falk Brunner

So wie ich das Datenblatt lese hat er ein kleines ROM und kann deshalb das FLASH löschen und beschreiben. Ob das für Anwenderprogramm problemlos verwendbar ist steht da explizit nicht.

Der 68HC908 ( v. Neumann ) kann das Flash per Software die man ins RAM kopiert byteweise beschreiben. Das Byte muß leer d.h. FF sein. Die Page ( 0,256k - 1k Byte ) wird deshalb gelöscht. Mein FORTH im GP32 basiert auf dieser Möglichkeit die der AVR ( Harvard ) früher jedenfalls nicht hatte. Jedoch: unabhängig was im Datenblatt steht ist bei mir nach

100 Schreibzyklen Ende, MassErase der das gesamte Flash löscht behebt den Defekt. Insofern ist Flash kein brauchbarer Ersatz für EEPROM oder batteriegepuffertes SRAM.

MfG JRD

Reply to
Rafael Deliano

Hm, schade. Aber eigentlich kein Problem. Hab gerade mal nachgesehen. Ich schätze mal, ich brauche mindestens 8KByte um die Kundenanforderungen zu erfüllen. Mit nem 24C512 hätte ich dann noch ausreichend Reserve. Und wenn ich sowieso eine RTC mit I2C Bus vorsehe, macht das eigentlich keinen Unterschied...

Gruß

Stefan DF9BI

Reply to
Stefan Brörring

Falk Brunner schrieb:

Hö? Gibts da nicht ne Fuse, die bestimmt, ob der SPM-Befehl nur aus der Bootloadersektion oder global verwendet werden darf? Ist schon länger her, dass ich mir das mal durchgelesen habe, aber ich meine mich an sowas zu erinnern.

Viele Grüße, Johannes

--
"PS: Ein Realname wäre nett. Ich selbst nutze nur keinen, weil mich die
meisten hier bereits mit Namen kennen." -- Markus Gronotte aka Makus /
 Click to see the full signature
Reply to
Johannes Bauer

Johannes Bauer schrieb:

^^^^^^^^

Es geht schon. Es ist nicht trivial, aber auch keine mystische Kunst. Flash ist nur nicht für oft geänderte Daten geeignet, siehe Schreibzyklen.

Die IMO beste Lösung ist es, mit 5 I/O-Leitungen eine MMC/SD-Karte anzuflanschen. So habe ich bei Messungen im Feld ca. 2000 Werte/s aus dem ADC geloggt[0]. Auf FAT-Spielchen habe ich verzichtet, in "/dev/sdd" steht alles, was ich brauche.

Falk P.S.: Hat jemand Bedarf an ein paar MB Beschleunigungswerte aus einer Autofahrt ;-)

Reply to
Falk Willberg

Johannes Bauer schrieb:

Nein. Will soll den der Flash beschrieben werden, wenn das Program noch daruas gelesen/ausgeführt wird? Geht AFAIK bei keinem uC, die haben alle mehrere Sektionen. Nur inaktive kann man beschreiben. Siehe auch MSP430.

MFG Falk

Reply to
Falk Brunner

Falk Brunner schrieb:

Doch.

Gerade nachgeleen, Datenblatt vom ATmega32 nennt auf Seite 247 vier Fuseses (BLB01, 02, 11 und 12), die kontrollieren, ob SPM aus der Application Section (BLB01 und BLB02) und ob es aus der BL-Section (BLB11 und BLB12) schreiben darf (und wohin).

Der SPM-Befehl darf also sehrwohl auch aus der Application-Section verwendet werden. Was überhaupt kein Problem ist, schließlich ist eine BL-Section eh nur eine logische Unterteilung, die es dem Programmierer einfacher macht. Zugriff erfolgt ja Seitenweise (Pagegröße beim tiny2313

64 Byte, beim mega32 bin ich jetzt zu faul zum nachschauen), ist also gar kein Problem.

Viele Grüße, Johannes

--
"PS: Ein Realname wäre nett. Ich selbst nutze nur keinen, weil mich die
meisten hier bereits mit Namen kennen." -- Markus Gronotte aka Makus /
 Click to see the full signature
Reply to
Johannes Bauer

Johannes Bauer schrieb:

Ja, aber nicht im KOMPLETTEN Application Section. Der Flash wird ja in drei Teile geteilt. Bootloader, Application Section NRWW und Application Section RWW. Die beiden ersten sind eher klein, der letzte Block der Grösste. Klar, alles machbar, aber eher aufwändig. Ein exterener I2C ist zehnmal schneller angeschlossen. Und einfacher in der Handhabung,

10..100 fach mehr Programmierzyklen etc.

MfG Falk

Reply to
Falk Brunner

Dem Gedanken zu externem Speicher stimme ich zu. Wir hatten auch hin und wieder Probleme mit uC Flash und es gab Faelle, wo bei Herstellern betretene Gesichter auftraten. "Wir kommen demnaechst mit einen verbesserten Chip raus ..." und solche Sachen.

Habe letztens dieses in ein Kunden-Design gesetzt:

formatting link

Der ist so gross, dass jeder noch einen kurzen Lebenslauf reinsetzen koennte, aber man weiss ja nie und der eine Dollar ging bei dieser Schaltung im Rauschen unter. Das Dingen muss sehr gaengig sein. Ein anderer Consultant, der zeitgleich ein digitale Board machte, hatte unabhaengig den gleichen Chip gewaehlt. IMHO ist SPI populaerer, doch das koennte in Europa anders sein.

--
Gruesse, Joerg

http://www.analogconsultants.com/
Reply to
Joerg

Joerg schrieb:

Nett. Und das Gruppenfoto nicht vergessen!

- Henry

--
www.ehydra.dyndns.info
Reply to
Henry Kiefer

Das waere allerdings die Kuppe! Muss ich mal vorschlagen.

--
Gruesse, Joerg

http://www.analogconsultants.com/
Reply to
Joerg

Du hast nicht richtig gelesen. Die BL-Fuses kontrollieren ausschließlich, wohin geschrieben werden darf.

Ja. Er macht dort bloß nix. Du kannst getrost auch ein NOP hinschreiben, hat genau denselben Effekt.

Der schreibende Code muß aber auf jeden Fall in der Bootloader-Sektion stehen. Genau genommen muß nur der eigentliche SPM-Befehl zwingend dort stehen, aber einige weitere Details der Sache sorgen dafür, daß noch etwas mehr Code zumindest im NRWW-Bereich platziert werden muß, der mit dem Bootloaderbereich identisch sein kann, aber nicht sein muß.

Der Bootloaderbereich ist sicher immer vollständig im NRWW-Bereich, so daß es sinnvoll ist, die drei kleinen benötigten Routinen komplett dort zu platzieren. Der Rest eines Flash-Filesystems für den internen Flash der ATMega kann an beliebiger Stelle stehen.

Allerdings muß man bei interruptgesteuerten Anwendungen zumindests für die eigentliche Zeit des Schreibens bzw. Löschens einer Page leider die Interrupts disablen. Die Alternative ist, sowohl die Interruptvektoren als auch den gesamten Code der ISRs im NRWW-Bereich unterzubringen. Das ist i.d.R. nicht möglich, weil interruptgesteuerte Anwendungen ja oftmals außer ein wenig Initialisierungskrams nur aus ISRs bestehen. Das paßt einfach nicht alles in den NRWW-Bereich.

Wer damit leben kann, daß die Interrupts bei Pagezugriffen disabled werden, kann die folgenden Routinen verwenden (müssen im Bootloaderbereich platziert werden), die sich auch gleich selber darum kümmern, die Interrupts im richtigen Moment zu sperren. Aber Achtung: Sie kümmern sich nicht darum, daß ihnen keine EEPROM-Operationen ins Gehege kommen. Das muß die Anwendung selber organisieren, wenn sie Flash und EEPROM benutzt.

;->[Z]: Pageadresse spm_writepage: push R16 ldi R16,(1

Reply to
Heiko Nocon

Wurde schon gemacht, allerdings in einem Kinderspielzeug (C64 DTV):

formatting link

Allerdings hat das Team da so viele Gimmicks drin versteckt, als Testpunkte deklariertes Tastatur- und Floppyinterface z.B., das es mich wirklich erstaunt, daß das Management der Firma, die das Teil als Spielzeug auf den Markt gebracht hat, das nicht gemerkt hat. Soll ihnen aber im Nachhinein recht sein, Geeks und Hacker kaufen das Ding wie blöde (ja, ich hab' auch einen :-) ).

Gruß Henning

Reply to
Henning Paul

Klingt interessant, ist aber hier nicht notwendig. Es handelt sich um ein Labormessgerät an dem Reihenmessungen gemacht werden. Das sind in der Regel maximal 200 Messungen pro Stunde bzw. max. 1500 Messungen am Tag. Das Gerät sollte mindestens die Messungen eines Tages speichern können. Für eine Messung komme ich wohl mit 3 Byte aus, so dass ich ca. 4500 Bytes benötige. Das ist zwar nur knapp über dem, was ein ATMega128 als internes EEProm hat, aber eben doch etwas zu wenig. Deshalb denke ich momentan an einen 512 KBit I2C EEProm 24C512 o.ä. Das dann in Verbindung mit einem I2C Uhrenbaustein mit CMos-RAM wo ich dann den Zeiger auf das EEProm ablege.

Damit könnte dann das Gerät theoretisch 1.000.000 x 12 Tage betriebn werden, bevor die EEProm-Zellen schlapp machen.

Gruß

Stefan DF9BI

Reply to
Stefan Brröring

Offensichtlich lebt ihr in euren eigenen Parallelwelt. Nett. Apple hat auch so einiges in diese Richtung. Unterschriftensammlung im Gehäuse, Bilder im ROM usw.

- Henry

--
www.ehydra.dyndns.info
Reply to
Henry Kiefer

Wo hast Du im Datenblatt ein ROM gefunden?

MfG

Reply to
Thorsten Böttcher

... und zusaetzlich noch das Lesen via LPM.

Ack. Die BOOTSZ Fuses legen den Adressbereich fest in dem SPM ausgefuehrt werden kann/darf. Das kann also maximal die gesamte NRWW Section sein (4KiByte).

Micha

Reply to
Michael Baeuerle

Oder man kauft sich ganz dekadent etwas fertiges:

formatting link

--
Gruesse, Joerg

http://www.analogconsultants.com/
Reply to
Joerg

Hi,

Schonmal über Methoden der Datenreduzierung nachgedacht (Indices, nur Differenzen speichern usw.) ?

Frank

Reply to
Frank Esselbach

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.