-
GAMEPOD.hu
Arduino hardverrel és szoftverrel foglakozó téma. Minden mikrovezérlő ami arduinoval programozható, és minden arduino program, board, és hardverrel kapcsolatos kérdések helye.
Új hozzászólás Aktív témák
-
atesss
addikt
Üdv !
ESP8266-nál milyen lehetőségek vannak a kód-feltöltésre ?
Létezik sokféle kialakítású board, láttam külön downloadert, stb.
Mi az ami mindegyiknél megvan ? Serial - valamilyen fizikai kialakításban - ugye mindig adott ?
És mi az ami csak bizonyos board-okon van meg ? Ha jól sejtem a Serial-USB chip az egyik ilyen.
Van olyan megoldás, ami WiFi-n keresztül újraprogramozható (nyilván ha kell akkor elsőnek serial-on felrakva a "bootloadert") ?
Egyáltalán van itt ilyen hogy bootloader ?
Ha nem Arduino, hanem MicroPython alatt akarom programozni akkor az mennyiben más HW/perifériák szempontjából ? Vagy pl. bootloader ?
MicroPython-al mennyire foglalkoztok ebben a topicban ?
Melyik a legkisebb/legolcsóbb ESP-s panel, amin van már van I2S ? -
atesss
addikt
válasz
atesss
#12939
üzenetére
Látok egy ilyet AliExpress-en, hogy "MicroPython maker programming ESP8266 development board" [link]
Na de miben más ez fizikailag ? Vagy csak amiatt írták át a nevét ilyenre, hogy MicroPython-ra keresve is megtalálják az emberek ?
Vagy valami SW-es különbség (pl. bootloader) van ? -
atesss
addikt
válasz
Janos250
#12945
üzenetére
A kérdésem legfőbb részt a chip-re vonatkozott.
De akkor ezek szerint az ESP8266-ben is van I2C, no ezt nem tudtam.
Meg akkor ezek szerint az ESP32-ben is.
Ez a kamerás OV2640 panel viszont baromi jó. Találtam részletesebb leírást róla: [link]
1500Ft-ért, kamerával, SD-kártya foglalattal együtt nem rossz.
Főleg ha még működik vele ez az I2S mikrofon is plusz 1500Ft-ért [link] -
atesss
addikt
válasz
Janos250
#12956
üzenetére
De akkor ezek szerint az ESP8266-ben is van I2C, no ezt nem tudtam.
Igen, elírtam, természetesen az I2S-re gondoltam !Valamit olvastam az ESP-khez rakható külső memóriákról. Hogy mi is a különbség az SRAM & SPIRAM között, meg hogy milyen a sebességük.
De nem világosodtam meg teljesen.
Ha +2-3$-ért van egy külső flash a nyákon egy ESP32-höz, az szerintem elég hasznos lehetne.Igen, én is most dilemmában vagyok ESP8266 és ESP32 között.
Találtam pl. egy egész szimpatikus board-ot ESP8266-ra: [link]
És lehet rádugni a tetejére shield-eket. Pl. az ugyanott kapható "Data shield" elég hasznos lenne hozzá, DataLog FAT32 microSD-re + egy RTC, plusz $2.19-ért (ok, még egy olcsó microSD meg a gombelem biztosan kell hozzá).Valami hasonlót tudsz ajánlani ESP32-esben ?
A kis fizikai méret nem olyan fontos. Sőt, ha ki van vezetve tényleg minden GPIO-ja, akkor felőlem nyugodtan lehet sokkal nagyobb is. Viszont az fontos lenne, hogy létezzenek hozzá hasonló Shield-ek (pl. ez az RTC+SD elég alap lenne részemről).[ Szerkesztve ]
-
atesss
addikt
válasz
Janos250
#12956
üzenetére
Közben még megtaláltam két márciusi hsz-edet az ESP32 előnyeiről: [link] [link]
Illetve utánanéztem a "külső ram"-nak is. pSRAM -nak hívják, itt egy részletes leírás a használatáról: [link]
Ezek alapján én már egy PSRAM-os ESP32-s board-ot próbálok keresni.
Nagy segítség ebben a wikipedia: [link]
Aliexpress-en a "ESP32 pSRAM"-ra keresve ezek jönnek be: [link]
A legelső találat pl. elég jónak néz ki:
4MB / 16MB FLASH for TTGO T8 V1.7 wifi Bluetooth ESP32 WROVER 4MB FLASH 8MB PSRAM electronic module T8 V1.7.1 ESP32 [link]
SD-foglalat és akksicsatlakozó is van rajta, $6.55-ért.
És ráadásul itt azt írja, hogy lehet a 4MB flash verzió helyett 16MB flash verziót is választani.
Bár a wikipedian nem írja hogy létezne ilyen.
Wikipedia alapján is próbáltam amúgy olyat is keresni, amiben a Flash memory 4 MiB fölött van.
De így Surface-mount module-t találtam csak, és azt is csak a gyártói oldalakról, Aliexpress-en nem. Azt meg nem annyira állnék neki kézzel forrasztgatni hogy board legyen belőle. -
atesss
addikt
válasz
Janos250
#13003
üzenetére
Eddig nem is tudtam, hogyan is működik az ugrókódos biztonság. Mármint elsősorban távirányító-technikában (autó, kapunyitó).
Most már nagyjából megvilágosodtam, köszi
Egyszerű de nagyszerű az ötlet.
A szinkron elvesztése viszont elsőre reális problémának tűnik. A "megnyomod N-szer a gombot" nem hordoz biztonsági kockázatot ? Ha a feltörni vágyó ismeri ezt a nyomás-számot (de mivel ez gondolom fix nyomás-szám, így pl. az eszköz kézikönyvében is le kell írniuk, onnantól meg tudható).
ESP-hez létezhet ilyen ugrókódos (leginkább 433Mhz-es) adó illetve vevő modul ?
Vagy egy "standard" 433-es modullal is meg lehetne oldani, hogyha én implementálom SW oldalon az ESP-ken az ugrókód generálást illetve ellenőrzést ? -
atesss
addikt
válasz
Janos250
#13012
üzenetére
Közben utánanéztem milyen 433Mhz-es adómodult lenne érdemes venni (HW).
Találtam egy nagyon jó leírást, ezt is a bitekmindenhol.blog.hu-n [link]
Ez alapján be is raktam az Aliexpress-es rendelős listámba egy SYN480R + SYN115 adó-vevő modul szettet [link] , és 2db Superheterodyne RXB12 modult [link]
De az még nem teljesen világos, ez az RXB12 modul használható adó és vevő üzemmódban is, vagy csak vevőként ? Ha csak vevőként, akkor mit lehetne hozzá adó párnak használni (az előzőben linkelt másik modulon kívül, valami hasonlóan jó adóerősségűt) ?
Illetve még antennák, első körben csak kicsi spirálantennák is kellenének hozzájuk. Azt nem találtam Ali-n egyik helyen sem ahonnan amúgy is vásárolnék, úgyhogy az szerintem magyar elektronikai boltból keresek mivel úgyis filléres lehet. De nem nagyon találtam eddig. Ok, akár tudok csinálni is ha nagyon kell, de ha van, inkább vennék készen.
Ezek a modulok milyen hosszúságú kódot küldenek ?
Az ugrókódos megoldásnak ezekkel lehet értelme ? -
atesss
addikt
Köszi, a tippet.
Találtam is ugyanott [link]
1 Set 433MHz 100 Meters Wireless Module Kit ASK Transmitter STX882 + ASK Receiver SRX882 + 2Pcs Copper Spring Antenna - $1.73.
És van a szettben két tekercsantenna is.
De sajnos úgy látom nincs az STX882 adómodulon kvarc. Vagy a kör alakú fémtok alatt lenne (bár kétlem hogy elférne, meg miért raknák bele) ?
A kerámiaszűrő az a 3 lábú, narancsos-barnás színű 3 lábú alkatrész lenne az SRX882 vevőmodulon ?
MOD: hát az Aliexpress kereséssel az "STX882 SRX882" kulcsszóra [link] mindegyik pontosan ugyanígy néz ki, nem látok az adómodulon kvarcot sehol sem.Ja ok, ez akkor csak tényleg egyszerű rádió. Amúgy kb. milyen az adatsebessége ?
Amúgy a 868Mhz-et is szabadon lehet használni, nem ?
Arra léteznek hasonló modulok ?[ Szerkesztve ]
-
atesss
addikt
Rémlik egy olyan információ, hogy a tokozásban a kvarcok-kristálynak van egy minimális fizikai mérete, és az alatt a méret alatt jóval nehezebben működik a rezonancia (illetve csak bizonyos rezonancia frekvenciákig). De aztán nemtom, lehet ez hülyeség.
Ok, akkor ez a szett ezek szerint viszonylag normálisabb kiépítésűnek tűnik.
Ez az adatsebesség annyira nem is kevés. Ok, nem ezzel fognak video-t stream-elni, de ahhoz képest a kb. bit/s-es nagyságrendnél - amire a legtöbb ilyen eszközt használják, távirányításra - azért jóval több.
Úgy látom vannak amúgy sokkal komolyabb antennák 433MHz-re is: [link]
De egyelőre nem veszek ilyesmit. Majd ha esetleg jól beválik ez megoldás, és épp kevés lenne a hatótáv, akkor.
Meg van tekercsantenna is, de ahogy látom csak ilyen 50 meg 100db-os csomagban [link]
Frekvencia-gazdálkodási előírás (mármint konkrétan EU-s/Magyarországi) alapján az antennára vagy bármilyen fizikai kialakításra amúgy nincs kitétel, csak az adónak az adóteljesítményére (mW) van egy maximum ? -
atesss
addikt
Az egyszerűbb PIR modulokon (pl. HC-SR501 [link] ) a műanyag burkolat pontosan mit csinál ?
Van esélye ezt valami kisebbre cserélni ?
Valami olyan megoldáson gondolkodom, ami kilátna egy mondjuk 10mm-nél nem nagyobb lyukon (amiből lehetőleg nem is lóg ki).
Egy csúszdán (zárt cső) való ember-lecsúszás érzékelésén gondolkodtam vele.
Illetve léteznek olcsóbb radaros mozgásérzékelők is, de nem tudom azok gyakorlatban hogyan működnek, erre jó vagy jobb lehet-e.
Infrasorompós megoldás annó nem jött be a célra (túl nagy volt a távolság).
Pedig nem is reflexiós volt, hanem egyik oldalon sima 5mm led tokos infraled, másik oldalon ugyanilyen tokos fototranzisztor (egy DIY összeforrasztós áramkör, de cserélgettem is utána alkatrészeket teljesítménynövelési célból, hiába)[ Szerkesztve ]
-
atesss
addikt
Ja ok, így már rémlik a szemléltető "csíkozott" ábra a PIR-ekről. Csak azt nem gondoltam hogy azt a burkolat hozza létre. Ez a komolyabb, biztonságtechnikai PIR-eknél is így van ?
"ahhoz túl lassú."
Annyi, hogy ez a csúszda alsó részén lenne. Tehát ott már eléggé lelassulnak az emberek.
De az optokapus megoldás sokkal jobb lenne persze. Főleg hogy annak már gyakorlatilag meg van a helye, mindkét oldalon. Mármint nem csak a furat a diódáknak, hanem egy-egy kb. 10x10cm-es kivágás a csúszdacsőnek a külső falában (duplafalú a csúszdacső, és a kettő közt kb. 5cm vastag üreg van, ahol kb. el is fér egy kis elektronika). De egy-egy kis kötődoboz is van még rajtuk.A lézerdióda mondjuk nem hangzik rosszul, csak viszont olyan kellene hogy biztosan ne legyen veszélyes a szemre (plusz gyerekek is vannak). Illetve ha komolyabban látszik, az sem szerencsés.
A nagyító lencse is lehetne, bár az azért már átmérőben nagyobb.
Viszont mindkettő a további fókuszálásra épít, így azt is feltételezi, hogy nagyon pontosan, és fixen be tudom állítani az adó és a vevő egymásra látását. Bár ragasztóval elvileg lehet fixálni. Csak egyszer kell jól...
Illetve azt is figyelni kell, hogy a csúszda megterhelésére vagy esetleg hőingásra nem mozdul-e el túl sokat.
Ennyiben lenne jobb egy még erősebb infraled. Aminek nem a sugárzási szöge nagyon kicsi, hanem a teljesítménye nagyobb (természetesen csak msec ideig, nagyon kicsi kitöltéssel vezérelve).[ Szerkesztve ]
-
atesss
addikt
Sajnos az én esetemben ennek a TSOP vevőnek a beépítése kicsit nehézkesebb, mint egy 5mm kerek "led" tokos fototranzisztornak. Bár lehet nem annyira vészes, de ehhez élőben kéne látnom.
Ebben a kísérletedben az adó led pontosan mi volt, és milyen adatlap szerinti sugárzási szöggel ? -
atesss
addikt
válasz
Janos250
#13092
üzenetére
Van erre megoldás sokkal olcsóbban.
Csak nem serial, hanem SPI protokollal.
Wiznet-nek vannak ilyen IC-jei, és arra épülő board-ok Arduino-khoz.
Én ESP-hez (illetve nem tudom már fejből biztosan, a lényeg hogy valamilyen 32 bites, Arduino board-okon is jelenlévő chiphez) néztem annó.
Egyszerűen csak megbízhatósági okból a Wifi-t kiváltani.Az elv a következő volt:
Ha már táp úgyis kell, akkor minden eszközhöz ki lenne húzva egy-egy UTP (pontosabban inkább FTP). És akkor azon az UTP-n a táp mellett (2 érpár, passzív POE) el tud menni egy 100M Ethernet is (2 érpár).
(Bár amúgy aktív, szabványos POE-ben is gondolkoztam, csak az már egy elég nagy fejlesztés lenne, kitalálni, nyákot tervezni, fizikailag pedig beültetni, stb.)Annyi volt vele az egyik problémám, hogy amikor ennek utánanéztem (most már kb. min. fél éve), akkor azt találtam, hogy hiába programozhatók ezek az ESP chipek is már MicroPython-ban, sajnos a vezetékes Ethernet library nem működik velük.
Van valaki itt, aki MicroPython-ban programozik ?[ Szerkesztve ]
-
atesss
addikt
válasz
atesss
#13095
üzenetére
Közben meg is találtam ami elsődlegesen gondoltam: Wiznet W5500 alapú SPI-Ethernet hálózati modul [link]
1700Ft-ért (és úgy hogy ez az ár magyar boltból) egyáltalán nem mondható drágának szerintem.
De Aliexpress-ről talán olyan 700-800Ft-ért is lehet, ha több db-ot rendelsz.Gergosz2
Természetesen van benne beépített Ethernet trafó is.
Az ESP-s modulokon a legkisebbek kivételével (ami 8 pin kivezetéssel van) szinte mindegyiken van SPI, jól sejtem ?[ Szerkesztve ]
-
atesss
addikt
Üdv !
Ugyan a vezérlő HW most - a számomra jelenleg gyorsabb fejlesztés, és egyszerűbb távelérés miatt - inkább egy Raspberry lenne, de ez nem nagy különbség, gyakorlatban egy Arduino-ra vagy ESP-re gondolom ugyanúgy kellene bekötni a fototranzisztort, ezért bátorkodom itt feltenni a kérdésem:
Fototranzisztort szeretnék használni egy Raspberry Pi GPIO bemeneteként.
Egy külső rendszer 7-szegmenses piros led kijelzőjének bizonyos szegmenseit érzékelném vele. Gyakorlatilag ha hiba van ebben a külső rendszerben (ez a led kijelzőjén látszik, fixen "ERR..." felirat van rajta), akkor csinálna rajta egy teljes resetet (táp kikapcsolás majd gyors visszakapcsolás).
Nem egy szép megoldás, de mivel egy eléggé zárt rendszerről van szó (és nincs hiba esetén más visszajelzés, pl. egy kimenet), nem tudtam mást kitalálni, ami célravezető lenne.
A fototranzisztor bekötése:
Egy feszültségosztó középső pontja lenne a GPIO bemenet. A feszosztó felső pontja tápfeszültségen (3,3V), alsó pontja GND-n. A feszosztó egyik tagja lenne a fototranzisztor(kollektor a pozitívabb oldalon), másik tagja pedig egy saccra olyan pár kOhm-os ellenállás.
Csak az kérdés, hogy melyik tag legyen a GND, és melyik a +3,3V oldalon ?
Arra jutottam, hogy ha pozitív logikát akarok (akkor legyen logikai 1-es a GPIO, amikor meg van világítva a fototranzisztor), akkor ehhez az ellenállásnak kellene lennie a GND oldalon.
Jól gondolom?
Inkább nem 5mm-es, hanem 3mm-es tokozású eszközt választanék, mert sajnos viszonylag kicsi a "megfigyelendő" kijelző is, így elég közel kellene lennie a detektoroknak is.
Például egy BPW85B-t: [link]
Az ellenállás mekkora legyen ? -
atesss
addikt
Mekkora ellenállással próbálkozzak első körben ?
Dugdosós próbapanellel csinálnám szerintem még ezt a tesztelést.
Pl. bedugok pl. egy 50k-st, megmérem a megvilágított és a nem-megvilágított áramokat, meg mondjuk a kimeneti feszültséget is mindkét esetben.
Ha a megvilágított áram 5mA fölött van, akkor még mehetek feljebb egy lépcsővel, és berakok egy fele akkora ellenállást ?
"Az érték függ a kiépítéstől is, például mekkora környezeti fény jut vissza a detektorra."
Szerintem környezeti fény nem fog túl sok, mivel egy kis falapba tervezem befúrni a fototranzisztorokat. És az egész falapot felcsavaroznám a figyelendő eszköz elé, szorosan rá (és a kijelző csak kb. 1-2mm-el van mélyebben mint a külső háza).
Viszont a közeli szegmensekből visszajuthat fény. A szomszédosból nem, vagy legalábbis hibás működést nem okozna szerintem. Úgy tervezem megcsinálni mind a detektorok elhelyezését, mind a SW-es érték-méréseket, hogy ez ne befolyásoljon.
Amikor nincs hiba, akkor minden kijelző szegmensein egy "körbefutó" jelzés van. Egyszerre egy szegmens világít, és egy "ciklus" alatt körbemegy mindegyik szegmensen, mindegyiket felvillantja (bár ez elég gyors, kb. olyan 1-1,5 sec).
Amikor hiba van, akkor viszont fixen világítanak a szegmensek, az "Err ..." feliratot kiadva.
Gyakorlatilag azt érzékelném, hogy mikor világít egyszerre két szegmens (pl. az "E" betű alsó és felső vízszintes szára, azaz szabványos kiosztással számolva az A és a D szegmens). Ezen felül meg még mondjuk biztonságnak bejöhet egy harmadik detektor, a második r betű egyik szegmensére.
Viszont az eszembe jutott, hogy ha multiplexelve vannak a kijelzők, akkor esetleg az okozhat problémát ebben a logikában
-
atesss
addikt
Ja igen, a poti jobb ötlet, ja.
Csak helipotim szerintem nincsen. De végülis gondolom sima trimmerrel is jó, ha óvatosan tekergetem.
MOD:
Illetve egy-egy sima trimmer akár még bent maradhat a végleges kapcsolásban is, és akkor minden szegmensre külön-külön is beállítható lehet a leginkább megfelelő feszültségosztás/kollektoráram.
Mondjuk 2x3 detektorra ez már 6 trimmer. A nyákon tulajdonképp elférne. Árban meg nemtom, kb. 100-200Ft egy darab trimmer (azaz 600-1200Ft összesen, ami az egész projekthez képest nem jelentős tétel) ?A multiplexelés hatását még nem tudom, csak egy sejtés. De akkor majd szkóppal kimérem. Na most jól fog jönni, hogy egy 4-csatornásam van, egyszerre tudom majd nézni mindhárom fototranzisztor feszültség-idő függvényét.
"... az ellenállás értékéhez igazított - elektrolit kondenzátort"
Ezt pontosan milyen képlettel számoljam ki ?De persze először a "futó" kijelző szegmenseinek váltása közti idő kellene, ezt szerintem első körben telefonnal kamerázva fogom mérni (képkockánként kiléptetve), ha ez a 25/30fps-hez nem túl gyors (többet nem tud sajnos a telefonom).
[ Szerkesztve ]
-
atesss
addikt
"Akár úgy, hogy méred a világítás idejét, és ha sokáig nem alszik ki a led, akkor ERR lépett fel"
Ez viszont egy nagyon jó ötlet, köszi !
Ezt az elvet digitális bemenettel ugyanúgy alkalmazni lehet (feltéve, ha sikerül jól beállítani a kapcsolást, hogy "digitális jelet" adjon).
De amúgy ADC-t Raspberry-re is ugyanúgy be lehet kötni. Annyi hogy az AVR-el ellentétben mindenképp külső kell. Asszem van is valami egyszerűbb, 8 bites, I2C-s típusom itthon.Akarok log-ot csinálni, illetve ezt a log-ot távolról is el akarom érni.
Esetleg e-mail vagy hasonló riasztást, ha valamikor nagyon gyakori (értsd. pl. pár percenkénti) lett a hiba.
Emiatt mindenképp valamilyen távolról is elérhető (azaz Ethernet vagy Wifi képes) kontroller kell.
Sőt, majd a hibák gyakoriságától/pontos előfordulási időpontjától függően gondoltam arra is, hogy akár a kameraképekkel (meglévő analóg CCTV rendszer, jelenleg egy DVR-re kötve, de egy kis késleltetéssel RTSP-n is elérhető) együtt, egy "timeline" vonalon jó lenne visszanézni hogy mikor avatkozott be a resetelő-eszköz, és ekkor mi történt a kameraképeken.[ Szerkesztve ]
-
atesss
addikt
Egy "8D" Mozi rendszer mozgásvezérlője.
Mozognak a székek, miközben megy a film (leginkább ilyen hullámvasút meg hasonló dolgok, legalábbis ott van legjobban értelme). Meg vannak effektek is (hó, füst, szél, buborék, storoboszkóp, hirtelen sűrített levegő fújás), illetve a kép meg 3D-s.
Csak hát egy zárt kínai rendszer az egész. (Mármint ez full kínai, a tervezés is... Félig pl. a Windows XP is kínai.)
Ma du. megyek be, csinálok róla célzott fotókat/videót, felrakom akkor majd ide is[ Szerkesztve ]
-
atesss
addikt
válasz
atesss
#13199
üzenetére
Itt vannak az ígért fotók az eszközről:
[kép] [kép] [kép] [kép] [kép]
A 3. és 4. kép alapján látszik, hogy tényleg multiplexelve vannak a kijelzők. A vaku-s fényképezés zárideje alatt van amikor csak 2-3 kijelző aktív.
A "normál üzemről" - a szegmenseken körbefutó jelzésről - pedig videót csináltam, azt hova lenne érdemes feltölteni, hogy itt linkelni tudjam ? -
atesss
addikt
válasz
atesss
#13241
üzenetére
Összeraktam, és csináltam is egy tesztet.
2k lett a fix ellenállás, és vele sorban pedig egy 5k-s trimmer potméter.
Első körben zseblámpával teszteltem, egy viszonylag sötét teremben.
Úgy elég jónak tűnt a min és max. érték.
1cm-ről a zseblámpával szembevilágítva közelíti a 3,3V-ot. Míg a zseblámpát kikapcsolva 0V.
A potméter tekerésével nem történt jelentős változás (legalábbis a szélsőértékeknél).Aztán beraktam élesbe, a kijelző elé is, eddig ennyit tudtam mérni vele:
[kép] [kép] [kép][ Szerkesztve ]
-
atesss
addikt
Üdv !
Használt már itt valaki PCF8574 alapú I2C-s I/O modult ?
Azon belül is a különálló Interrupt Pin működése érdekelne.
Én ugyan most Raspberry Pi-n használom, Python kóddal, de ez a probléma nem úgy néz ki hogy ettől függene, a modul működésében lehet valami hiba vagy furcsaság.Ez az Interrupt pin arra szolgálna, hogy ha történik bármelyik PIN-en változás, akkor ez a pin megváltozik. A fő kontroller így elég ha csak annyit csinál, hogy ezt a pin-t figyeli (akár interrupt-al, de akár csak polling-al). És csak akkor állok neki az I2C-n keresztül kiolvasni a bemenetek állapotát, ha ez a pin jelzi hogy változás történt.
Az hátrány, hogy egy külön pin-t fel kell használni hozzá.
Cserébe a kód gyorsabb tud lenni, meg kevesebb erőforrást használ (nem használom folyamatosan az I2C buszt). Egy Arduino-n ez szerintem még inkább fontos tud lenni.Én konkrétan ezt a modult használom: [link]
Ahogy láttam, nem mindegyik modulnál van sajnos kivezetve ez az Interrupt pin.
Az IC adatlapja [link] elég részletesen leírja a működését (az INT működése részletesen: 11.old).
A 15. oldali példakapcsolás alapján kötöttem be (10 kOhm pullup VC-re). Annyi, hogy nálam nem rögtön megy a fő kontrollerre, hanem még van ott egy 330 Ohm ellenállás is sorosan (ezt biztonsági okból a Raspberry-nek minden használandó GPIO pinjére felraktam, kapásból, fixen).
Én úgy vettem ki a leírásból (meg ez is lenne a logikus), hogy ahogy csinálsz a modulról egy kiolvasást, akkor az INT pin rögtön "nullázódik" is. Ez elvileg mindössze 4us kéne legyen (adatlap: 5.old).
Amikor változás van, rendben 1-be vált az INT pin. Utána kiolvasom az összes bemenetet, rendben látszik is hogy a PCF8574-nek melyik bemeneti pinje változott meg.
De az INT 0-ban marad ez után is, nagyon sokáig.
Direkt beraktam sleep-et, hogy teszteljem ezt, és még 0.1s után is maradt.
A programkódom ennek ellenére jelenleg ellátja a feladatát, és épp a következő gomb-megnyomáskor vagy elengedéskor mégis újra meghívja a kiolvasó függvényt. Ezt még nem teljesen értem hogyan, most próbálom kideríteni
De attól még a modul nem működik úgy ahogy kellene.
Multiméteren is felugrik az érték az INT pin-t mérve (ha pár msec lenne, akkor ezt nem mutatná ki), de szkóppal sajnos most pont nem tudom megnézni pár napig.
Van valakinek ötlete ?[ Szerkesztve ]
-
atesss
addikt
Hát igazából felhúzó ellenállást nem raktam fixen a Raspberry GPIO pinekre, csak egy soros 330 Ohm-os ellenállást.
Mondjuk belegondolva ez - ha a GPIO bemenet Mosfet-es, amire jó esély van - akár okozhatna is problémát. Bár eddig még sehol nem fordult elő ebből problémám.
De ha pont ez okozná a gondot, akkor miért lesz a "GPIO-nullázódás" ideje pont ilyen "emberi léptékű" tized-másodperces időtartományban ?
Igen, mind a 8 pin bemenetként van használva.
Illetve pontosabban a 8-ból 2 nincs is használva, azt én nem is kötöttem be sehova.
Ugyan nem tudom a modulon belül van-e bárhova kötve, de igazából nem nagyon kellene. Főleg nem VCC-re.
Igen, azt néztem is hogy ezt "quasi-bidirectional" -nak írták. De eddig még nem mentem bele, hogy ez pontosan mit is jelent elektronikai szempontból.
"maszkolni a megszakítást (adott input eredményezzen-e olyat)" - Ez is hasznos mondjuk.
Hát ezek tényleg nagy előnynek hangzanak azért így együtt már. Utánanézek részletesen akkor ennek az MCP230xx-nek is.
Csak persze az is kérdés, hogy mennyivel drágább ez a modul...
Meg mennyivel nagyobb a modul nyákja, stb. -
atesss
addikt
Ahha, látom, igazad van.
100kOhm-ot ajánl felhúzónak. Most csak 10kOhm van itthon (már ha egyáltalán megvan az a maradékom még 8db), az esetleg jó lehet ?
A bemenetek közül 4db mikrokapcsoló, 2db meg mikronyomógomb. Ezek most egy-egy 2,2kOhm-os ellenálláson keresztül húzzák földre a pineket, amikor átkapcsolom a kapcsolót/lenyomom a gombot.
Így is jó lehet még a 10k ?Mondjuk azt még mindig nem annyira értem, ez hogyan okoz ilyen hibát. A - felhúzóellenállás hiányában - ha pl. a mosfet feltöltődik, akkor hogyhogy pont ilyen tizedmásodperc nagyságrendű idő lesz mire visszaáll ?
Illetve nem is. Ha az Interrupt Pin 1-es, akkor ez azt jelenti, hogy változott a bemenet.
Vagyis akkor lebeg a Pin, azaz 0 és 1 között ugrál folyamatosan ?Hát hozzávetőleges támpontnak jó az IC ára.
De igazából az a kérdés, a kínaiak mennyiért építettek rá kész modult.
Azt meg nem mindig lehet ilyen egyszerűen magyarázni. Pl. volt hogy néztem, hogy egy teljes modul ára a nagy(1000+) db-os tételben kapható IC áránál is jelentősen olcsóbb volt...MCP230xx-ból amúgy van 16 portos, vagy akár még annál is nagyobb kivitel ?
[ Szerkesztve ]
-
atesss
addikt
Pedig nagyon úgy néz ki hogy kell külső felhúzó ellenállás a PCF8574-nél.
Legalábbis az adatlap 15. oldalán a "Typical Application" ábrájára gondolom hogy nem véletlenül rakták fel.
De most megint átnézve az adatlapot, igazából olyan infót viszont nem találtam leírva, hogy "muszály" tenni.
Az MCP23017 az könnyen lehet hogy más, simán lehet hogy abba viszont már építettek be. (Ez akkor még egy - nem is kicsi - előnye lenne akkor annak az IC-nek, illetve a rá épülő moduloknak.)Na ezt elírtam. Javítva így néz ki:
Amikor változás van, rendben 0-ba vált az INT pin. Utána kiolvasom az összes bemenetet, rendben látszik is hogy a PCF8574-nek melyik bemeneti pinje változott meg.
De az INT 0-ban marad ez után is, nagyon sokáig.És a multiméteres mérést is pontatlanul írtam:
"Multiméteren is felugrik az érték az INT pin-t mérve (ha pár msec lenne, akkor ezt nem mutatná ki), de szkóppal sajnos most pont nem tudom megnézni pár napig."
Ebben az esetben az INT pin-t a VCC-hez (3,3V-hoz) képest mértem.
Vagyis alapból 0-t mutat a multiméter (1-esben, azaz 3,3V-on van az INT). És ha Interrupt van akkor pedig a felugró érték egy negatív lesz (nem megy el -3,3V-ig, de kb. olyan -1,5V-ig igen).
De a lényegen ez igazából nem változtat. Az a probléma, hogy olyan hosszú időre megváltozik az Interrupt pin, hogy ezt még egy mezei multiméter is simán kimutatja.[ Szerkesztve ]
-
atesss
addikt
Hát a kódom elég gyorsan fut (kb. pár msec lehet egy teljes ciklus), ennyi időnként pollingolja a Raspberry-nek azt a GPIO bemenetét, amire rákötöttem a PCF8574-nek az INT pinjét.
Amint azt érzékeli a fő programszám, hogy 0-ban van ez a GPIO, rögtön meg is hívja a PCF8574-et I2C-n kiolvasó függvényt. A PCF8574 pedig a kiolvasás után magától, rögtön (adatlap szerint, ha jól olvastam ki, 4usec-en belül) alaphelyzetbe (azaz 1-esbe) állítja az INT Pint.
Tehát elvileg pár msec időre kellene csak megváltoznia az INT pinnek. Amit pedig egy multiméter észre se venne.
Szerintem - maximális eltérésként, de ez tényleg csak egy pillanatra (a multiméter-kijelzőt szemmel olvasva) - az a -1,5V körüli érték azt jelenti, hogy ennél jóval több időre megváltozott.
Nem tudom pontosan mekkora egy mezei multiméter sebessége, milyen ADC van benne, de kb. pár tized sec lehet a mérési illetve átlagolási ideje. A -1,5V kb. azt jelenti, hogy a megváltozott érték időtartama nem éri el az átlagolási időt, de közelít hozzá (nagyon durva becsléssel fele körül van).
De hát sokkal pontosabb lenne ezt szkóppal kimérni
Most már kíváncsi vagyok, asszem inkább várok, és nem is forrasztom be fixre a felhúzó ellenállásokat mielőtt letesztelném szkóppal.Nincs bekapcsolva a pulldown a raspberry-n.
[ Szerkesztve ]
-
atesss
addikt
Adatlap 11.oldala:
Resetting and reactivating the interrupt circuit is achieved when data on the port is changed to the original setting or data is read from, or written to, the port that generated the interrupt. Resetting occurs in the read mode at the acknowledge bit after the rising edge of the SCL signal, or in the write mode at the acknowledge bit after the high-to-low transition of the SCL signal.
...
This device does not have internal configuration or status registers. Instead, read or write to the device I/Os directly after sending the device address (see Figure 16 and Figure 17).
By sending an interrupt signal on this line, the remote I/O can inform the microcontroller if there is incoming data on its ports without having to communicate by way of the I 2C bus. Therefore, PCF8574 can remain a simple slave device.Úgy néz ki ez nem tud ilyet, nem tudom felülírni az INT regisztert, mert nincs olyan neki (vagy legalábbis ha van is valami belső, kívülről nem hozzáférhető).
[ Szerkesztve ]
-
atesss
addikt
A kódba beraktam debug-nak plusz lekérdezéseket, ami lekérdezi az INT lábat, és kiírja a terminalra.
Közvetlenül az I2C-s kiolvasó függvény elé is raktam be, illetve közvetlenül utána is.
Plusz kipróbáltam azt is, hogy az I2C-s kiolvasó függvény után beraktam még sleep()-et. Először egészen rövidet (0.0001 sec asszem), gondolva hogy oké, alapból akkor "túl gyors" a Raspberry, de ha berakom a sleep()-et, utána már tényleg újra HIGH-ban lesz.
Aztán utána, hogy láttam hogy még mindig LOW maradt, növeltem ezt a sleep()-et. Elmentem egészen 0.1 sec-ig, és még akkor is LOW maradt. -
atesss
addikt
Hát én erősen kétlem.
A PCF8574-hez ezt a python library-h használom: [link]
Most közben frissítettem a kódomat, és az INT pin-t most már nem pollinggal, hanem interrupttal kezelem le.
De a problémás résznél nem történt semmi változás.
Bemásolom akkor az összes releváns részét a kódomnak.
Bár ez már így kicsit OFF kezd lenni, mert az Arduino miatt általában C vagy C++-t szoktatok írni a topicba.import RPi.GPIO as GPIOI2C_IO_INTERRUPT_GPIO = 26 # Board (physical) Pin Number 37GPIO.setmode(GPIO.BCM)GPIO.setup(I2C_IO_INTERRUPT_GPIO, GPIO.IN)from pcf8574 import PCF8574I2C_PORT_NUM = 1I2C_IO_ADDRESS = 0x20i2c_io = PCF8574(I2C_PORT_NUM, I2C_IO_ADDRESS)def i2c_io_reader():io_interrupt_flag = GPIO.input(I2C_IO_INTERRUPT_GPIO)print("Interrupt pin állapota - olvasás előtt: ", io_interrupt_flag)i2c_io_readed_array = i2c_io.porttime.sleep(0.001)io_interrupt_flag = GPIO.input(I2C_IO_INTERRUPT_GPIO)print("Interrupt pin állapota - 0.001 sec-el olvasás után: ", io_interrupt_flag)return i2c_io_readed_arraydef i2c_io_interrupt_handler(channel):i2c_io_readed_array = i2c_io_reader()i2c_io_readed_array_reversed = i2c_io_reverser(i2c_io_readed_array)i2c_io_state = i2c_io_namer(i2c_io_readed_array_reversed)i2c_io_evaluator(i2c_io_readed_array_reversed, i2c_io_state)i2c_io_printer(i2c_io_readed_array_reversed, i2c_io_state)GPIO.add_event_detect(I2C_IO_INTERRUPT_GPIO, GPIO.FALLING, callback=i2c_io_interrupt_handler)[ Szerkesztve ]
-
atesss
addikt
Na most próbálkoztam tovább még más sleep időtartamok megadásával.
Illetve a main függvénybe (ami másodpercenként kb. 70-80x lefut) is beraktam egy kiiratást.
Nekem úgy tűnik, hogy hiába adok meg kb. bármilyen időtartamot...Viszont a main függvényben lévő kiiratás meg már az első alkalommal is HIGH-nak írja az INT pint. Mindegy, hogy ez az előbbi sleep idő most éppen néhány msec volt, vagy 400msec...
Lehet hogy amint kilépek ebből a i2c_io_reader() függvényből, akkor frissülhet csak a GPIO pin állapota ??[ Szerkesztve ]
-
atesss
addikt
válasz
gyapo11
#13450
üzenetére
De mivel többször is mértem, így eléggé valószínűtlen hogy minden mérésnél pont a rövid impulzusba mért volna bele.
Mindegy, ma du. végre kiderül, ma meg tudom mérni szkóppal.
A PCF8574 bemeneti pinjeire erősen ajánlott ellenállásokat is megveszem, de még direkt nem forrasztom be, előtte kimérem szkóppal ezt az anomáliát.
Mondjuk már így előre felmerült bennem, hogy ilyen "egy-impulzusos" jelre hogyan fog tudni szinkronizálni a szkóp.
Minek kellene lennie majd a trigger-forrásomnak ?
Rigol, digitális, elég nagy tudású (és sajnos a bonyolultabb funkciókat nem is nagyon tudom használni). -
atesss
addikt
No a szkópos mérés alapján úgy néz ki hogy mégiscsak valahogy a programkód okozza a problémát.
Az 1. ábrán nem volt sleep a python scriptben a kiolvasú függvényemben a PCF8574 kiolvasása után: [kép]
A 2. ábrán 35 ms sleep() volt: [kép]
A 3. ábrán pedig 125 ms sleep() volt: [kép]A kék az INT pin.
A sárga pedig a nyomógomb amit megnyomtam, és a PCF8574 egyik bemenetét húzza földre egy ellenálláson keresztül.[ Szerkesztve ]
-
atesss
addikt
No már elkezdtem írni hogy mi lehet ennek az "anomáliának" az oka.
Aztán miközben írtam, esett le hogy mi is van:
Mivel a --változásokat-- figyeli a PCF8574, akkor is van ugyanúgy interrupt, amikor elengedem a gombot (az INT pin akkor is 0-ba megy).
És a gombot jelző sárga jel ugye így pont az inverze. De amúgy semmi más különbség nincs, most teszteltem.
Valószínűleg csak annyi történt, hogy a 3. képnél még nyomva tartottam a gombot, amikor csináltam a képet. Vagy esetleg STOP-oltam a triggerelést a szkópon.
A sárga mérőfej magán az input porton volt (illetve egy 20cm-es hozzáforrasztott kábel végén).
A kék mérőfej pedig magán az INT porton (szintén egy 20cm kábelen).
A felhúzó ellenállás még nem került fel. Írtam, hogy direkt úgy tesztelem most a szkóppal, hogy még nem forrasztom fel őket.
Az I2C-s mérés is egy jó ötlet lenne. De közben még tesztelgettem, és egyértelműen programkód-oka van a dolognak.
Ámde azon belül valami nagyon is fura oka...
Direkt kiszedtem a GPIO interruptot. Illetve a PCF8574 beolvasását is közvetlenül a MAIN-be raktam (kiszedtem még a MAIN-ből meghívott függvényből is). De erre nem lett változás.
Eddig amit találtam hogy "megoldja" a problémát, ha kiprintelem a tömböt, amibe előtte már beolvastam a PCF8574-nek a portját.
Próbáltam, hogy kiprintelek egy másik, teljesen ugyanilyen adat-szerkezetű tömböt, de arra meg nem.
Szóval egyelőre tiszta X-akták...if GPIO.input(I2C_IO_INTERRUPT_GPIO) == 0:# i2c_io_readed_array = i2c_io_reader()print("------")io_interrupt_flag = GPIO.input(I2C_IO_INTERRUPT_GPIO)print("Interrupt pin állapota - olvasás előtt: ", io_interrupt_flag)print("--")i2c_io_readed_array = i2c_io.portif len(i2c_io_readed_array) == 8:# passprint("az előző kiolvasás megfelelően megfordított értéke: ", i2c_io_readed_array_reversed)teszt = i2c_io_readed_array# print("A beolvasott port tömbje egy külön [teszt] nevű változóba átmásolva: ", teszt)# print("PCF8574 Port beolvasva. A beolvasott port tömbje:", i2c_io_readed_array)time.sleep(0.125)io_interrupt_flag = GPIO.input(I2C_IO_INTERRUPT_GPIO)print("Interrupt pin állapota - 0.125 sec-el olvasás után: ", io_interrupt_flag)print("------")i2c_io_readed_array_reversed = i2c_io_reverser(i2c_io_readed_array)i2c_io_state = i2c_io_namer(i2c_io_readed_array_reversed)i2c_io_evaluator(i2c_io_readed_array_reversed, i2c_io_state)i2c_io_printer(i2c_io_readed_array_reversed, i2c_io_state)
A legbelső if-ben láthatóak a tesztelt "feltételeim".
Csak az utolsó két, most #-el kikommentezett print() bármelyike oldja meg a problémát (természetesen a teszt változós csak akkor ha előtte megvan az értékadása is).
Ez valami eléggé érdekes bug lesz... -
atesss
addikt
Igen, ez a hardveres pergésmentesítés tényleg probléma forrás.
Ezt milyen kapcsolással tudnám megoldani a lehető legegyszerűbben ?
Ugyanakkor ezt az elég fura, programkód-alapú hiba forrást (konkrétan én ezt valami bug-nak sejtem már) valószínűleg nem oldaná meg.
Miért lesz teljesen más az INT pin működése - a szkópon is láthatóan - , ha beteszek egy már kész (fixen feltöltött) változót kiprintelő függvényt ??
(Jó párszor lefuttattam direkt, szóval a pergés miatti különbséget ebből a szempontból kizárhatjuk.)
"És az INT láb értékét ne olvasd közben, mert ahogy írtam, python-ból ez is lassú, talán még lassabb, mint az i2c."
Na de ténylegesen ez a GPIO-olvasási művelet lassú (az adott programkód lefutása sok idő)? Vagy pedig amit már írtál egyszer korábban hogy bizonyos időn belül újra meghívva nem frissíti a korábban lekérdezett állapotot ?
Bár azt azért kipróbálnám, hogy mi van ha kiveszem, azif GPIO.input(I2C_IO_INTERRUPT_GPIO) == 0:
feltételvizsgálatot, és úgy olvasom be folyamatosan i2c-n a port állapotot. -
atesss
addikt
válasz
gyapo11
#13462
üzenetére
2db egy-áramkörös záró mikrokapcsoló van, ilyesmi: [link] (Hiába nézne ki elsőre két-áramkörösnek a 4 lába miatt, nem az.)
Illetve van még 4db DIP-kapcsoló, ilyesmi: [link]
Utóbbinál is lehet pergés tulajdonképpen, szóval azt is meg kellene oldani akkor már.
És ráadásul már elég kevés helyem is van a nyáknak azon a területén, szóval helytakarékosnak is kellene lennie (pl. 1-2 raszteres alkatrészekből).
MOD:
aryes
Hát igen, a SW-es megoldás jobban tetszene.
Bár most ugyan nem számítana, de - kvázi tanulási célból is - olyan megoldást szeretnék ami azért kicsit elegánsabb.
Szóval sleep-et nem szívesen raknék be, mert amúgy indokolatlanul lassítja a program működését, sőt fixen egy időre megakasztja.
Ami az ötletem lett helyette:
Lehetne az Interruptot ugyan letiltani ilyenkor, de helyette a MAIN ciklusban "órával" mérni, hogy mikor telt el már több mint 80ms. És ha ez eltelt, csak akkor indulna el a tényleges interrupt-handler függvény. A függvény végén pedig újra engedélyezni az Interruptot, globálisan.[ Szerkesztve ]
-
atesss
addikt
"de ha kiveszed a feldolgozást az interruptból és a main-be teszed"
Azért ettől még nem raknám be a main-be. Az Interrupt megtörténte átállítana egy Flag-ként használt változót. És akkor innentől indulna el az időmérés a main függvényben (innentől minden ciklusban lefutna a mainben az, ami ellenőrizné mennyi idő telt el).
Amint az eltelt idő több mint 50ms, akkor indítanám a "tényleges interrupt-handler" , azaz a PCF8574-et kiolvasó, és utána az ezt a kiolvasott értéket meg feldolgozó függvényeket.
"Ennek a módszernek a hátulütője, hogy minimum 50ms-al lassítja a program reagálását."
Ez sajnos így van, ez speciel tényleg nem tetszik ebben a megoldásban.
"Ha fontos az azonnali reagálás, pl vmi időzítő kapcsolódik a gombnyomáshoz, akkor az első interruptra indulhat a művelet, és utána kell figyelni, hogy a mondjuk 80ms-belül érzékelt újbóli gombnyomást figyelmen kívül kell hagyni."
Ez tényleg gyorsabb. Viszont itt már figyelni kell rá, hogy mi van ha pl. két gombot egyszerre nyomtál le.
Akkor ha tényleg eléggé egyszerre történt a megnyomás (80ms-on belül), akkor simán előfordulhat, hogy ugyan az első beolvasás időpontjában (1-2ms után) még csak az egyik gomb volt lenyomva. De viszont a 80ms vége után (amikortól megint újra figyelnénk a változásokat), viszont már mindkettő, és így már többé nincs változás --> nincs Interrupt.
Vagyis a második gomb lenyomása így akár el is veszhet. -
atesss
addikt
"Azért ettől még nem raknám be a main-be."
Mármint ezt magára a port-lekérdezésre és a feldolgozásra értettem.
Az "órás mérés" az, amit viszont beraknék a main-be.Közben viszont kiderült, hogy az event detection függvény:
- Tud olyan kapcsolót is, hogy ... , bouncetime=xxx [msec]
Ez így kb. azt valósítja meg készen, amit te írtál első opciónak. Amint van egy interrupt, onnantól vársz 80ms-ot (ilyenkorra ugye már biztosan nem lesz 0-sban az INT pin, mivel pont ez a cél vele).
Szóval ez most nekem nem túl jó megoldás.
- Alapból Threading-ként, többszálúan működik [link] (Install RPi.GPIO version 0.5.2a for multiple threaded callback interrupts)
És nem találtam rá opciót, hogy kikapcsolható lenne a Threading (egy ezt még nem tudó régi verziót - csak ezért - meg nem akarnék felrakni)."Ezért is nem érdemes az interruptot letiltani."
Pedig ezzel próbálkoztam most. Első körben csak hogy csak egy gombra megoldjam a pergésmentesítést kb. valahogyan.
De hát nem akar így sehogy se menni, szóval megyek tovább úgy, hogy nem tiltom le az interruptot.[ Szerkesztve ]
-
atesss
addikt
válasz
tibi-d
#13477
üzenetére
"mert a szelep zárásával nem lineárisan változik a levegő mennyisége."
Ha szervóról beszélünk, akkor azzal elvileg viszonylag pontosan szabályozható a szelepnek a szöge. Persze ha az egyéb mechanikai elemek is eléggé merevek ehhez.
Szerintem ha egyszer kiméred műszerrel, hogy milyen szervó állásnál mennyit szállít (mondjuk 10-20 különböző állásban), akkor abból már tudsz csinálni egy függvényt. Vagy akár csak egy look-up-table-t, interpolációval. És onnantól az alapján már vezérelheted. Nyilván nem lesz óriási a pontossága, de ha nem speciálisabb ipari rendszerbe kell, akkor szerintem a célnak megfelelhet. -
atesss
addikt
válasz
repvez
#13475
üzenetére
"DE a legjobb valami olyan lenne ami csak a keresztmetszet szűkítésével operál és nem zavarja meg az áramlást a csőben mint egy keresztbe tett lap."
Ez nem is rossz ötlet.
Ha tényleg elég rugalmas és tartós a csöved, akkor esetleg lehetne olyat csinálni, hogy egy szalagot/kötelet meghúzva, "összehúzod" a csövet. Nyilván ez csak egy bizonyos határig működik (csőtől függő, de szerintem a min. olyan 1/4 átmérő lehetne, még valami spécin rugalmas csővel is).
Tehát egy motor tengelye egy szalagot húz meg/enged el (ami mondjuk egy kis orsóra/rúdra fel van tekerve). Amikor meghúzza, akkor ezzel összehúzza a csövet. Amikor meg elengedi, akkor a cső a saját rugalmassága segítségével nyomja magát vissza eredeti állapotába.
Persze még külön kiépített, megfelelő végállások is kellenének, hogy biztosan ne húzza túl a csövet.
Elvileg a motor-fordulatok száma az orsó kerületével szorozva megadja az áramlási cső kerületének csökkenését. De a gyakorlatban itt is ki kellene a léghozamot úgy mérni, mint ahogy az előzőre is írtam.[ Szerkesztve ]
Új hozzászólás Aktív témák
ekkold- Sony MILC fényképezőgépcsalád
- Házimozi haladó szinten
- Nothing Phone (2) - több, mint elsőre látszik
- Autós topik látogatók beszélgetős, offolós topikja
- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- TCL LCD és LED TV-k
- Dell notebook topic
- OTP Bank topic
- Az alaplapgyártókra hárítja az Intel az egyes Core CPU-k stabilitási gondját
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- További aktív témák...
