FLASH geheugen PIC beperkte levensduur?

Hallo,

In de datasheet van PIC18F4550 staat dat het FLASH geheugen 100 000 wis/schrijf cycli aankan.
Nu was ik aan het overwegen om de program memory te gebruiken om het programma frequent data in op te slaan en terug van te lezen. (Als buffer voor de coördinaten ontvangen door USB voor mijn CNC machine.)

Gaat dit dan op korte tijd onbruikbaar worden?

Dank,
Tom

Ik neem aan dat je het eeprom geheugen bedoelt? Geen idee hoeveel data je wilt opslaan maar met een beetje management kun je het aantal cycli verhogen door gebruik te maken van het volledige geheugen. M.a.w. Niet telkens op dezelfde locatie wegschrijven.

This is the world we know best, the world of madness

Nee, ik bedoel het flash programma geheugen.

Arco

Special Member

Flash is inderdaad meestal 100k (nieuwere pics zelfs 10k). Voor parameteropslag beter een losse eeprom nemen.
(of in het RAM van de processor opslaan als het toch maar tijdelijk is)

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com

Adviezen voor types van extern ram geheugen voor grotere opslag?

Gewoon in RAM schrijven.
Als de netspanning weggevallen is, de gegevens in RAM naar FLASH schrijven.
PIC voedt je met stevige condensatoren zodat na netspanningsuitval nog even tijd hebt om de boel in FLASH te zetten.

Maar probleem is dat ik meer geheugen nodig heb

Tidak Ada

Golden Member

Hoe dat bij SSD? Daar wordt continue gelezen en geschreven en staan gegevens opgeslagen die je niet kwijt wilt....

Andere oplossing voor PIC's en degelijke is het gebruik van een CF kaartje. Daar bestaan zelfs IDE kaartjes voor, zodat je ze snel en gemakkelijk kunt wisselen. Schijnt tegenwoordig ook met SD-kaartjes mogelijk te zijn. Maar ik dacht dat die laatsten minder schrijf- leescycli aan kunnen

Rommelige werkplek? In de natuur is wanorde de meest stabiele toestand; de entropie is dan maximaal. Het handhaven van "orde" kost daarom altijd energie. ----> TUBE COLLECTORS ASSOCIATION - †
Arco

Special Member

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com

Je kunt ook een microcontroller gebruiken met meer dan 2kB RAM.

@Arco: 96kB in een 8-bit PIC? Welke dan? De grootste die ik zo snel kan vinden bij Farnell heeft krap 4kB RAM. Een STM32F407, die goedkoper is dan die grootste PIC, heeft 192kB RAM.

Afgezien van het aantal erase cycles heeft flash nog wel meer nadelen; het wissen is traag, en bij de meeste controllers kun je geen code uit flash uitvoeren terwijl je daarmee bezig bent (maar ik ken de details van die PIC niet), wat meestal betekend dat je je code moet uitvoeren vanuit RAM.

Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken
Arco

Special Member

Grootste ram in een 8 bitter is 8k, meer als genoeg voor meeste programma's (ik heb het nog nooit vol gekregen)
Programma's in 8 bitters zijn meestal klein (beperkte flash) dus veel ram heb je ook niet nodig.
Een 18F4550 is trouwens niet de beste keuze, door beperkte ram/flash i.c.m. usb)

Een processor als de 24FJ256GB206 heeft 96kb ram...
Voor dataopslag in flash kun je ook een dual partition pic gebruiken. (1 partition voor data, andere voor de firmware. Beide 512kb)

PIC32 zijn er zelfs met 640kb ram...

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com

Op 9 december 2018 23:30:41 schreef Arco: PIC32 zijn er zelfs met 640kb ram...

Dat moet genoeg zijn voor iedereen ;-)

Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken

Op 9 december 2018 23:13:54 schreef SparkyGSX:
... STM32F407, ...

...[wissen]... en bij de meeste controllers kun je geen code uit flash uitvoeren terwijl je daarmee bezig bent ...

