Én ezt úgy oldanám meg, hogy a kapcsolt adja a tápot az egésznek. Mikor megy a ventillátor a pára tartalom fuggvényében , akkor biztosít magának egy öntartást az állandó tápról arra az esetre ha közben a villanyt lekapcsolnák. Ezt bontaná két perc után.

Esetleg egy fényérzékeny alkatrésszel meg lehetne oldani a világítás figyelését ... Talán kevesebb alkatrész ( pl egy foto tranzisztor + ellenállás), és nem kell 230V-al bajlódni.

Nem tudjuk mennyit akarsz rá költeni, de kb egy Ardunio europai árától joval olcsobban készen kapni pl egy CS3-16 idözitö kapcsolot, ami szinte mindent tud amit akarsz, csak a páraérzékelést kell megoldani. A google egy csomo találatot dob ki a CS3-16-ra. Nálam egy ilyen, igaz más célokra már 12 éve gond nélkül müködik.

Helló!

Tudtok mutatni olyan projektet, amiben Attiny24/44/84 a CPU és SPI vezetéken ST7735 a kijelző?
Hiába írom be ezt a két paramétert, valahogy mindig csak arduinot talál a kijelzővel,
vagy attinyt I2C kijelzővel...

Esetleg ezzel a libbel valakinek volt már dolga? Azt írja, kb 15x gyorsabb mint az arduino shiftOut().
Sajna az example -jében nincs ST7735 kijelzős példa.

Szerintem azért nincsen ilyen példa, mert egy teljes képernyő még monokrómban is 2560 bájt a felbontás miatt (ha jól számoltam). Tehát azt nem tudod megcsinálni, hogy memóriában előkészíted a képet és kiteszed, hanem közvetlenül rajta kell rajzolni. Az meg bonyolultabb szerintem.

Az ATTiny program memóriája is nagyon kicsi. Csináltam egy betű rajzoló libet, abban is majdnem 2kB csak a betűk képe: https://github.com/rizsi/playing_with_MCUs/blob/master/libraries/ri...ters.h Tehát beférne az ATTiny24-be, de nem maradna sok hely a programnak. A nagyobbakba befér simán. Tehát nem lehetetlen megvalósítani a rajzolást ezekkel, de nem is egyszerű. A kishiftelés lesz a legkisebb gondod.

Ránéztem a könyvtárra is: szerintem koncepcionálisan hülyeség letiltani az interruptokat küldés közben, mert az SPI-nek pont az a lényege, hogy a küldő határozza meg az órajelet, nincs szükségünk rá, hogy fixen tartsuk. Ha interruptos dolgot is használsz, akkor zavaró lehet ez a letiltogatás.

Éppen ezért a szoftveres kishiftelés is teljesen jó megoldás, és közben végig bekapcsolva lehetnek az interruptok. A libben SPI írás közben le vannak tiltva az interruptok és "kézzel" lökögeti tovább a clockot, ebből következően pontosan annyira lesz gyors, mintha szoftveres kishiftelést csinált volna. Persze csak akkor lenne ugyanilyen gyors a szoftveres SPI master, ha low level írja meg, nem digitalWrite-tal, hanem a PORTA/PORTB adott bitjét állítgatva. Úgyhogy én nem ezt a könyvtárat használnám, felesleges.

Erre csak ránéztem, de sokkal értelmesebbnek tűnik: https://github.com/tessel/avr-usi-spi/blob/master/spi_via_usi_driver.c

Még jómagam sem tudom, mivel lenne érdemes. Annyit tudok, hogy van fiókban Attiny44, és avval akarnék összekalapálni egy egyszerű feszültségszint jelzőt. A kijelzés egy színes akku piktogram lenne, ami a töltöttségi szinttel arányosan merül, és változik a színe kb úgy, mint a laptop tálcán.
A kijelző meg egy ilyen lenne...

(Megszakítás egyébként nem kell).

Nekem csak a "15x gyorsabb" opción akadt meg a szemem, nem ragaszkodom ahhoz a libhez.
Bármi jó, amivel meg lehet oldani a vázolt feladatot.

Ha mem ragaszkodsz az Attiny44-hez akkor inkább arduino nano-t használj.


Kicsi, az usb csatlakozás miatt sokkal kényelmesbb a használata/programozása, és van elég flash

