mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik AVR: Chip Erase löscht SRAM?


Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo liebe Leser,

kann es sein, dass das Chip-Erase den Inhalt des SRAMs zurücksetzt? Bei 
einem Test mit den Sparmatic Zero Heizugsreglern habe ich die Erfahrung 
gemacht, dass nach einem Chip-Erase der Inhalt der RTC, die im SRAM 
liegt, auf $00 gesetzt wird. Ein normales RESET oder ein 
(Über-)Programmieren ohne vorheriges Chip-Erase verändert das SRAM 
nicht. Der Controller ist ein Mega169PV, Programmiersprache ist ASM, 
wobei ich das SRAM bei einem RESET absichtlich nicht komplett 
initialisiere, sondern nur die Zellen, die einen bestimmten Inhalt haben 
sollen. Da ich dieses "Feature" in keinem Datenblatt oder einer AppNote 
gefunden habe, frage ich hier.

Autor: abc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wenn es "chip erase" heisst, würde ich erstmal davon ausgehen, dass auch 
der komplette chip (inkl. sram) gelöscht wird.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Davon ausgehen heißt: Nicht wissen. Das Datenblatt sagt FLASH und (bei 
nicht gesetzter EESAVE-Fuse) EEPROM werden gelöscht, nicht aber 
(unbedingt) das SRAM...

Autor: xxxxxxxx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Probieren geht über studieren.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na ich hatte es ja probiert, aber mir fehlt so ein bisschen die 
Bestätigung aus der Community, denn ich kann mir einerseits nicht 
vorstellen, dass ich der Einzige bin, dem das auffällt und zweitens wäre 
es ein Ding, wenn das SRAM tatsächlich gelöscht wird und es nirgendwo 
dokumntiert ist. Ich habe schon an den verschiedensten Ecken des 
Internets nach diesem Tehma gesucht, bevor ich hier aufschlage, habe 
aber nichts gefunden. Scheinbar bleibt bei allen anderen AVR-Benutzern 
das SRAM beim Flashen unverändert, oder niemand hat bislang das 
Bedürfnis gehabt, Variablen auch nach dem Flashen wieder verwenden zu 
wollen. Ich möchte ja auch nur wissen, ob das normal ist, denn dann 
müsste ich die Variablen zyklisch im EEPROM sichern.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vorstellen könnte ich mir, das im Programmiermodus der SRAM vom Strom 
abgeklemmt wird sicher das alles genullt wird?
Man könnte natürlich auch mal schauen ob das ISP Protokoll es überhaupt 
erlaubt den SRAM zu beeinflussen.

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich könnte mir vorstellen, dass das SRAM zum Programmieren genutzt wird, 
um die Page zwischenzuspeichern. Wissen weiß ich's aber nicht...

...

Autor: weinbauer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
für den prog-mode wird der reset gepullt ... wenn da der ram nicht 
resettet wird, wann dann?

Autor: elmo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
weinbauer schrieb:
> für den prog-mode wird der reset gepullt ... wenn da der ram nicht
> resettet wird, wann dann?

Ein Reset bewirkt keinen "Reset des Rams". Desswegen müssen Variablen 
zur Laufzeit auch noch initialisiert werden.
Ich hab das mal ausgenutzt, um z.B. Variablen über einen beabsichtigen 
Watchdog Reset hinweg zu retten.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Läubi .. schrieb:
> Vorstellen könnte ich mir, das im Programmiermodus der SRAM vom Strom
> abgeklemmt wird

Naja... nicht ganz. Ohne Chip-Erase bleibt alles erhalten. Wenn ich also 
einfach ein gleiches Programm über das bereits im Flash enthaltene 
drüberbügele, gibt es keine Probleme mit dem RAM.

Läubi .. schrieb:
> sicher das alles genullt wird?

Noch nicht. Ich bin sicher, dass es eine Menge Speicherzellen im unteren 
SRAM-Bereich betrifft.

Läubi .. schrieb:
> Man könnte natürlich auch mal schauen ob das ISP Protokoll es überhaupt
> erlaubt den SRAM zu beeinflussen.

???

Hannes Lux schrieb:
> Ich könnte mir vorstellen, dass das SRAM zum Programmieren genutzt wird,
> um die Page zwischenzuspeichern. Wissen weiß ich's aber nicht...

Denkbar, aber warum nur mit Chip-Erase und nicht ohne? Noch dazu gibt es 
einen eigenen temporären Page-Buffer, der extra vorhanden ist und der 
über ISP auch gefüllt/verändert wird, bevor die betreffende Page 
geschrieben wird.

