Pedig nagyon könnyű megmérni. Megméred a mega-t kijelző nélkül. Utána megméred beledugott kijelzővel. Az utóbbiból kivonod az előbbit és megvan az eredmény. Amúgy meg felesleges kivonni, mert a stabilizátoron a mindkettőnek az árama átfolyik, így az a mérvadó. Van 2.4-es kijelzőm is, ILI9325 vezérlővel, az is 110mA-t vesz fel. Ez be fogja izzítani az LDO-t, ha 12V bemenetet adsz neki. Használj dc-dc konvertert, vagy alternatív megoldásként azt is csinálhatod, hogy 4.7V-os teljesítmény zenert (vagy 8db sorba kötött diódát) teszel sorba a bemenettel. Így kb. 7V-ra ejted a bemeneti feszültséget, és a stabilizátor nem fog már annyira melegedni.

Megmértem a lehúzós módszerrel és ezek jöttek ki
12V lcd-vel = 177 mA
12V csak a mega = 73mA
5V Lcd-vel = 80 mA
5V csak a mega = 33 mA

Ugyanazzal a műszerrel mérted? Csak mert valami nem kerek. 1-2mA-nél nagyobb eltérés nem lehetne az 5V és a 12V-os táplálás esetén, hiszen a kijelző és a mega mindkét esetben 5V-ról működik.

Ugyanazzal mind a 4 estben. Talán az AMS1117 fogyaszt ilyen sokat mert az forrósodik .

Az nem fogyaszt, csak stabilizál, és a stabilizálás miatt melegszik.
Két lehetőséged van. Vagy beraksz egy hűthető stabilizátort, és akkor nem lesz semmi forró, vagy használsz DC-DC konvertert 12V-ból 5V-ot előállítva.

Lehetséges ,hogy veszek 1 DC-DC konvertert. Esetleg létezik olyan tápegység mint egy led táp csak 2 kimenettel 12V és 5V ? A pc táp nem jó mert nagyon nagy és a háza sem olyan, hogy önmagába lehessen használni.

Ha a mérést jól csinálta, akkor az AMS1117 plusz fogyasztást okozott (1-2 mA-nál többet persze nem lenne szabad). Előkotortam a saját mega panelemet (pont egy LCD tesztprogram volt benne szerencsére), és az LCD-vel együtt a kijelzőt folyamatosan működtetve 200-230mA körül van az áramfelvétele 5V-ról az AMS1117-et kihagyva (igaz hogy csak egy USB-be dugható mérővel mérem, aminek a pontossága ki tudja mennyi). Az adaptercsatlakozóján 12V-al megtápolva jelenleg sajnos nincs lehetőségem kipróbálni, de elvileg hasonló áramfelvételt kellene ott is kapnom.

A dc-dc konverternél arra figyelj, hogy lehetőleg olyat szerezz be, aminek a negatív be és kimeneti pontja azonos potenciálon van, tehát az esetleges áramfigyelés ne oda legyen bekötve.
Ez pl. olyan.

Köszi, ezt jó tudni.

Srácok, ezek a rotary encoderek ennyire ***-ok, vagy én vagyok béna?
Még egyik irányba csak-csak, de a másik irány téveszt mint atom.
Bővebben: Link

Ejnye!

Ezek a legalja enkóderek. Vagy megoldod valahogy a pergésmentesítést vagy Alps márkájúval próbálkozz, már ha a program biztosan jó.

Kiegészítés: Ezek Step - Dir rendszerű enkóderek, a Gray kód szerinti olvasás nem jó hozzá, illetve fordítva sem működik.

STM32 hardveres enkóder kezelése megbírkózik velük.

Már ha tudja a felhasználó kezelni a modult.Ettől függetlenül tényleg ezek a legócskább enkóderek.

Léteznek eleve gyári hibások. Sajnos a jóval drágább kategóriákba esők közt is.
Régebben már kibeszéltük a témát.

