PIC16 minne som överlever strömavbrott.

[dangraf]

Många av de pic-kretsar jag använt har en HLVD (high low voltage detect tror jag det står för) som i princip en en koparator som kollar ifall spänningen är över eller under den referens-spänning som man ställer in.
I det läget så skulle man kunna koppla HLVD pinnen till den externa spännings-matningen. När spänningen försvninner där så kanske man har några millisekunder på sig innan kondensatorerna har laddats ur så att även matningen till pic-processorn börjar sjunka. I det läget så borde det vara ganska safe att spara undan värden i eepromet.

Det går ju att göra väldgit strömsnåla applikationer till en pic beroende på vad den ska göra. lägger man processorn i sleep kan den dra ca 4-5uA och vakna var 10ms och göra ett arbete på 0.5ms. I de fallet så får man ner strömförbrukningen väldigt mycket jämfört med att aldrig lägga processorn i sleep. Jag har byggt ett brandlarm till en pic 16f88 som klarade sig ca 3-4 år på ett vanligt 9v batteri. Men den applikationen var ganska speciell. Det jag försöker säga är att det skulle kanske kunna gå att köra enbart på batteri och byta det 1 gång om året eller liknande..

[Swech]

Vad är det du vill spara då?
Varför vill du spara?
Ge oss mer info om vad du försöker uppnå så får du fler relevanta svar
Oftast så har man viktiga parametrar i EEprom minnet förutsatt att man inte
uppdaterar dem flera 10.000 - 100.000 gånger

Ta som exempel en volymkontroll... digital.. kan man spara i EE varje gång man justerar den
Den kommer sannorlikt att "överleva" produkten utan att slita ut EE minnet

Swech

[choppertony]

tanken att med pic och en display och en bunke knappar ställa och nolla en del utgångar. Man skall se texten i displayn, med en bock framför för de utgångar som är satta. Om strömmen försvinner och kommer tillbaka så skall man i FRAM minnet kunna läsa av vilka utgångar som var satta . och sen sätta dem igen och få rät text i displayen med rätt bockar.

[Nerre]

Då behöver du alltså bara skriva varje gång du trycker på en knapp. Hur många gånger på ett dygn ändrar du inställningen? Och hur många är det?

Om det t.ex. är 8 stycken är det bara en byte du behöver hinna spara vid strömavbrott, det funkar nog med nåt interrupt-knep. 16 blir två bytes.

[TomasL]

Det är ju bara att öagra det i interna eepromet, sannolikheten att det skall inträffa ett strömavbrott i samma millisekund du trycker på en knapp är väl obefintlig.
Det är ju bara att skriva till promet när du trycker på knappen, när du bootar efter en reset läser du eepromet och ställer utgångarna.

[choppertony]

Det skall oxå hålla reda på var i ett program som strömavbrottet skedde Programmet skall starta där igen. Så det blir en del flaggor som skall sättas och nollas under tiden programmet körs..... ungufär som återstart av en industrirobot. Den kan inte gå närmsta vägen till första punkten i programmet om den startar om.Då river den med utrustingen oxå *L*... Den måste fortsätta där den var när strömmen gick.

[danielr112]

Frågan är om ditt program behöver göra det?

Ska den hela tiden ändra på nåt? Programmet som jag förstod ska bara ändra saker när du trycker på knapparna?

Dvs dör strömmen startar den om från scratch. Den läser minnet. Finns där nåt av värde så läses de in och den ställer in allt.
Finns inget ställer den in default istället.

Eller är det så att ditt program hela tiden ska köra någon slags slinga och den slingan för inte startas om från punkt 1?

[limpan4all]

Med E2PROM behövs roterande buffrar samt dubbelskrivning av värdena med t.ex CRC för kontrollen, om inte CRC stämmer så kraschade det under skrivning och man använder det gamla värdet.
Att gå på ett defaultvärde är bara ett tecken på dålig och amatörmässig programmering.

[danielr112]

limpan4all. varför skulle det vara amatörmässigt att ha ett defaultvärde? Det har ju de flesta apparaterna när du kör hardreset...

[limpan4all]

Självklart skall man ha defaultvärden, men dom skall bara gälla tills något värde sätts för första gången, inte användas som fallskärm efter det att verkligheten har knackat på.
OM sen en användare anser att han har ställt till det och vill återställa defaultvärden så är det en helt annan sak, oftast så vill användare bara återställa det som han KAN ändra och har ändrat till helt fel värden (det ligger vanligen lagrade värden som INTE skall ändras och som ställts in på fabrik också).

