-
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
-
And
veterán
válasz
Janos250
#12810
üzenetére
Az én JLC-s pakkom április 2-től - mikor is a követés szerint beért az országba - május 5-ig (!) meg sem mozdult. Az utóbbi dátumtól számítva két napon belül már a kézbesítőnél volt. Szóval türelem, már és is azt gondoltam, hogy erre keresztet vethetek..
Április huszonvalahányadikán a Postát írásban is kérdeztem, mire az a sablon válasz jött, hogy az ő rendszerükbe ez a küldemény még nem került be. Vagyis nem ők ültek rajta több, mint egy hónapig. -
-
And
veterán
válasz
atesss
#13025
üzenetére
Amikor kellett ilyen modul, mindig olyan verziókat szereztem be, amelyekhez járt tekercsantenna is (STX/SRX-882), szintén az Ali-ról. Mellesleg jobban elhelyezett, normálisabb antennával azért többre is képesek, mint ezekkel a vacak tekercsekkel, bár néhány méterre lényegtelen.
Az az RXB12 modul csak receiver, vagyis vevő. Mindenképp érdemes párban venni Rx-Tx modulokat, mert úgy egyrészt általában olcsóbbak, másrészt akkor nem lesznek gondok a kompatibilitással. Az STX882 is ASK-t használ, arról az általad linkelt RXB-ről kevesebb infó van. Általános jó tanács, hogy kerüld azokat a (főleg vevő-) modulokat, amelyeken nem látsz kvarcot (adón azért szokott lenni), és az sem baj, ha ezen felül kerámiaszűrőt is tartalmaz a vevő, mert utóbbi sokkal jobb közelszelektivitást ad.
"Ezek a modulok milyen hosszúságú kódot küldenek ?"
Pontosan olyan hosszút, amilyen hosszút te beleküldesz
. Mivel ezek egyszerű rádiók, nem tartalmaznak egyéb kontrollert. Van is némi tapasztalatom arról, hogy apró nyűgjeik vannak, például nálam az első 1-2 byte adat 'lemaradt' a vevő kimenetén, tehát meg kellett toldani kissé az átvitt adatot, ami összesen szintén csak pár byte volt. Egyéb tekintetben az említett STX-882 és SRX882 páros bevált: az adó kellően nagy teljesítményű, mindkettő viszonylag normális adatlappal rendelkezik és extraként alig fogyasztanak inaktív állapotban (ha az adóra nem megy adat; a vevőn pedig van engedélyező input, és ezek megléte az akkus üzem miatt nálam fontos szempont volt). -
And
veterán
válasz
atesss
#13028
üzenetére
Az adó is kvarc- (vagy legalábbis felületi hullámszűrő által) vezérelt, simán befér abba a fém tokba. A vivő pontossága ±100 kHz, azért rakják bele, hogy ez tartható legyen, lehetőleg ne sok MHz-cel odébb működjön, mint kellene. Vevő kerámiaszűrő: igen, a háromlábú alkatrész, 10,7 MHz-es, ennek megléte normálisabb felépítést, középfrekvenciás szűrést jelent.
Adatsebesség 0,1...10 kbps, kisebb adatrátán általában jóval érzékenyebbek ezek a vevők, az adatlap is 1,2 kbps-re adja meg a specifikált -110 dBm-es (tipikusan) igényelt jelszintet.
Mod.: a 868 MHz-es sáv is használható, de azon kicsit kötöttebb az adatforgalom (tudomásom szerint csak meghatározott, elég limitált impulzushosszban működtethető az adó), ezen felül a modulok típusválasztéka is kisebb, és az áruk is magasabb, mint a 433 MHz-es példányoké.[ Szerkesztve ]
-
And
veterán
válasz
atesss
#13032
üzenetére
A kerek fémtok az adómodulon maga a SAW-szűrő: [link], igaz nem kvarc, de azért nem is egy hangolt LC-kör (mint egyes kristály nélküli vevőmodulokon látható).
Kis hatótávolságú eszközökre (SRD-kre) vonatkozó hazai szabályozás:
433 MHz: max. 10 mW ERP, 100%-os kitöltés,
868 MHz: az alkalmazott sávszélességtől (is) függ a teljesítmény és a kitöltési tényező, alacsonyabb sávszél esetén max. 25 mW ERP és 1%-os kitöltés (adás / szünet arány).
Bővebb infók itt: [link]. -
And
veterán
válasz
Janos46
#13049
üzenetére
Belefutottunk már hasonlóba ezzel az SSD1306-os vagy kompatibilis vezérlővel. Egy darabig ment, aztán egyszer csak induláskor hasonló szemetelést produkált a kijelző. Más példánnyal / típussal egyszer normálisan elindult, másszor meg szemetelt. Akkor azt vettük észre, hogy a jelenség a tápfeszültségtől függ. Hiába volt a típus leírásában az Aliexpress-en, hogy Vcc: 3,3...5V, ha stabilizált 5.0 V-ot kapott, akkor gyakran csinált ilyet. Viszont ha a tápját akár csak egy soros Schottky-diódával, 2-3 tizedvolttal csökkentettük, a jelenség megszűnt. Ezt esetleg kipróbálhatod, ha most 5V a display tápja. Ha jobban kellene csökkenteni a tápot, akkor esetleg az I2C-busz felhúzó ellenállásait is erre a redukált tápfeszre kellene kötni (nem tudom, mennyire 5V-toleráns az oled SDA / SCL lába, ha a modul annál jóval kisebb, pl. 3.3V-os tápot kap). Ha a felhúzók az arduino-n vannak, akkor ez nem annyira járható út, de egy próba erejéig akár a kontroller tápja is csökkenthető egy picit.
-
And
veterán
válasz
gyapo11
#13056
üzenetére
(A TSOP-sorozat nagyon jól kitalált, annyira rá van hangolva a segédvivő (a -4838 típus esetén konkrétan 38 kHz) frekvenciájára, hogy nem érdekli sem a folyamatos háttérfény, sőt adott időt túllépve már a vivő jelenléte sem. Maga a tok pedig valószínűleg előszűrőként működik a hullámhossz érzékenységi maximum, 950 nm környékén. Azt azért megérzi, ha az adóoldali IR-led nincs rendesen kihajtva, közvetlen uC-lábról táplálva - tranzisztor nélkül - nem tud akkora hatótávot.)
-
And
veterán
Igaz, nem csak a port maximális árama korlátozhat. Esetünkben az elem típusa is erős limit volt (CR2032), mivel az nem tud 10+ mA-eket leadni. A lencse is dobhat természetesen a hatótávon, de az erős nyalábolás kézi távkapcsolónál nem annyira szerencsés. Szóval a tapasztalat az volt, hogy 2032-es elemes táplálásnál, pár mA-es IR-ledáram mellett a hatótáv max. 2...3m volt viszonylag széles sugárzási szögű leddel, és ebben a formában semmilyen visszaverődést nem érzékelt a TSOP vevő már 50 centiről sem, csak közvetlen rálátással működött. Ugyanezt a ledet tranzisztorral, az előbbihez képest legalább 10x-es csúcsárammal (> 50 mA) hajtva már a szoba összes pontjáról vette a TSOP, visszaverődve is.
Vivőfrekvencia: a TSOP-adatlapokon van erre vonatkozó görbe, ami a relatív érzékenységet mutatja a frekvenciaeltérés függvényében. Például a vivő névleges frekvenciájától ±30%-kal eltérve az érzékenység az eredeti érték < 20%-ára csökken. Vagyis marad valamennyi áthallás más vivőkre, de mondjuk a statikus fény abszolút nem zavarja a vevőt. -
And
veterán
válasz
atesss
#13061
üzenetére
Esetedben a TSOP IR-remote vevő sorozat nem igazán nyerő, mivel az nem egy szimpla fotodióda, és sok szempontból kötött jelformát igényel. Létezik amúgy kifejezetten proximity IR-detektor is a Vishay kínálatában, TSSP-típusjelzéssel, például: TSSP77P38, ez a TSOP-sorozattól annyiban tér el, hogy az IR-adó oldaláról nem a szokásos remote-protokollok szerinti adattal kell etetni, hanem szimpla vivőfrekvenciás impulzussorozattal, és a detektor válasza egy, a vett jelszinttől (ergo távolságtól) függő diszkrét impulzus lesz. Legjobb lenne, ha az IR-ledet is tartalmazná a tok, de sajnos az nincs benne.
"Ebben a kísérletedben az adó led pontosan mi volt, és milyen adatlap szerinti sugárzási szöggel ?"
Konkrét típusra nem emlékszem, csak arra, hogy a Lomex-ből származó többféle példánnyal is próbáltam (víztiszta illetve szürke tokossal), és eléggé átlagos nyílásszöggel rendelkeztek, ami az ilyen diódáknál szokásos 30..40° volt, a hatótávolságuk nem szórt túlságosan adott áramú meghajtással. Az egyik típus talán a kékes színű tokba szerelt CQY37-es volt, az elég jellegzetes kivitelű és 24° nyílású. -
And
veterán
válasz
gyapo11
#13063
üzenetére
Stílszerűen egy kontrollerrel
. Én 12F-sorozatú PIC-kel szoktam, nem tudom, van-e ilyen célkontroller készen hozzáférhető kivitelben is. Vagy hogy egy arduino - mondjuk a legkisebb nano - PWM-je rávehető-e erre, talán igen. Bár azt nem igazán értem, miért kell neked valamelyik IR-protokoll szerinti jelet adnod (szimpla folyamatos vivő nem elegendő!) és azt dekódolnod egy egyszerű optokapu helyett. Így az egyetlen előnye a környezeti fény kizárása. Akkor már inkább az a TSSP közelítésérzékelő, bár ahhoz is szükség van legalább egy rövid impulzusokra kapuzott / modulált vivőre.[ Szerkesztve ]
-
And
veterán
válasz
atesss
#13191
üzenetére
"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?"
Jól gondolod.
"Az ellenállás mekkora legyen ?"
Erre első körben nem hinném, hogy konkrét értéket lehetne írni. Ismert ugyan a fototranzisztor kimeneti karakterisztikája (kollektoráram az optikai teljesítménysűrűség függvényében), de tudni kellene még pár adatot:
- nyugalmi állapothoz (kijelző inaktív) tartozó kollektoráram,
- aktív szegmenshez tartozó kollektoráram, illetve az előző értékhez mért különbsége,
- RasPi GP input küszöbfeszültsége.
Az érték függ a kiépítéstől is, például mekkora környezeti fény jut vissza a detektorra. Úgyhogy valószínűleg csak teszteléssel mehetsz biztosra az adott határokon - pl. a maximális kollektoráram 50 mA lehet - belül. Ha a két megvilágítási állapothoz tartozó áramok különbsége túl kicsi, az input hiszterézise meg viszonylag nagy, akkor előfordulhat, hogy macerás vagy lehetetlen a megfelelő ellenállásértéket belőni. Mod.: vagy egy plusz komparátorral kell kiegészíteni a fokozatot.[ Szerkesztve ]
-
And
veterán
válasz
atesss
#13193
üzenetére
"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."
Az elv oké (már amennyire egy ilyen projekt oké lehet ), de én kisebb ellenállással kezdeném, vagy egy relatív kis (legyen 1k) ellenállás + néhányszor 10k-s helipot soros kapcsolásával, mert 50k esetén a legnagyobb kialakuló kollektoráram sem lehet nagyobb 66 μA-nél, azaz a nagyobb áramú munkapontokat eleve kizárod. Jó esetben nem sokszor tíz mA lesz a kialakuló áram, de ezt kellene csak korlátozni.
"Viszont az eszembe jutott, hogy ha multiplexelve vannak a kijelzők, akkor esetleg az okozhat problémát ebben a logikában "
Az időmultiplexelés okozta villogás frekvenciája általában 100 Hz nagyságrendű, vagyis akár egy szimpla integráló taggal eltüntethető, minimális plusz reakcióidő növekedés árán. Akár úgy is, hogy a kiszámított ellenállással párhuzamosan kapcsolsz egy - az ellenállás értékéhez igazított - elektrolit kondenzátort, hogy megfelelő időállandót adjon, például tizedmásodperces nagyságrendben. -
And
veterán
válasz
Gergosz2
#13204
üzenetére
Vaagy (ez a tiéddel nagyjából ekvivalens) fogja az RC-időállandót, ami a fenti példából - 10 μF, 10 kΩ - kiindulva 100ms-ot ad eredményül (ami a fel- és lefutásnál, végső soron a reakcióidőnél számít), illetve az abból számítható törésponti frekvenciát: f= 1/(2πRC)= 1.59 Hz. Tudván hogy a vágási meredekség egy RC-tagnál 20 dB/dekád, két dekáddal a töréspont felett (azaz 159 Hz-en) 40 dB lesz, ezzel a 160 Hz-es összetevő a századrészére csillapodik feszültségben. Ugyanebből visszafelé is lehet számítani egy kapacértéket, ha tudjuk, hogy mekkora frekvenciájú a szegmens meghajtójele és mekkora maradék hullámosságot engedünk meg a digit. bemeneten.
-
And
veterán
Ez a módszer egy egyszerű ellenállásosztó kimeneti feszültségéből kalkulálja az egyik ellenállást, és ahogy a linken is írják, az eredmény akkor lesz elfogadható pontosságú, ha a két ellenállás (ismert és mérendő) nagyságrendje azonos.
Gyors számolás után az elméleti felbontóképesség a 10-bites ADC okán a tartományban sehol nem lehet jobb, mint 2..3 °C. Egyébként fizikailag milyen ellenállást mérnél? Mert ez csak akkor járható út, ha létezik egy szabadon lógó, sehova be nem kötött mérőellenállás. -
And
veterán
Ok, akkor csak viccből kérdeztem, hogy pontosan / fizikailag milyen ellenállást is tervezel mérni. A többit aryes kolléga leírta. Amúgy az a belső PTC csak azért van a pákán, hogy te az ellenállását méricskéld, vagy a páka kiegészítő áramköre is használja valamire? Mert nyilván csak az első esetben tudod közvetve hőmérésre használni.
[ Szerkesztve ]
-
And
veterán
válasz
atesss
#13426
üzenetére
A bemenetek mindegyikére tettél felhúzó ellenállást? Nincs prell a bemenet(ek)en? Egyáltalán: csak adatot olvasol a PCF-ből, vagyis minden portot bemenetnek alkalmazol?
Ennek a port extendernek az előnye - nem kell külön belső regisztereket konfigurálni - egyben hátrány is lehet. Egy jobban beállítható extender, pl. az MCP230xx esetén portonként be lehet lőni az adatirányt, maszkolni a megszakítást (adott input eredményezzen-e olyat), és az INT-kimenet működése is elég részletesen befolyásolható. -
And
veterán
válasz
atesss
#13429
üzenetére
"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."
Nem is a RasPI GPIO-pinjeire gondoltam, hanem a PCF8574-re: ha a portjait csak inputnak használod (másképp fogalmazva: az I2C-busz csak olvassa a chip-et, sosem írja), akkor a portok mindegyikére illik 1-1 felhúzót tenni, lásd a rajzot a 15. oldalon, amire korábban hivatkoztál. Lebegve hagyni csak akkor lehet a Px-portok bármelyikét, ha kimenetként írod azokat (a többivel együtt).
"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..."
Maga az MCP23008-as chip (ez a 8-portos, a PCF8574-hez hasonló kivitel) nettó 300 Ft körül kapható a hazai forgalmazónál, szóval van rá esély, hogy ha valaki nagy tételben veszi a gyártótól és modulra építi, akkor nem lesz veszett drága a PCF-es modulhoz képest. Ha nyákot is tervezel a kész kivitelhez, akkor meg mindegy, maga a chip is elegendő.
Emlékeim szerint volt már említve ebben a topikban az MCP23..-as I/O-extender, és mások is jó véleménnyel voltak róla. Létezik belőle SPI-buszos kivitel is, MCP23S08 típusjellel. Elég jól felépített, valódi kétirányú portokkal rendelkezik, 11 belső regisztere van és szanaszét konfigurálható. -
And
veterán
válasz
atesss
#13432
üzenetére
"2,2kOhm-os ellenálláson keresztül húzzák földre a pineket, amikor átkapcsolom a kapcsolót/lenyomom a gombot."
A bemenettel soros ellenállás nem igazán kell, de ha maga a port nincs elhúzva a Vcc felé, az nem oké. Lehet 10kΩ is a felhúzó, az csak annyit eredményez, hogy aktív (alacsony) inputnál, megnyomott gombnál a rajta átfolyó áram nagyobb lesz. Nagyimpedanciás inputot amúgy sem szokás szabadon hagyni: extrém alacsonyra tervezett nyugalmi áram (pl. telepes táplálásnál) helyett megnövekedett nyugalmi áramfelvétel, határozatlan szint az eredménye.
16 portos MCP-verzió: MCP23017 (I2C) vagy MCP23S17 (SPI). -
And
veterán
A kötelező felhúzót a PCF8574-re írtam, az MCP-kben valóban van 100k-s belső kapcsolható ellenállás. A PCF INT-polaritásában igazad van, de ez eddig nem is tűnt fel
. Az adatlapon első blikkre kicsit megtévesztő. Még jó, hogy az MCP-k esetén az INT-jel polaritása is megszabható, meg az is, hogy csak open-drain kimenet legyen, vagy push-pull. -
And
veterán
válasz
atesss
#13452
üzenetére
"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 ?"
Egyszerűen nem automata triggerelést választasz (amikor ész nélkül fut a sugár akár van trigger, akár nincs), hanem normál vagy 'one shot' módot - hívják akárhogyan, a lényeg, hogy csak triggerre induljon a mérés. A trigger szintjét féltápfesz környékére választod, a típusát pedig lefutó élre. -
And
veterán
válasz
atesss
#13456
üzenetére
Az nem világos, hogy ha gombnyomásra indul a folyamat, és az input portra kerülő jelet - vagyis a gombnyomást, ami GND-re húz - a sárga görbe írja le, akkor miért csak a 3. képen szerepel ez a jel lefutó éllel, a másik kettőn pedig felfutóval? Egyáltalán, hol volt a mérőfej, magán az input porton, vagy a soros ellenállás előtt? Amúgy végül került arra a portra felhúzó vagy sem? Bocs, ha említetted volna, de nem találom ezt az infót.
Az is egy érdekes mérés lenne, ha a második csatornán nem az INT-jelet vizsgálnád, hanem magát az I2C-jelfolyamot, hogy az hogyan viszonyul időben a fizikai bemenet változásához képest. -
And
veterán
válasz
Janos250
#13673
üzenetére
Ez nem jó elképzelés. Mindkét (A, B) jel minden szintváltozására megszakítást kell kapni, és ezekből ideális esetben négy, de minimum három vagy kettő darab szükséges az irány egyértelmű detektálásához (ha nincs meg a 3 db. él, akkor 'félútról' visszatekerve kaphatunk egy ellenkező irányú jelzést is, ami nem feltétlenül korrekt). Amíg nincs meg az irány, addig nem lehet / szabad felhasználni a beérkezett éleket, mert addig csak annyi bizonyos, hogy az enkódert megmozdították, de még nincs feldolgozható és egyértelmű (üzembiztos) működtetés valamelyik irányban. Az nem elegendő, hogy az első megszakításban olvassuk a másik fázis jelét, mivel ha a futás kellően gyors és/vagy a rotary-t lassan tekerik, akkor nagyságrendekkel gyorsabban fut le az IRQ, mint ahogy az összes szükséges él beérkezne az inputokra.
Van rotary enkóder olvasásra bevált kódom, de nem arduino-ra, hanem más uC-re. -
And
veterán
válasz
repvez
#14061
üzenetére
A slave-címeket alapvetően a chip határozza meg, vagyis egy adott slave eszköz / modul adatlapján, leírásában lehet találkozni vele. Sok esetben legalább részben módosítható a cím, pl. a chip három lábának alacsony / magas szintre kötésével beállítható - a szokásosan 7-bites - cím három bitje, így abból akár nyolc is felfűzhető ugyanarra a buszra. A többi része fix, illetve van olyan típus is, amelynél az alacsony lábszám ára, hogy totál fix címe van. Létezik egyetlen input lábon analóg feszültségszinttel beállítható című slave is. Szóval modulja és a ráépített chipje válogatja, hogy mennyire szabadon állítható be a cím, ha egyáltalán módosítható.
"HA nem tudom , hogy van e felhuzo ellenállás a panelokon, akkor enélkül nem is tudom tesztelni öket ?"
Nem. Felhúzó ellenállás mindenképp kell, mivel a busz két vezetéke a slave-eken nyitott kollektoros tranzisztorokhoz kapcsolódik. Itt látható a jellemző I2C-busz felépítés: [link].
"Mitől , függ, hogy honnan számit hosszúnak a vezeték aminél már kisebb ellenállás kell?"
Van erre többféle leírás, app-note, néha még a slave-ek adatlapja is ad erre útmutatót. Általános esetben 4,7 kΩ körüli felhúzók megfelelnek, de az érték függ a busz hosszán felül a tápfeszültségtől (amire az I2C-busz fel van húzva, lásd az előbb linkelt ábrát) és a slave-ek típusától, darabszámától. Egyébként az I2C-vonalat nem túl nagy hosszra szokás tervezni, vagy ha igen, a sebességet lehet csökkenteni, illetve léteznek transzparens buszmeghajtók is ilyen célra. Azért egy-két méteren belül jó esetben nem lesz szükséged ilyesmire.
Mod. a #14062-re: a portra kapcsolható, uC-n belüli felhúzó megfelelhet, de mivel az általában túlságosan nagy értékű (sokszor 10 kΩ nagyságrendű), esetenként nem kerülhető meg a külső felhúzó. Ez főleg nagyobb buszsebesség, több slave és relatív nagy busztávolságok esetén igaz.[ Szerkesztve ]
-
And
veterán
"[..] csak PWM meghajtás kell a ledeknek és egyszerű digitális bemenetként lehet a tsop jelét olvasni."
(Sajnos ez nem ennyire egyszerű: a TSOP-sorozat IR-távkapcsolókhoz való, nem szereti a folyamatos vivőt. Kifejezetten szükséges, hogy apró 'csomagokat' vegyen, közöttük meghatározott minimum hosszúságú szünetekkel, hogy az AGC megfelelően állítsa be az érzékenységet. Bármilyen frekvenciájú folyamatos vivőt - mint zavarjelet - a folyamatos fényhez hasonlóan igyekszik elnyomni.)
Mod: léteznek egyébként a TSOP-khoz hasonló megjelenésű közelítésérzékelők is TSSP-típusjellel, inkább azok valók ilyen célra: [link].[ Szerkesztve ]
-
And
veterán
Ez, ahogy az adatlapja is említi, a TSSP-sorozat egyik (mára kifutott) elődje. Ennek megfelelően nincs benne AGC sem. Ezt a szerepkört teljesen átvették a TSSP-k. Mellesleg a TSOP1838 is kifutott hivatalosan, ha jól látom, a helyette a TSOP22xx, -24xx, -44xx, -48xx jelűek vannak manapság.
"A TSSP sorozatot nem ismerem egyáltalán, tudsz konkrét darabot javasolni?"
Valamelyik relatív kis érzékelési távolságú és gyors típussal próbálnám a linkelt táblázat alapján. Sajnos olyan kivitel nincs, amelyiknél a tokba lenne integrálva az IR-sugárzó is (pedig némelyik tokozás /Heimdall/ úgy néz ki, csakhogy az megtévesztő, mert az is csak receivert tartalmaz). -
And
veterán
válasz
Tomika86
#15013
üzenetére
Csatlakoznék Aryes kollégához, ami a lebegőpontos műveletek sebességét jelenti. Más - de szintén 8-bites - kontroller is elég nagy kódot generál az ilyesmihez, de ha adatküldési vagy megjelenítési ciklusonként csak egyszer kell végrehajtani, az lópikula.
A Nextion-hoz viszont két dolog: az első, hogy a debug-módja nem túl életszerű, mikor soros porton küldözgetek rá adatokat szoros időzítések mellett (erre egyébként a leírása is utal). A másik, hogy a változói számára a hagyományos módú értékátadás (egyáltalán: parancsküldés) rettentő pazarlóan bánik az adatmennyiséggel. Ezt megkerülni csak 'reparse' módban lehet, amit a Nextion parancskészlet részletezése is jótékony homályban hagy. A legtöbbször csak annyit említ róla, hogy ezt úgysem szokás használni, így aztán mindenféle netes példákból lehet csak kihámozni a gyakorlati megvalósítását (pedig nagyon előnyös dolog). Azzal viszont én 500 ms-os gyakorisággal adok át a legkisebb (Basic-sorozatú, vagyis a létező leglassabb) típusnak közel 100 változót, és nem tűnik lassúnak. Persze egyetlen képernyőn sosem jelenik meg az összes, de azért pár tucat biztosan, és mellette mást is csinál, animál / rajzol a HMI. A valóságban hibátlanul működik, debug-gal pedig ugyanaz a Nextion-kód közel sem tökéletes.
Mod: a bitráta a uC - Nextion között nálam is 115,2 kbps.[ Szerkesztve ]
-
And
veterán
válasz
Tomika86
#15024
üzenetére
Mivel a Nextion-féle Gauge objektumnak nem sok beállítható jellemzője van, ezért igen, muszáj írni egy rövidke script-et, ami adott eseménynél - most a Timer-en, ill. annak lejártán kívül más nem jut eszembe, ami erre a célra jó lenne - szépen átszámolja / átskálázza neked a bemenő mennyiségeket (nyomásértékeket) a mutató szükséges elfordulását eredményező ívszögekké.
-
And
veterán
(Aki találkozott már az iparban használatos bármilyen terminállal, az tudja, hogy az nem egy kategória a Nextion-féle "HMI"-kkel, hiába adnak utóbbiaknak ilyen fellengzős nevet. Nyilván nem is azok versenytársaiként vannak a piacon. Ráadásul amit linkeltél, az más hasonló tudású HMI-hez képest szerintem kifejezetten drága. Egy hasonló képernyőméretű és -felbontású Schneider pl. ennek a töredékébe kerül, és lépességeiben - LAN, RS485, USB host, ingyenesen elérhető kezelőszoftver - is meghaladja a linkelt Omron-típust.)
-
And
veterán
Ha kontrasztosat akartam volna, akkor biztos valami Siemens-sel jöttem volna elő, lehetőleg valami Ex-es kivitellel
![;]](//cdn.rios.hu/dl/s/v1.gif)
. Amúgy a soros port meglététől lenne a HMI az, ami? Mert az sem mindegyiken van..
Visszatérve a Nextion-okra: ezeknek a legfőbb előnyük az áruk (legalábbis a kis méretű típusoknál). Ezeknél olcsóbban már csak intelligencia nélküli kijelzőmodulokat találtam, amelyekhez biztos létezik valamilyen arduino-s library (bár én eleve nem arduino-hoz szántam), de azért az nem ugyanaz, mint amikor a kijelző egy csomó mindent meg tud oldani 'házon belül', és van hozzá elegendő belső tárkapacitás is. Próbálkoztam régebben 4D Systems modulokkal is, de a hasonló méretű alapjáraton a Nextion árának a duplájába került, és igen erős limitációkkal rendelkezett (például nagyon kicsi tárhelye volt). -
And
veterán
Nem egészen. Vagyis nem csak a soros porton keresztül lehet neki megmondani, hogy bármit is csináljon (a változók értékátadásán túl). Kapsz egy szerkesztőprogramot, amit akár ki is próbálhatsz, ingyenes, és van benne debugger, lényegében szimulátor. Pontosan azért HMI, amiért hasonlít az ipari HMI-khez: pl. nem kell neked minden egyes grafikus elemet külön összerakni, hanem van egy valag előre definiált objektum, amit külön oldalakra szervezve tudsz letenni. ilyenek a gombok, bargraph-ok, szám- és szövegmezők, bitmap-képek, stb. Ezen felül vannak nem látható elemek, pl. belső változók, touch-területek (hotspotok), timerek is. Ezeknek az objektumoknak mind van egy vagy több tulajdonságuk (pozíció, méret, színek, állapotok, szövegtartalom, változók értéke, ..), amelyek változtathatók a HMI-n megírt eseményvezérelt script-ekből, vagy a soros vonalon keresztül. Úgymond önálló programot képes futtatni, változókkal dolgozni, logikai műveleteket végezni és a többi. Ehhez rendelkezésre áll egy csomó belső RAM ill. flash-tár, amelybe a programrészletek (script-ek), grafikus elemek, betűtípusok kerülnek. Vagyis ezek a feladatok az alap kontrollertől - amihez a HMI kapcsolódik - függetleníthetőek, a HMI leveszi az adattárolás, animáció és akár egy csomó logikai művelet terhét az eredeti kontrollerről. Tehát nem egy 'buta' kijelzővezérlő, mint mondjuk az SSD1306, amire bitmap-ként kell kiküldened az utolsó pixelt is, hanem egy önálló mikrogép, amelynek van saját programtára és kijelzője. A felhasználói kódot és adatokat az éles felhasználás előtt ugyanúgy le kell töltened a HMI-re, mint az arduino-ra a saját kódját.
(Van néhány erős hiányossága, amely szoftverből orvosolható lenne, de együtt lehet élni vele. Az például roppant zavaró, hogy nincs egy egységes, egyben áttekinthető 'programod', amit megírhatsz, hanem adott oldalon, adott objektum adott eseményéhez rendelhető egy hosszabb-rövidebb script. Így sajnos a felhasználói kód már eléggé áttekinthetetlen, ha az adott projekt bonyolulttá válik.)[ Szerkesztve ]
-
And
veterán
válasz
Tomika86
#15104
üzenetére
Erős túlbiztosításnak tűnik. A kétlépcsős stabilizálás a hőtermelés szempontjából sokat nem segít, valószínűleg nem lesznek túlságosan távol egymástól a stabok. A 4700 μF-os puffer a bemeneten is soknak tűnik (elvégre nem egy trafó a forrás), a második stabkocka kimenetén pedig egyenesen ellenjavallt, egy stabilizátor vagy LDO eleve nem szereti az ilyesmit. Stabilabb nem lesz tőle, a bekapcsolási áramlökés pedig nem kívánatos. Oda bőven elegendő egy 0,1 / 1 μF-os kerámia, elvégre a 78xx-ek hullámosság elnyomása - bár nyilván frekvenciafüggő - nem annyira rossz érték.
-
And
veterán
válasz
Tomika86
#15106
üzenetére
Függ a várható terhelőáramtól, amúgy annál is jóval - egy nagyságrenddel - kisebb kapacitásértéket szoktak használni. Viszont egy autóban a feszültségtüskék csúcsértéke szélsőséges esetben akár sokszor 10V is lehet, úgyhogy a bemeneti kapacitás tűrési feszültsége is ennek megfelelően választandó, illetve az induktivitás helyétől függően be lehet tenni a körbe szupresszort is. Ötletek: [link], [link].
-
And
veterán
válasz
gyapo11
#15109
üzenetére
Csakhogy nem fog megroggyanni. Az LM78xx adatlapok szerint a Load regulation paraméter értéke teljes (1,5 A-es) impulzusszerű terhelésnél tipikusan 9 mV (!), ami azért nem jelentős. Ennek az adatlapnak a 11. oldalán grafikusan is látható (fig. 13, bár tévesen Line regulation a neve, egyértelműen a terheléstől való függést ábrázolja): [link]. Amitől - bekapcsoláskor - a stabkocka kimenete fulladhat, az épp a túlzottan nagy kapacitású elkó lehet. Nem véletlenül nem ajánlanak ilyesmiket egyik alkalmazási példán / adatlapon sem. Kifejezetten low esr kapacokat (kerámia, esetleg tantál) javasolnak a kimenetre, legfeljebb 1...10 μF-os nagyságrendben.
[ Szerkesztve ]
-
And
veterán
válasz
Tomika86
#15112
üzenetére
Rosszul tudom, hogy a 'hagyományos' 7805-ösökből - ezzel a típusmegnevezéssel - csak 1 vagy 1,5 A terhelhetőségű létezik?
"Nextion 7" kijelző (erre 2A áramfelvételt írnak)."
Mindegyik 7"-os típusra (basic, enhanced, intelligent) 430..530 mA-es fogyasztást írnak. Javasolt tápellátás címén említenek lehetőleg minimum 2A terhelhetőségű tápot, de a valós fogyasztás annak a negyede lesz még maximális háttérfényerőnél is.
Ha valóban 3A-t közelítené az áramfelvétel - a valóságban az összes említett csingilingivel együtt sem fogja -, akkor a 20W-ot meghaladó disszipáció miatt sokkal jobban járnál egy kapcsolóüzemű megoldással (mellesleg azt is meg lehet toldani szűréssel).[ Szerkesztve ]
-
And
veterán
válasz
Tomika86
#15119
üzenetére
Persze. Az adatlap 21. oldalán láthatsz is egy példát (Fig. 34) az opcionális szűrésre, ami egy plusz aluláteresztő LC-tagból áll. Amúgy a tervezett konfigurációhoz nagy valószínűséggel 1A-es terhelhetőség is bőven elegendő lesz, én olyan 6-700 mA körüli fogyasztásra tippelnék.
-
-
And
veterán
válasz
Tomika86
#15222
üzenetére
Ennek a kivitelezése szerintem nem arduino-specifikus. Ha nincs egy 'send', 'ok' vagy hasonló gomb a kijelzőn, ami az értéket elküldené az MCU-nak, akkor szerintem kerülőúton juttathatod be a változót, például:
- rendszeresen, adott időközönként kiolvasod az értékét az MCU-val (get x0.val), vagy
- ugyanezt megteszi a HMI, timer-eseménnyel ciklikusan adatot küld az MCU felé (prints x0.val.0), vagy
- mint az előbb, de a timer event-hez felhasználsz egy temp változót, aminek csak az a feladata, hogy összehasonlítsa az előző értéket az aktuálissal, és ha utóbbi megváltozik, elküldi a beviteli mező értékét (a lényeg, hogy csak egyszer küldje, ne folyamatosan).
Arra ügyelni kell, hogy - mivel a HMI nem ismeri a natív float típust - "Xfloat" mezőből is mindig integer értéket kapsz, ilyen bevitt értéknél a tizedespont helyét és ezzel a kapott szám értelmezését az Xfloat-mező ws0 és ws1 attribútumai adják meg. -
And
veterán
válasz
Tomika86
#15233
üzenetére
A Nextion felől visszaküldött üzeneteket bizonyos szintig be tudod állítani a bkcmd nevű belső változóval. Ha nullára állítod (default értéke: 2), az invalid variables üzenet elvileg nem jön többé, de a buffer overflow továbbra is megmarad. Ennek oka van, bár korábban szerintem már volt erről szó, hogy a debugger ilyen jellegű, soros átvitellel kapcsolatos szimulációja elég sok kívánnivalót hagy maga után. Vagyis a jelenség nem is feltétlenül valós. Azt is említettem, hogy a protocol reparse mode aktiválásával egy csomó probléma kiküszöbölhető, a rendkívül terjengős eredeti adatmennyiség a töredékére csökkenthető, cserébe neked kell a vételi pufferből kiszedni és a kívánt adatformátumra gyúrni a HMI-be beeső adatokat ( u[index] vételi tömb illetve ucopy függvény segítségével).
-
And
veterán
válasz
Tomika86
#15236
üzenetére
Amúgy nem tudom, milyen mennyiségben és mekkora periódussal küldöd be az adatokat, de ha a hagyományos módban elég sok változót adsz a HMI-nek folyamatosan, nagy bitrátával, és nem hagysz elég időt a belső feldolgozásra, akkor biztosan ki lehet akasztani az 1kB-os puffert (parancs + adat + lezárás).
A reparse mode ezen úgy segít, hogy nem kell komplett parancsokat vagy értékadásokat a hagyományos módon beküldened, elegendő csak magát az értéket. Például: az "n0.val=123" parancs a lezárással együtt 13 byte hosszú, protocol reparse módban pedig egyetlen byte-on elküldhető az érték, amit egy script képes a megfelelő helyre / változóba tenni. De még nagyobb értéktartomány esetén sem lesz 2..4 byte-nál hosszabb az üzenet. Mivel ilyenkor adatokat küldesz, nem parancsokat, a visszirányú forgalom (HMI válaszüzenetek száma) is minimalizálható.[ Szerkesztve ]
-
And
veterán
válasz
Tomika86
#15239
üzenetére
Ezt perpillanat csak te tudhatod. Natív adatmennyiségben a komplett képernyőn megjelenő input információ akár 16..18 byte-on is továbbítható. Hogy a lebegőpontos értékeket miért továbbítod text-ként, azt nem teljesen értem, de szerintem felesleges. Xfloat-ként (vagy akár szimplán ponttal elválasztott, byte-méretű értékpárokként) mondjuk 1..2 byte adattal megúszható lenne egy-egy ilyen mező. Ha a hagyományos módon, egyenkénti értékadással, parancsonként továbbítasz ennyi adatot, akkor a korábbi példa alapján az egyszeri frissítéshez is az említett hasznos adat minimum 8..10-szeresét kell karakterként a HMI-be küldeni, ami nagyságrendileg 150..180 byte. Az adatokat másodpercenként pl. 10x frissítve ez már bő másfél kilobyte, bár valószínűleg a számértékeket tartalmazó mezők frissítéséhez ez a ráta túl sok, a mutatós műszerekhez pedig esetleg kevés (bár itt már képbe jönnek a hardveres képességek, illetve hogy pontosan milyen módon animálod a mutatókat).
Én ezt úgy oldanám meg, hogy a szükséges frissítési gyakoriságok okán kétféle - egyenként fix hosszúságú - adatcsomagot küldenék az MCU felől, a HMI-t pedig protocol reparse-ba állítanám: az egyik típusú, ritkábban küldött csomagban lennének a numerikus mezők értékei pl. 16 byte-on (két bevezető + 7*2 byte), a másik, sűrűbben frissített csomagban pedig a mutatóké, mondjuk 6 vagy 8 byte-on.
Azt mindenképpen ki kell majd tapasztalnod (és nem a debugger-ben, hanem a valós kijelzőn!), hogy milyen frissítésnek van egyáltalán értelme a mutatós műszereknél, mert ez nagyon hardver- és megoldásfüggő. De ha jól csinálod, semmiképp nem a szükséges adatmennyiség vagy az átviteli sebesség fogja korlátozni a megjelenítést, mert másodpercenként erre 2-300 byte elég lehet, a 115.2 kbps-es portsebesség pedig adatkerettel együtt 11 kbyte/s hasznos átvitelt adhat. -
And
veterán
válasz
Tomika86
#15246
üzenetére
Azt lenne jó látni (pl. egy terminálprogrammal), hogy mennyi adatot küld valósan ilyenkor az MCU. Nem tudom, mennyi attribútumot lehet megadni egy Xfloat-hoz, de jó sok van neki, és ha több ilyet egyenkénti parancsként leküld az arduino, akkor bizony egy valag töltelékadat lesz a kommunikációban. Mondjuk a Text-nek is van elég tulajdonsága, bár nem annyi, mint az Xfloat-nak.
A nyers adatként szükséges 1..2 byte-hoz képest minden más módszer terjengős. -
And
veterán
válasz
Tomika86
#15495
üzenetére
Többféle lehetőséged is van, de mind kerülőutas. Az első, amit a #15224-ben volt említve (temp változós megoldás). A másik, hogy a numerikus pad bekapcsolása létrehoz egy zárolt képernyőt keybdB néven, ezt unlock-kal felnyitod, és az "OK" gomb megnyomásához írsz egy rövid szkriptet, ami elküld valamit. Ennek hátránya, hogy globális, vagyis ha több numpad-ot is leteszel, mindegyikre érvényes lesz.
-
And
veterán
válasz
Tomika86
#15497
üzenetére
Én így csináltam régebben (nem Nextion mellé, ott az Arduino vezérelte a sokkal egyszerűbb kijelzőt, és egy 'master' kontroller felől kapta az adatokat, de ez lényegtelen):
char msg[64];char term = 0xFE;bool firstc = true;void loop() {if (Serial.available() > 0) {uint8_t msgl = Serial.readBytesUntil(term, msg, 64);if (firstc) {oled.clear();firstc = false; }switch (msg[0]) {case 0:page0();break;case 1:page_IRlearn();break;// ...}}}Az is kiderült, hogy jobban járok, ha a teljes vételi 64 byte-os pufferméretet megadom neki, mert különben néha hibázik.
[ Szerkesztve ]
-
#15511
And
veterán
tonermagus
#15510
And
veterán
válasz
tonermagus
#15510
üzenetére
Ja, látsz egy nyers kódot. Szimbólumnevek, kommentek, ugrási címkék, függvény- és rutinnevek nélkül. Ebben már kiigazodni sem könnyű, de alapszintű módosításokon (pl. egy konstans megváltoztatása) kívül szerkeszteni már nagyon nem egyszerű. Duplikálni jó, meg 'biztonsági másolatnak'.
-
And
veterán
válasz
Tomika86
#15703
üzenetére
"Nextion ha jól tudom tud 3,3Vos adatbusszal kommunikálni."
Olyannyira, hogy bár a tápfeszültségük 5V, a Nextion-ok Tx-vonala konkrétan 3,3V szintű jelet ad. Ezért a kapcsolódó kontroller UART-áramkörének vételi érzékenysége és tápja függvényében esetenként szükség lehet egy szintillesztő beiktatására is. -
And
veterán
válasz
Tomika86
#15735
üzenetére
"Van hátránya az I2C külső ADC ICnek?"
Azon felül, hogy elfoglal néhány pin-t (már ha az ehhez szükséges adatbusz amúgy nem létezik / nem használt), inkább csak előnyei lehetnek: nagyobb felbontás, jobb konfigurálhatóság, differenciális bemenet lehetősége, kisebb zaj, jobb linearitás, egyéb képességek, pl. változtatható előerősítő, stb. -
#15909
And
veterán
tonermagus
#15906
And
veterán
válasz
tonermagus
#15906
üzenetére
Nem úgy tűnik, hogy létezne olyan beállítás, amit szeretnél. A 'Config register A'-ban nem látni ilyet, ahogy a másik két írható regiszterben sem. Van ott átlagolásra illetve adatfrissítési rátára vonatkozó beállítás, valamint két bit (MS1 / MS0), ami elvileg 'mérési konfiguráció', de nem arra való, amit említettél. Ha jól látom, utóbbival egy fix értékű (pozitív vagy negatív eltolású) mágneses teret lehet létrehozni, ami csakis teszt céljára való, és ha emellett a Config register B-ben a Gain beállítása nem megfelelő, akkor szépen ki tudod akasztani vele a szenzort. Valószínűleg muszáj lesz szoftverből átszámolni az eredményt, ami nem tűnik olyan bonyolultnak.
. Mivel ezek egyszerű rádiók, nem tartalmaznak egyéb kontrollert. Van is némi tapasztalatom arról, hogy apró nyűgjeik vannak, például nálam az első 1-2 byte adat 'lemaradt' a vevő kimenetén, tehát meg kellett toldani kissé az átvitt adatot, ami összesen szintén csak pár byte volt. Egyéb tekintetben az említett STX-882 és SRX882 páros bevált: az adó kellően nagy teljesítményű, mindkettő viszonylag normális adatlappal rendelkezik és extraként alig fogyasztanak inaktív állapotban (ha az adóra nem megy adat; a vevőn pedig van engedélyező input, és ezek megléte az akkus üzem miatt nálam fontos szempont volt).
. Én 12F-sorozatú PIC-kel szoktam, nem tudom, van-e ilyen célkontroller készen hozzáférhető kivitelben is. Vagy hogy egy arduino - mondjuk a legkisebb nano - PWM-je rávehető-e erre, talán igen. Bár azt nem igazán értem, miért kell neked valamelyik IR-protokoll szerinti jelet adnod (szimpla folyamatos vivő nem elegendő!) és azt dekódolnod egy egyszerű optokapu helyett. Így az egyetlen előnye a környezeti fény kizárása. Akkor már inkább az a TSSP közelítésérzékelő, bár ahhoz is szükség van legalább egy rövid impulzusokra kapuzott / modulált vivőre.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
. Amúgy a soros port meglététől lenne a HMI az, ami? Mert az sem mindegyiken van..
Új hozzászólás Aktív témák
ekkold
- Suzuki Swift 2005 1.3 GLX CD AC - AndroidAuto & CarPlay
- Bomba ár! HP Elite X2 1011 G1 - m5 I 8GB I 256GB SSD I 11,6" FHD Touch I CAM I W10 I Gari
- Bomba ár! Lenovo ThinkPad T490 - i5-8GEN I 8GB I 256GB SSD I 14" FHD I Cam I W10 I Garancia!
- 8db GeForce RTX 3090 Egyben
- VAST AI - VAST AI - VAST AI - GeForce RTX 3090
Állásajánlatok
Cég: Alpha Laptopszerviz Kft.
Város: Pécs
Cég: Ozeki Kft.
Város: Debrecen