Színes kép az Arduino Nano-ba sem fér be. Ha meg úgysem fér be a memóriába a kép, akkor ésszerűbb megoldás anélkül megoldani a rajzolást közvetlenül a célra rajzolva.

Van a kijelzőhöz Adafruit által írt library itt: https://github.com/adafruit/Adafruit-ST7735-Library
De ez az Adafruit GFX-re épít, ami pedig memóriában tarja a képet, lásd ebben a buffer változót: https://github.com/adafruit/Adafruit-GFX-Library/blob/master/Adafru...FX.cpp
Amit ráadásul malloc-cal allokál, nem is lehet statikusan. Ez tehát nem fog működni ATTiny-n az tuti.

Én úgy csinálnám, hogy:

* Az Adafruit libből "lelopnám" az inicializáló szekvenciát és a pixel feltöltés módját (persze lehetne adatlan alapján is, de egyszerűbb kimásolni)
* A képet úgy rajzolnám ki, hogy végigszaladok az összes pixelen, és ott helyben eldönteném, hogy milyen színű legyen. Tehát nem tárolnék semmit RAM-ban. Első körben ha x<töltöttség, akkor egyik szín, ha nagyobb akkor másik szín. Tehát egy téglalap jelezné a töltöttséget
* Ha már idáig is eljutottam, akkor kisebbre venném a bitkolbászt és köré rajzolnám az akkumulátor piktogrammot kézzel leprogramozva kizárólag téglalap rajzolással.

Ez bőven beleférne egy ATTiny-be is, de sajnos elég sokat kell programozni hozzá, nincs készen levehető megoldás.

Há ha *.bmp nem fér be, jó nekem a sima rajzolás is.
Ezt találtam csak még a példaprogramot nem látom, lehet átsiklottam felette...

Ez ránézésre nagyon ügyes lib. Pont ilyenre gondoltam volna, hogy ilyet kellene csinálni, és lám ez is készen van már.

Kezdem is pedzegetni... De kissé zavar, hogy az egész egy fájlban van.
Próbáltam a void setup() előtti részt kivágni és egy külön fájlba elhelyezni TinnyGFX.c néven.

Aztán az *.ino fájl elejére betettem egy #include "TinnyGFX.c" sort, amit el is fogad ugyan,
de a *.c fájlban hibát jelez.

"TinnyGFX.c:92:7: error: unknown type name 'uint8_t'..." meg még egy rakás mást is.

Hogy lehetne a setup függvény előtti rész kiinportálni egy másik fájlba?

Mi került abba a*.c file-ba?
Mutatsz kódot?

Csak simán kivágtam az eredeti *.ino fájlból a setup előtti rész, és beillesztettem a *.c fájlba...
A cél csak annyi volna, hogy a "sallang" ne a program fájlba legyen, úgy áttekinthetőbb a program írás közben, pl ha az elejére tekerek, nem kell keresgélni, mert rögtön a képernyő tetején a saját kódom kezdődne.



Ha idézőjelekkel írom akkor dobja a hibát,
ha kacsacsőrös zárójelbe, akkor meg "TinnyGFX.c No such file or directory",
holott ugyan abba a mappában vannak.

Közben meg is találtam a problémát...
Először is, a kacsacsőrös zárójelbe tett fájlokat csak a rendszer mappákban keresi,
egyedi mappában nem. Tehát ha van egy projekt mappám, és abban van az *.ino és *.c fájl,
nem találja meg az include -olni kívánt *.c fájlt, hiába egymás mellet van a két fájl.

Erre megoldás az, hogy kacsacsőr helyett idézőjeleket használunk, ekkor már látja a fájlt az *.ino fájl mellett is, de valamiért hibát dobott.
Hát a nagy helyzet az, hogy a *.c fájl kiterjesztését átírtam *.h -ra, úgy meg megette.
Tehát csak *.h kiterjesztéssel tudja behúzni a másik fájlban szereplő kódot rendesen.

No így mostmár nekikezdhetek a program megírásának is...

