Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.sci.electronics > #275281 > unrolled thread

STM32FXX Flash Speicher weniger abnutzen

Back to article view | Back to de.sci.electronics

Contents

  STM32FXX Flash Speicher weniger abnutzen Ole Jansen <remove.this.kaspernasebaer@gmx.de> - 2020-02-12 14:53 +0100
    Re: STM32FXX Flash Speicher weniger abnutzen Andreas Fecht <forum@aftec.de> - 2020-02-12 16:27 +0100
      Re: STM32FXX Flash Speicher weniger abnutzen Ole Jansen <remove.this.kaspernasebaer@gmx.de> - 2020-02-13 08:54 +0100
        Re: STM32FXX Flash Speicher weniger abnutzen Andreas Fecht <forum@aftec.de> - 2020-02-13 11:43 +0100
          Re: STM32FXX Flash Speicher weniger abnutzen Ole Jansen <remove.this.kaspernasebaer@gmx.de> - 2020-02-14 08:49 +0100
            Re: STM32FXX Flash Speicher weniger abnutzen Thorsten Böttcher <thorsten_nospam@gmx.net> - 2020-02-14 09:33 +0100
              Re: STM32FXX Flash Speicher weniger abnutzen Ole Jansen <remove.this.kaspernasebaer@gmx.de> - 2020-02-14 14:18 +0100
        Re: STM32FXX Flash Speicher weniger abnutzen Thorsten Böttcher <thorsten_nospam@gmx.net> - 2020-02-13 11:45 +0100
    Re: STM32FXX Flash Speicher weniger abnutzen Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de> - 2020-02-12 19:57 +0000
    Re: STM32FXX Flash Speicher weniger abnutzen Marte Schwarz <marte.schwarz@gmx.de> - 2020-02-13 08:25 +0100
    Re: STM32FXX Flash Speicher weniger abnutzen Rafael Deliano <rafael_deliano@arcor.de> - 2020-02-13 17:40 +0100
    Re: STM32FXX Flash Speicher weniger abnutzen Volker Bartheld <news2020@bartheld.net> - 2020-02-13 20:43 +0100
      Re: STM32FXX Flash Speicher weniger abnutzen Ole Jansen <remove.this.kaspernasebaer@gmx.de> - 2020-02-14 08:17 +0100
        Re: STM32FXX Flash Speicher weniger abnutzen Volker Bartheld <news2020@bartheld.net> - 2020-02-14 10:30 +0100
          Re: STM32FXX Flash Speicher weniger abnutzen Ole Jansen <remove.this.kaspernasebaer@gmx.de> - 2020-02-14 13:45 +0100
            Re: STM32FXX Flash Speicher weniger abnutzen Hanno Foest <hurga-news2@tigress.com> - 2020-02-14 14:23 +0100
              Re: STM32FXX Flash Speicher weniger abnutzen Ole Jansen <remove.this.kaspernasebaer@gmx.de> - 2020-02-14 15:00 +0100
                Re: STM32FXX Flash Speicher weniger abnutzen Hanno Foest <hurga-news2@tigress.com> - 2020-02-14 16:28 +0100
                  Re: STM32FXX Flash Speicher weniger abnutzen Ole Jansen <remove.this.kaspernasebaer@gmx.de> - 2020-02-17 10:28 +0100
                    Re: STM32FXX Flash Speicher weniger abnutzen Hanno Foest <hurga-news2@tigress.com> - 2020-02-17 11:29 +0100
                      Re: STM32FXX Flash Speicher weniger abnutzen Ulf.Kutzner@web.de - 2020-02-17 03:42 -0800
              Re: STM32FXX Flash Speicher weniger abnutzen Volker Bartheld <news2020@bartheld.net> - 2020-02-14 16:35 +0100
                Re: STM32FXX Flash Speicher weniger abnutzen Hanno Foest <hurga-news2@tigress.com> - 2020-02-14 17:16 +0100
                  Re: STM32FXX Flash Speicher weniger abnutzen Volker Bartheld <news2020@bartheld.net> - 2020-02-14 17:37 +0100
            Re: STM32FXX Flash Speicher weniger abnutzen Falk Willberg <faweglassenlk@falk-willberg.de> - 2020-02-16 21:40 +0100
      Re: STM32FXX Flash Speicher weniger abnutzen Helmut Schellong <rip@schellong.biz> - 2020-02-14 13:06 +0100
        Re: STM32FXX Flash Speicher weniger abnutzen Thorsten Böttcher <thorsten_nospam@gmx.net> - 2020-02-14 14:27 +0100
          Re: STM32FXX Flash Speicher weniger abnutzen Helmut Schellong <rip@schellong.biz> - 2020-02-14 17:46 +0100
    Re: STM32FXX Flash Speicher weniger abnutzen Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2020-02-14 13:53 +0100
    Re: STM32FXX Flash Speicher weniger abnutzen Ole Jansen <remove.this.kaspernasebaer@gmx.de> - 2020-02-17 18:10 +0100
      Re: STM32FXX Flash Speicher weniger abnutzen Thorsten Böttcher <thorsten_nospam@gmx.net> - 2020-02-18 07:19 +0100
        Re: STM32FXX Flash Speicher weniger abnutzen Ole Jansen <remove.this.kaspernasebaer@gmx.de> - 2020-02-18 07:53 +0100
          Re: STM32FXX Flash Speicher weniger abnutzen Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2020-02-18 09:11 +0100
            Re: STM32FXX Flash Speicher weniger abnutzen Ole Jansen <remove.this.kaspernasebaer@gmx.de> - 2020-02-18 14:22 +0100
              Re: STM32FXX Flash Speicher weniger abnutzen Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2020-02-18 18:15 +0100