een uitzondering op die regel is bijvoorbeeld de STM32F407 . :-) Die heeft twee flash banks en je kan code uit de ene bank blijven uitvoeren terwijl je de andere bank aan het flashen bent.

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/
Kruimel

Golden Member

Op 9 december 2018 23:09:22 schreef Tidak Ada:
Hoe dat bij SSD? Daar wordt continue gelezen en geschreven en staan gegevens opgeslagen die je niet kwijt wilt...

Bij SSD's wordt een alogaritme gebruikt dat de geschreven data verspreid over de cellen die het minst gebruikt worden, de data staat dus niet op volgorde in het geheugen (wat Blackfin suggereert dus). In "echte" SSD's worden bij het uitvallen van cellen reservecellen ingezet, maar als deze 'wear levelling' goed werkt betekent het (versimpeld) dat je naar een SSD van 1TB met een schrijfduurzaamheid van 1000x dus 1PB moet schrijven om zo ver te komen, maar zo een schrijfregime is erg onnatuurlijk.

Op 9 december 2018 23:30:41 schreef Arco:
Een processor als de 24FJ256GB206 heeft 96kb ram...
Voor dataopslag in flash kun je ook een dual partition pic gebruiken. (1 partition voor data, andere voor de firmware. Beide 512kb)

PIC32 zijn er zelfs met 640kb ram...

Da's niet niets inderdaad. Anders een exerne I2C NVRAM of FRAM gebruiken? Ik kwam een aantal interessante chips tegen met deze zoekterm. Ik weet niet om hoeveel coördinaten het gaat, maar het klinkt alsof een relatief beperkte hoeveelheid RAM voldoende zou moeten zijn toch?

@Hieronder: inderdaad is een SRAM hier de aangewezen optie, als de coördinaten niet meer nodig zijn na een power-down.

Arco

Special Member

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com

F(e)RAM ook, en houdt data ook vast als voedingsspanning eraf is. Vaak wel duurder dan andere soorten geheugen (al dan niet extern).

Lijkt me handig als topic starter nog even aangeeft of het nodig is dat data een aan/uit cycle overleeft? Zo niet, is 'vergeetachtig' SRAM net zo acceptabel als flash, F(e)RAM of ander soort NVRAM geheugen. En hoeveel ruimte daadwerkelijk nodig is.

Je kunt ook slim met je flash omgaan.

STEL dat je iedere seconde 3 coordinaten wil opslaan. Kies de schaling zodanig dat je max-waarde 65534 is, dan past het in 16 bits.

Stel ik heb een STM32F072RB met 128k flash.

Dan zou je die 48 bits gewoon ergens in flash kunnen dumpen en iedere keer overschrijven. Met een max levensduur van 10000 cycles, ben je na een uur of drie er doorheen.

Maar stel nu dat ik 32k geheugen reserveer. En ik schrijf gewoon steeds achter mekaar door steeds 6 bytes iedere seconde. Dan duurt het anderhalf uur voordat ik de 32k vol heb. Tijdens het opstarten moet je dan wel vanaf het eind op zoek naar de "laatst geheel beschreven record". Binair zoeken kan best, dus je hebt in een stap of 13 het meest recente record gevonden.
Nu duurt het anderhalf uur voordat ik door m'n 32k heen ben. En dus bijna 2 jaar volcontinue aan voordat ik door de 10000 cycles heen ben. 20 jaar als je flash niet 10k maar 100k haalt.

Nu moet je wel zorgen dat de coordinatencombinatie "0xffff, 0xffff 0xffff" niet voorkomt. Door in alle drie de assen voor deze uitzonderingswaarde te zorgen, kan je ook de laatste GELDIGE waarde vinden, voor als de boel uitgaat terwijl je aan het schrijven bent. 0x1234, 0x3456, 0xffff is dan dus een "niet affe schrijf actie, gebruik de vorige".

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/
Kruimel

Golden Member

Eigenlijk precies wat Blackfin zegt dus? :)