elmo schrieb:
> Ein Reset bewirkt keinen "Reset des Rams". Desswegen müssen Variablen
> zur Laufzeit auch noch initialisiert werden.
> Ich hab das mal ausgenutzt, um z.B. Variablen über einen beabsichtigen
> Watchdog Reset hinweg zu retten.

Exakt, RESET alleine macht am RAM gar nichts. Ich kann den Chip ewig 
intern oder extern resetten, ohne dass im SRAM ein Bit kippt. Es scheint 
reproduzierbar nur mit dem Chip-Erase zu tun zu haben.

Autor: Daniel M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Servus !
Das ist mir auch aufgefallen im Zusammenhang mit einer RTC, als ich von 
einem Mega8 auf einen Mega88 umgestiegen bin.
Denn bei der ISP-Programmierung wird bei neueren AVRs der SRAM genullt, 
wobei bei den älteren der SRAM immer einen nicht definierten bzw. vor 
dem Reset definierten ;) Inhalt hatte. Seitdem verwende ich den 
Bootloader vom FireFly-Projekt.
Dennoch ist dies keine perfekte Lösung, weil der Bootloader ja selbst 
den SRAM verwendet.
Von Atmel hatte ich diesbezüglich ebenfalls nichts gelesen !
Die ham das einfach vo einem Tag am andren geändert ;)
Schöne Grüße,
Daniel

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke Daniel, das ist doch mal ein Wort. Wobei der Mega169(P) ja noch 
ein Chip der älteren Garde ist. Aber gut zu wissen, dass ich nicht 
alleine bin mit der Feststellung. Mir hat die alte Vorgehensweise mit 
dem undefinierten bzw. unveränderten RAM besser gefallen. Der Witz ist, 
dass der STACK nicht automatisch auf RAMEND gesetzt wird, wie das bei 
allen Controllern ab dem Tiny2313 gemacht wird, das muss man noch selber 
machen...

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich könnte mir vorstellen, das es aber gewissermaßen ein 
"Sicherheitsfeature" ist, da man ja durch einen ChipErase ja auch die 
Lockbits löschen kann.
Damit nun ein Angreifer nicht aus dem RAM noch irgendwelche geheimen 
Daten nutzen kann wird dieser beim Chiperase gelöscht. (Man könnte sonst 
ein Programm aufspielen, welches einfach nur den SRAM ausliest und per 
RS232 raushaut)

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joah, das könnte so sein. Aber warum dokumentiert ATMEL das dann nicht 
und lässt die Anwender im Nebel stochern...?

Autor: Klaus De lisson (kolisson)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es wäre ja auch sehr schwer einen Sinn darin zu erkennen,
dass die Daten im Sram erhalten bleiben wenn man den Flash löscht.
Was sollten die Daten im Sram wenn im MC garkein Programm mehr drinne 
ist ?

Gruss K

Autor: Daniel M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, wenn man nur eine kleine Änderung an seiner (Zeit(schalt))Uhr 
macht, aber nicht jedes mal die Zeit neu stellen möchte ;)
Man kann ja fixe SRAM-Adressen verwenden und eben in die .noinit - 
Section geben.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus De lisson schrieb:
> Es wäre ja auch sehr schwer einen Sinn darin zu erkennen,
> dass die Daten im Sram erhalten bleiben wenn man den Flash löscht.
> Was sollten die Daten im Sram wenn im MC garkein Programm mehr drinne
> ist ?

Stell Dir vor, ein Programm ist im Flash, welches eine RTC hochzählt. 
Jetzt lädst Du ein Update desselben Programms auf den Controller und 
WUUUUSCH, alle RTC-Daten sind weg. Somit stellst Du die Uhr neu. Da der 
Controller nicht weiss, wann das Update kommt, kannst Du nur durch ein 
zyklisches Sichern im EEPROM sicherstellen, dass die RTC-Daten erhalten 
bleiben, wenn man neu flasht. Wäre das RAM einfach nur ein stures RAM, 
wären die Daten noch da, und zwar so lange, bis man den Strom abzieht. 
Es geht mir aber mehr um die Dokumentation, denn wenn ich weiß, dass das 
RAM abkackt, dann muss ich mich halt um den Erhalt der Daten kümmern.