Om man som programmerare VILL att värdet skall finnas kvar efter ett oväntat spänningsfrånslag och man genom att inte gardera sig mot att spänningsfrånslaget faktiskt kan komma under skrivning och man därmed förstör alla sina parametrar (vanligen ligger minnet som block på 256 byte som raderas i sin helhet) om man då "tvingas" att återställa alla parametrar till defaultvärden så är det bara en konsekvens av dålig programmering.
Han som skriver kod till mina projekt (och jag förstås) anser att man skall ha alla sina parametrar i tre (fem för kritiska projekt) block med 16bit CRC, majoritetsbeslut gäller om vad som är korrekt information efter uppstart. Självklart så roterar använda block i E2PROMET så att alla block används lika mycket. Bootrutinen avgör vad som är gällande block (inkrementellt ökande och löpande serienummer) i blockstruktur och vad som är korrekta parametrar efter en omstart.

Detta gäller förstås när man har väsentliga parametrar blandat med obetydliga parametrar.
Om man egentligen inte bryr sig så finns det ju ingen som helst anledning att ha E2PROM alls, då blir det ju alltid defaultparametrar.

Så min åsikt är följande - anser man att man behöver ha E2PROM så skall det lagras på ett idiotsäkert sätt, annars så kan man gott strunta i E2PROM och alltid använda defaultvärden.

Att kalibreringsvärde, en MAC adress eller en fast IP adress ändrades till defaultvärden för att E2PROMET skrevs till under spänningsfrånslag är inte god programmering.

Sen så kan man ju göra det hela mera avancerat förstås, lägg alla "oföränderliga data i FLASH" resterande i E2PROM. Men som sagt om man anser att ett skrivfel får generera defaultdata så kan man lika gärna strunta i E2PROM helt, kunden kommer ändå att bli skitsne den enda gången det sket sig och inte alls tycka att "det händer så sällan så det behöver vi inte planera för"...

Fundera över vad du skulle tycka om en matningsspänningsglitch just när du uppdaterar BIOS på ditt MB. Detta genererar en massa strul, numera så har alla seriösa MB tillverkare dubblerat BIOS av just den anledningen (det händer kanske 1 gång på 1000, inte oftare, men anses såsom helt nödvändigt att dubblera).

[limpan4all]

Jag tror för övrigt att vi lägger ned dubbelt så mycket tid på att diskutera möjliga felfal och hur varje enskilt felfall skall hanteras som på funktionen som skall göra själva jobbet.
Koden för att hantera felfall och användarinterface är vanligen minst dubbelt så stor som koden för att göra själva jobbet och den lär vara minst tre gånger så tråkig att skriva och tio gånger så tråkig att testa (alla felfall skall skapas och verifieras att dom hanteras korrekt).

[Swech]

Det låter istället som att du skall sätta en supercap på t.ex. 0.47F (inte uf utan just 0.47 Farad)
på din 5V nätdel. (alldeles vid din matning av processorn och endast mata processorn)
Sen skall du detektera om matningen försvinner, gå ned i sleep läge
och vakna upp igen då strömmen återkommer. Med en supercap så håller du liv i systemet i > 30 minuter.

Vid någon annan lösning så är det svårt att förvänta sig att systemet skall kunna skriva allt som behövs till EE och även kunna starta upp där programmet abvbröts.

Swech

[Nerre]

Det skall oxå hålla reda på var i ett program som strömavbrottet skedde Programmet skall starta där igen.

Men om det nu är en mikroprocessor som kör så löper den igenom sitter program på bråkdelen av en sekund (1 Mhz klocka, 1 instruktion per klockcykel och 2 kB program ger 2 ms för att köra igenom programmet.

Med andra ord har du en masa fördröjningar eller? Eller väntar du på externa signaler för att stega igenom en viss sekvens? Kan du då inte använda dessa externa signaler för att avgöra var i sekvensen du är?

Ska man aldrig kunna stänga av eller starta om programmet? Vad händer om programmet hänger sig eller buggar ur, hur ska en ny uppstart ske då? Du kan inte förutsätta att programmet kommer att snurra hela tiden efter att du har startat det.

[choppertony]

Det får bli ett FRAM minne. Det är kanske inte det enklaste sättet. Men på resans gång lär man sig en del matnyttigt. Att kunna skriva o läsa till ett externt minne är nog en mycket bra grej att lära sig. Förr eller senare så måste man lära sig det ändå.

Lösningar som håller programmet igång eller i sleep 30 minuter är oxå bra tills man får ett avbrott som varar längre.

Någon som vet hur det är med stegmotor....? Får man ett värde vart motorn är när den startas upp, eller måste den gå till ett hemmaläge? Vad för slags värde får man? är det bara en puls eller någon binärt värde? Om det är pulser så kanske man kan spara ett uppräknat antal pulser i ett FRAM så man vet vart man håller hus när man startar om igen?

De säljer ngn liten stegmotor på Kjell o Company men där finns inget datablad att hämta på deras sida så jag har inte kunnat läsa mig till det själv.

[danielr112]

Du kan ju alltid låta motorn gå till sitt ändläge och sedan tillbaka igen för att mäta av vart den stod...