Új hozzászólás Aktív témák

• #38948 atesss addikt azbest #38945

  Új Válasz 2020-08-06 12:37:25 #38948

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  atesss

  addikt

  válasz azbest #38945 üzenetére

  "A megjelenítés vagy kiírás pedig, ha oda helyi idő kell, akkor arra szokott lenni függvény, ami kiadja magából olyan, emberi fogyasztásra alkalmas formában."
  Akkor ezzel a függvénnyel az alapból UTC-ben kiolvasott TimeStamp-ot alakítsam át ?
  Most a konkrét esetben amúgy nem végeznék semmilyen műveletet vele, csak kiírnám a log-ba a már részletezett célokra.
  De amúgy arra jó lehet az UTC használata, hogy akkor ezt a megoldást szokom meg már most. És így írom meg a kezelő-függvényeimet, amit akkor később - amikor már tényleg kell is az UTC - egyszerűbben újra tudok hasznosítani/ ismét fel tudok használni.

  "Szóval nem azt mondod, hogy végeten ciklusban nézegeted az órát, hanem megmondod neki, hogy 1 másodpercenként történjen a végrehajtás és adott függvény végezze akkor el. "
  Igen, ez teljesen jogos.
  Annó Atmega-n használtam Timer Interruptokat. És nem a - HW-es működést elég komolyan elfedő - mostanában nagyon népszerű Arduino alatt, hanem a gyári IDE-vel (akkoriban még AVR Studio-nak hívták), közvetlen a regiszterek bitjeit címezve. Sőt, asszem még AVR-assembly alatt is használtam timereket.
  Viszont mivel úgy tudom hogy a Raspberry Pi ilyen szempontból elég gyenge ehhez képest, így első körben nem erőltettem a Timer Interruptot.
  (Lehet kivétel ha valami RealTime OS-t rakok fel rá, de ahogy sejtem az RTC hiánya miatt még az alatt sem lesz teljes értékű.)
  De persze nem lenne rossz, csak kérdés mennyire bonyolult használni. Illetve ezekre a feladatokra még oké lesz, ledet villogtatni, meg ADC-t átlagolni.
  De kicsit valamiért úgy érzem, hogy - bizonyos szempontból - hiába tanulnám meg. Mivel amit te írtál, hogy:
  ", de komolyabb feladatokra túl kell lépni ezeken."
  Az a sejtésem, hogy bizonyos komolyabb feladatokra, ahol pontosabb időzítés kell, oda meg mégsem lesz elég ez sem.

  "Az áramszünetre: az már egy teljesen más probléma és gondolom most sem tudod lekezelni. Oda már valami nyilvántartás kell (adatbázis), hogy mi történt meg és ha késik, akkor megtörténjen -e és ha igen, akkor mikor."
  Jó igen, ha olyan a feladat, hogy ez fontos, akkor ilyen eseteket tényleg csak így lehetne profin. De most erről azért nincs szó.
  Itt nem arról van szó, hogy az áramszünet befolyásolt-e valamit. Hanem szimplán csak arról, hogy az áramszünet okán a Raspberry órája kicsit elállítódott. És ha pont akkor áll vissza a pontos idő, amikor a scipten belül fut valamilyen, a rendszeridőt kalkulációnak használó függvény, akkor ezt a függvényt az óra-átállítás "eltérítheti".

  "Egyébként újraindulásnál érdemes azt is megnézned, hogy mikor történik az óra netes szinkronizációja. Hogy előtte elindul-e a szolgáltatásod."
  Igen, már a téma-indító hsz-emben is feltettem ezt a kérdést. Hogy hogyan lenne arról információm, hogy egy netes idő-szinkronizáció történt.
  cigam ötlete közvetlenül ezt nem oldja meg, mert azzal csak letiltani tudnám meg engedélyezni a funkciót. De arról nem lenne információm, hogy egy rendszerindulás után megtörtént-e a "kezdeti" szinkronizáció.

  "Egyébként systemd óta úgy emlékszem külön érdemes megadni a raspbianon, hogy várja meg a szolgáltatások indításával a netkapcsolatot."
  Egyrészt: az internet-csatlakozás, és a hálózati idő-szinkronizáció megtörténte nem feltétlenül esik egybe.
  Másrészt: azért ha esetleg nincsen net, attól még nem lenne rossz ha elindulna a scriptem.
  Vagyis akkor be kéne rakni ide egy plusz timeout-ot is, hogy ha nincs netkapcsolat x idő után sem, akkor viszont indítsa el a scriptet, ne várjon a végtelenségig.

Új hozzászólás Aktív témák