Page 2 of 2 — ← Prev page 1 [2]

#275709

Am Montag, 17. Februar 2020 11:29:05 UTC+1 debilierte Hanno Foest:
 
> -- 
> Nie irgendwas […]

[toc] | [prev] | [next] | [standalone]

#275511

On Fri, 14 Feb 2020 14:23:27 +0100, Hanno Foest wrote:
> Am 14.02.20 um 13:45 schrieb Ole Jansen:
> [Tesla NAND Problem]
>> Dabei ist ihre Software neben der Marke das größte Asset von der Firma.
> Na ja, shit happens. Peinlich ist es jedenfalls.

Peinlich ist eine ganz andere Sache, nämlich der Umgang damit: '[...]
"Tesla has known about this issue for years now and has done nothing to
mitigate it. I've personally reported it on multiple occasions, and I know
others have as well. I've noted this to Tesla on several occasions,
starting in late 2015, and several times since." [...]', aka. jahrelang
die Beine stillhalten, dann - auf wachsenden Druck irgendwann
zähneknirschend innerhalb (und nur dann!) der Gewährleistungsfrist das
ganze Board austauschen, spezialisierte Firmen aussperren, die nur das BGA
tauschen könnten.

Und was wurde daraus gelernt? Einfach: "Instead of mitigating the issue, it
writes even more data to the logs today than ever before. Combined with
the max-size firmware images, general caching – map tiles, Autopilot info,
music, etc. – this makes every MCUv1 have a high probability of failure."
so Jason Hughes, einer derjenigen die das Problem offiziell lösen könnten,
aber nicht dürfen.

Also genau das, was man von solchen Unternehmen erwartet, in guter
Gesellschaft mit z. B. Apple. Ist den Fanboys aber egal, die haben ihr
lustiges Spielzeug und fertig.

Volker

[toc] | [prev] | [next] | [standalone]

#275514

Am 14.02.20 um 16:35 schrieb Volker Bartheld:

> Und was wurde daraus gelernt? Einfach: "Instead of mitigating the issue, it
> writes even more data to the logs today than ever before. Combined with
> the max-size firmware images, general caching – map tiles, Autopilot info,
> music, etc. – this makes every MCUv1 have a high probability of failure."
> so Jason Hughes, einer derjenigen die das Problem offiziell lösen könnten,
> aber nicht dürfen.

Finde ich insofern seltsam, als die Karren doch eh ständig online sind. 
Was muß man da so viel loggen?

