Zatížení arduina a generování času

[daton]

Ne není ted mi to došlo je spojena se shieldem W5100 a tedy se s ním nepřímo ovládá.

[Dex]

Netuším, jak držíte čas interně v Arduinu, každopádně např. http://playground.arduino.cc/Code/Time možná odpoví na Vaše otázky. Jinak "unix time" je v podstatě standard - viz např. https://en.wikipedia.org/wiki/Unix_time

Existují i jiné cesty i když asi nejsou tak elegantní. Třeba Adafruit dělá modul kde je GPS a RTC (https://www.adafruit.com/products/746). Čas se bere z GPS takže je dostatečně přesný. Vy se na něj jen občas zeptáte RTC obvodu. Každá legrace ale něco stojí

[fulda]

Podle toho co tu čtu tak odhaduji, že je ledka L ovládaná zhruba tak, že pokud je IDLE tak svítí a pokud se něco děje na ethernetu, tak je zhasnutá.

[daton]

No čas generuji celkem primitivně pomocí funkce delay

Kód: Vybrat vše

  vterin ++;  // přičtem další vteřinu

  if (vterin == 60){  // pokud je vteřin 60
  vterin = 0;   // vynulujem vteřiny
  minut ++;     // přičtem minutu
  }

  if (minut == 60){ // pokud je minut 60
  minut = 0;  // vynulujem minuty
  hodin ++;   // přičtem hodinu
  }
  
  if (hodin == 24){ // pokud je hodin 24
  hodin = 0; // vynulujem hodiny
  dni ++;    // prictem den
  }

  // počká vteřinu
  delay(1000);

Tak že synchronizace se serverem z netu by byla super ale nejsem si jist že bych to zvládal synchronizovat s takto jednoduše generovaným časem.

[Dex]

Mno já bych na to šel jinak Například bych si pořídil nějaký RTC modul na I2C, z něj četl čas když je k něčemu potřeba a třeba jednou za den bych ten RTC obvod seřídil přes NTP. Arduino by pak mělo více času na jiné věci, navíc bych tím vyřešil i datum.

[daton]

Dobře chápu že modul by nebyl špatný ale jen hypoteticky bylo by možné synchronizovat ten můj jednoduchý kod s NTP? Napadá mne že bych mohl vždy třeba o pulnoci přepsat aktuální výpis ze smyčky programu a znovu začít počítat.
Ten modul mám dokonce koupený ale ted se mi jeví možnost přes internet mnohem lepšé a když by se to každý den aktualizovalo pak by se tím mohl měnit i datum.

[Dex]

Určitě by to šlo nějak naroubovat, ale nelíbí se mi tam ten "delay". To je takové hrozné plýtvání navíc vše ostatní určitě netrvá vždy přesně stejnou dobu aby se to dalo rozumně kompenzovat. Takovéto hodiny tedy myslím musí už z principu ujíždět. Záleží na zbytku kódu o kolik (možná to nehraje roli), ale když RTC modul stojí necelé dva dolary...

[daton]

No to je pravda ten kod není zrovna mojí nejlepší napsanou věcí. Určitě bych to změnil mám už dávno doma modul Tiny RTC I2C modules s baterkou. Chtěl jsem ho tam implementovat ale nějak k tomu nedošlo i vzhledem k tomu že ten kod jakž takž chodil ale pokud by se to dalo zlepšt tak to zkusím. Zapojoval jste už někdo tento modul? Asi hloupá otázka ale raději se zeptám jak se vám to dařilo.

[daton]

Je to d1307 AT24C32 Real Time Clock Modul .

[DavidO]

Jak jsem naznačil dříve, to s tím delay(1000) se nutně bude zpožďovat. Teď tedy vysvětlím: delay(1000) sice počká na tom místě 1000ms=1s, ale mezi dvěma aktualizacemi uběhne čas nejen ta vteřina, ale navíc tolik, co trval výpočet aktualizace a všeho ostatního, co se dělá v té smyčce.
I bez RTC to jde udělat líp (ale i docela dost přesně), náznakem asi takhle:

Kód: Vybrat vše

unsigned long cas;
unsigned long minulycas=millis();
unsigned celevteriny;
void loop() {
// tady může být libovolný kód, který dělá cokoli co je potřeba a trvá klidně i dlouho. A může tam být i skoro libovolně dlouhé čekání
spike.send(); //yes, it's that easy.
delay (234); 

// a ted aktualizace času:
cas=millis(); // zeptáme se systému, kolik je hodin, teda milisekund od startu systému.
if(cas-minulycas>1000) // a protože v minulycas držíme něco jako čas minulé kontroly, tady to projde, až bude aspoň o vteřinu víc, než minule
{
  vterin += (cas-minulycas)/1000; // přičteme celý počet vteřin od minula (to dělení je celočíselné)
  minulycas %= 1000; // posuneme minulý čas o celé vteřiny (resp. necháme tam jen ty necelé pomocí operace "modulo")
  
  if(vterin > 60) {
    minut += vterin/60; // přičteme celý počet minut
    vterin %= 60; // a zbylé vteřiny necháme na příště
  }
  // atd.
}

Trik je v tom, že tam není pevné čekání ale jen kontrola, jestli náhodou už není víc jak vteřinu po minulé aktualizaci. Pokud ano, tak si hodiny zaktualizujeme o tolik celých vteřin, kolik jich uteklo od minula a zbytek (tu necelou vteřinu) necháme na příště. Podobně u minut, kdybychom snad náhodou testovali až za fakt dlouho, že by uteklo víc minut jak jedna. U hodin a dní by to puristicky mělo být taky tak, ale ... na to se asi můžeme vyignorovat.
Takhle to bude ukazovat čas skoro tak dobře, jak dobře tomu tiká krystal. Kdyby to co se dělá před aktualizací času (to posílání spajku) trvalo vždycky třeba tři a třetinu vteřiny, no tak se budou hodiny aktualizovat jen jednou za tři a čtvrt a kousíček vteřiny (ten kousíček trvá ta aktualizace), ale vždycky se zaktualizujou na správný čas. A ta třetina se tam po každém třetím průchodu projeví jak má a skočí to né o tři, ale o čtyři vteřiny.

Má to jeden skrytý problém, po cca 50 dnech se stane něco divného. Aby to čtenář neměl úplně zadara, nechám na něm, ať si najde, co, proč a jak to vyřešit