Jelen állapotban 3 expander szerepel a kapcsolásban. Egy az I2C LCD modul és a 2 kezelö felület 1-1 expandere.

Én is igy csinálnám, nekem már egy sereg expander kellett a kb 70 be és 70 kimenetre.

Már csak egy példa program kellene, amivel tudom tesztelni a gombokat és a LED-eket. Amiket kaptam segítségként linkek nem igazán müködnek, van amelyiket le sem forditja az IDE.

Keress rá a PCF8574 arduino-ra. Legalább egy tucat progit találsz. Ha letöltöd a PCF könyvtárat abban is van 2-3 minta ( examples). Sajnos most nem vagyok PC közelbe igy nem tudok berakni müködö kodot. A YT-n is van legalább féltucat ilyen temáju anyag.

A legegyszerübb az egyik PCF-böl beolvasni az egész byteot, és a következö lépésben ugyanazt a byteot kiküldeni a másik PCF-re. Egy sorban is meglehet oldani. ( persze initialás meg két három sor kell definiálni a PCF mibenlétét.

Sziasztok
NodeMcu-val dolgozok.
A programba egy DS szenzort figyel az egyik lábon egy másikon PWM jelet ad ki.
7-13 dutycycle közötti tartományba hülyíti meg a DS szenzor mért értékét (kb minden 10-dik mérés -127 fok)
Mi a franc hülyíti ezt a tartományt? E fölött és alatt jó.

Az else if ágban az if valami = true van. Oda KETTŐ egyenlőseg jel kell, mert feltételt vizsgálsz. Amit megadtál az ertekado utasítás.

A többi még nem néztem.

Találtam egy kódot, ami müködik is, így tudtam tesztelni a kapcsolást. Szuperül üzemel.

Örülök, hogy segithettem. Én is egészen meglepödtem, mert nálam a sereg port extender is szinte elsöre elindult, pedig 48-nak bonyolultabb a bemenete, két jel függvényét kell a kimenetre vinni ( villog vagy stabilan világit.

Érdekes, mert így is működik.
Most próbáltam, hogy a kritikus szakaszt 14-es pmw alatt átugorja (amúgy se kell az alatta lévő, node mcu ráadásul 10 bites pwm-el megy)
Így már nagyon jó lenne, de sajna néha még mindig bedob egy -127 fokos mérést, ami gáz.
Tettem 100µF kondit az 5 voltos ágra is.
És biztos, nem a szervo szivatja, mert azt lekötve sincs változás.

Sziasztok. Remélem elfér ebbe a topikba a kérdésem,nem találtam csak fejlesztő környezetes topikot(nemtudom kellene e). Egy jó ideje már szinte csak Eclipse IDE -t használok és szeretem is. Régebben valaki ajánlotta itt a Visual Studio Code -ot(+ Platformio plugin), mondom megpróbálom mivel úgy tudom hogy Jantje aki fejlesztette a Sloeber plugint Eclipse alá abbahagyta a fejlesztést és ugye Eclipse elég memóriaigényes. Mit mondjak, meg kell szokni ezt az új környezetet(IntelliSense nagyon bejön) de mindjárt az elején van egy dolog ami nagyon zavaró számomra és eddig nem sikerült megoldanom, hogy a használaton kívüli preprocesszor direktívákat jelölje meg (lehet nem jól fogalmazok ezért itt vannak a képek). Próbáltam az Atom IDE -t is, ott is ugyan az. Használ valaki VS -t és tudja e a megoldást? Köszönöm

Igen mert a nyit változnak semmi hatása nincs jelenleg. Be tudod tenni a teljes kódot? De simán lehet hogy a szenzor ilyen, ennyit tud. Ha ez van akkor merj pl 3 szor egymás után és csak akkor fogadd el, ha pl10 százalékkal térnek el egymástól. Ha egy kiugró adat van akkor újra kell mérni.

A vezeték szakadást is le kell kezelni, vagy ha lehúzod a szenzort, akkor az se okozzon gondot. Az egymás utáni 3x mérés jó ötlet, csak komplikált megoldani, hogy a programodnak ne kelljen 3x700ms-ot várnia, de megoldható egy külön állapotgéppel. Egyébként a -127-et egyből eldobhatod, nem hiszem, hogy bármikor is ilyen hideg lesz. 85fokC is előjöhet, azt is le kell kezelni.
Én azt is lekezelném, ha a szenzort lehúzod és visszadugod. Ez tipikus vezetéktörés.

Az a gáz, ha a pwm-es részt kiveszem, akkor tök jól mér, tehát azzal van összefüggésbe.
Ha teszek bele delay-t minden mérés után 200ms-ot akkor mérséklődik a gond.

Nem is rossz ötlet .

Nem ismerem ezt a csipet, hogy hogy működik, de a DS szenzorokhoz tipikusan SW időzítéssel lehet drivert írni. Esetleg valami interrupt rosszkor jön, és megzavarja a kommunikációt?

Elképzelhető elektromos probléma is: mit vezérel a PWM?

Optocsatolóval leválasztott-Fet DC motor, de jelen pillanatba 1db leddel vizsgálva is gázos és főleg a 10 alatti PWM a nagyon gáz.
De Kovidivi ötletéből a probléma megoldva:

Nem kellene indítanod egy újabb konverzió startot? Mert így csak ugyanazt kapod vissza (-127-et), kivéve, ha a kommunikációban volt hiba, de az érték a DS18b20-ban korrekt.

Hát... Csak beszivja néha a - 127 et.
Nem védi ki, nem értem

Erősen gyanús, hogy a kommunikáció volt megszakítva. A konverzióhoz csak meg kell kapnia a parancsot és végrehajtja. Bár azt most hirtelen nem tudom, hogy mi van ha a konverzió közben lekérdezik. Gondolom akkor is befejezi, csak a lekérdezett adat lesz hibás. Azt írta megoldotta a problémát, tehát megerősíthetjük, hogy a kommunikációban volt a gond. Nem ismerem azt servo libet, nem tudom használ-e megszakítást.

szerk: Hehe, látom mégsem oldotta meg
Túl gyorsan írtam.

Nem röhög... Együtt érez!

Viszont a -127 honnan jön? Úgy emlékszem a DS18B20 85-öt ad vissza hiba esetén.

Nagy valószínűséggel (akár véletlenül is) újrahasznált változó(k) értékét írja a program, majd azt konvertálja át hőmérsékletté.

Kommunikációs hibára tippelnék: nézd meg az adatlapját, hogy hogyan kommunikál - One Wire Interface a neve tudtommal. Az olvasó elindítja az olvasást, majd minden bitre küld egy lehúzást, amire a válasz lehúzás vagy semmi. Ha semmik jönnek vissza - tehát a DS... nem kezdett el kommunikálni - akkor olvasunk csupa 1-et. Ebből lesz -127 a konverzióból.

Ismételd meg az egész lekérdezést, ugye két részből áll. Tiltsd le a megszakításokat arra az időre, amíg kommunikáció folyik.
A -127-et ne csak egyszer dobd el, hanem mindig. While (temp==-127) hom_lekerdez() ... Soros porton debuggolnám is, ha -127 jön, hogy lássam, milyen sűrű. Nem kellene sűrűnek lennie! Habár én találkoztam már hibás DS18b20-szal, bizonyos hőmérséklet felett nem lehetett vele kommunikálni...
Azt csinálnám, hogy egy sima hőmérséklet lekérő fv-t készítenék, futna ez a progi néhány órát, és számoltatnám, hányszor hibás az adat. Semmi más nem futna, csak a hőmérséklet konverzió indítás, várás, adat lekérés, soros port átküldés (esetleg a programon belül is számolhatod ha akarod).

Az rendben van,hogy one wire de a Dallas lib minden lekérdezéskor resetel és nem kérdez ha a resetre nem kap választ. Ha a resetre válaszol a DS akkor később miért hal be? Belekukkantottam a servo lib-be futólag, elég kacifántos, de ha jól látom timer interruptot használ. Átfogóan nincs időm visszakövetni, de elég valószínű, hogy ez okozza a hibát.

Nem értem, hogy mire gondolsz azon, hogy ne csak egyszer dobjam el

nem is vehetné föl a -127-et, de mégis fölveszi valahogy, nem értem.

Ha minden nélkül, csak a hőmérséklet mérést iratom ki a soros monitorra, akkor minden fasza, a pwm szivatja.
Annyira kezdő vagyok, hogy nem tudom, hogy kell megszakítást kérni.
innen koppintottam le
Nem tudom, hogy mit kellene rajta alakítni?

Valóban nem kellene, hogy felvegye. Hogy kizárjuk Bakman elméletét, nevezd át a temp-et valami másra. A temp-et szokták használni temporary változónak. Adj neki valami specifikusabb változónevet, pl: DS_temp, vagy amit akarsz. Ha azután sem jó akkor lehet tovább keresni.

Ja és még valami. Amit Kovidivi javasolt az az, hogy addig dobáld el amíg jó értéket nem kapsz while-al. Amit te csináltál azzal az a baj, hogy valóban nem kellene felvennie a -127-et viszont ha a temp -127 akkor nem adja át a temp-nek, tehát az előző érték van a a temp-ben és amikor kiíratod a serial.print-el akkor az előző értéket írja ki ha -127 volt a lekérdezés eredménye. Nem tudom érthető volt-e.

Reset után van egy utasítás, hogy melyik csippet szólítjuk meg. Ha ezt rosszul veszi, akkor az okozhatja például, hogy nem ad semmi választ. Ha jól emlékszem, mert csak fejből írom.

Az tuti, hogy nekem is van egy mérőm, ami időnként hibát ad, és én is interruptra gyanakszom, de egyszerűen én is kimaszkolom a rossz értéket és kész, ahogy Kovididi javasolta.

PWM interrupt: AVR-en úgy működik, hogy ha olyan lábra állítasz be PWM-et, amire van HW PWM, akkor nem használ hozzá interruptot, a hardver magától tolja ki a tűpontos négyszögjeleket. Nézz utána, hátha van ilyen funkció a te csippeden is, és csak át kell költöztetni a funkciót egy másik lábra!

Ugyanis ha letiltod az interruptot a kommunikáció idejére, akkor az el fogja rontani a PWM-edet, pontatlan lesz!

Ezt nem szeretem egyébként a DS... csipekben, hogy nem lehet interrupt letiltás nélkül kommunikálni vele AVR-ről. Esetleg a serial HW-t firnyákosan használva meg lehetne oldani valahogy. Kiküldünk egy 0-t, ami ugye csak egy startbit: ez lenne a trigger jel, és ugyanazt a vonalat az RX-re is kötve a bitekben valahol bejönne a DS... válasza. Hmmm, erre még nem is gondoltam eddig, de jó ötlet! ki kellene dolgozni a megoldást!

Esetleg megoldás lehet az is, hogy a PWM-mel szinkronizálod a kommunikációt: akkor kommunikálsz, amikor a PWM timer interruptja éppen lefutott és egy darabig nem fog újra futni. A timer számlálóját kiolvasva ki lehet várni a megfelelő időpontot...

"Ugyanis ha letiltod az interruptot a kommunikáció idejére, akkor az el fogja rontani a PWM-edet, pontatlan lesz!" - a hardveres pwm kimenetnek pont nincs semmi köze az interrupthoz, az mint egy külön hardver változtatja a kimeneteket, a programtól teljesen függetlenül. Olyan, mint az SPI hardver, beadod neki az adatot, aztán ő kitolja a megfelelő pin-ekre, te pedig azt csinálsz a programban, amit akarsz. Ergo két szálon tud a proci dolgozni.

Igen, ezt értem és nincs is ezzel gond, nekem megfelelne, egyébként se tud változni a hőmérséklet ilyen rövid időn belül, holnap kipróba amit írtál.
Üdv