> Also genau das, was man von solchen Unternehmen erwartet, in guter
> Gesellschaft mit z. B. Apple. Ist den Fanboys aber egal, die haben ihr
> lustiges Spielzeug und fertig.

Ich bin generell altmodisch und mag mir keine Geräte zulegen, über die 
jemand anderes die Kontrolle hat. Vgl. auch

https://www.golem.de/news/software-tesla-deaktiviert-autopilot-funktionen-bei-gebrauchtwagen-2002-146528.html

Hanno

-- 
Nie irgendwas von Ulf Kutzner glauben, insbesondere Zitate immer im
Original und Kontext nachlesen. Er versucht, durch Zitatefälschung
Strohmann-Argumente zu konstruieren.

[toc] | [prev] | [next] | [standalone]

#275517

On Fri, 14 Feb 2020 17:16:29 +0100, Hanno Foest wrote:
> Ich bin generell altmodisch und mag mir keine Geräte zulegen, über die 
> jemand anderes die Kontrolle hat. Vgl. auch
> https://www.golem.de/news/software-tesla-deaktiviert-autopilot-funktionen-bei-gebrauchtwagen-2002-146528.html

Ach was. Nichts gegen einzuwenden, wenn Du z. B. eine €€€ SD-Karte mit
WiFi-Funktionalität kaufst und dann gearscht bist, weil der Hersteller den
zwingend erforderlichen Onlinesupport einstellt *). Kannst ja das
Nachfolgemodell kaufen, von irgendwas müssen die schließlich auch leben.

Volker

*) https://www.diyphotography.net/eyefi-drop-support-cards-will-magically-stop-working-september-16-2016/
Ja, nee, es gab einen Shitstorm und EyeFi ist schließlich eingeknickt.
Vermutlich hatten sie ihre Gewährleistungsbedingungen nicht richtig
formuliert.

[toc] | [prev] | [next] | [standalone]

#275677

On 14.02.20 13:45, Ole Jansen wrote:
> Am 14.02.2020 um 10:30 schrieb Volker Bartheld:

...

> Ausserdem gibt es noch folgendes Problem: Wenn der Watchdog
> einen Reset auslöst verliere ich Ereignisse.

Wenn der WD auslöst, ist die FW sowieso kaputt^Wbuggy.

>>> Wenn ich die Firmware rausrechne hätte ich noch ca. 40k soda Flash
>>> Speicher die ich sinnlos kaputtrösten "darf". Sagen die Auditoren...
>>> Ich bin bei sowas aber aber Ästhet [...]

Sowas lese ich gerne. Außerdem ist das kaputtrösten von nKb Flash etwa
so schwierig, wie drei von zehn Spiegeleier in der gleichen Pfanne
anbrennen zu lassen.

>> Mich nervte es damals schon, als der Motorola-Microcontroller im
>> Concert/Chorus-Autoradio meines olympischen Alptraums vergeßlich wurde,
>> nur, weil irgendso ein Arsch bei Blaupunkt es eine gute Idee fand, jede
>> Eingabe sofort synchron aufs Flash zu schreiben, anstatt das erst im RAM
>> zu puffern und nur kurz vor dem Standby zu übertragen.

Die Firmware in meinem Auto wird auch vergesslich. Regelmäßig wenn ich
mich über OBD-II verbunden habe, geht irgendwann der Kühlerlüfter auf
kleinster Stufe an, was vollständig sinnlos ist.
Da hilft Ziehen und wieder Stecken der 200A-Sicherung der
Traktionsbatterie. Beim letzten Mal hat das Steuergerät dabei die
Parameter fürs Fahrpoti vergessen: Ich konnte zwar auf ~90% des Weges
unglaublich gefühlvoll verzögern aber auf den verbleibenden 10% nur in
groben Stufen und auch nur mit 50% des Maximums beschleunigen. Naja,
irgendwas ist ja immer ;-

> Dabei ist ihre Software neben der Marke das größte Asset von der Firma.
> Mit ihrer Hardware dürftem die kein Geld verdienen.

Das trifft auf Microsoft ebenso zu und ... ähem.... tja....

...

> Die sind nicht so schlimm wie beleidigte TESLA-Fanboys. Glaube ich...