Más kod kell hozzá, ennek CLK/DIR kimenete van. Az Arduino standard kodja meg Gray kodot kezel.

Itt a jo kod:

Encoder clk/dt

Én a legolcsóbb Ebay-es rotary encodert használtam, tökéletesen ment. Persze a programot hozzá kellett igazítani, meg kellett hardware-es prellmentesítés is, de ezek szerintem normális dolgok.

Ezzel próbáltam, nagyon sokat téveszt, másikkal is, szerintem én bénázok.

A voidban is hiányoznak a pullupok.

A loop teljesen rossz. Elöször is nimcs benne semilyen prellmentesités. Minimum 1 ms delay rakj minden beolvasáshoz.
Vannak - ahogy elöbb linkeltem, kész és müködö kodok. Nézd meg azokat, hogyan kezelik ezt az enkodert.

Köszi

Eszembe jutott 1-2 kérdés ami nekem nem tiszta.Ha egy arduino program hosszú akkor az jobban terheli az avr-t mint egy rövid program? Mit nem ajánlatos írni, hogy az avr hosszú életű legyen? A könyvtárak befolyásolják vagy lassítják a programot?

A kérdés számomra nem értelmezhető.
Elvileg sincs élettartamot befolyásoló mértéke a programhossznak.
A mikrokontroller szempontjából tökmindegy, hogy akár értelmetlen NOP-okat vagy értelmes kódot hajt végre és hogy honnan.
A gyakori felprogramozás viszont egy idő után 'elfárasztja' az eepromot. Ennek a mértékét a gyártó specifikálja, hogy hány újraírási ciklust bír el hiba nélkül az eeprom. Jellemzően nagyságrendileg 10000.
Ez a RAM-ra természetesen nem vonatkozik.
Ha a fogyasztásra gondolsz, mint terhelésre, akkor a programhossznak nincs, de a modulok bekapcsolásának van hatása. Ja és hát persze a frekvencia, amivel hajtod.

Az AVR folyamatosan folytatja a loop függvényt, szóval a program hossza nem számít. Ami az élettartamot befolyásolhatja az az, hogy a flash memória/eeprom korlátozott számú újraírásra képes, de itt se tizes-százas nagyságrandre gondolj.
A könyvtárak alapban nem lassítanak, de lehetnek bennük lassú függvények.

Köszi mindenkinek.

100 000 újraírást ír az adatlap az eeprom-ra. Olvasás nem számít.
A program memória (flash) pedig egy külön dolog, erre ír az adatlap 10 000 újraprogramozást, és ide kerül a program, nem az eepromba.
A RAM pedig a változókat tárolja program futása során, és elvileg végtelenszer újraírható.

Ezt csak a program/adattárhely területét rövidíti meg.
Fordítás végén úgyis ott van mekkora programtárhelyet(flash) és memóriát RAM foglaltál le.

Igen többszörös felprogramozással "kopik" a program tár flash-e és EEPROM tára is.

EEPRPOM területre 100ezer felülírási ciklust adnak meg ugyanarra a bájt tömbre.
FLASH programtár területre 10 ezer felülírási/újraprogramozási ciklust adnak meg az adatlapok.

valaki gyorsabb volt

Ha 9% van használva akkor akár a maradékot be is tölthetem?
Sketch uses 23 988 bytes (9%) of program storage space. Maximum is 253 952 bytes.

Röviden: be.

De a flash az nem eeprom?

Nem. Program memória (=flash), eeprom, ram 3 különböző dolog. Az eepromba te menthetsz el adatokat. A program memóriába a programod töltődik fel. Zavaró lehet esetleg az, hogy egyes mikrovezérlőknek nincs eeprom-ja, ilyenkor a program memóriába lehet adatokat menteni, mintha eeprom lenne.

Lehet, hogy elnevezését és funkcióját tekintve más, de a flash bizony egy eeprom, működését tekintve.
A ram-ot nem én kevertem ide...