Mi történik akkor, ha pl. egy UNO egyik bemenetére 5V kerül úgy, hogy nincs rajta tápfeszültség.

Az attól függ, hogy GND összeköttetés van-e, csak táp nincs, és attól is, hogy mekkora áram érkezik az 5V-tal.

A GND össze van kötve, a bemenet és az 5V között kb. 6k8 ellenálás van.

Az a ~0,7mA, ami azon át tud folyni, szerintem egész biztosan nem tud kárt tenni semmiben.
Most azon gondolkodtam el, hogy a védő diódán keresztül amúgy meg tudja táplálni magát a uC-t (kb. 4,3V jutna a Vcc lábra), ha nagyobb áram érkezne, egészen addig nem lenne attól sem baja, amíg a bemenetet védő dióda túl nem terhelődik, ezt viszont sajnos nem tudom, mekkora áram lehet.

Egy tapasztalat, hogy más ne fusson bele.
Aki enkódert használ, és a Paul Stoffregen féle Encoder.h könyvtárat használja olyan programban, aminek a ciklusideje nagyobb 20ms-nál, akkor az enkóder hibás értéket adhat vissza.

Még egy tapasztalat, amiről nem találtam információt.
A TimetOne.h időzítő könyvtár kizár néhány I/O pontot a PWM használatából.
Pl. a Mega2560 11, 12-es lábait is lehet PWM-ként használni (leírás szerint). Ha a fenti időzítőt akarja valaki használni, akkor ezeken a lábakon nem működik a PWM. A TimerThree.h mellet viszont használható.

Wifi routert váltottam, és a WiFi.setHostname
az ESP oldalon megszűnt működni, azaz hiába állítja be saját magának az ESP a host nevet, azt sehol, semmi nem látja.
Van itt olyan hálózati guru aki tudja mi a probléma? 🤔

Encodert nem szokás loop-ból használni, megszakítással lehet csak megbízhatóan.

Ezért csináltam én is megszakítással, annak ellenére, hogy a példaprogram loop-ot használ. Igaz, hogy semmi más nem futott rajta kívül. A megszakítás vezérlő pedig kilőtte a PWM funkciót néhány lábról.

[ Szerkesztve ]

Meg lehet azt jól is csinálni. A forrasztóállomásomban [link] pl. a loop-ból kezelem a gombokat és/vagy az enkódert is, ráadásul úgy, hogy nincs hardveres prellmentesítés, hanem azt is szoftverből oldottam meg (hibátlanul működik). Persze ehhez olyan program felépítés kell, ahol a loop nagyon gyorsan fut (de igyekszem mindig ilyen elven programozni).
Most egy másik projektben gombokat és egy forgó kereket, amit két optokapu figyel (enkóderhez hasonlóan kell kezelni) egy 40µs-os timer megszakításból kezelem. Azért így mert a kijelző multiplexelését is szoftveresen kellett megoldani.
[link-video] [link-video]
Baloldalt a fordulatok számát - jobb oldalon a másodpercenkénti fordulatszámot mutatja.

Lehetne persze az input lábakkal indítani megszakítást, de így sokkal nehezebb a prellezést szoftveresen kezelni (akkor kellene pl. RC tag a bemenetre, hogy ne tudjon túl sűrűn megszakítást indítani).

[ Szerkesztve ]

Persze, igazad van, de egy olyan program, aminek a ciklusideje nagyobb 20ms-nál nem ilyen módon optimalizált kód.
Én csináltam már szoftveres prellmentesítést megszakítással is. Nyilván nem elegáns, de azért a feladatát teljesítette.

Ezt a prellmentesítést hogyan oldottad meg?
Ami megoldást láttam eddig ott a megszakításban kivárta a prellezés végét, ami akár 1ms is lehet - hát az nem túl szép. Vagy rá lehet nézni a loop-ból, hogy abbahagyta-e már a prellezést, vagy timer megszakításból is, de akkor meg majdnem ugyanott vagyunk mintha eleve így kezelnénk pollozással...

De hátha tudsz valami jobb megoldást... ?

Így:

volatile long encoder0Pos=0;
volatile long previousMillis0 = 0;
volatile int currentPos = 0;
volatile int previousPos0 = 0;
volatile long currentMillis = 0;

attachInterrupt(0, doEncoder0, CHANGE );

void doEncoder0()
{
currentMillis = millis();
currentPos=digitalRead(encoder0Pin);
if (currentMillis - previousMillis0 >= interval) {
if (currentPos != previousPos0) {
previousPos0=currentPos;
previousMillis0 = currentMillis;
encoder0Pos++;
}
}
}

Ennek így nem látom át a működését. Az interrupt eleve akkor hívódik meg amikor változik a láb állapota. Megnézed, hogy eltelt-e bizonyos idő, és tényleg változott-e a láb állapota, és ha igen akkor növeled az értéket.
Mi történik prellezéskor, és mikor fog csökkenni az érték?

