Epoch med mikrokontroller?

[blueint]

Har funderat lite på en mer seriös väckarklocka. Och kommer fram till att jag vill då använda unix epoch. Dvs antal sekunder sedan 1970 Jan 1, 00:00.00 UTC.
Denna konverterar man till lokal tid genom att använda localtime().

Fördelar:
* Vinter/Sommartids justering sköts automatiskt.
* Endast ett deterministiskt 32-bits nummer behöver skickas för att ställa klockan.
* Den interna klockan kan bestå av en 32-bits räknare rakt av.
* Alarmtider kan specifieras kompakt med en 32-bit per tidpunkt. Eller t.ex kl 8 endast på tisdagar.
* Alarmtid 5 veckor framöver varje fredag kl 10 för att sedan raderas.
* Jämförelser av 32-bits nummer bör vara effektivt för även en 8-bit mikrokontroller.

Nackdelar:
* Komplexitet vid programmeringen, som man har igen senare.

Att tidskonvertering är komplext inses när man vet att skottår är beroende på ifall årtalet är jämnt delbart med 4, men inte 100, utom om 400. Samt att tidszon offset varierar med land, årtal, och vinter/sommartid. Och där datum för vinter- och sommartids växling varierar beroende på land och årtal dessutom. Samt att vissa regeringar saknar förmåga att bestämma sig..
Sedan ska man då få fatt på årtal utifrån epoch för att få reda på om det är ett skottår. Och för det behöver man egentligen årtalet från början.. Samt att antal dagar per år varierar med skottår och att skottårsdagen i februari har flyttats (24 till 29).

Frågan är då om det finns något färdigt? som är förutan en massa beroenden och hiskeliga kodstorlekar. Allmänna tankar om konvertering är också intressanta. Inget är skrivet i sten ännu..

[Icecap]

Århundrade kan väl kvitta? Det är aktuellt nästa gång om runt 90 år och jag tror faktisk inte att din klocka fungerar så pass länge.

Rent omedelbart tycker jag att det verkar ganska "overdone" med epoch men du kanske har en idé jag inte förstår.

[TomasL]

En realtidsklockkrets är väl enklast, eller en uC med inbyggd sådan (pic32)

[sodjan]

Eller en separat I2C ansluten RTC.

> eller en uC med inbyggd sådan (pic32)

Finns även "mindre" i alla fall i PIC24 serien...

[Icecap]

Och larmtider osv. framåt i tiden är knappast ett problem att klara, använda och radera.
Vill man packa lite kan en komplett datum/tid packas till 32 bit:
År: 6 bit + året i år (2010) ger alla år mellan 2010 och 2073, borde räcka.
Månad: 4 bit
Datum: 5 bit
Timme: 5 bit
Minut: 6 bit
Sekund: 6 bit

Alltså samma storlek men delat upp i yyyy-mm-dd hh:mm:ss.

Och ja, jag har faktisk gjort detta i praktiken, faktisk har jag en C-fil som kan ge en massa svar rörande datum/tid:
* Är (yyyy-mm-dd hh:mm:ss >/=/< yyyy-mm-dd hh:mm:ss)?
* Är (yyyy-mm-dd hh:mm:ss) ett legal datum?
* Är (yyyy) skottår?
* Vilken veckodag är (yyyy-mm-dd hh:mm:ss)?

Och den kan enkelt expanderas till att kompensera för tidzon.

Inte att det är fel att använda en 32-bit räknare, den är t.ex. otroligt enkel att kompensera för tidzon men likaväl är omräkningen till datum/tid ganska intressant då datum inte är helt enkelt, det hade ju varit mycket enklare om det hade varit samma antal dagar/månad, inget skottår osv. men nu är det inte så tyvärr.

[blueint]

Skulle nog försöka använda så enkel mikrokontroller som möjligt. Då det påverkar backuptid osv.

Den funktion man behöver ifall man använder yymmdd-hhmmss som räknarformat är ju att den slår över korrekt. Då det är olika längd på månader, år osv. Samt klarar att visa 2010-10-31 01:59 två gånger utan att fastna t.ex

När man går från sommartid till vintertid och ska dra ifrån en timme kl 02:00 men endast göra det en gång blir det lätt klurigt. Dessutom ska det ske "sista söndagen i oktober". Otrivialt att formulera programmeringsmässigt.

[vfr]

Jag har börjat använda denna tid mer och mer. Den är mycket enklare att jobba med i allt som inte berör månader. Det är bättre att ha ett enkelt format i mikrokontrollern och sedan göra omräkningarna till text vid presentationen i PC:n. Eller tvärtom för inmatade tider. För t.ex logghändelser är den ypperlig.

