Svenska ElektronikForumet

Det här är väl ett problem som det nog inte finns någon riktigt bra lösning på om inte det använda RTC-chippet har en brown-out-bit implementerad i hårdvara. Det har inte den nu aktuella i varje fall.

Om strömmen varit helt försvunnen, eller något gått riktigt fel, kan man ju detektera genom att läsa ett kontrollord ur ett oanvänt register och se om det har förväntat värde. Om spänningen däremot varit tveksam så är det allt annat än säkert att detta fungerar. Minnet brukar klara sig långt längre ner i spänning än vad som krävs för att oscillatorn skall stanna.

Hur brukar Ni hantera detta? Bara låta vara, eller finns det något bättre?

Byta RTC till något lämpligare kanske är en lösning.
Är det en färdig produkt som finns i massvis eller är ni i utvecklingsstadiet?

Det är inte min, utan ett färdigt bygge som skall göras program till.Allt är i princip klart utom just att hantera detta chip. Hade det varit min egen skulle det inte funnits där, då hade alternativen varit inget alls eller DCF/GPS. Nu finns det där och problemet skall helt enkelt lösas optimalt under givna förutsättningar, alla anda alternativ är ointressanta sidospår som jag inte vill lägga tid och energi på i det här läget.

Jag tror det lättaste är att låta det vara. Detta är ju egentligen inte ett mjukvaruproblem i huvudtaget.

Matas processorn och RTC kretsen från samma källa ?
D.v.s får de samma BO samtidigt ?
Kan du använda processorns BO-detection för att bestämma
om även RTC's är "suspekt" ? Om jag förstår rätt så är inga
ändringar av HW möjliga nu ?

Nej, den är givetvis batterimatad. Annars skulle den ju inte vara till någon nytta. Normalt så räknar klockan tiden från PIC's 20MHz oscillator som är möjlig att precisionskalibrera i mjukvara. Det är för att kunna klara strömavbrott som extrakretsen är där.

Allt går ju att ändra, men det är nog föga aktuellt. Den enda ändringen blir antagligen att skära loss reset-ingången från GND och permanent reset-läge för att koppla den som den skall vara. En bra förutsättning för att det skall fungera.

Min erfarenhet av RTC är att de vid P.O. har mycket slumpmässiga värden i minnet, att göra en kontroll av legal datum & tid är inte svårt, året kan t.ex. inte bli lägre än året då du gör programmet och det är osannolikt att enheten kör om 100 år...

Det gör väl knappast mera nytta än att skriva kontrollvärden i oanvända register? Mycket enklare att testa ett sådant kontrollvärde och se om det har förändrats. Fast klockan stannar så gott som alltid långt innan lagrad data försvinner. Detta gäller även klockans register, och då är det ju ett OK värde man läser där med.

Jo, det är ju sant men utan hårdvara-kontroll är det knappast något man kan göra något åt i mjukvaran.

Vid start av pic bör du:

läs in föregående klockas värde från pic EE
Spara nuvarande klockas värde i pic EE
läs in klockan nu.
Har klockan gått baklänges eller hoppat fram orealistiskt långt t.ex 10 år
så har det skitit sig.. annars bör klockan vara ok...
inte 100% men ett steg i rätt riktning..


swech

Ser inte hurdet skulle ge mera än att användaett kontrollord och se om detta förändrats.

Hur som helst visade det sig sitta enannan krets på kortet än först angivet, en som har hårdvarustöd för oscillatorstopp eller brown out. Därmed är denna fråga löst på ett så bra sätt man kan begära.

Bra!