Mi történik ha a prellezés éppen hamarabb befejeződik mint az interval? Akkor mi fogja a függvényt meghívni?

[ Szerkesztve ]

Az interrupt eleve akkor hívódik meg amikor változik a láb állapota. Megnézed, hogy eltelt-e bizonyos idő, és tényleg változott-e a láb állapota, és ha igen akkor növeled az értéket.
Ezt vagy 6 évvel ezelőtt írtam. Nem emlékszem pontosan, hogy miért került bele az állapot ellenőrzés, de volt oka, az biztos. Optokapu jelét fogadta a 0-s interrupt és úgy emlékszem a nagyon lassú mozgásnál előfordult, hogy fals interrupt keletkezett (hiszen az egészet emiatt csináltam, gyors mozgásnál nem volt prell probléma), ezzel tudtam kiszűrni.

Mi történik prellezéskor, és mikor fog csökkenni az érték?
Melyikre gondolsz? Csökkenni nem fog egyik se.

Mi történik ha a prellezés éppen hamarabb befejeződik mint az interval? Akkor mi fogja a függvényt meghívni?

A függvény az első interruptra aktiválódik, vagyis a jelsorozat indulásakor, nem a prell lecsengése után. Vagyis bizonyos időn belül nem reagál a következő változásra, ami ez esetben 3ms-ra volt belőve (egy autó kerekének a forgását ellenőriztem ezzel).
Az elfordulást már a loopban értékeltem ki. Ez esetben irány érzékelés nem volt, mert csak 1 szenzor volt /kerék, csak az elfordulás mértékét (sebesség) kellett regisztrálni, az irányt tudtam, mert én forgattam a kereket. Egy saját PID vezérléshez kellett, csak akkor még nem tudtam, hogy ezt így hívják és van hozzá library, úgyhogy elég sokat kínlódtam akkor vele, hogy két olcsó kínai DC motorral tudjon egyenes vonalban gurulni az autó.

[ Szerkesztve ]

Így már értem, bár enkódernek hívod, de voltaképpen ez nem egészen az volt

Sajnos a mechanikus kontaktusokkal felépített rotary enkóderek, tapasztalatom szerint prelleznek mint a fene, ami csak elvileg nem gond, gyakorlatilag viszont olyan gyorsan is prellezhet, hogy kimarad megszakítás, mert hamarabb jön az újabb impulzus, mint ahogy az irq lefut. Emiatt volt nekem hatékonyabb a pollozás, mint a szintváltásra induló irq. Ha viszont van hardveres szűrés is (pl. sima RC-tag) akkor nem tud túl sűrűn új megszakítást indítani, és simán van idő mindenre a szoftverben.

Hát ez enkóder néven volt kapható annak idején és most is (bal oldalon a fekete korong + résoptó kombináció). Gyakorlatban ugyanaz a működés, csak irányt nem tudsz vele meghatározni.

Ennél az esetnél a DC motorra adott polarítás azért itt segíteni fog abban h merre megy...

visszatérve UNO ra 16MHz mellett 4 ciklus azaz 250 [ns] lesz mire elkezd futni az IRQ. Hardveres szűrés után elegendő lehet ha a tickeket számolunk és ciklusidő elején nullázzuk az értékét....

Ha ismert a kerék kerülete a sebessége is ismert lesz. Már csak az lesz a kérdés h tapad e a kerék.... innentől jöhet egy jó longacc, latacc yawrate szenzor.... kérdés mennyire akarja a projectet szenzorizálni.....

Sziasztok!
ESP32 Wroom-al (30 pines változat) tervezgetek jelenleg. A feladat "AC power meter" lenne, a kismegszakítók után lenne a szekrényben. Terv a fogyasztár mérése (nem kell 2 tizedes pontosság) az analóg bemeneteket felhasználva, árammváltóval.
Már az elején elakadtam :
Van, ahol ADC bemenetre 3,3 Vmax-ot írnak, van ahol 1,1 Vmax-ot (ESP8266-nál ennyi az biztos).
Most még csak keresgélek, mcu ez lenne, áramváltónak ezekből a 10A 1 V és a 20A 1 V (több helyen ajhánlották, de sztem vmi kisebb jobb lenne...). Valami védelem is kell majd az ADC pinekre, de ott még nem tartok...

Ha lehet egy javaslatom: ragassz egy fototranzisztort a villanyóra villogó piros ledére, és számold a villogást.
De ha jól tudom, van már olyan villanyóra, aminek van adatcsatlakozója ugyanerre a célra. Lehet a tiéd is ilyen.

Minek? Látom a fogyasztás nagy részét... meg a termelést is. Kismegszakítók után szeretném mérni. Itt is van pár mérő (Shelly 1PM), de szeretném 1 db wifi eszközzel kiváltani, ill. azokat is mérni, amiket eddig nem mértem, hamár van ez a rengeteg ADC pin.