Mein TESLA-Kollege ist als APPLE-Fanboy schlimmer ;-)

Falk

[toc] | [prev] | [next] | [standalone]

#275492

On 02/13/2020 20:43, Volker Bartheld wrote:

> In dem Fall rate ich dringend, den Flash nicht sinnlos kaputtzurösten,
> sondern die Zählerei im SRAM zu veranstalten und nur alle naslang genau
> die notwendigen Daten von SRAM in den Flash zu übertragen. Natürlich muß
> man sich das mit der Stromaufnahme und den Standbyzyklen genau überlegen
> und auch Vorkehrungen für den Brownout treffen, d. h. vielleicht einen
> Goldcap verwenden und mittels Betriebsspannungsüberwachung die Daten
> wegschreiben, bevor dem Chip der Saft ausgeht.

Ich habe lange mit AT45DB041D (atmel) gearbeitet.
Eines ist extrem wichtig:
Nach jedem Schreiben in eine Page muß unbedingt
pauschal ein 'AUTO PAGE REWRITE' gemacht werden.

Kollegen von mir machten das nicht.
Und beim Kunden haben nach wenigen Wochen alle diese
Flash-Speicher versagt und alle Anlagen blieben stehen.


-- 
Mit freundlichen Grüßen
Helmut Schellong   var@schellong.biz
www.schellong.de   www.schellong.com   www.schellong.biz
http://www.schellong.de/c.htm
http://www.schellong.de/htm/audio_proj.htm
http://www.schellong.de/htm/audio_unsinn.htm

[toc] | [prev] | [next] | [standalone]

#275502

Am 14.02.2020 um 13:06 schrieb Helmut Schellong:

> 
> Ich habe lange mit AT45DB041D (atmel) gearbeitet.

Ich auch, allerdings mit der großen Version, AT45DB641.
Der Baustein, bzw. der Nachfolger wird immer noch verbaut.

> Eines ist extrem wichtig:
> Nach jedem Schreiben in eine Page muß unbedingt
> pauschal ein 'AUTO PAGE REWRITE' gemacht werden.

Das steht aber so nicht im Datenblatt, und meine Erfahrung sagt das gleiche.
Wenn Daten in zufälliger Reihenfolge, in einem Sektor verteilt 
geschrieben werden, soll ca. alle 10000 page erase/programm Operationen 
ein Auto Page Rewrite ausgeführt werden. Beim aktuellen Baustein sind es 
sogar 50000.

> 
> Kollegen von mir machten das nicht.

Mache ich auch nicht.

> Und beim Kunden haben nach wenigen Wochen alle diese
> Flash-Speicher versagt und alle Anlagen blieben stehen.

Früher hab ich mitgezählt, und wenn die Zahl erreicht war, hab ich den 
Speicher beim Einschalten komplett aufgefrischt.
Mittlerweile lass ich das weg.
Datenverlust ist mir bis jetzt keiner gemeldet worden.
Und es kommen teilweise Geräte zur Überprüfung/Reparatur*, die älter als 
10 Jahre sind.

*Aus anderen Gründen, meistens mechanische Schäden.

[toc] | [prev] | [next] | [standalone]

#275518

On 02/14/2020 14:27, Thorsten Böttcher wrote:
> Am 14.02.2020 um 13:06 schrieb Helmut Schellong:
> 
>>
>> Ich habe lange mit AT45DB041D (atmel) gearbeitet.
> 
> Ich auch, allerdings mit der großen Version, AT45DB641.
> Der Baustein, bzw. der Nachfolger wird immer noch verbaut.
> 
>> Eines ist extrem wichtig:
>> Nach jedem Schreiben in eine Page muß unbedingt
>> pauschal ein 'AUTO PAGE REWRITE' gemacht werden.
> 
> Das steht aber so nicht im Datenblatt, und meine Erfahrung sagt das gleiche.
> Wenn Daten in zufälliger Reihenfolge, in einem Sektor verteilt geschrieben 
> werden, soll ca. alle 10000 page erase/programm Operationen ein Auto Page 
> Rewrite ausgeführt werden. Beim aktuellen Baustein sind es sogar 50000.