Skall man ha med hantering av sommartid, så är det mycket bättre att ha systemtiden i UTC (GMT) utan sommartid och sedan räkna om till lokal tid vid behov. Detta funkar alltid med rätt parametrar för start på sommartid och slut på sommartid. Tvärtom så finns det däremot en osäkerhetsfaktor just i övergången mellan sommartid/normaltid. Om din lokala tid säger någonting mellan kl 2 & kl 3 under övergångnatten (den förlängda natten) så vet du inte om det är den första timmen mellan 2 & 3 eller den andra. Om man däremot utgår från UTC så är det aldrig några problem att räkna ut rätt lokal tid.

[PeSve]

Realtidsklockan i STM32 verkar passa perfekt för detta tycker jag.

Se följande länk, sid 60-61 om du kollar numreringen längst ner på sidorna.
http://www.st.com/files/mcu/1221142709.pdf

Där har du dina 32 bitar som kan räknas upp varje sekund, och även ett alarm-register.

[Swech]

"Dessutom ska det ske "sista söndagen i oktober". Otrivialt att formulera programmeringsmässigt"

Det är väl busenkelt.
En tabell med sista söndagarna framåt i tiden nästföljande 20-30 år.
Samma sak med skottår, det är väl inte värre än att köra en tabell på max 100 år om man nu
tror att klockan klarar sig i 100 år.


Swech

[blueint]

Gillar väl algoritmer över statiska tabeller..

[toffie]

Alltså, det är väl bara att slänga in en liten DS1337?
http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3128

Sommar/Vintertid pratas det om här
http://www.edaboard.com/ftopic190411.html

[blueint]

Kan rapportera att jag i princip löst alla problem
Att beräkna "sista söndagen i månaden" är klurigt, men går om man använder lite smart matte.

[Icecap]

Nja... räkna ut veckodagen för sista dagen i månaden är ju enkelt, sedan är det bara att subtrahera lite...

Kod: Markera allt

const unsigned char _WEEK_Days_In_Month[13] = {0,31,28,31,30,31,30,31,31,30,31,30,31};
enum {Year_Out_Of_Range = 0x80,Month_Out_Of_Range,Date_Out_Of_Range};

unsigned char Day_Of_Week(unsigned int year,unsigned char month,unsigned char date)
  { /* 1=Monday, 2=tuesday etc. as the ISO runs like that */
  int Result;
  Result = Invalid_Date(year,month,date);
  if(Result) return(Result);
  if(month < 3)
    {
    month += 10;
    year--;
    }
  else month -= 2;
  Result = 2 + (((((26 * (int) month - 2) / 10) + (int) date + (year % 100) + ((year % 100) / 4) + ((year / 100) / 4) - (2 * (year / 100))) + 4));
  while(Result < 0) Result += 7;
  Result %= 7;
  Result++; /* Make it go 1-7 in stead of 0-6 */
  return(Result);
  }

int Is_Leapyear(unsigned int year)
  {
  return(!((year % 100) & 3) && ((year % 100) || !((year / 100) & 3)));
  }

unsigned char Invalid_Date(unsigned int year,unsigned char month,unsigned char date)
  {
  if((year  < 1753) || (year  > 9999)) return(Year_Out_Of_Range);
  if((month <    1) || (month >   12)) return(Month_Out_Of_Range);
  if((date  <    1) || (date  > (_WEEK_Days_In_Month[month] + ((month == 2) && Is_Leapyear(year)))))
    return(Date_Out_Of_Range);
  return(0);
  }

[blueint]

Löste veckodagsproblemet genom att använda antal dagar sedan 1970 till det aktuella året. Lägga till antal dagar till sista dagen i Mars eller Oktober och addera +4. Sedan tar man modulo 7 på det. Och drar ifrån detta från antalet dagar från 1 januari.
Så har man tidpunkten på året för vinter/sommartidsbyte.

Läste och räknade lite på skottårsdagen (skippar /100 och /400 faktorerna). För att det ska gå jämnt upp med skottårsdagen så behövs det att varje dag är 59,14 sekunder för kort. Fast om man skulle vänta till skottårsdagen för att korrigera det skulle det bli helgalet. Så därför lägger man in små extra sekunder lite då och då
Konsekvensen av det är ju att lokala klockor går "fel" ganska snabbt..

Sen blir tydligen dagarna 54,76 ns längre för varje dag (2 ms/100 år)
(Mer solsken åt folket)

[sodjan]

> Sen blir tydligen dagarna 54,76 ns längre för varje dag (2 ms/100 år)
> (Mer solsken åt folket)

Är det inte dygnet som blir längre ?
Alltså inte mer solsken till folket...