Autor: Andreas K. (derandi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der SRAM dient doch nur als eine Art Arbeitsspeicher, oder nicht?

Autor: Mark Leyer (m2k10) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab' diesen 'Effekt' bei einem mega644 als Videogenerator auch 
bemerkt. Nicht initialisierter Grafikspeicher enthielt nach Reset die 
Daten von vorher, nach dem Flashen war der gesamte SRAM auf 0x00. Bin 
mir nicht mehr ganz sicher, aber ich meine, beim EEPROM schreiben war 
das auch. Hatte aber auch nichts dazu gefunden, welches Verhalten lt. 
Atmel nun erwartbar wäre.

Die 128-byte-Pagegröße und 4kB SRAM widersprächen aber evtl. der 
Vermutung, es hätte mit dem Zwischenspeichern beim Flashen zu tun, da 
wird auch, meine ich, kein Page-Buffer verwendet sondern byte für byte 
eingelesen und direkt in den Flash geschrieben. Ist nur geraten, aber 
vielleicht wird beim Flashen alles 'abgeschaltet', was nicht benötigt 
wird (PORTS etc. und halt SRAM), beim RESET bleibt die Spannung 
erhalten?

Beim 6510er war es so, dass man Reset als Funktion nutzen konnte, da der 
Speicherinhalt erhalten blieb, es wurde nur der Prozessor beeinflusst. 
Beim AVR müsste man auch noch einen Extra-Schaltkreis einbauen, der das 
SRAM beim reset x Nano-, oder gar Mili-Sekunden vom Strom trennt damit's 
sicher gelöscht wird. Macht Arbeit, kostet Geld und schränkt den User 
unnötig ein.
Mark

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas K. schrieb:
> Der SRAM dient doch nur als eine Art Arbeitsspeicher, oder nicht?

Ja und? Bei einem externen RAM-Bausteinen bleiben die Daten auch 
erhalten, solange keiner den Stecker zieht oder die Batterien 
herausnimmt. Bei vielen Geräten wurde und wird batteriegepufferter RAM 
verwendet, um die Betriebsdaten und Presets zu speichern. Trotzdem kann 
man einen Werksreset oder ein Firmware-Update machen, ohne gleich alle 
Daten zu verlieren. Diese Funktion hätte ich gerne, aber ich kann und 
möchte an der Hardware nichts ändern. Nunja.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mark L. schrieb:
> Ich hab' diesen 'Effekt' bei einem mega644 als Videogenerator auch
> bemerkt.

Aah ja.

Mark L. schrieb:
> Bin
> mir nicht mehr ganz sicher, aber ich meine, beim EEPROM schreiben war
> das auch.

Das kann man durch setzen der EESAVE-Fuse verhindern. Dann wird das 
EEPROM bei Chip-Erase nicht angetastet.

Mark L. schrieb:
> Ist nur geraten, aber
> vielleicht wird beim Flashen alles 'abgeschaltet'

Dann wäre das SRAM aber nicht sämtlich auf $00, sondern undefiniert.

Mark L. schrieb:
> Beim 6510er war es so, dass man Reset als Funktion nutzen konnte, da der
> Speicherinhalt erhalten blieb, es wurde nur der Prozessor beeinflusst.

So kannte ich das bisher auch. Bin mir nicht ganz sicher, aber beim 
Mega16 ud älter habe ich kein RAM-Löschen registriert.

Mark L. schrieb:
> der das
> SRAM beim reset x Nano-, oder gar Mili-Sekunden vom Strom trennt damit's
> sicher gelöscht wird.

Nochmal: Abschalten eines SRAM löscht es nicht, sondern lässt es 
undefiniert wieder hochfahren. Es handelt sich bei den Speicherzellen um 
FlipFlops, die halt auf 0 oder 1 liegen. Der Startzustand hängt von 
vielen Faktoren ab und ist zumeist recht zufällig.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Knut Ballhause schrieb:
> Nochmal:
Und nochmal: Undefiniert heißt nicht das das Ergebnis nicht alles 0 sein 
kann ;)
undefiniert heißt einfach, das der Hersteller keinen definierten Zustand 
garantiert, das kann 00, FF, AE, oder was zufälliges sein.

