Köszönöm ezt a felvetést is. Nem biztos, hogy most, de alkalmasint ezt is ki fogom próbálni. Egyelőre a sargarigo fórumtárs által megadott kódot próbálom majd ki, és igyekszem megérteni.
De Neked is hálásan köszönöm, hogy ennyit foglalkoztál a felvetésemmel!

Előre bocsájtom, hogy sargarigo megoldása a legjobb szerintem. Ha csak lehetséges érdemes az állapotgépes megoldást használni.

De létezik egy másik megközelítés is, ami adott esetekben ésszerűbb lehet. A többszálúság. Meg lehet valósítani ATMega328-on is többszálúságot. A legszükebb a memória: minden szálnak külön stack-e kell hogy legyen, ráadásul minden stack-re egy teljes állapotmentés el kell hogy férjen, ami ATMega328-on 33 bájt. De még így is a 2KB SRAM-ba beleférhet akár 32 szál is - függően attól, hogy mekkora stack kell és mennyi egyéb objektumunk van.

Olyan esetekben érdemes ilyet használni, amikor az állapotgépes megvalósítás sokkalta bonyolultabb, mint a folyamat direkt leírása. Én template alapú webszervert akartam csinálni ezzel a megoldással Controllino-ra. Végül nem készült el, mert rájöttem, hogy felesleges az egész: bináris protokollt kell inkább csinálni, és a router-en kell webszervert futtatni, ott legalább egyből tudunk SSL-t is futtatni. Persze az sem készült el még .

A félkész de működő kódot fetettem ide:

Használat: https://github.com/rizsi/Arduino-IR-decoder/blob/master/libraries/m...main.c
Megvalósítás: https://github.com/rizsi/Arduino-IR-decoder/blob/master/libraries/m...ng.cpp

(A példaprogramban a hash számítás teljesen feleslegesen van ott, illetve a késleltetés CPU ciklusok alapján multithreading környezetben teljesen rossz. A delay a real time-ot kérdezgeti, azzal pontosan lehetne időzíteni. A koncepció működik, azt demonstrálja a példa.)

Üdv!

Időt (óra, perc) szeretnék küldeni ESP-nek JSON formátumban(valamint lehet, hogy vissza is). Mivel az idő 60-as osztású nem 10-es ezért egyszerűbb külön tárolni mint szorozni osztogatni. Szeretném összefűzni, majd az ESP-n szétszedni. Egymagában ugye nagyon incs értelme mert elküdhetném külön-külön is, de lehet, hogy 7 időérték lesz, valamint egy Nextion kijelzőre is el szeretném küldeni, és még EEPROM-ba(flash) is szeretném menteni. Még átgondolom, csak ötlet szintjén van, de ha át szeretném alakítani, hogy célszerű összeraknom, hogy a szétválasztás egyszerű legyen? Nem vagyok otthon a string és egyéb átalakító függvényekben, kell-e valami elválasztó karakter vagy csak számoljam a karaktereket? Hogy a legjobb összerakni?

A perc maximális értéke 59 lehet, ami elfér 6 biten. Az óra maximális értéke 23, ami elfér 5 biten. Ez összesen 11 bit, sehogy nem fér el egy bájtban. Célszerű egyszerűen két bájtot használni. Az egyik tartalmazza az órát, a másik a percet. Nem is nagyon kell összerakni-szétválasztani. Ha jól értem a kérdést.

Elismerésem!

Nem is tudok eléggé hálás lenni ezért a kódért!
Kipróbáltam, a "szájam ízére szabtam", és egyszerűen tökéletes lett! Jövök Neked eggyel.

Nem a tömörítés a lényeg, hanem az egyszerű kezelhetőség. Olyasmire gondoltam, hogy stringbe összerakni vesszővel(ezt még nem tudom hogy szedem szét), vagy az órát megszorzom 100-al és hozzáadom a percet(ezt könnyű szétszedni ellentétes művelettel), stb. Mondjuk lehet, hogy nem egyszerűbb összerakni szétszedni, mint külön-külön kezelgetni mindhárom felületen.

Szivesen, használd egészséggel!

Nincs ebben semmi tömörítés. Ha az órát szorzod 100-zal, majd hozzáadod a percet, akkor a legnagyobb szám 2359 lesz, ez sem fér el egy bájtban. Ennek is van egyébként értelme, leginkább akkor, ha adott időpontban akarsz kapcsolni. Ha a kapcsolási időt és a pontos időt így tárolod, akkor csak egy összehasonlítás kell, egy művelettel megoldható, nem kell külön az órát és külön a percet összehasonlítani. Vagy, ami még egyszerűbb, Integer változó, a felső bájt az óra, az alsó a perc.

