Továbbfejlesztése az AVR automatikus légfrissítő levegő kanóc freshmatic
Saját változata a jól ismert fejlesztések illatosító mikrokontroller Atmel ATtiny13A.
Finomítás, hogy csatlakoztassa a vezérlő szenzor válasz a natív rendszer segítségével abból motor pántok, LED-ek és ez kapcsolódik csak a tápegység. Vannak számláló riasztások, hogy figyelmeztesse a megközelítés a tartályban lévő folyadékot, hogy véget.
A kapcsoló a légfrissítő, hogy a kikapcsolt helyzetben.
Az algoritmus munkák illatosító válik:
1. Ha az érzékelő válasz igazoljuk, hogy az előző művelet előtt volt időkorlát (alapértelmezés 15 perc)
2. A várandós szünet (alapértelmezés 16 másodperc), a LED villog tájékoztatásul
3. Nyomja meg a henger szelep illatosító.
Hozzáadott egy gombot, ami meg lehet szakítani a műveletet a 2. fázisban vagy indítsa el a műveletet bármikor.
Továbbá, a saját meghatározott beállítások és tette a számláló nullázása.
A program tartalmaz egy számlálót műveletek és a maximális számú működések a tartály (alapértelmezett 2300).
A gyártó honlapján mutatja közelítő értéke - 2400.
Az első ballon dolgozott valahol 2340 pozitív.
Érték osztva 10 és a memóriájában tárolja. Miután a változás a henger változik memória cella, hogy növelje az akkumulátor élettartamát.
kalibrálása belső oszcillátor által OSCCAL (venni, amikor a EEPROM cellája 0) több, vagy kevésbé pontos időt hivatkozunk, mivel a frekvencia megfelelő - 2.621.440.
Úgy ítélik meg túlfolyó megszakítás időzítő 0 (működtet 10 másodpercenként).
Gomb feldolgozott PCINT0 változtatni a status pin, a stoppert használni, hogy késleltesse tovább, hogy megszüntesse a kapcsolattartó ugrál.
Sensor - infravörös LED és fotodióda egymással szemben a mosogató fölött tálba. A fotodióda kopott cső kizárni hamis pozitív. Által kiváltott metszéspontja a fény.
Úgy döntöttem, hogy megpróbálja ezt a módszert, de lehetséges, hogy döntetlen a mozgásérzékelő.
Kiváltó INT0 - a lefutó él.
Natív elemet használ, hogy energiát takarítson, ha a vezérlőt kikapcsolja a fényt.
A program írt C Atmel Studio 6.1.
Nos, akkor várjon meglepetés. Azt lehet mondani, hogyan lesz.
Tegyük fel, hogy, amint mondja, a MinRepeatTime 0. A nem atomi engedményezési DoNow függvénynek sztring MinRepeatTime = EEPROM_read (EPROM_MinRepeatTime) * 60;
Melyik lesz egyenlő az új számított érték MinRepeatTime - ez nem számít, legyen 0x0100. Fontos, hogy a hozzárendelés történik, nem atomi, byte „2 felvételi”: 01 és 00. Most nézni a kezem: miután a feladat a vezető
01 bájt megszakítás történt. Amint ezt a „nedoprisvoennaya» MinRepeatTime most állítólag van 0x0100, akkor a megszakítás kerül végrehajtásra sor if (MinRepeatTime) MinRepeatTime--; és MinRepeatTime továbbra 0x0100 - 1 = 0x00FF. Ezt követően megszakítás „sikeresen” befejezett és vezérlés visszakerül a DoNow. Ott fog történni az utolsó tragédia: a változó MinRepeatTime prisobachit low byte, és ez lesz egyenlő 0x0000.
Érti, hogy a több feltételes és a helyzet is meredekebb.
PS. By the way, az esetet írtuk le - nem az egyetlen meglepetés. Az optimalizáló általában rendetlen kezelni változó MinRepeatTime - például nem kap neki vagy zaoptimiztrovat felismerhetetlenségig, mert az optimalizáló nem tudja, tudja, mire használják máshol egy teljesen más „flow” - megszakad (különösen, ha a felvezető lesz egy másik fájlban) . Nem mondja a fordító változó MinRepeatTime szó illékony: «ez a változó nincs optimalizálva.”
Lásd alább, már megfogant.
Az első tele van az alacsony byte változó, és akkor is, ha kitölti a felső bájt megszakítja választ, és csökken a változó, ez nem az, hogy nem fogja érinteni.
Aha. A változata a fordító 123454321FF ez így lesz. A hosszabb változat 23454321AA - Meg tudja garantálni, hogy a fordító ugyanaz lesz?
És ha még írni illékony - ebben a sorrendben folytatódik. )
Részben ez nem kifejezetten csomagolva - memória nem elég.
Voltam szerelő megszakítás átírt hogy beleférjen kilobájt ...
EasyEDA: Free Cloud CAD