Akkor a témához kapcsolódik az is, hogy ha elkezded szétszedni a forrást különböző fájlokba, előbb utóbb belefutsz abba is, hogy hiába írtad le valahova egy változódat vagy függvényedet, mégsem találja!
Ennek az az oka, hogy minden a mappában szereplő forrásfájlt egyetlen nagy egészként kezel az arduino. Csak szerencsétlennek fogalma sincs hogy milyen sorrendben kellene összeillesztenie.
Az arduino a c-ből örökölt egy csomó mindent, többek között a *.h fájl támogatását is.
Én úgy szoktam széjjel darabolni a dolgaimat, hogy van egy fő programfájl, ami tartalmazza a setup(), a loop() függvényeket, valamint az elején az include "valami.h" sorokat. Ennek a fő programfájlnak a neve nagybetűvel kezdődik, a többi minden más meg kicsivel. Így garantálod, hogy ez fog először befordítódni, a többi majd csak ez után. A *.h fájlok define sorokkal vannak vezérelve, hogy csak egyszer, de pontosan egyszer legyenek figyelembe véve, akárhányszor is hivatkozunk rájuk.


A define sorok miatt nem lesz ismétlődés, akárhányszor is include-oljuk be. A *.h fájlokban nem illik tényleges programsorokat elhelyezni (bár működni fog), hanem csak a prototípusok gyűjtésére szolgál. Ez azt jelenti, hogy ha a motor.ino fájlban van egy void initMotor() eljárás, akkor a *.h fájlba ez kerül: void initMotor();. És ennyi. Nincs több. Figyelem, pontosvessző a végén! Mostantól a programod tetszőleges forrásfájljából meg tudod hívni, elég a fájl elején az include "motor.h" részletet beírni.




(Nekem ez a nagybetűs dolog amúgy úgy működött, hogy pl zSlave volt a főprogram, a többi meg csak sima kisbetűs. de azért próbáld ki úgy is, lehet hogy fordító függő. Csak a teljesség kedvéért )

Annyira azért nem szedem szét, csak az elejét tettem ki egy külön fájlba,
ami a grafika kezeléséhez tartozik, ez a TinnyGFX.h fájl.

A Program.ino meg mellette van ugyanazon projekt mappában, és a legelső sora az importálás.
Aztán néhány define, láb elnevezés, változók létrehozása, és utána setup és loop rész:

Ez így tudtommal egyszer fordítódik be. Tehát ha minden igaz, itt csak egy sorrend létezik,
első a TinnyGFX.h fájl, aztán a *.ino és nincs tovább.
Ha másik projekthez akarok ugyanilyen kijelzőt és cpu-t használni, akkor csak átmásolom egy másik projekt mappába a TinnyGFX.h fájlt, és mellé ugyanígy létrehozom a program.ino fájlt.

Viszont a példában az utolsó sort nem értem:

Hogy ez mi a fenét csinál...
Mármint az utolsó utasítás 5. sor, (nem az előtte lévő függvények)...

Infinite loop. Soha be nem fejezodo ciklus, magyarul itt megall a program( es velhetoen a hatterben megszakitasra var).

Tehát ha nincs semmilyen megszakítás, akkor megfagy az egész? Ha jön valami, akkor meg kezdi elölről?

Nyilván a megszakításra végrehajtja a megszakítás rutint és "folytatja" a végtelen üres for-t,
ugyanaz mint a while(1);
A loop elejére nem megy vissza soha

Nem fagy meg, csak szaladgal egy vegtelen ciklusban. Ha nincs megszakitas, akkor semmi 'lathato', hasznos dolog nem tortenik.
Alapvetoan maga a design is rossz. Ha az a cel, hogy a BarChart() funkcio csak egyszer fusson le es utana varjon megszakitasra a mikrovezerlo, akkor a BarChart() hivasanak a setup()-ban kellene lennie es a loop() pedig uresen futkarozna. (kerdes mi van a BarChart funkcioban)
Ez mondjuk nem feltelen hiba, csak nem elegans.

Jól van, akkor értem...

Gondolom azért tette oda a gazdája, mert csak annyi volt a "feladat" hogy bemutassa a kijelző kezelését. Egyszer lefut(nak) a függvény(ek), aztán nincs más feladat tulajdonképpen.
A programozó aki használni szeretné, úgyis kitörli azt a két függvényt meg a for ciklust,
és beírja majd a saját kódját, mint ahogyan én is.

Ui.: Amúgy a "megfagyást" csak képletesen értettem, az nem volt világos, hogy akkor visszamegy e a loop elejére valaha is, de akkor nem. Magyarán beleragad a for ciklusba.

De ha jól értem, akkor az a zárójelben lévő két pontosvessző, egy paraméter nélküli for ciklus akar lenni. Azért volt furcsa, mert sose láttam még ezt a megoldást.

