Köszi! Még ma rápróbálok, de valószínűleg csak délután lesz rá időm.

Sajnos én nem tudtam még elegendő tudást felhalmozni ilyen téren(Mikor foglalkozni kezdtem az elektronikával, még az volt a fenegyerek a városban akinek volt 1db tranzisztora, mivel még elektroncső volt mindenben. Ezért vénségemre nehézkesen megy a fejlődés, de igyekszem.), hogy ebben érdemileg állást foglaljak. Nekem kellemetlen tapasztalataim vannak a "kompatibilis" alaplapokkal. Legutóbb az STM32 vs. CH32F103C8T6 volt problémám, ahol minden jó volt, hiba nélkül felment, csak nem akart működni a program, stm-en pedig igen.
De volt gond LGT-vel is régebben. Nekem valami nem éppen hozzávaló alaplapkezelővel is lefordult/feltöltött hiba nélkül csak nem ment, de a hozzávaló alaplapkezelővel sem...

Kipróbáltam több alaplap kezelőt az LGT-hez, és van olyan is, amiben vannak apróbb hiányosságok. Nem mindegy, hogy melyiket használjuk.

Nem sikerült előbbre lépni. Oda jutottam, hogy Atmega328 lesz felhasználva, és kiegészítem valami külső ADC-vel.

Ha hozzáadsz a minta elejéhez két bitet, akkor az is ki lesz shiftelve, de a csipnek teljesen mindegy, mert átshiftelődik rajta "kijön a másik végén". Mire a ST strobe-ot adod, addigra már nem lesz ott.
Tehát mondjuk ha a legmagasabb bittől kezdve shifteljük ki a 16 bites változót, akkor ez tökéletesen fog működni:

Arduino IDE 2.3.6 nagyon lassan fordít

Próbálok egy programot feltölteni egy ESP32-re, de fél óra nem elég az Arduino IDE-nek, hogy lefordítsa.
( ESP8266-nál is eltart pár percig az első fordítás, de után már viszonylag használható tempóban dolgozik)
Még csak nem is bonyolult program, mert próbaképp csak a wifire kéne csatlakoznia.

Van valakinek valami ötlete, hogy ne őszüljek meg itt a gép mellett?

Nekem nanora nem akart felrakni egy szintén nem túl nagy programot, nem gyöztem kivárni, a végén valami hibát írt ki. Viszont nagyon érdekes, hogy a blink-et másodpercek alatt vissza rakta de mást nem volt hajlandó. Félő , hogy meg kell várni míg jőn egy javítás.

Én a hordozható 2.3.4 verziót használom, de semmi problémám a sebességével.

1.8.5 is lassú esp-vel. Igaz egy mázsa lib kellett hozzá. De nálam a lassó 5-7 perc egy ezer éves 2. generációs i7-en.

Komfort index

Sziasztok.
Megcsináltam egy alap kapcsolást arról hogy igy képzelném el a komfort index vezérlését.
Az index kar gnd vezérelt ami 8mA áram folyik mikor testre van húzva.
A működésé program szinten hogy D2 vagy D3 alacsony állapotba kerül 1 sec-500milisec idő között akkor "pöccintés" történt.
Ha ez igaz akkor vagy D5-D6 alacsony állapotba került 3 másodpercig.
(Az auto modulja vezérli a reléket igy a villogtatás nem az én részem)

Azon is gondolkodtam elég lehet 2 láb figyelésre és vezérlésre.
De ennyire nem vagyok jártas a dologba.
Segítséget kérnék a kapcsolás javításába ha nem helyes vagy ha van valakinek jobb megoldása szívesen meghallgatnám.

Mi volna a feladata ennek a "komfort index-nek" ? Mit kell csináljon az arduino ha pöccintés történt?

Annyit csinál ha pöccintés történt hogy D5 vagy D6 lábát testre húzza igy a led világit és behúzza a tranzisztort.



De elküldöm a programkódomat.

Szia!
Volt egy olyen tippem, hogy túl lehet tölteni, de nem volt rá konkrét példa vagy utalás így elkerültem. Szerintem a példádat fogom követni - persze megépítem a kapcsolást egy próbapadon és kitesztelem az éles helyzet előtt.
Köszi!

Szerintem a 66 és a 72. sorokba kellene még némi zárójel (mint ahogy az 56. sorban van).

Ha feltettem a szükséges alaplapi támogatást az 1.8...alá, akkor ment. 2... ismeri élből. Mindkét IDE alól megy. Néha az eredetivel többet szívtam. Illetve a HEstore klónokkal. Igaz - olcsóak. De ha összehasonlítom az Aliexpressel, amit külföldről rendeltem - egyrészt hamarabb megjött, másrészt sokkal stabilabbak voltak.