Die Interpretation meines Satzes paßt nicht.
Das heißt, ich hätte es mehrfach ausführlicher schreiben sollen,
damit es eindeutig verstanden wird.

Ich meine damit, daß eine Funktion eine Page aus dem Flash
in das RAM liest und ändert.
Nach dieser Page/Schleife wird das RAM in die Page kopiert
und pauschal 'AUTO PAGE REWRITE' durchgeführt.

Ich habe grundsätzlich dies Paar:
       FL_write(FL_CONFIG+pga, buf.b, _264);
       FL_rewrite(FL_CONFIG+pga, 1);
programmiert.

>> Kollegen von mir machten das nicht.
> 
> Mache ich auch nicht.
> 
>> Und beim Kunden haben nach wenigen Wochen alle diese
>> Flash-Speicher versagt und alle Anlagen blieben stehen.

Meine Kollegen hatten gar kein Rewrite programmiert.
Prompt kam es zur beschriebenen Katastrophe.

Nachdem sie es machten wie ich, war dies Problem weg.

> Früher hab ich mitgezählt, und wenn die Zahl erreicht war, hab ich den 
> Speicher beim Einschalten komplett aufgefrischt.

Das finde ich in meinem Kontext zu unsicher und zu aufwendig.

> Mittlerweile lass ich das weg.
> Datenverlust ist mir bis jetzt keiner gemeldet worden.
> Und es kommen teilweise Geräte zur Überprüfung/Reparatur*, die älter als 10 
> Jahre sind.
> 
> *Aus anderen Gründen, meistens mechanische Schäden.

Bei uns rächte sich die Unterlassung schnell.


Code-Beispiel:

void CopyDefaultsToCfg(void)
{
    CFG_t *sp;
    UNS pga, rpga, rest, adr, len;
    UNS const pgae= MU.anzcfgpg*_264;
    union { BYTE b[_264+OBJMAX*2]; UNS2 w[(_264+OBJMAX*2)/2]; } buf, rbuf;
    UNS2 n, z;

    memsetw(buf.w, 0xFFFFu, sizeof(buf.w)/2);
    for (pga=0;  pga<pgae;  pga=rpga?rpga:pga+_264)  {
       for (rpga=rest=0,sp=CFGdata;  sp->grp;  ++sp)  {
          adr= sp->adr;
          if (adr>=pga && adr<pga+_264)  {
            adr-=pga; len=sp->len; n=sp->nelem; z=0;
            do {
              if (sp->dfstr)
                    strncpyNF_F((z?rbuf.b:buf.b)+adr, sp->dfstr , len);
              else   memcpyNF_F((z?rbuf.b:buf.b)+adr, sp->dfmima, len);
              adr+=len;
              if (!z)  { //COPYTO(buf.b);
                if (adr>_264)  { z=1;
                  rpga=pga+_264; adr-=_264;
                  memsetw(rbuf.w, 0xFFFFu, sizeof(rbuf.w)/2);
                  memcpy_F(rbuf.b, buf.b+_264, adr);
                }
              }
              else  { //COPYTO(rbuf.b);
                if (adr>=_264)  {
                  WD_RESET;
                  FL_write(FL_CONFIG+rpga, rbuf.b, _264);
                  FL_rewrite(FL_CONFIG+rpga, 1);
                  rpga+=_264;
                  memsetw(rbuf.w, 0xFFFFu, _264/2);
                  if ((adr-=_264)>0)  memcpy_F(rbuf.b, rbuf.b+_264, adr);
                  memsetw(rbuf.b+_264, 0xFFFFu, (OBJMAX*2)/2);
                }
              }
            }
            while (--n);
            if (z)  rest=adr;
          }
       }
       WD_RESET;
       FL_write(FL_CONFIG+pga, buf.b, _264);
       FL_rewrite(FL_CONFIG+pga, 1);
       memsetw(buf.w, 0xFFFFu, sizeof(buf.w)/2);
       if (rest)  memcpy_F(buf.b, rbuf.b, rest);
    }
    return;
}