Én is akartam ilyet. Nézegettem is a dolgokat, de a fogyasztáshoz nem csak az áramot kell mérni, hanem a feszültséget is, ami plusz egy eszköz még.
Aztán ott van az ADC pontatlansága. Azt találtam róla, hogy sokkal pontatlanabb, mint egy arduino ADC-je.
Sokat gondolkodtam, hogy mi legyen. Végül a sonoff gyári megoldását választottam.
Sínre szerelhető megoldás a Sonoff POW Elite. 29€-ért EU-s raktárból, 20A-ig. Remélem ez már bírni fogja a garázs hőmérsékletét és a kocsi töltőjét. Van amúgy 16A-es kiszerelés is.
Bár ezek szélesek a kijelző miatt. Más márkából láttam olyan vastagot, mint egy biztosíték, de az 100€ körüli.
Másik megoldás lehet az S60TPF konnektorba dugható. Ezt aliexpress-ről tudtam megrendelni Kínából, 12,36€ darabáron. 5-öt rendeltem. Elég hamar ideért.
Fontos volt, hogy Home Assisstant támogatás legyen. Ezekhez van. ESP van bennük.
Persze, ha mindenképp fontos, hogy csak egy ESP-vel old meg, akkor ezek nem megoldások számodra.
Ha nagyon elakadnál, akkor alternatívának még mindig jól jöhet.

Shelly 1pm van, sonoff az macerásabb Homa Assistanthoz. Feszültség mérve van mind a 3 fázison. nem a hajszálpontos fogyasztás érdekel, esp32 12 bit felbontás elég, áramváltó sem hajszálpontos. jelenleg 3 Shelly van ott, kellene még 3... 6 db wifi egy helyen, ez helyett lenne jó 1 eszköz, Shellyk mennének kötődobozba. k

Találtam ilyet is: [link] ez már pontosabb. ESP32 ADC-ről nem találtam imfót, csak annyit, h kb. minden pontosabb nála... akkor viszont lehet ESP8266 is, amihez BluePill-t lehet csatolni, asszem I2C-n keresztül.

nincs miért
Az a fura, h mindenhol azt írják, az ESP ADC nem pontos. Viszont a Shelly cuccok ESP8266, az újabbak pedig ESP32 alapon működnek...
Akkor mi a nem pontos? Vagy ott hogy oldják meg a fogyasztásmérést? Nagyobb Shelly-ken van áramváltó, a kicsik hall sensorosak gondolom.

Van mellette BL0942 vagy hasonló, és az végzi a mérést az esp csak vezérel, adatot dolgoz fel.

Köszi!
Ez így már túl könnyű... [link]

biztos csak a kezdők lelkesedésével írom:

lehet egyszerűbb áramváltóval és az áramváltó feszültségértékét mérni feszültségmérő modullal. így az ESP ADC-jét nem kell használni, ez valamivel biztonságosabb az ESP számára és pontosabb mérés is lehetővé válik.
pl nem kell félni az 5A-eresnek mondott áramváltó 1V feletti nem lineáris feszültségértékeitől 20A esetén.

talán csak azért nem használnak egyszerűbb noninvazív áramváltót a szerelődobozba építhető eszközökben, hogy mert nincs hely. viszont mindenféle kapcsolásoknak és SMD alkatrészeknek van hely a nyákon.

igen, az áramváltó az eredeti terv, fesz mérés nélkül, mert az már van mind a 3 fázison logolva. De a fenti megállapítás is jogos, h az ESP nem olyan pontos az ADC-je, kérdés, h mennyire nem? Áramváltónak is van egy pontatlansága + az ESP32 ADC... de nem gondolom, h ezzel bajom lenne. A hiteles úgyis az, amit a villanyóra mutat. De nem elszámoláshoz kell, csak felügyelni a ház részeit, hamár szétkaptam nagyfogyasztókra meg mindenféle körökre a rendszert. Láttam komolyabb ADC modult is, de annyi extra modul megdobná az árat. Fesz mérő modulra nem gondoltam, de ez is lehet opció

Most ez hátrébb lett sorolva, megjött a motoros szelep, annak kell vmi vezérlés.

Sziasztok! Mikro usb-s Nodemcu v3-at építenék be kisebb dobozba 2x16-os kijelzővel, 1 piros leddel, kis hangszóróval együtt. Usb type-c kábellel, töltőről való tápláláshoz megoldás lehet az, hogy veszek ilyen 2pines csatlakozót, és ráforrasztom erre, és ezt csatlakoztatom a boardhoz?

Minek a microusb csatlakozó? Mekkora a doboz hogy ilyen toldásokat tudsz csinálni? Az USB-C csatlakozóról direkt ráköthetsz a nodemcu-ra.

A doboz 90 x 65 x 36.
Usb-c-ről akkor mehet egyből a vin-re meg a mellette lévő gnd-re? Eddig úgy tudtam hogy micro usb-ről stabilabb a táplálás, de lehet csak rögeszme.