Nincs rá szükség, mert a logikai ésnél már alig van gyengébben kötő operátor. Lásd: https://en.cppreference.com/w/c/language/operator_precedence

Persze mivel ez általában nem verseny, hogy ki tudja jobban fejből a sorrendet, bátran ki lehet rakni a zárójeleket, de ez esetben nem fog változást hozni.

A kapcsolás jó lehet?
Azért kérdezem mert kipróbáltam az autónál és sajnos azt vettem észre hogy a tranziztoron 1mA folyik ha rá kötöm az index lábakat pedig tisztán testre 8-10mA folyik. 5v ágon 20mA folyik a ledeken .
PC817 használok.

Hello! A hibák ott kezdődnek, hogy a rajzodon nincsenek alkatrész értékek, sem pozíciószámok. Így hivatkozni is keserves bármire.
- Az opto-nak van egy CTR tényezője. Ez azt mutatja meg, hogy a Led árama milyen viszonyban van a tranyó kollektor-emitter áramával. Csak ez a tényező, ennél a típusnál, nagyon szélsőséges tartományban van megadva. Az értéke 50..600%. 5mA Ledáram és 5V kollektor-emitter feszültségnél van megadva.CTR
Tervezni, a legrosszabb esetre kell vagy is "pesszimista tervezési módszerrel".
Tehát az 50%-ra. Vagy is ha 20mA a Led árama, akkor fogja a 10mA-t lehúzni.

- De ha az index bemenet lehúzásakor 8..10mA folyik, akkor ehhez még hozzá jön a másik optocsatoló Led árama, mert azt is le kell húzni. Mivel az AVR bemenete Pull-Up áramkörrel van felhúzva, ott csak 140uA áram fog folyni. Tehát 50%-al a Led áramának 280uA áramnak kell lenni. De mivel a CTR tényező áramfüggő is, így 1mA Ledáramot adva, megfelelő lesz a port bemenetlehúzása. A dióda előtét ellenállását ez szerint kell megválasztani.
Mivel a Led Vf feszültsége 1.2V, az AVR tápja meg 5V, Re=(5V-1,2V)/1mA=3,8kohm, tehát egy 3,6k megfelelő lehet.
Az AVR meghajtó oldalról nézve, 20mA terhelésnél, 4,4V-ot ad ki, ebből levonva az 1,2V Led feszültségét, Re=(4,4V-1,2V)/20mA=160 ohm előtét ellenállás kell.

Ha így jársz el, vélhetően lehúzza majd az index bemenetet is. Mivel a Led reverz feszültsége maximum 6V, kicsit necces amikor az index 12V-on van, a Led meg V-n, mert az 7V. De el fogja viselni.

(Precízebben kell fogalmazni, rajzolni és nézni az adatlapot. Mind az opto,mind az AVR esetén.)

A 3-as es 4-es optonak nincs munkaellenallasa a +12V fele >>> ha vezerlest kap a 5-os vagy 6-os porton akkor eloall a 12V vs 0V osszekapcsolasa az indexkaron keresztul.
Valamint az 1-es es 2-es opto munkaellenallasa utan szukseges lenne 1-1 diodara, mert az optok ledjei nem szeretik a 6V-nal nagyobb elleniranyu feszultseget.

Kedves Proli007

Köszönöm a segítséged .

Feltüntettem az ellenállás értékeket a leírásod alapján.

Ahogy értem a Led reverz feszültség adhat aggodalomra okot.

Igen, ha korrektek szeretnénk lenni, a Led-el soros 3k ellenállással sorba kell kötni egy pld. 1N4148-as diódát.
Viszont a tranyók kollektorával sorba lévő 3k felesleges.

Szerintem ennek az egésznek nincs így értelme.

Két irány van: bemenet és kimenet. Az 5 V-os részt elválasztjuk a 12 V-ostól és viszont - nem lehet átjárás. Két optocsatoló az egyik irányba néz, a másik kettő meg a másik irányba. Minden LED egyik fele a testen van (ha ellenálláson keresztül, akkor úgy), nincsenek keresztben összeköttetések - a logika az Arduinoban van, nem a kapcsolásban, azért számítógép.

Az Arduino két bemeneten megkapja az indexkarok állapotát, valamint két kimete az indexkarokkal párhuzamosan kötve képes az indexet működtetni. Köztük persze optocsatolók vannak a megfelelő irányban, ahogy írtam.