Ha külön küldöd (és kezeled) az órát és külön a percet, nincs mit szétszedni a vevő oldalon, a küldő oldalon nem kell összerakni. Egyszerű kommunikációkban (UART, SPI, I2C, OneWire) egyébként is bájtonként jön-megy az adat.

Adatforgalom nem számít. A tcp meg a Nextion sebessége is elbírja bőven ha több byte is legyen. A 30+ adat mellet még elfér. Csak gondoltam, hátha meg tudom oldani, hogy timerenként ne 2 hanem csak 1 adattal kelljen foglalkoznom. Egyébként visszafelé számláló lesz, a pontos időre nincs szükségem. Közben nagyjából már körvonalazódott, ahogy átgondoltam mi hogy kezeli az adatokat, bár még agyalok rajta. Szerintem a beviteltől a megjelenítésig külön kezelem majd. Megjelenítést az android esetében az androidon fűzöm össze, Nextion esetében meg már összefűzve küldöm el neki a hátralevő időt a kettősponttal.

Az ilyen feladatokat általában úgy oldom meg, hogy felhasználok néhány változót:
unsigned long last_millis, period.
A last_millis tárolja azt az időt, amikor utoljára lefutott a program. A period tárolja azt, hogy milyen sűrűn fusson le a függvény.
A függvény folyamatosan meg van hívva, az első sora pedig egy feltétel: if (last_millis+period<millis()) , ha ez igaz, akkor eltelt a period idő (ha valami megakasztja a loop-ot, akkor sokkal több idő is eltelhet, mint period, de a következő lehetséges időben le fog a függvény futni!). Egy kis "késés" lehet a fv. futásában (minimális), de ha amikor lefut, ezt használjuk: last_millis+=period, akkor a késés nem fogja megzavarni az egész időzítést, és összességében jól fog működni a rendszer. Egyébként itt nagyon pici késésekre kell gondolni, ami pl. egy LCD frissítésénél vagy LED villogtatásnál észrevehetetlen. Főleg, ha pl. valamit csak fix időnként akarunk kiszámolni, hát nem teljesen mindegy, hogy 200 vagy 200.05ms-ként fut-e le az a programrész?
Ezzel a megoldással annyi egymástól teljesen független függvényt lehet ismétlődően, fix időközönként futtatni, amennyit csak akarunk. Minden fv-hez kell két változó.

Mivel egy óra csak 60 percből áll, elég 60-al szorozni. A lényegen mondjuk ez sem változtat, mert a teljes nap 1440 percből áll ami ugyanúgy nem írható le egy bájton.

100-al szorozva órát és percet hozzáadva "beszédesebb" és nem kell külön 60as számrendszert használni az átváltáshoz

Lehet úgy is de akárhogyan trükközünk, két bájt kell. Akkor inkább egy Integer, a felső bájtban az óra, az alsóban a perc. Összehasonlításhoz ez is bőven jó, az esetleges műveletek (AND, OR, léptetés) gyorsan elvégezhetőek .

Az a kérdés, hogy az időponttal mit akar csinálni. Ha számolni is szeretne vele (pl. két időpont között eltelt időt), akkor célszerűbb 60-al szorozni. Ha meg csak megjeleníteni, akkor meg minek kellene szorozni, elég 1 bájtban elküldeni az órát, egy másikban meg a percet.

Időzítő. Beütöm mennyi idő(-k) múlva kapcsolja ki az eszközt(-öket), elindítom és visszaszámlál. Közben megjeleníti egy Nextion-on hol tart, valamint ha megnyitom az android appot akkor abban is látom mennyi a hátralevő idő(-k). Mint írtam az egyben kezelés volt a cél. Van 7 aktuális hőmérséklet értékem, 7 megcélzott hőmérséklet értékem, 7 kapcsoló állapotom, 7 triack állapotom, plusz 5-6 hozzátartozó állapot értékem. Gondoltam (7 timer esetében) hátha 14 időérték helyett megúszom 7-el. Ennyi lett volna a lényege. Viszont:
-Ha 60-al szorzom akkor kevesebb adat, könnyű kezelni a számlálót, viszont a megjelenítéshez újra alakítani kell.
-Ha 100-al szorzom az órát és hozzáadom a percet, mutatósabb, de ez nem vizuális adat tehát lényegtelen, viszont számláláshoz és kijelzéshez is alakítani.
-Ha külön kezelem akkor egy kis plusz az egész óra váltásakor, kijelzéshez csak össze kell fűznöm, cserébe több adat oda-vissza. Azt hiszem ez a kevesebb macera. Maradok ennél.