Autor: Andreas K. (derandi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Knut Ballhause schrieb:
> Ja und? Bei einem externen RAM-Bausteinen bleiben die Daten auch
> erhalten, solange keiner den Stecker zieht oder die Batterien
> herausnimmt.

Ja also, wenn ich nen Chip-Erase durchführe dann wohl nicht um das selbe 
Programm hinterher nochmal aufzuspielen.
Da wird sehr wahrscheinlich eine geänderte Version draufgeschrieben, 
also was würde ich dann noch mit dem eventuell nicht mehr konsistenten 
Inhalt des Arbeitsspeichers von früher anfangen wollen?

Das bei älteren Chips der SRAM nicht gelöscht wurde würd ich eher als 
Bug bezeichnen.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas K. schrieb:
> Ja also, wenn ich nen Chip-Erase durchführe dann wohl nicht um das selbe
> Programm hinterher nochmal aufzuspielen.

Ja.

Andreas K. schrieb:
> Da wird sehr wahrscheinlich eine geänderte Version draufgeschrieben,

Genau.

Andreas K. schrieb:
> also was würde ich dann noch mit dem eventuell nicht mehr konsistenten
> Inhalt des Arbeitsspeichers von früher anfangen wollen?

Die neue Version verwendet dieselben globalen Variablen am selben 
Speicherplatz.

Andreas K. schrieb:
> Das bei älteren Chips der SRAM nicht gelöscht wurde würd ich eher als
> Bug bezeichnen.

Ansichtssache. Ich mag Chips, die nichts machen, was ich nicht vorher 
auch angewiesen habe. Die automatische Init der Hardware-Register ist da 
schon in Ordnung, aber vom User zu definierender Arbeitsspeicher soll 
doch bitte auch vom User zu definieren sein...

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Läubi .. schrieb:
> Und nochmal: Undefiniert heißt nicht das das Ergebnis nicht alles 0 sein
> kann ;)

Ja klar, ich nahm Bezug auf

Mark L. schrieb:
> vom Strom trennt damit's
> sicher gelöscht wird.

Autor: blkfn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
lieber so
als das dieser löscheffekt wirklich zufällig eintitt
solche dinge können dann von gerät zu gerät variiren und für kurioseste
effekte sorgen

Autor: Andreas K. (derandi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Knut Ballhause schrieb:
> Die neue Version verwendet dieselben globalen Variablen am selben
> Speicherplatz.

Möglich, aber wie wahrscheinlich ist das?
Mit Assembler lässt sich das sicherlich gut kontrollieren, aber unter C 
krieg ich das nicht wirklich mit, wenn sich die Adressen im 
Arbeitsspeicher verschieben.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
blkfn schrieb:
> lieber so
> als das dieser löscheffekt wirklich zufällig eintitt
> solche dinge können dann von gerät zu gerät variiren und für kurioseste
> effekte sorgen

Nein. Wenn ich das SRAM initialisieren will, dann mache ich das. Jede im 
Programm zu nutzende Variable wird bei Programmbeginn ohnehin 
initialisiert, egal ob das SRAM ausgenullt ist, oder nicht. Man kann 
sich als Programmierer ohnehin nicht auf einen definierten Zustand eines 
Arbeitsspeichers verlassen, zumal bei einem RESET keine Ausnullung 
stattfindet. Wenn ich aber eine Variable später, egal welcher 
Betriebszustand (außer Spannungsmangel) zuvor eingetreten ist, noch 
brauche, ist eine automatische Ausnullung problematisch.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas K. schrieb:
> Mit Assembler lässt sich das sicherlich gut kontrollieren

Richtig :-)

Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas K. schrieb:
> Möglich, aber wie wahrscheinlich ist das?
> Mit Assembler lässt sich das sicherlich gut kontrollieren, aber unter C
> krieg ich das nicht wirklich mit, wenn sich die Adressen im
> Arbeitsspeicher verschieben.

Aus diesem Grund schreibt man hardwarenahe (wie in diesem Fall 
gewünscht) und zeitkritische Dinge auch in ASM.

Autor: Klaus2m5 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist zwar nicht dokumentiert, aber es gibt einen guten Grund, SRAM beim 
Chip Erase mitzulöschen.

Ein Programm speichert sicherheitsrelevante Informationen, z.B. 
Passwörter im Klartext im SRAM. Der Programmierer hat die Lockbits 
aktiviert.

Ein Hacker lädt nach  einem Chip Erase sein eigenes Programm, um das 
SRAM auszulesen. Ohne SRAM Erase wäre es jetzt möglich, die Passwörter 
zu sehen!

Autor: Mark Leyer (m2k10) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Knut Ballhause schrieb:
> Mark L. schrieb:
>> Bin
>> mir nicht mehr ganz sicher, aber ich meine, beim EEPROM schreiben war
>> das auch.
>
> Das kann man durch setzen der EESAVE-Fuse verhindern. Dann wird das
> EEPROM bei Chip-Erase nicht angetastet.

Ich meinte den SRAM, gleicher Effekt (alles 0x00), egal ob ich nur den 
Flash oder nur den EEPROM neu beschreibe (Chip-Erase war daher 
deaktiviert), müsste aber mal die Schaltung rauskramen und nochmal genau 
ausprobieren. Mir war das damals nur so nebenbei aufgefallen und da ich 
nichts dazu im Datenblatt fand, habe ich das Thema nicht mehr weiter 
verfolgt.

