Szia,

Nem látom ennek értelmét így. Egy szál 328p-vel megoldható ez a feladat, az idő 99,9%-ában úgyis csak a változásfigyelés pörög. Ha nincs túlhúzva, az i2c és az spi is megy egymással gond nélkül, ha valaki nem akar egyidőben mindent megoldani. De itt a másodperc töredéke alatt futnak le a teljes adatküldések, így nincs jelentősége, ad abszurdum, másodperces frissítést is lehetne csinálni (nem lehet, mert a kijelző lassú).
Ha képes lenne rá (keretrendszer hiányosság) én elküldeném deep sleep-be, oszt jónapot. Az einknek úgysem kell felügyelet.

Amit én csinálnék:

-- RTC kezelés. Minden adatot ki, manipulálás mindenféle formában, eredmények soros vonalon ki. Addig, amíg úgy nem fut, ahogy nekünk a legjobb.

-- eink kezelés. Ismert formátumú adatok kiküldése először kötött formátumban, utána változó adatként (léptetés, switch/case stb.), a végső feladat, hogy az rtc-ből kijövő formátum (nem a konkrét adat) menjen ki rá úgy, ahogy azt elképzeltük.
-- eink második menet: frissítési gyakoriság változtatása állapotgéppel (gombnyomásra, fényerőre, eltelt időre, stb.). 

-- kódoptimalizálás olyaténképpen, hogy az adott modul egy függvényben legyen, ha szükséges, paraméterhívással. Így is teszt.

-- aztán mehet az összegyúrás. A loop csak figyel, mint a korábbi példában is, állapotgépként, a többit csinálják a függvények.

 

Amíg egy modulteszt nem 100%-os az összes szóba jöhető állapotra, addig kell ütni, amíg nem lesz az. Utána lehet esetleg optimalizálni (de nem muszáj). A "majd megoldjuk a teljesben" NEM megoldás.

És verziótörténet végig, nyilván.

 

Ami az Arduino-t illeti. Pontosan, nem több, nem kevesebb. Csak ugye mindenki azzal kezd, hogy holdmodult, okosházat és motorszabályozó elektronikát akar építeni belőle. Pedig ezekre így pont teljesen alkalmatlan.

 

Üdv,

 

Prof