Hur nöts minnet i en PIC, är det per cell eller per krets som antal erase/write anges?
I de kretsar där man kan radera valfritt avsnitt så skulle det ju i så fall löna sig att då och då byta ställe som programmet läggs på för att inte flasha om samma område massor av gånger medan det meta av minnet inte alls används..
Flashminnens nötning i PIC?
100k ypiskt och 10k minimum står det. 100k är nog svårt att komma upp i, men 10 är knappast en omöjlighet. Flashar man den 28 gånger om dagen är 10k passerat inom ett år. Nåväl, det är ju väldigt extremt att göra så.
Vid högre temperatur sjunker antalet flashningar. Menas det med detta att kretsen slutar fungera när det är varmt även om den flashats vid rumstemperatur, eller menar de att flashning vid hög temperatur nöter hårdare?
Vid högre temperatur sjunker antalet flashningar. Menas det med detta att kretsen slutar fungera när det är varmt även om den flashats vid rumstemperatur, eller menar de att flashning vid hög temperatur nöter hårdare?
Grejen är att laddningen/urladdningen styrs vid programmering/radering och vid högre temperaturer och många cykler kan det bli fel så att en radering inte raderar eller en programmering inte programmerar.
Så det är per krets som parametern anger eller rättare: om du programmerar blockar är det per block men då startadressen är den samma ska man göra en ganska klurig programmering för att inte belasta den block ganska mycket vilket gör att det inte är lönt.
Om kretsen faktisk är programmerat & verifierat OK bör den fungera OK, verifieringen utförs ju såklart under "worst case"-villkor som sig bör vid produktionsprogrammering.
10K minimum betyder att de garanterar att du kan byta program 10K gg och når man det antal under utvecklingen kan man nog kosta på sig en ny krets då. Såklart kan det vara M$ som uppdaterar i vanlig ordning och då kan man ju relativt snabbt komma dit men jag har inte för mig att de gör mjukvara till PIC.
100K typisk betyder alltså att det flesta kretsar (>70%?) kan omprogrammeras så många gånger.
EEPROM-delen av minnet brukar tåla många fler R/W innan det är dags att "friska upp" minnet.
Men jag förstår inte riktigt anledningen till frågan; skriver du 20 versioner per dag och håller på 5 dagar i veckan lär det ta minst 23 månader innan det är dags att byta kretsen ut och typisk 19 år innan den uppvisar fel, sitter du då fast i samma träsk kan det kanske vara på sin plats att sampla en ny krets med "lite uppdateringar" i eller hur?
Om det är för att du sparar data i kretsen och har problem med antalet skrivningar är det nog lämpligt att kolla på FRAM-versionerna av EEPROM, de har numera unlimited antal skrivningar.....
Så det är per krets som parametern anger eller rättare: om du programmerar blockar är det per block men då startadressen är den samma ska man göra en ganska klurig programmering för att inte belasta den block ganska mycket vilket gör att det inte är lönt.
Om kretsen faktisk är programmerat & verifierat OK bör den fungera OK, verifieringen utförs ju såklart under "worst case"-villkor som sig bör vid produktionsprogrammering.
10K minimum betyder att de garanterar att du kan byta program 10K gg och når man det antal under utvecklingen kan man nog kosta på sig en ny krets då. Såklart kan det vara M$ som uppdaterar i vanlig ordning och då kan man ju relativt snabbt komma dit men jag har inte för mig att de gör mjukvara till PIC.
100K typisk betyder alltså att det flesta kretsar (>70%?) kan omprogrammeras så många gånger.
EEPROM-delen av minnet brukar tåla många fler R/W innan det är dags att "friska upp" minnet.
Men jag förstår inte riktigt anledningen till frågan; skriver du 20 versioner per dag och håller på 5 dagar i veckan lär det ta minst 23 månader innan det är dags att byta kretsen ut och typisk 19 år innan den uppvisar fel, sitter du då fast i samma träsk kan det kanske vara på sin plats att sampla en ny krets med "lite uppdateringar" i eller hur?
Om det är för att du sparar data i kretsen och har problem med antalet skrivningar är det nog lämpligt att kolla på FRAM-versionerna av EEPROM, de har numera unlimited antal skrivningar.....
Jovisst. Jag gjorde ett projekt på mitt tidigare jobb där vi sparade statistik i en flash-bank som var ledig. Men varje skrivning i på varandra följande lokationer var ju bara 1 skriv/radera cykel, vi samlade alltså ihop data som man senare tömde ur och raderade.
För varje tömning + radering var det ju att räkna som 1 cyklus, med 10K blir det MÅNGA resor till Stockholm innan man får byta krets.
Så att skriva 1 byte (eller word beroende på) är en "halv" cykel för den byte(/word), det är inte 1 cykel för varje byte(/word).
För varje tömning + radering var det ju att räkna som 1 cyklus, med 10K blir det MÅNGA resor till Stockholm innan man får byta krets.
Så att skriva 1 byte (eller word beroende på) är en "halv" cykel för den byte(/word), det är inte 1 cykel för varje byte(/word).
Det är endast programlagring det gäller. Ibland är det som att svart magi är inblandad och det behövs många omflashningar med speciell felsökningskod för att hitta var trollet gömmer sig. Förr när det var flerchipsdator med RAM så gällde ju oändligt antal omprogrammeringar, men flash håller ju länge det också. Det är nog mest känslan det hänger på.
Angående test vid olika spännngar och sådant är det lite svårt när den programmeras in-circuit. Där är det alltid 5.0V (ibland 5.12V för att få lätthanterligare AD-avläsningar) som gäller.
Angående test vid olika spännngar och sådant är det lite svårt när den programmeras in-circuit. Där är det alltid 5.0V (ibland 5.12V för att få lätthanterligare AD-avläsningar) som gäller.
Jag minns inte helt på rak arm, men det kan vara "J" modellerna (3.3V)
eller något liknande. 1000 om-flashningar "typical" om jag inte minns fel.
EDIT :
Jag skulle varken kalla det "skräp" eller anse att det i sig är
en anledning att undvika dom. Det är bara något man bör veta.
Hur som helst, undet *utveckling* så kan man ju alltid kör till det "tar slut".
Sedan använder man en ny för den färdiga applikationen. Inget stort problem...
eller något liknande. 1000 om-flashningar "typical" om jag inte minns fel.
EDIT :
Jag skulle varken kalla det "skräp" eller anse att det i sig är
en anledning att undvika dom. Det är bara något man bör veta.
Hur som helst, undet *utveckling* så kan man ju alltid kör till det "tar slut".
Sedan använder man en ny för den färdiga applikationen. Inget stort problem...
Det stämde, i varje fall på den "J" jag tittade på. Minimum 100 och typiskt 1k.
De är väl inte skit när de används för produktion, men för en amatör är det nog allt i minsta laget. En 100-dubbling av förbrukningen är ingen "finess" jag känner något större behov av.
Vad är det för attraktiv egenskap som framtvingar att göra dem så "svaga"? Det kan ju knappast vara ett självändamål.
De är väl inte skit när de används för produktion, men för en amatör är det nog allt i minsta laget. En 100-dubbling av förbrukningen är ingen "finess" jag känner något större behov av.
Vad är det för attraktiv egenskap som framtvingar att göra dem så "svaga"? Det kan ju knappast vara ett självändamål.