-- 
Mit freundlichen Grüßen
Helmut Schellong   var@schellong.biz
www.schellong.de   www.schellong.com   www.schellong.biz
http://www.schellong.de/c.htm
http://www.schellong.de/htm/audio_proj.htm
http://www.schellong.de/htm/audio_unsinn.htm

[toc] | [prev] | [next] | [standalone]

#275498

Am 12.02.2020 um 14:53 schrieb Ole Jansen:

> Kennt jemand den Chip oder die Funktionsweise des internen
> Flash etwas genauer oder hat einen anderen Tip?

Wie wäre es mit einer Uhr (RTC mit Batterie), und Speicherung des 
Zählers im CMOS RAM? Dann wird das Speichern nur durch die Lebensdauer 
der Batterie begrenzt.

DoDi

[toc] | [prev] | [next] | [standalone]

#275734

Am 12.02.2020 um 14:53 schrieb Ole Jansen:
> Moin,
> 
> Für deinen  STM32F107 Connectivity Line möchte ich einen nicht
> flüchtigen Ereigniszähler implementieren und das interne Flash Memory
> benutzen. Ich benötige lediglich eine Routine welche die Zahl der
> Ereignisse zurückgibt und eine Andere welche die Anzahl der Ereignisse
> um 1 erhöht.
> 
> Der Chip hat in seinem Flash Speicherseiten mit 2048 bytes die als
> Ganzes gelöscht werden können (danach sind alle bytes 0xFF) und die
> mitgelieferte Bibliothek verwendet fürs Schreiben einer Zelle
> jeweils ein word mit 2 byte.

Ingrid stellt Folgendes fest: Der Chip hat CRC für Flash hart
verdrahtet und erlaubt vermutlich nur seitenweises Löschen auf 0xFFFF
und 16bit weises Schreiben und fragt daher was in diesem Fall am
sinnvollsten wäre um de FLASH möglichst wenig abzunutzen bzw. einen
robusten Zähler zu erhalten. Folgende Ideen:

Annahme 1: Beim Erase nutzen sich gewechselte bits mehr ab als
ungewechselte. Es ist daher am günstigsten beim Schreiben eines 16 bit
Wortes immer nur ein bit zu wechseln und bei jedem Durchlauf
auf ein anderes bit umzuschalten.

Annahme 2: Annahme1 ist falsch, aber bei einem "verbrannten"
Flash kippen oft nicht ganze Worte sondern einzelne bits.
Es ist am günstigsten beim Schreiben immer alle bits zu schreiben,
d.h. das ganze Wort von 0xFFFF auf 0x0000 setzen und beim
Lesen z.B. allss !=0xFFFF als 0x0000 zu interpretieren oder
ähnlich.

Annahme 3: Alles egal. Nach Soundsovielen Erase Zyklen ist
es sowieso kaputt und kaputte Zellen sind komplett unbeschreibbar.
Es wäre am sinnvollsten Schreibfehler zu erkennen und ggf. automatisch
auf Reserveseiten umzuschalten.

Irgendwelche Ratschläge?

Viele Grüße,

O.J.

[toc] | [prev] | [next] | [standalone]

#275796

Am 17.02.2020 um 18:10 schrieb Ole Jansen:
> Am 12.02.2020 um 14:53 schrieb Ole Jansen:
>> Moin,
>>
>> Für deinen  STM32F107 Connectivity Line möchte ich einen nicht
>> flüchtigen Ereigniszähler implementieren und das interne Flash Memory
>> benutzen. Ich benötige lediglich eine Routine welche die Zahl der
>> Ereignisse zurückgibt und eine Andere welche die Anzahl der Ereignisse
>> um 1 erhöht.
>>
>> Der Chip hat in seinem Flash Speicherseiten mit 2048 bytes die als
>> Ganzes gelöscht werden können (danach sind alle bytes 0xFF) und die
>> mitgelieferte Bibliothek verwendet fürs Schreiben einer Zelle
>> jeweils ein word mit 2 byte.
> 
> Ingrid stellt Folgendes fest: Der Chip hat CRC für Flash hart
> verdrahtet und erlaubt vermutlich nur seitenweises Löschen auf 0xFFFF

Dass man das Flash nur Seitenweise löschen kann ist normal, und war IMHO 
schon bei den 8 Bit AVR so.
Mit CRC hat das nichts zu tun.