Itt egy picit hosszabb magyarazat errol a megoldasrol.

Köszi, már megvan. Az első kód kinyerése fél nap volt. A másodiké másfél óra A továbbiaké 15-15 perc. Már megvan minden kód, és gombnyomásra ki is adja a kimeneten, a redőnyök szépen mennek le-fel. Csak most eljött az optimalizálás ideje, hogy ne kelljen mind a 18 kódot (daramonként 200 sor) minden alkalommal beírni. Jó lenne valami hivatkozással meghívni a kódsorozatokat. Most ezen szenvedek. Már zsong a fejem, de még mindig nem értem, hogy hogyan. A .h, és a .cpp fülekkel próbálkozom....... eddig nem sok sikerrel...

Írd le mi a gondod, szerintem találunk megoldást!

Először is köszönöm.
A program amit írtam 17-224-es sorig egy kód. Ha a kimeneten ezt adom ki a lábon lévő jeladó leengedi a redőnyömet. Van ennek felfelé kódja is, és van össz. 9 ilyen redőnyöm. A stop jel nem kell bár az is van. Szóval arra gondoltam, hogy ezekre a kódokra hivatkoznék a
for(int counter = 0; counter < 12; counter++) { sor után. Mivel több nanot kell telepítenem, a hatótáv miatt lenne egy egyszer megírt adatbázis, ahonnan csak kiválasztom milyen feltétel után mit csináljon, (vagy mint csináljanak) a redőnyök. pl lábra érkező 1-es jelszintre leenged két különböző redőnyt. Vagy négyet. Az eső szenzorom (mert az lesz) eső érzékelés alkalmával logikai 1-et fog adni 3-4mp-re. Azért kellene adatbázisba tenni, mert a későbbiekben bonyolítanám foto ellenállással, mint feltétel, meg még nem tudom mivel. Evés közbe jön meg az étvágy. És ha már tudnák hivatkozni a jelekre nem kellene mindig leírni, és nem foglalna el annyi helyet. Persze ha nagyon penge lennék, akkor csak egyeseket, meg a nullákat kéne beírnom, és a progi behelyettesítené az időket hozzá, mivel a logikai szintek egyforma nullákat, és egyforma egyeseket tartalmaz. Kivéve persze az első pár szinkron részt. Ez így érthető volt? Vagy nem sikerült jól megfogalmaznom....

Első körben én úgy próbálkoznék, hogy az 1 és 0 értéket betenném egy egy függvénybe,
így csak egyszer kell leírni. Aztán annyiszor hívod meg, ahány 0 és ahány 1 kell...

Második lépcsőben akár egy egész kódsorozatot is betehetsz egy függvénybe, ahány féle kódsorozatod van, annyi függvényt kell megírni, és amikor adni kell, csak egyszer kell meghívni.

Ez hasonló mint amikor távíróadó kódolót írtam .
Ott a teljes morse ABC levolt fektetve egy "táblába" Az adott betűhöz tartozott egy hexa érték.
A betűk morzejeleiből lett képezve.
Ahol Tá volt ott 1 szerepelt, ahol Ti ott 0 ... igaz kellett 1 stop bit is ... az nem más volt mint az utolsó karakter 1-es. Ez azért kellett mert a morze jelek változó hosszúak 1 és akár 7 rövid hosszú jelből állhatnak. A lényeg az volt hogy mindig balra léptettem a változót.
A baloldali legelső bitet ellenőriztem és ha 0 akkor rövid időzítő függvényt hívtam meg ha meg 1 volt akkor a hosszút.
A végjel a 80₁₆ volt mert a végjel bájt a 10000000₂ alakú volt mindig.

Neked is ezt kell tenni.
Igaz neked 40 bit hosszú (avagy amennyiből állnak)a mintáid 100110... stb
Akkor duplaword vagy nagyobb tipusú változód lesz inkább a végére záró 0-kat vagy 1-ket írsz.
De mivel fixek a minták méretei így fix számú balra / jobbra shiftelést kell végezned rajta.
(morze esetén változó méretű minták voltak)
Az aktuális bit értékét eldönteni hogy 0 vagy 1 eldönthető AND művelet bit maszkolással vagy set/reset eljárással tudod.

ha használod a Kód gombot akkor egyből ide a hozzászólás dobozába is szépen tagoltan be tud kerülni az forráskódod :