Hab' mich da wohl 'etwas' unglücklich ausgedrückt.
Da der Inhalt der einzelnen Speicherzellen undefiniert ist, muss es ja 
eine Funktion geben, die u.a. beim 'Einschalten' alle Zellen auf 0 
setzt. Da die Funktion aber wohl beim Reset unterbleibt ist sie 
offensichtlich nicht Teil der üblichen Resetprozedur. Einfachste 
Möglichkeit die mir spontan einfiel, wäre eine Schaltung, die das 
Aktivieren der Stromzufuhr erkennt, alle Select-Leitungen der 
Speicherzellen aktiviert und alle auf 0 setzt. Wenn im ISP-Modus nur die 
benötigten Teile mit Strom versorgt werden, könnte das SRAM auch 
deaktiviert sein. Keine Ahnung, wie Atmel das nun gelöst hat, aber es 
würde zu meinen Beobachtungen und dem, was ich hier gelesen habe, 
passen. Die Datenblätter schweigen sich darüber ja leider aus.

Es handelt sich ja anscheinend um ein neues Feature dass der SRAM auf 
0x00 gesetzt wird. Aber wie auch immer das umgesetzt wurde, die Frage 
ist ja mehr die, wann das auftritt (Stromzufuhr, ISP-Zugriff, ???), bzw. 
wann nicht (Reset, ???). Tiefergehend könnte man noch über die 
Informationspolitik der Firma Atmel diskutieren ;-)

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das trägt zumindest zur Sicherheit bei. Sonst könnte man Daten / 
Passwörter im SRAM auslesen, indem man ein entsprechendes Programm 
flasht.

Für einen DS1307 war kein Platz mehr?

Autor: Andreas K. (derandi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian H. schrieb:
> Aus diesem Grund schreibt man hardwarenahe (wie in diesem Fall
> gewünscht) und zeitkritische Dinge auch in ASM.

Eingangs gehts um nen Heizungsregler, ich seh da keinen Grund 
"Hardwarenah" zu programmieren.
So wie ich das sehe gehts nur um die fehlende Dokumentation,.

Autor: Mark Leyer (m2k10) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mark L. schrieb:
> Hab' da was bei Atmel gefunden:

Okay, das sagt zwar nichts über das Problem, aber die 32 Arbeitsregister 
scheinen als Alternative zum Retten der RTC übrigzubleiben. Muss ich mal 
testen.

Andreas K. schrieb:
> Eingangs gehts um nen Heizungsregler, ich seh da keinen Grund
> "Hardwarenah" zu programmieren.

Ha, der war gut. Was spricht dagegen? ;-)

Andreas K. schrieb:
> So wie ich das sehe gehts nur um die fehlende Dokumentation,.

Ja. So ist es.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es steht doch nirgends, daß nach einem ISP-Programming das SRAM erhalten 
bleibt.
Also wüßte ich nicht, warum man dann Atmel eine Vorwurf machen sollte.

Wenn Du willst, daß der SRAM erhalten bleibt, mußt Du eben einen 
Bootloader verwenden. Der SPM-Befehl ändert das SRAM nicht.


Peter

Autor: Andreas K. (derandi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Knut Ballhause schrieb:
> Ha, der war gut. Was spricht dagegen? ;-)

Es wäre äußerst gründlich und die passenden Utensilien finden sich auch 
vor Ort, und dennoch: Ich putze mein Bad nicht mit der Zahnbürste. ;)

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:
> Es steht doch nirgends, daß nach einem ISP-Programming das SRAM erhalten
> bleibt.
> Also wüßte ich nicht, warum man dann Atmel eine Vorwurf machen sollte.

Umgekeht wäre besser. Einfach sagen, was Sache ist. Alles andere ist 
haarklein beschrieben.


Peter Dannegger schrieb:
> Wenn Du willst, daß der SRAM erhalten bleibt, mußt Du eben einen
> Bootloader verwenden

Ein Bootloader ist zwar immer gern gesehen, hier aber momentan keine 
Option.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas K. schrieb:
> Ich putze mein Bad nicht mit der Zahnbürste.

Ich auch nicht. Der Vergleich hinkt. Da in diesem System fast 
ausschliesslich mit Pins getoggelt wird und Hardware-Interfaces bedient 
werden, drängt sich ASM förmlich auf. Okay, ein paar Berechnungen wären 
in C vielleicht elegant zu erschlagen gewesen, aber die habe ich auch 
ohne Arithmetik-Lib hinbekommen. Aber das führt hier jetzt am Thema 
vorbei. Zudem denke ich, dass soweit alles gesagt ist. Danke für alle 
Informationen zum Thema.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.