Maar 'truth be told', de TS zou misschien wat meer informatie moeten geven over de daadwerkelijke hoeveelheid data, schrijffrequentie en snelheidsvereisten.

Op 11 december 2018 12:31:40 schreef rew:
Dan zou je die 48 bits gewoon ergens in flash kunnen dumpen en iedere keer overschrijven.

Gaat niet helemaal op voor de STM32.
Het is slechts 1x mogelijk om een plek in het flash geheugen te schrijven.
Wil je hem nog een keer schrijven moet je de gehele page wissen.
Wil je dus een waarde wegschrijven in flash zal deze steeds op een nieuwe plek worden weggeschreven. Is de pagina vol, dan worden de waardes gekopieerd naar een nieuwe pagina en wordt de oude gewist, etc..
Hierdoor heb je eigenlijk al automatisch dat er aan wearlevel wordt gedaan.

bprosman

Golden Member

Waarom zou je dit ueerhaupt in Flash (code memory) willen doen, volgens mij is het daar ook helemaal niet voor gemaakt.
Arco's serial SRAM suggestie (met een battery backup) lijkt me meer ideaal.
Of een Ramtron (tegenwoordig Cypress) FRAM'metje in I2C, 10 Miljard write cycles.

http://www.cypress.com/products/f-ram-nonvolatile-ferroelectric-ram

[Bericht gewijzigd door bprosman op dinsdag 11 december 2018 15:19:52 (11%)

De jongere generatie loopt veel te vaak zijn PIC achterna.
Arco

Special Member

Batterij backup is bij iets als een CNC waarschijnlijk niet eens nodig...
Die FRAM is interessant, maar de prijs is wel even slikken... (23 euro...)

[Bericht gewijzigd door Arco op dinsdag 11 december 2018 15:50:44 (34%)

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com
Tidak Ada

Golden Member

Doet me denken aan bubbel memory. Dat was nog duurder.

Rommelige werkplek? In de natuur is wanorde de meest stabiele toestand; de entropie is dan maximaal. Het handhaven van "orde" kost daarom altijd energie. ----> TUBE COLLECTORS ASSOCIATION - †
bprosman

Golden Member

Die FRAM is interessant, maar de prijs is wel even slikken... (23 euro...)

Per writecycle een koopje :+

De jongere generatie loopt veel te vaak zijn PIC achterna.

Op 11 december 2018 14:05:26 schreef 2N3055:
[...]
Gaat niet helemaal op voor de STM32.
Het is slechts 1x mogelijk om een plek in het flash geheugen te schrijven.
Wil je hem nog een keer schrijven moet je de gehele page wissen.

Klopt. Maar IK gebruik op de STM32 een stuk flash voor het opslaan van de parameters. Omdat ik niet verwacht dat dit meer dan "een paar keer" gebeurt, heb ik verder geen aandacht aan "wear leveling" gegeven. Ik heb gewoon "struct config { int mode; char name[32]; int configured_pins[16];}; " en dan als er geschreven wordt, dan wis ik de hele pagina en schrijf sizeof (struct config) bytes naar het begin van die pagina. Een naieve implementatie voor de "steeds veranderende" data zou dat ook kunnen doen. Met de juiste "handige" functies is het gewoon "write_to_flash (&config, sizeof (struct config));", en het "wissen van de hele pagina" is iets wat de write-to-flash functie gewoon intern ergens doet. Merk ik niets meer van: Ik heb dat ding jaren geleden geschreven en het werkt prima.

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/

als je de buffer wilt gebruiken voor GCODE voor een CNC, dan adviseer ik toch echt (s)RAM.

ik heb een 3D printer met een ATMega (denk een paar KB ram) en deze heeft per laag een paar keer de buffer ververst. dus een print van 100 lagen is honderden keer de buffer overnieuw vullen.

dan lijkt me flashgeheugen geen meerwaarde, zeker omdat het om tijdelijke gegevens gaan (als je na powerfail door wilt starten kun je evt battery backup plaatsen.)

GMT+1