Már csak az áramokat kell kiszámolni a CTR-ek alapján. De mivel az index 8 mA-rel működik, ha jól olvastam (bocs, ha tévedek, kevés időt töltöttem vele), egy 1-5 mA közti áram az optocsatoló LED-jén bőségesen elég lehet. A másik irányban az Arduino meg még kevesebbet fogyaszt. Persze meg kell nézni az adatlapot, mi az a minimum, amivel biztonságosan működik az adott optocsatoló.

Ne haragudjon hogy ilyennel terhelnèm a diódák helyét és irányát be rajzolná köszönöm.

Nagyon egyszerű, a Led-el soros 3k után kell bekötni, anód az optocsatoló Led felé.

Unsigned long vagy mégse ?

Tisztelt Fórumlakók !

Nagyon rég írtam már a HE fórumra, de most igazán szükségem lenne a segítségre
Egy hülye kérdéssel fordulok a nagyközönséghez, mert nem látom és nem értem, hogy hol vagy mi a hiba. Már csináltam egy sosor monitoros program részletet, de így sem értem, hogy hol a gebasz.....
A program 4 bájton kezeli a bevitt összeget. Egy külső epromban tárolódik I2C vonalon keresztül ( szerintem ez lényegtelen ). A 1-4-es memória címen tárolja az összeget persze megfelelő lebontásban ( 1 bájt -- x*16777216 + 2 bájt --- x*65536 + 3 bájt --- x*256 + 4 bájt adja a végeredményt ).Ezt minden esetben beolvasva és hozzáadva a bevitt összeget újra felbontja a megfelelő bájtokra és kiírja az epromba.
A helyzet a következő :
- Van egy számláló kezelő program ami a mega vagy uno alaplapokon nem működik jól. A probléma, hogy ha adatbevitel esetében pl 32000-es összeget választjuk addig jól írja be, rádobunk még 500-at, szintén jó. Még 500, és borul a dolog ( 32768-nál tulcsordulás, de miért ? )
Kiolvasásnál meg már értelmezhetetlen számokat jelenít meg. Amennyiben 64000 a bevitt összeg, azt jól írja be a memóriába de kiolvasva már hülyeséget ír. És innentől már tökmindegy milyen összegek kerülnek bevitelre borul az egész memória kezelés.
A véletlen szám generátorral bevitt összegek is csak abban az esetben lesznek helyesek ha 32768 alatt vannak....
- Due alaplapon kifogástalanul üzemel és számol. Nem találtam hibát bármekkora számokkal is kezelte rendesen ahogy kellene neki.

Hol a gond pedig az "adat" változót unsigned long tipusúként kezelem.

A rövid progi a következő, ha valaki veszi a fáradtságot és megnézi, kipróbálja.

Nem ismerem a feljesztőkörnyezetet de ez talán segít.


sor helyett ezt:


Az adatok mentését lehet egyszerűsíteni, nem kell annyi feltételes elágazás:


Ha mentés után az adat nevű változó nem fog kelleni, akkor az adat2 nevű változó felesleges.

Szerintem tegyél UL-t a konstansok végére és nézd meg, úgy mi történik, pl. 16777216UL.

Az Arduino Due ARM-ot tartalmaz, ugye? Ott az int eleve long int, 32 bites, a kisebb, 16 bites procikon pedig short int. Ez az, amitől másképpen viselkednek.

Amúgy a külön jelölés nélküli literálok addig signed-ek maradnak, amíg a következő legkisebb típusba beleférnek. Ha abba sem férnek bele, akkor lesznek csak maguktól unsigned-ek.

Ezt leszámítva ha signed és unsigned közt végzünk aritmetikai műveleteket, valóban unsigned-re lesznek alakítva a műveletek elvégzése előtt implicit konverzióval, de jobb nem rábízni az implicit konverziókra - pont a hasonló esetek miatt.

Ebből például pont az unsigned-re való konverzió miatt lesz nagy gáz, de ezt csak az élmény kedvéért írom ide: : -)

unsigned long a = 100;
long b = -200;

unsigned long result = a + b;

Jobban jár az ember ha az stdint féle típusokat használja, nincs kavarodás a különböző architektúrák között. uint8_t uint16_t satöbbi.

Az adatolvasás parádés, rendben működik.
Miért nem jutott eszembe a biteltolás...
Az adatrögzítés viszont valahol hibás majd még kibogozom ( a sajátom az if hegyekkel viszont jól megy így is ).

Persze, érdemes áttérni rá, de ezeket sem árt megtanulni, különben ugyanúgy pórul járhat valaki.