Köszi a választ. Nem 2db I2C-re gondoltam, hanem a kijelző és az ADC I2c-t használ, ez a rész működik. E mellé szeretném még az A0-t is kiolvastatni amin van egy feszültségosztó, és ennek az eredményét is szeretném látni az I2C LCD-n. Sajnos semmilyen kódot nem találtam amiben a ilyen összvér megoldás van...
Úgy bizony! A 20 és a 10 mA közötti differencia nem nagyon látható, de műszakilag ég és föld szinte. A 20 és a 30 mA közötti különbség ellenállásban már elég minimális, de a 30 mA már lehet, hogy meggyilkolja a rosszabb minőségű ledet.
Ha nem ütköznek össze, akár az összes analóg bemenetet is használhatod i2c-vel együtt. Jelszintekre kell figyelni, egyébként nem vészesen bonyolult szerintem a probléma.
Alapból az van, hogy az 5V-ból kell levonni a nyitófeszültséget és a maradékra kell kiszámolni az ellenállást a LED kívánt áramfelvételének megfelelően.
Az általad írt értékek kb. 20mA-t eredményeznek, ami lehet akár jó is, de én sokkal följebb kezdeném, mondjuk 470 ohmmal.
Az én tapasztalatom, hogy egy 20mA-es LED már 10mA-nél is közel max fényerővel világít, nagyon keveset változik nagyobb áramra, ellenben sokkal hosszabb lesz az élettartama, de ki kell próbálni.
Nekem van olyan dobozom, hogy az SMD LED-eket már 1,5k-val hajtom és így is kiveri a szememet, de ez csak indikátor, bőven elég ha látom, hogy villog.
5 voltról működtetve milyen ellenállásokat használjak? A chatGPT a pirosra 150 ohm, a többire 100 ohmot ajánl, szerintetek ez jó érték?
Nem figyeltem de szerencsére közös katódosat (-) rendeltem, de ha közös anódos lett volna, akkor hogyan megy a bekötés? Akkor inverzben kell beállítani a PWM-et?
Nagyon szépen köszönöm a részletes magyarázatot! Első olvasatra bonyolult. Egy ADS1115 modult használok feszültség mérésre, ami működik(I2C), a kijelző is I2C. Az arduino Nano egy szabad analóg bemenetével szeretnék még áramot mérni egy ACS712 modullal. Egyáltalán lehetséges az I2C mellett még egy analóg bemenetet is használni?
Jó a megközelítés. Első menetben külön-külön próbáld ki két kóddal az érzékelőket. Ha mindkettő úgy fut, ahogy futnia kell, akkor:
praktikusan a hosszabb / nagyobb / bonyolultabb kódot mentsd el egy újabb projektként.
a másik érzékelő működő kódját másold be a létrehozott újabb projekt végére, egyértelműen jelezve, hogy hol van a kettő határa.
A két kódrészlet összehasonlításával szedd ki a bemásolt második szakaszból azt, ami az első szakaszban egyébként már benne van. Ilyenek pl. az #include direktívák, de ebből viszonylag kevés lesz.
Szakaszonként (lásd alább) fűzd össze a két kódot úgy, hogy a bemásolt részt a felső kvázi "eredeti" rész megfelelő helyeire másolod be.
Ehhez az alábbi irányelvek fontosak:
Sorrendiség: #include-ok, utána #define-ok, utána a változó deklarációk (int, const int, float, unsigned long, stb.) ezek mind a void setup() szakasz fölé kerüljenek. Ezeken belül a sorrend mindegy.
ezek után jön a void setup() szakasz, amibe a bemásolt (alsó) void setup() elemeit kell átrakosgatni. A sorrend itt már nem teljesen mindegy: pinMode-ok előre, utána az összes többi.
Itt is, és a void loop()-ban is nagyon fontos, hogy a legkülső kapcsos zárójeleken belüli kapcsos zárójeleket csak egyben szabad mozgatni, rendszerint a nyitó kapcsos zárójelet megelőző paranccsal együtt. Ebben az IDE is segít, ha megfelelő a formázás, akkor nagyjából az a szabály érvényesület, hogy ami beljebbezve van, azt az előző kóddal együtt kell mozgatni. Példa: Itt a while (true) utáni { és } közötti szakaszt együtt kell mozgatni.
A void setup()-ot és a void loop()-ot szintaktikailag és logikailag ugyanazokkal a szabályokkal kell felépíteni, a kettő között az a különbség, hogy a setup csak egyszer fut le, a loop pedig folyamatosan megy körbe-körbe. Mindkettőre igaz, hogy a végrehajtás sorrendje a kódsorok sorrendjével egyezik (kivételek persze vannak, de nem jellemzőek). Ennek megfelelően nem lehet össze-vissza egymás után rakosgatni az egyes kódsorokat és/vagy a két működtető kódot, mert elképzelhető, hogy a két kódban vannak teljesen azonos funkciót ellátó részek (pl. Serial.println()), illetve előfordulhat az is, hogy a két érzékelőt más logikával/parancsokkal kell kiolvasni és más módszerrel kell a kiolvasott adatokat feldolgozni. Más megközelítéssel nagyon nem mindegy a sorrend. Szóval ezen a ponton (a void setup() és a void loop() szintjén) már elengedhetetlen, hogy legalább nagyjából tudd, hogy mi az, amit a kód csinál, mire valók az utasítások és azokat milyen szintaktikával kell használni. Ebben nagy segítsége az Arduino honlap referencia szakasza: https://www.arduino.cc/reference/en/
Alapvetően nem lehetetlen megcsinálni azt, amit szeretnél. Ha az angol megy és nem vagy 100%-ig tehetségtelen, akkor a mai és a holnapi nap (ha picit segítünk) elég lehet arra, hogy az egészet végigcsináld. Arra készülj, hogy szinte biztosan nem fog elsőre lefordulni a kód, és nagyjából kizárt, hogy az első sikeres fordítás után a kód úgy működjön, ahogy azt szeretnéd. Ez tök természetes, a lényeg, hogy ne add fel! Én a mai napot a helyedben a két alap kód megértésére szánnám, holnap délelőtt az összefűzés és első tesztelés, délután pedig a már működő kód finomhangolása lehet.
Nagyjából leszek ma, ha van kérdésed, nyugodtan írd meg!
Két 15x15-ös doboz van, az egyikben az eredeti 230-as kötések, a másikban az arduino + a relé.
Az hogy if vagy while az nem jelent semmit, látni kellene az assembly kódját. A legújabb arduino IDE-ben már meg lehet nézni egy utasítás függvényét, és például a delay() utasításnak elég szörnyű kódja van.
Tehát akkor azt mondjátok, hogy mehet nyugodtan a loop függvény évekig, ahol folyamatosan figyelem a bemeneteket mondjuk 200 ms-ként, mert mért' ne... ?
Én amondó vagyok, hogy valahol valami összeszed pár dolgot és az bebolondítja az MCU-t. Amit egyébként sem túl szerencsés 230 V-tal egy dobozkába rakodni.
A koncepcióval kapcsolatban: a megszakításnak nem biztos, hogy van értelme ebben az esetben. Persze nem feltétlenül rossz, csak jól mell megcsinálni.
Az if() return; megoldás kifejezetten nem szép, ehhez képest egy while() {} is megteszi, pontosan ugyanaz az eredménye (a loop()-ba rakott return; visszaugrik a loop() elejére.
Én megnézném, hogy:
előfordulhat-e túlcsordulás az időmérésnél (valószerűtlen, de ha hosszú időre van tervezve a működés, akkor lehet reális gond),
jól van-e megírva az ISR,
nem hal-e be valamikor a lapka és nem indul-e újra kvázi random.
És egyébként:
minden bemenetet hidegítenék, az aktívakat diódákkal tisztogatnám a károsabb hatásoktól, plusz
leválasztanék minden külső szenzort közvetlenül a bemenet közelében (júl méretezett schmitt triggerekkel),
ellenőrizném a tápolást,
ellenőrizném a valós idejű futást (egy i2c lcd kijelző erre bőven elég), illetve betennék egy watchdogot (külsőt, van rá filléres IC).
A csövek multiplexelve vannak, vagyis minden katód megkapja ugyanazt a vezérlést, de csak az a cső világít, amelyiknek szimultán az anódja is be van kapcsolva. Kb. 4 ms a multiplex idő, ezzel pörög folyamatosan.
Mondjuk, így is be kellett tennem egy portbővítőt, mert van hanglejátszás, GPS és külön óramodul, gombok, potméterek, a nyavalyás háttérvilágítás, úgyhogy ez mind már nem fér bele, de a sallangok nélkül beleférne.
Nem fejlesztői board van benne, hanem sima Atmega328.
Az egy jó ötlet, hogy egy felhúzó ellenállást teszek be az input_pullup helyett mert az lehet hogy csak akkor kapcsol fel, ha semmit nem érzékel a lábon, itt meg van egy méter vezeték aminek lehet alapból valamilyen töltöttsége és ha FET kapcsol, annak ez nem mindegy. Az interrupt részt azért tettem bele, hogy ne dolgozzon feleslegesen a proci, a loop{} első sorában meg van egy if (mode==0)return; és a mode-t az interrupt változtatja meg. De lehet hogy hülyeség az egész mert attól hogy a loop függvény nem dolgozik, még van száz másik dolog ami pörgeti a processzort. Reggel óta minden ajtónyitást érzékel, tuti hogy valami "üres" vezeték töltöttsége zavarja meg, holnap nem dolgozok, majd rakok be egy felhúzó ellenállást. Amúgy meg (Alpári Gnác) multkor gondolkoztam a nixie csöves órádon, ott van négy digit, vagyis 0-2, 0-9, 0-9, 0-9 az harminchárom plusz a villogó pontok, azt hogyan csináltad meg? Mármint azt hogy ennyi kimenete nincs az arduinonak, azt valami shield-el oldottad meg?
Sziasztok! Csináltam egy gagyi-project-et, kint a műhelyben van egy lámpa amit ha felkapcsolok, akkor lefut egy interrupt, elkezd visszaszámolni egy számláló, majd nullánál egy relé áramot ad a kapcsolónak fél másodpercre ami amúgy is egy impulzus-relét működtet és lekapcsolja a villanyt. Van még egy végálláskapcsoló az ajtón ami zárt állapotban összezárja a GND-t a 3-as lábbal, ezen is egy interrupt van, szintén elindul a visszaszámláló és ugyanúgy lekapcsolja a villanyt. A gond az, hogy fél nap után kinyitom az ajtót és nem történik semmi, illetve a második vagy a harmadik ajtónyitás-csukástól mégis működik. A villany felkapcsolásánál ilyen gond nincs, ott működik a dolog. A villanynál van egy ilyen https://www.hestore.hu/prod_10044455.html optocsatolós izé, az egyik lábára rámegy az 5V a másikra a GND, a harmadik lábon vagy 5 vagy 0 volt van, ez megy rá az arduino 2-ik lábra.
A végálláskapcsolónál más a helyzet, ott a GND a végálláskapcsolón keresztül rámegy a 3-as lábra
pinMode(3, INPUT_PULLUP);
ha bontja az áramkört a végálláskapcsoló elvileg fel kéne húzni 5V-ra, de ez nem működik fél nap után. Tudom hogy csúnyán néztek amiért 230-at kapcsolgatok arduinoval, de szakmám szerint amúgy is villannyal foglalkozom, eddig is csináltam FET-es alkonyatkapcsolót vagy lépcsőházi automatát, az egész egy 15x15-ös kötődobozban van lezárva, szóval nem vág agyon az áram. Ez az egész csak egy kísérlet, hogy bírja-e az arduino hónapokig-évekig a folyamatos működést, de úgy tűnik elsőre nem jött össze :(
Közben találtam egy fórumot, ahol a Gree klímák távirányításával foglalkoznak és ott a távirányítók kódjának a visszafejtése a téma, vagyis nem véletlen hogy nem tudtam kiolvasni és visszajátszani, mert a Gree-nél komoly védelem van a távirányítók másolását illetően. Úgyhogy egyelőre hanyagolom a témát
Kicsit naívan álltam az infra adó (vevő) dologhoz, azt hittem ez egy egyszerű dolog lesz. A vevő oldalon az interrupt függvényben csak annyi volt hogy irBuffer[x++] = micros(); ezt utólag feldolgoztam, az első értéket levontam az összes többiből, így lett
void loop() { if (Serial.read() != -1) { x = micros() + 1000; //a mostani időhöz 1000 msec múlva fog először bekapcsolni az infra led for (int i = 0; i < 104; i += 2) { z = x + irBuffer[i]; while (micros() < z) {} digitalWrite(pinIR, HIGH); z = x + irBuffer[i + 1]; while (micros() < z) {} digitalWrite(pinIR, LOW); }
úgy voltam vele, hogy a mikroszekundum az egymillió az egy másodpercben, ha valahol csúszik 4 mszekundumot, azt még elbírja (egymillióban a 38 KHz megvan 26-szor) mert elvileg az összes időzítés az elsőhöz van igazítva. Hát nem bírta el :) Próbáltam a buffer értékeit -8-tól +8-ig eltolni, de ez sem segített. Van egy teszterem ami a távirányító jelét is kiírja számokban, na az konkrétan nem mutatott semmit, ebből gondoltam hogy valami nagyon nem stimmel. Két konklúziót is levontam ebből, első hogy a tv-k és más infravevők valami nagyon precíz órajel szerint dolgoznak, második hogy az Arduino valahogyan képes a precíz időzítésre is, de én ehhez túl kezdő vagyok, itt már ismerni kéne az Arduino belső működését, annyira meg nem akarok belemenni.
Először egy skimmerrel megnézném, hogy mit ad-vesz a klíma és a távirányítója. Igen, van különbség az infra ledek között, emlékeim szerint legalább 4-5 féle alap szabvány van, amelyek szignifikánsan ugyan nem térnek el egymástól, de simán előfordulhat, hogy a két "szélső" már nem látja egymást adó és vevő oldalon.
Sziasztok! Szenvedek egy infra távirányítóval, amivel a Gree klímát szeretném bekapcsolni, de sehogy sem akar sikerülni. Míg a TV-t simán ki-be kapcsolom, addig a klíma nem érzékeli az infra jelet, pedig már próbáltam három féle programmal. A legrészletesebben a VEGA IRremote library ReceiveDump írja hogy mit ad a klíma távirányítója, amit ide bemásolok, a négy csillaggal lerövidítettem a kódot, mert a ti szempontotokból az nem lényeges:
Protocol=PulseDistance Raw-Data=0x2 35 bits LSB first
Raw result in internal ticks (50 us) - with leading gap rawData[74]: -65535 +178,-88 +14,-10 +13,-10 +14,-32 +14,-32 **** +14,-10 +13,-32 +14,-10 +14 Sum: 1354 Raw result in microseconds - with leading gap rawData[74]: -3276750 +8900,-4400 + 700,- 500 + 650,- 500 + 700,-1600 + 700,-1600 **** + 700,- 500 + 650,-1600 + 700,- 500 + 700 Sum: 67700
Result as internal 8bit ticks (50 us) array - compensated with MARK_EXCESS_MICROS=20 uint8_t rawTicks[73] = {178,88, 14,10, 13,10, 14,32, 14,32, 14,31, 14,32, 14,10, 14,10, 14,10, 13,32, ****,14,32, 14,10, 14,10, 13,32, 14,10, 14}; // Protocol=PulseDistance Raw-Data=0x2 35 bits LSB first
Result as microseconds array - compensated with MARK_EXCESS_MICROS=20 uint16_t rawData[73] = {8880,4420, ****680,520, 680}; // Protocol=PulseDistance Raw-Data=0x2 35 bits LSB first
Most hogy mondod a nagyfeszültségű tápegységet, nekem a digitális konyhai mérleg szokott meghülyülni ha megy a mikrohullámú sütő fél méteren belül, ezt leszámítva még soha nem tapasztaltam, hogy nagyfeszültség és törpefeszültség összeakadt volna
A nixiket és a 141-ket felkötheted egyszerre,csak a nagyfeszgenerátort állítsd le. Sanszos,hogy az (ill- annak a tápvezetéke) lesz a bűnös.
Kértem TŐled skiccet az áramkörök földelédéről.... Ha nagyfeszgen nélkül műxik a dolog,akkor annak a tápvezetékelését kellene szemügyre venni. Az én tapasztalatom az,hogy az a legstabilabb megoldás,ha az ilyen tápok közvetlenül a tápegységük pufferére csatlakoznak (és nem egy hosszú "tápkígyó"-ra vannak felfűzve).
Gondoltam rá, de 12V-os akku / 7805 párossal is villog.
Sajnos csak nemrég értem haza és mint mondtam, este látom/veszem észre igazán a bármilyen változást, most lehúztam róla az öcsipanelt, amin a 74141 és a nagyfesz táp van és úgy néz ki, hogy most nem villog.
Megpróbálok ezután szisztematikusan haladni, ahogy javasoltátok és egyenként visszadugdosni az egyes elemeket.