Snip

> Irgendwelche Ratschläge?

Bis wieviel willst Du denn zählen? Und wie schnell musst Du zählen?

Es gab so viele gute Lösungsmöglichkeiten hier.
Goldcap, Spannungserkennung und nur ab und zu schreiben, oder FRAM dran 
und quasi unbegrenzte Schreibzyklen.
Oder halt, wenn Du unbedingt nur den Prozessor benutzen willst, eine 
Flashseite nach der nächsten verheizen.

[toc] | [prev] | [next] | [standalone]

#275799

Am 18.02.2020 um 07:19 schrieb Thorsten Böttcher:
> Dass man das Flash nur Seitenweise löschen kann ist normal, und war IMHO 
> schon bei den 8 Bit AVR so.
> Mit CRC hat das nichts zu tun.

Das mit dem Löschen ist klar. Es ging um das Schreiben. Bei meinem
ST können keine FLASH Adressen überschrieben werden die nicht
0xFFFF sind. Das war mir am Anfang nicht ganz klar.

>> Irgendwelche Ratschläge?
> 
> Bis wieviel willst Du denn zählen? Und wie schnell musst Du zählen?

Bis etwa 4x10^8 mit max 70Hz.

> Es gab so viele gute Lösungsmöglichkeiten hier.
> Goldcap, Spannungserkennung und nur ab und zu schreiben, oder FRAM dran 
> und quasi unbegrenzte Schreibzyklen.

Ja, weiß ich.

> Oder halt, wenn Du unbedingt nur den Prozessor benutzen willst, eine 
> Flashseite nach der nächsten verheizen.

Präferiert wäre eine Softwarelösung die in ein ein vorhandenes Design
passt. Plan B ist der Ersatz durch einen anderen pinkompatiblen Chip.
Designänderung wäre Plan C. Bislang habe ich es geschaff den Code so
weit zu entschlacken dass im µC etwa 40k Flash zur freien Verfügung
wären.

O.J.

[toc] | [prev] | [next] | [standalone]

#275802

On Tue, 18 Feb 2020 07:53:09 +0100, Ole Jansen
<remove.this.kaspernasebaer@gmx.de> wrote:

>Präferiert wäre eine Softwarelösung die in ein ein vorhandenes Design
>passt. Plan B ist der Ersatz durch einen anderen pinkompatiblen Chip.
>Designänderung wäre Plan C. Bislang habe ich es geschaff den Code so
>weit zu entschlacken dass im µC etwa 40k Flash zur freien Verfügung
>wären.

Schmeiß den Softwaremist weg und bau sowas ein:

<https://de.wikipedia.org/wiki/Betriebsstundenz%C3%A4hler#Quecksilber-Coulometer>

(Nein, das mein ich nicht ernst, aber ich find die Dinger supercool. Nix dran,
nix drin, reset durch Umdrehen, gusseisern bis EMP-fest, ... Über die Auflösung
sag ich mal nix.)


Thomas Prufer

[toc] | [prev] | [next] | [standalone]

#275828

Am 18.02.2020 um 09:11 schrieb Thomas Prufer:
> Schmeiß den Softwaremist weg und bau sowas ein:
> 
> <https://de.wikipedia.org/wiki/Betriebsstundenz%C3%A4hler#Quecksilber-Coulometer>

Hihi, sowas hab ich noch neulich noch in einem alter Interferometer
gefunden. Betriebsstundenzähler für den HeNe-Laser. Gibts die auch
mit ROHS? <duck weg>

O.J.

[toc] | [prev] | [next] | [standalone]

#275837

On Tue, 18 Feb 2020 14:22:28 +0100, Ole Jansen
<remove.this.kaspernasebaer@gmx.de> wrote:

>Hihi, sowas hab ich noch neulich noch in einem alter Interferometer
>gefunden. Betriebsstundenzähler für den HeNe-Laser. Gibts die auch
>mit ROHS? <duck weg>
>
>O.J.

"Freilich ist das bleifrei."

<auch duckundweg>

Thomas Prufer

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | de.sci.electronics

csiph-web