Hva vil skje?

det kan hende det ikke består paritetskontroll. så å laste opp kode ville ikke være mulig.

Når det er sagt, har jeg aldri hatt en flashbasert mcu-feil på grunn av utholdenhet. det er utallige mcus siden så vidt jeg kan huske.

for å gi deg litt følelse av designhøyde, skrev jeg til og så tilbakelevering fra eeprom på et bilde over flere timer @ 10ms per lese / skrive , uten feil. at eeprom er rangert som 1 M i utholdenhet.

så med mindre du får noen rare deler eller du skriver til det gjentatte ganger over lang tid, er det sannsynlig at flashfeil ikke er et praktisk problem.

Denne Wikipedia-artikkelen om Flash-minne diskuterer feilmekanismer, inkludert referanser til relevante artikler. Et poeng som overrasket meg var "Les forstyrrelse" av tilstøtende celler etter et stort antall (> 100.000) avlesninger fra en celle siden siste sletting, noe som fikk den tilstøtende cellen (e) til å lese feil feil. Det er sannsynligvis mer der og i de refererte artiklene enn du noen gang ønsket å vite om Flash-feilmekanismer.

Imidlertid ...

Ved 5 minutter per test tar 10000 tester deg 35 dager jobber døgnet rundt eller over 100 dager @ 8 timer / dag, og opprettholder den hastigheten på testing. Poenget mitt er at du sannsynligvis ikke når 10K-sykluser. Men hvis du er bekymret for å sette en kraftig brukt brikke i feltet (og det kan også være, i noen tilfeller), vil det være verdt å bruke stikkontakt nr. 1.

Selv om det ikke er et direkte svar på spørsmålet ditt, kan det være et svar på problemet ditt (behovet for å gjøre intensiv prøving og feiling.

Sannsynligvis tester du for det meste programmet ditt (endringer) , og ikke maskinvaren din (endringer). Siden jeg ikke antar at du bytter maskinvare (breadboard) hvert 5. minutt.

Hvis programmet er ganske komplisert, vil det sannsynligvis være best å skrive en spesifikk offline testprogram, og kjør det på en datamaskin i stedet for en Arduino. Du må sannsynligvis stoppe noen klasser / biblioteker du bruker, men det kan spare deg for mye tid. Også har du fordelen med en bedre IDE og mange flere feilsøkingsmuligheter. Etter at testene på testprogrammet for offline er bestått, prøver du det på Arduino.

På denne måten trenger du sannsynligvis å laste opp programmet bare noen få ganger om dagen på Arduino.

AFAIK produsenten sier at antall skrivesykluser er garantert. Vanligvis er brikken i stand til å tåle litt mer (for at produsenten skal være sikker på å opprettholde garantien), kan enkelte sjetonger tilfeldigvis tåle mye, mye mer.

Også feilen kan resultere i to typer problemer - først er det bedre på en måte - skrivingen mislykkes bare, etter å lese returnerer "noe" (vanligvis en del av den skrevne verdien, men noen biter er alltid satt til samme 0/1). Den andre er at bruk gjør skrivingen upålitelig - du skriver den, du leser den er ok, men etter en stund (som dager / måneder) endres innholdet, og hvis du leser det igjen, vil du få "noe "som i forrige tilfelle.

Det ville være bedre å sørge for at du er i stand til å bytte brikken, før du går til" normal bruk "og legger den fersk - bruk en stikkontakt / opprett et nytt kort / uløsemiddel gammel brikke og lodde ny. Bruk den slitte brikken for mer testing / utvikling, men bruk en fersk med bare noen få sykluser med refleks. Programvareemulatorer kan også øke hastigheten på utviklingen din og redusere behovet for / antall reflekterende brikker på brettet.

Forutsatt at du ikke trenger å finjustere hvert brett individuelt, bare ikke send brettet som du gjør testingen / justeringen til "feltet" ..... hold det internt, og bruk bare nye tavler for feltbruk.