Szerk: Ezek csak az oda-vissza szaladgáló adatok. Ettől sokkal több változó van

Ne használd a string.h-t. Egyszerűen használj három (elég 1 is) kételemű char tömböt. Pl. char Ora[2] ,char Perc[2] Masodperc is hasonlóan.

Ezeket a char tömböket egésszé alakíthatod amikor számolni kell velük. Kijelzéskor valami ilyesmi:

Print ora[1] & ora[2] & ':'....Stb.


Char array to integer:

https://forum.arduino.cc/index.php?topic=44151.0

Az atoi() lesz majd a barátod. El kellene gondolkodni azon, hogyan lehet char-ból byte, mert az óra, perc stb. tárolásához elég a byte is.

Ha az adatok meg egy előre definiált hosszú karakterláncként kapod meg, akkor egyszerűen feltöltöd ezeket...
ha a bejovo pl '12:03:16' <--- Azaz a bejövő adat a bejovo[] tömbbe tárolódik.

Ora[0]=bejovo[0]
Ora[1]=bejovo[1]

Perc[0]=bejovo[3]
Perc[1]=bejovo[4]

De mi lenne, ha a küldés fogadás egyszerűen 3 byte írás olvasás ide oda adagolásával oldódik meg, a kiíratáskor csak a formátumot adod meg?

Hmm végülis lehet minden percben is 60as szorzo + percek hozzá adva.
A szétválasztást végezheti a 60al való maradékos/maradéktalan osztások.
Habár a 100-al is meg lehet csinálni ugyan ezt.

És 256-tal is, 2 byte pedig mindenképp kell...

Igen, kb. hasonló mentén indultam el én is. A gondot az okozta, hogy az egyes ciklusoknak eltérő számban, és egymástól függetlenül kellett lefutniuk. Ez kavart be, meg az, hogy az egyes (többszörös) villanások között változó hosszúságú "szünetnek" kellett lennie. Sargarigo fórumtárs megoldása ezt teljes mértékben kiküszöbölte, igaz, cserébe jelenősen bonyolultabb lett a kód. Viszont abszolute használható, és teljes mértékben "testre szabható". (Ezért sem győzök elég hálásnak lenni érte!)

Sziasztok! Még mindig keresem a kérdésben feltett mintaprogramot! Ha valaki tudna valamit javasolni azt megköszönném.

Ha tudott volna valaki, akkor már mondott volna.
A datasheet-et ha megnézed (9.2 Typical Application), akkor ott vegyes konfigban szerepel. Ugyanakkor az i2c cím utolsó bitje adja meg, hogy épp írod vagy olvasod-e az eszközt, és ha jól láttam akkor vagy az összes 8 bitet írod, vagy az 9sszes 8-at olvasod. Valahogy nyilván körbe lehet dolgozni, de én nem bohóckodnék ezzel, simán használnék 2 ilyet más-más címmel. Egy 200 Ft-os cuccról beszélünk...

Aki keres, talál.

Köszönöm. Én nem találtam.

Wow, nem rossz. Ezt a PCF libet majd jól megnézem, mert a datasheet-et baromira nem értettem, pedig többször is megnéztem.

Én most vadászom a lib-jét, sajnos a leírásban nem találtam.

Ahogy elnézem, ha 1-et írsz a kimenetre, és utána olvasod, akkor ki / bemenet ha meg nullát akkor egy nulla szintű kimenet. Ha a kimenetre 1 szintet küldesz, az nem egy terhelhető szint lesz, egy cmos bemenetet elég lesz felhúzni, de többet nem tud. Így ha kívülről egy fix szintet kényszerítesz rá, akkor azt fogod visszaolvasni, és nem terheled az IC-t sem vele. (hasonló az OC kimenethez egy plusz felhúzó áramgenerátorral ellenállás helyett.) Ha így van, GND-hez képest rákötött led sem fog világítani róla, hiába állítod magasra a kimenetet.

Nekem is ez jött le. Érdekes egy IC, csak egy regisztere van, ettől butább már nem is lehetne.

Hát, nem egy meghajtó IC. Gondolom az egyszerűség volt a lényeg. Akinek teljesítmény kell nyilván nem ezt fogja használni.

Szerintem ez: Bővebben: Link

Viszont ahogy látom, ez i2c-n keresztül egyben írja a 8 bitet, szóval izé...