- Gurulunk, WAZE?!
- Luck Dragon: Asszociációs játék. :)
- Argos: Szeretem az ecetfát
- sziku69: Fűzzük össze a szavakat :)
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- eBay-es kütyük kis pénzért
- vrob: Az IBM PC és a játékok a 80-as években
- Magga: PLEX: multimédia az egész lakásban
- zebra_hun: Hűthető e kulturáltan a Raptor Lake léghűtővel a kánikulában?
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
-
LOGOUT
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
.-..-.
#23656
üzenetére
Jól érted, ha csak nem valami elcseszett konstrukció, vagy pl. szerelt pcb, amin már rajta vannak a felhúzók. Esetleg olyan slave is van a vonalon, ami tartalmaz ilyeneket, mint pl. a szokásos SSD1306-modulok (amik bár külsőleg 5V-ot kapnak, de a belső 3,3V-os tápjukra húzzák az I2C-jeleket..).
Megnéztem, hogy mi a helyzet az 5V toleranciával.
- ESP32-nél nincs ilyen IO-pin, úgyhogy bár a gyakorlatban rövid időtávon a beszámolók szerint elviseli ezt a szintet, hivatalosan ellenjavallt, a kontroller meghibásodását okozhatja.
- STM32: itt megúszható a szintillesztés, mivel a gyártó szerint is léteznek FT (five volt tolerant) pin-ek, és az alap I2C-portok mind ilyenek. A megkötés annyi, hogy ilyenkor az adott portok belső felhúzóit szoftveresen nem szabad engedélyezni, ill. a uC tápjának /Vdd/ hiányában nem lehet jelen a pullup-ellenállások túlvégén sem a felhúzó feszültség. Azt sem tudom, hogy szoftveresen át lehet-e portolni más pin-ekre a belső I2C-perifériákat, esetleg olyan GPIO-kra, amelyen nem FT-képességűek. -
And
veterán
válasz
.-..-.
#23654
üzenetére
Aha. Az LTC2990 adatlapja azt mondja, hogy (mivel ennek a tápfeszénél lehet alacsonyabb a buszon mért magas szint) a minimális feszültség, amit HIGH-nek detektál: V_IH = 0,7 * Vdd, vagyis 5V-os táp esetén 3,5V. Ez ugye gond lehet, mert ha 3,3V-ra, a master-eszköz tápjára húznak a pullup-ellenállások, akkor problémás vagy egyenesen lehetetlen lesz az adatforgalom. A másik eset, hogy 5V-ra húzod a buszt, de kérdés, hogy az ESP / STM32 ezt elviseli-e (5V tolerant input, adatlapról esetleg kiderül). Ha nem, akkor két dolgot tehetsz: szintillesztést teszel a buszra, vagy lecsökkented az LTC2990-es tápfeszét, melynek üzemi tartománya 2,9 ... 5,5V.
I2C szinteltolás diszkrét elemekkel: [link], a két vonalra (SDA/SCL) két külön mosfet kell, és mindkét oldalra külön-külön felhúzók szükségesek. -
And
veterán
válasz
.-..-.
#23652
üzenetére
Az I2C-'kimenetek' (az SDA-pin forgalma ugye kétirányú) alapban nincsenek semmilyen szinten, hiszen nyitott kollektoros / drain-es kivitelűek. Ezért a külső felhúzó hozza azokat fix potenciálra, ha a vonal nyugalomban van, vagyis a belső tranzisztorok master és slave oldalon is zártak. Itt a kérdés az, hogy a uC ill. a slave-eszköz (az LTC2990) mekkora konkrét tápfeszültségről jár, és ha a felek tápfesze nem egyezik, akkor el lehet dönteni, hogy milyen szintre legyen felhúzva az I2C-busz. Ez sok tényezős kérdés. Ha a tápok egyeznek, nincs gond, ha nem, akkor több eset lehetséges: az alacsonyabb tápfesszel rendelkező eszköz elviseli-e a pin-jein a nagyobb szintet, vagy fordítva, a saját tápfeszénél alacsonyabbra húzott adatbusz eléri-e a számára dedikált magas szintet. Ha valamelyik eset problémás, szükség lehet szintillesztésre a felek között.
Mod: vagy az egyértelmű, csak nekem nem esett le elsőre, hogy a master (ESP vagy STM32) alacsonyabb tápfeszültséggel, pl. 3,3V-tal működik? -
And
veterán
válasz
Wolfram
#23074
üzenetére
Több ilyen - leginkább Microchip gyártmányú - adatbuszos touch-detektort próbáltam már különböző körülmények között. Fontos kiindulási tényező, hogy mekkora az érzékelő, vezető anyagú szenzorlap és ha van, akkor milyen anyagú és vastagságú felette a szigetelő, pl. üvegréteg. Ezek a detektor IC-k eleve valamilyen mérési ciklusidővel dolgoznak (néhányszor 10...100 ms nagyságrend, ez nagyban meghatározza a chip átlagfogyasztását is), ami azt jelenti, hogy egy akármilyen gyors sweep-et nem feltétlenül vesznek észre. Az érzékelési küszöbérték, erősítés, ciklusidő mind konfigurálható, így be lehet állítani, hogy csak elég határozott felületű és kellő ideig fennálló érintés aktiválja a touch-ot. Nem mellesleg adott időnként teljesen újrakalibrálják magukat, hogy a környezeti hatásokat, statikus kapacitásokat eltüntessék a képletből, így nem lehet mondjuk fél perces folyamatos 'gombnyomást' sem előidézni velük.
-
And
veterán
válasz
Wolfram
#23071
üzenetére
Ezeknek gumiszerű távkapcsoló billentyűzeteknek semmi közük a kapacitív elvhez, eleve nem touch- vagy proxy-szenzorok. Egyszerű kontaktust adnak, csak annyiban térnek el a hagyományos kapcsolóktól, hogy a vezetőrétegük grafitszerű anyag, ezért közel sem nulla átmeneti ellenállást eredményeznek működtetéskor (száz ohm-os nagyságrend jellemző). Sok billentyű esetén mátrixba vannak szervezve.
A valódi kapacitív szenzorok ezzel szemben érintést érzékelnek egy megfelelő méretű fémfelületen, akár a pcb-n kialakítva. Ha az érzékenység és a kapacitásváltozás megfelelő, közelítést is érzékelhetnek pár mm-es szigetelőréteg alatt. -
And
veterán
válasz
GeriSzán
#23048
üzenetére
Ennek a realitása nagyjából annyi, mint ha a fordítottját szeretnéd elérni, Siemens PLC-n arduino kódot futtatni. Ha arra gondoltál, hogy egy viszonylag egyszerű meglévő PLC-logikát átírsz bármilyen mikrokontrollerre (annak saját fordítójával) az más kérdés. De hogy egy teljesen rendszerfüggő xmi / xml projektformátumot nem fogsz megetetni egy μC-vel (egy az egyben), az több, mint valószínű. Ilyesmi még a különböző TIA-verziók között sem magától értetődő, ahogy látom. Amúgy sem egy TIA-szerű drága és óriási szoftverszörnyeteget néznék ki ilyen célra.
#23047: Pedig egy jobb fajta, jól konfigurálható és érzékeny kapacitív touch több milliméter szigetelésen keresztül is érzékelhet, ha kellően nagy a fémfelület alatta. Olyan típusokkal próbálkoztam, amelyek már 20 fF (1/50 pF) kapac. változást is detektálni tudtak, azok simán érzékeltek 2-3 mm műanyag vagy épp rétegelt fa takarólap alatt. -
And
veterán
válasz
Wolfram
#22960
üzenetére
Ez pont egy olyan vevő, amit említettem az előbbi hsz-em végén: nem egy diszkrét jel jön le róla, hanem egy soros adatfolyam, 0,1 ... 10 kbps sebességgel (ezt az adóoldal határozza meg, mivel semmilyen kontrollert nem tartalmaz). Ez az Rx-modul a modulációban hozzá való adóval egy szimplex / egyirányú soros UART-ként használható. Ez az ASK-modul annyiban különbözik attól, amit a #22958-ban linkeltél, hogy ehhez kell egy uC, ami kezd valamit az adatfolyammal, ahhoz meg nem feltétlenül, hiszen az direkt vezérlésre használható DO-jeleket ad.
-
And
veterán
válasz
Wolfram
#22958
üzenetére
Ezek az xx2272-szerű cuccok párhuzamos jeleket adnak vissza vevőoldalon, és ennek megfelelő bemenetekkel dolgoznak az adóik is (tipikusan: nyomógomb megnyom az adón, a vevőn pedig az ahhoz tartozó jelkimenet lesz aktív). Mindössze 2...6 bit hasznos adatról van szó, amelyek független pin-eken jönnek ki a vevőmodulból. Esetedben a hét pin közül kettő tápfesz, egy antenna, a maradék négy pedig a hasznos adat. Ezek az eszközök az elérhető nagyobb, mint félmilliós címtér miatt hasznosak, mert elméletileg ennyi eszköz különíthető el címben anélkül, hogy a másiknak szánt üzenetet dekódolják. De a hasznos adat csak az a pár bit, talán egymástól függetlenül is vezérelhető (bár ez sem egyértelmű), ami legfeljebb 16-féle kombinációt adhat.
Ha ennél összetettebb adatátvitel kell, akkor valami normális soros vezérlésű Rx/Tx modulpár ajánlott, amibe annyi adatot küldesz be és úgy dekódolod a vevő kimenetét, ahogy tetszik. Ezekkel lényegében egy vezeték nélküli UART-ot kapsz. ([link]
). -
And
veterán
válasz
Wolfram
#22832
üzenetére
Ha belegondolsz, maga az IR-sugárzó és a detektor is műanyagházas, szóval van olyan fajta, amin átmegy. Gyári készülékeken is sokszor műanyag takarólap mögött van az IR-vevő. Itt eleve NIR-hullámhosszról van szó, a láthatóhoz nagyon közeli 850..900 nm környékén. A plexi /akril/, polikarbonát majdnem teljesen átlátszó ebben a tartományban. Egyébként célszerű lehet a detektor IC-t (TSOP xxxx) nem olyan kivitelű PCB-n használni mint a fotón látható, mert ebben a formában nehéz az előlap közelébe szerelni.
-
And
veterán
Abból kiindulva, hogy a ledek degradálódása a melegedéssel erősen fokozódik, én kerülném a direkt napsütést, pláne ha az pl. üvegablak mögötti elhelyezéssel társul egy szellőzés nélküli szekrényben. OLED-ekre ez valszeg. fokozottan igaz. LCD-k, ipari HMI-k sem szeretik ezt hosszútávon (bár ez ügyben hiába szoktam tépni a szám
). Talán egy kisebb-nagyobb árnyékoló lemezzel vagy kedvezőbb tájolással lehet segíteni a problémán, csak ez nem mindig járható. -
And
veterán
Hi! Az OLED már csak ilyen, biztos hogy idővel fárad. HD44780-kompatibilis LC-kijelzők ledes háttérfénye is eléggé el tud gyengülni, ha folyamatosan üzemel.
A korábban itt felvetett szoftveres PWM nem igazán járható, mivel az SSD1306 és közeli rokonai (pl. SH1106) max. 400 kHz-es I2C órajellel működnek, ami összességében és felbontástól függően mindössze kb. 40..60 fps-t jelent, ha a teljes kijelzőt állandóan frissítjük, ráadásul ez eszi a kontroller hasznos idejét. Vastagabb vonalaknál az 1 px-es tologatás sem javítana sokat.
Viszont: az SSD1306-nak van egy kontraszt nevű - lényegében fényerőt meghatározó - 8-bites parancsregisztere, címe 0x81, azzal szépen le lehet csökkenteni a pixelek fényét. Szerencsére már a default értéke sem a full fényes, hanem a lehetséges maximum fele (127-es a 255-ös skálán). Tapasztalat alapján a tartomány alja nem annyira lineáris, de azért meglehetősen haloványra lehet állítani. Én egy alkalmazásban kijelző timeout-nál néhány tizedmásodperc alatt szépen ledimmelem a kontrasztot egy menüben beállítható értékre, ami lehet 1, de akár nulla is. Némelyik SH1106 esetén alacsony kontrasztnál néha vibrálni kezd a kijelző, kásásodik a kép, de ez eléggé kivitelfüggő, ahogy észrevettem. -
And
veterán
Ja, én a mouser-nél néztem, elég jó parametrikus keresőjük van. Közvetlenül is lehet tőlük rendelni, de létezik hazai képviseletük (sajnos üzletük nem), ami kis tételeket is beszerez. De kis darabszámban, egyéb egzotikus alkatrészek nélkül tényleg nem annyira nyerő onnan hozatni.
Amúgy én is feltenném PHM kolléga korábbi kérdését: miért nem jó ilyen célra NPN bipolárt használni? 'Nyitófeszültségben' verhetetlen (valójában áramvezérelt eszköz), bőven 1 mA alatti vezérlő- (bázis-) árammal képes kihajtani egy 50 mA áramigényű terhelést, és akkora kollektoráramnál 200 mV alatti (szaturációs) feszültség maradhat rajta nyitott állapotban. Szinte bármely normális kisjelű típus megteszi, akár a BC182 is. -
And
veterán
"Azt hittem, h itt a gate-source threshold voltage-et elég néznem, és a MAX érték (3V), amikor már teljesen nyit."
A küszöbfeszültség egy adott, elég alacsony drain-áramra vonatkozik (ami itt 1 mA). Ennél sokkal érdekesebb, hogy a 'normál' terhelésekhez / csatornaáramokhoz mekkora nyitófeszültség szükséges, mert lássuk be, 1 mA az édeskevés, bármely MCU kimeneti portja ennél önmagában is minimum egy nagyságrenddel nagyobb terhelhetőségű. Releváns adat az 5. oldalon látható 5-ös ábra görbeserege: itt látható, hogy 3V-os Ugs mellett még 100 mA-t sem tudunk kivenni az eszközből, a névleges DC-maximum 200 mA-hez pedig közel 4V-os Ugs kell. Hasonló a transzfer karakterisztikáról is leolvasható (6. oldal, 6-os ábra). Mellette a 7-es ábrán látható a 'nyitott' csatorna ellenállása (Rds_on) a nyitófeszültség függvényében, ezen is feltűnő, hogy alacsony Ugs-értéknél a D-S között sokkal nagyobb ellenállás marad a normális nyitófeszültségekhez képest.
A BSS138 például már 2V-os Ugs-nél képes közel 200 mA-es drain-áramot adni, jóval kisebb csatornaellenállás mellett. Igaz, ez csak SMD-tokban létezik. A 2N7000-rel megegyező tokozásban (TO-92) hasonló logic level típus pl. a TN0106. -
And
veterán
(A 2N7000-es egy eleve nem túl nagy áramú (max. 200 mA DC) mosfet, amelynél a 3,3V-os nyitó- (Ugs-) feszültség már igencsak necces. Ekkora Ugs-nél a 'nyitott' csatorna ellenállása is meglehetősen nagyra adódik, az adatlapon már nincs is feltüntetve 4V-os érték alatt. Néhányszor 10 mA-es draináramhoz még elmegy ekkora nyitófesszel is, de azért eléggé határeset, ennél nem nehéz sokkal jobb paraméterekkel rendelkező típust találni.)
-
And
veterán
válasz
Wolfram
#18762
üzenetére
RF-szempontból sok mindent lehetne rá mondani, de hogy abszolút csúcsmodell lenne, az nem is enyhe eufemizmus
. Konkrétan a létező leggagyibb megvalósítás, amit a vevőpanelen látni: sehol egy kvarckristály vagy KF-szűrő, csak hangolt LC-körök. Ez pedig érzékenységben, szelektivitásban és stabilitásban sem szokott jót jelenteni. Egyedül a könnyen konfigurálható és kellően nagy címtér az, amiben erős.
A gombok számához: a vevőn látható dekóder (SC2272-M4, alias PT2272-M4) összesen 4 adatbitet képes kihámozni a vett adatfolyamból, ezért látható csak ennyi nyomógomb az adón. Igazából nincs köze se a frekvenciához, se a csatornához. Valójában ez a rendszer meglehetősen pazarlóan bánik a rádióspektrummal, mivel eleve egy 10 kHz nagyságrendű órajellel / modulált segédvivővel küldi meg az UHF-sávú adófokozatot. -
And
veterán
("Több eszköz esetén azért nem jelent problémát, mert tudtommal eszközönként kellene egy-egy 4,7k ellenállás (/fixme)."
Nem így van, egyébként magad is leírtad, hogy miért. A komplett busz két vezetékére kell összesen egy-egy felhúzó. Ha minden slave-hez tennénk, azok párhuzamosan kapcsolódnának, és mivel egy időpillanatban csak egy eszköz lehet aktív - hiszen a busz közös, egyszerre csak egyvalaki 'beszélhet' rá az adatvonalra -, annak a buszmeghajtó tranzisztora károsodhatna. Bár utóbbi elég extrém eset, csak rengeteg slave és eleve alacsony egyenkénti felhúzó mellett volna realitása, egyébként is feleslegesen nagyra adódna a felhúzóáram. Az is igaz, hogy az I2C a gyakorlatban viszonylag igénytelen, nem kíván pontos értékű felhúzókat, erre elég széles ellenállástartomány szóba jöhet. De - ahogy arra utaltál - a nagyobb sebességű átvitelhez a uC-k belső portfelhúzója /sokszor 10 kΩ nagyságrend/ általában túl nagy, azokkal a busz jellemzőitől /hossz, vonali kapacitás, slave-ek darabszáma/ függően nem feltétlenül tud kialakulni a megfelelő meredekségű négyszögjel a buszon. Szoftveres I2C-hez, maximum néhányszor 10 kHz-es busz-órajelhez még talán elmegy, de az SSD/SH oled-ek 400 kHz-es buszsebességet tudnak és akad olyan slave is, ami bőven 1 MHz feletti I2C-órajel mellett is képes kommunikálni.) -
And
veterán
válasz
#70211840
#18628
üzenetére
Ugyan a szerelt I2C-slave eszközök részére (modul szintre) nem túl szerencsés dolog felhúzókat tenni, mivel több is lóghat belőlük ugyanazon a buszon, az SSD1306 modulok ebből a szempontból kivételek. Van rajtuk felhúzó 2 x 4,7 kΩ formájában, ezek ki is mérhetőek a modul kikapcsolt állapotában egy multiméterrel az SCL <-> 3,3V ill. SDA <-> 3,3V között (itt a 3,3V-ot a belső stabilizátor kimenetére értjük), mivel itt nem a modul szokásosan 5V-os külső tápjára vannak felhúzva a vezérlőjelek.
A 0,96"-os (128 x 64 pixeles) SSD-modulok fogyasztása különben kontraszt- (fényerő-) és képtartalom-függő, kikapcsolt pixelekkel néhány milliamper, ami kijelzéstől függően 20 mA fölé is emelkedhet. Semmiképp nem egy nagyfogyasztó. -
And
veterán
válasz
t72killer
#18602
üzenetére
(Azért - ha az adatlapja hihető - egész szép adatokkal rendelkezik az a HC-12 modul. Egy 1 km-es linken ideális esetben, mindkét oldalon alap 2 dBi-s dipólokkal is lesz > 55 dB tartalék. Ennyiből 'valós körülmények' /bár ez ugye elég tág fogalom/ között is maradhat értelmes jel, ráadásul nem csak alap dipólokat lehet használni 433 MHz-en, legalább az egyik végpontban. Használtam már normális vevőmodult, az is jól teljesített, pedig csak tekercsantenna volt rajta és az érzékenysége is rosszabb volt 10 dB-lel, mint az említett típusé.)
-
And
veterán
válasz
#70211840
#18446
üzenetére
Ok, de gombelemek méréséhez nem kell 50V-os méréshatár, se 1:10 feszültségosztó, ha egyébként más forrásból van 5V-os referenciád. Ebben az esetben akár a kontroller analóg(nak konfigurált) bemenetére is mehet közvetlenül az elem feszültsége. Annak esetleg érdemes utánanézni, hogy egy ilyen AI-port mekkora impedanciával terhel (vagy mekkora lehet a szivárgóárama), de általában elég naggyal. Elemmerülés jelzéséhez egyébként belső komparátor is megfelelhet, ha az adott uC rendelkezik olyannal.
-
And
veterán
válasz
#70211840
#18435
üzenetére
Hálózat / fázisfigyelés: célszerűen egy optocsatolón keresztül érdemes megoldani. Példák: [link], [link]. Feladatfüggő, hogy mennyire szükséges szűrni a uC felé szánt jelet (mekkora időállandóval, csak a fázis jelenléte érdekes, kimaradt félperiódusok számlálása is kell-e, stb.).
Feszültségmérés: a konkrét megoldás itt is a körülmények függvénye. Ha a mérendő forrás terhelhető (pl. tápfeszültség), akkor egy natúr ellenállásosztó elegendő, lehetőleg 10 kΩ-ot nem meghaladó forrásimpedanciával a kontroller felé. Ha pufferelés (nagy bemeneti impedanciával kell fogadni a mérendő jelet) és / vagy túlfeszültségvédelem is szükséges, akkor egy opa-fokozattal (pl.: [link]) kiegészíthető az eredeti feszültségosztó, amelynek tagjai ebben az esetben jóval nagyobb értékűek is lehetnek. -
And
veterán
válasz
ReFleXx
#18352
üzenetére
(Egy szem Li-cellához és 3.3V-os kimenethez jó szívvel nem ajánlanék hagyományos lineáris stabilizátort, LDO-t. Lehet akármilyen kicsi is a dropout - bár várható fogyasztást vagy terhelhetőséget nem írtál -, azért pár tizedvolttal mindenképp számolhatsz, ami praktikusan azt jelenti, hogy a cellában tárolt energia kisebb-nagyobb hányada LDO-val kihasználhatatlan lesz. Ilyen feladatra inkább buck-boost DC-konverter való, annak minden előnyével / hátrányával. Pl.: [link], ez 600 mA-es, nyugalmi árama < 0.2 mA, Ube: 3...15V.)
Mod @Aryes: na, mire leírom
. -
And
veterán
Jellemzően telefonhoz készült modem IC-k köré (pl. AM7910: [link], TCM3105) épült, soros COM-portról vezérelt félduplex megoldások voltak adás-vétel vezérléssel, kizárólagos adatátviteli móddal. Vagyis nem a fónia mellett, hanem azt kizárva működtek. Létezett diszkrét elemekből épített, nem cél IC-s kapcsolás is, de az jóval kevésbé volt megbízható. Egyébként sokban hasonlított a wifi-hez, csak utóbbiból a kezdeti 802.11b is sokkal, úgy 3..4 nagyságrenddel nagyobb adatsebességgel (meg nyilván sávszélességgel) ment: korlátozott hosszúságú adatcsomagok oda-, majd arra visszaigazolások visszafelé. Fájlokat is lehetett küldeni, volt csomagrádióhoz a komplett működést összefogó kliensprogram. Az effektív átviteli ráta a félduplex üzem, a visszaigazolások és az adás-vétel váltások okán jóval kisebb volt a nyers jelzési sebességnél, lásd megint csak a wifi-t. Egy kapcsolás TCM3105-tel: [link], BayCom-modem néven lehet találni ilyesmit, ma valószínűleg jóval kisebb méretben is össze lehetne hozni, jó részét szoftverből megoldva.
-
And
veterán
(Avagy hogyan csináltak a rádióamatőrök már évtizedekkel ezelőtt is digitális átvitelt a hangsávon: pont úgy ahogy írod, AFSK- vagy FSK-modulációval. A '90-es években élte virágkorát a 'csomagrádiózás': helyi elérésű node-okkal és a közöttük kiépült nagytávú linkekkel egész nagy távok voltak áthidalhatóak akár egy szimpla kézirádióval /miután annak csak a közeli csomópontot kellett elérnie/. Jellemzően 1200 bps-es AFSK-val és 9600 bps-es AFSK-val működtek. Konkrét céláramkörök léteztek rá, nekem is van egy akkori recept alapján készült példányom 1,2 kbps-re.)
-
And
veterán
válasz
daninet
#17959
üzenetére
Képtalálatok: [link], itt tényleg csak az RC-tagok (a jelúttal soros R- ill. utána a 0V felé kötött C-tag) érdekesek. A konkrét értékük több tényező függvénye lehet, mint pl. a PWM frekvenciája, a szükséges időállandó (R*C érték) vagy épp a vezérelt áramkör bemeneti impedanciája. Ha a PWM frekvencia és a fogadó áramkör impedanciája kellően magas, akkor elég széles tartományból válogathatunk, de alapesetben néhány kΩ és pár µF megfelelő.
-
And
veterán
válasz
daninet
#17957
üzenetére
Ehhez nem kell feltétlenül analóg kimenet. Egy kellően magas frekvenciásra állított PWM-kimenet és egy külső aluláteresztő / integráló szűrő (egyetlen RC-tag formájában) is megfelelő lehet. A kitöltési tényező változtatásával az RC-tag után egy változó DC-szintet kapsz. Ha a PWM-kimenet 5V-os, akkor 0..100% kitöltésre 0..5V DC-t kapsz.
-
And
veterán
Nem tudom, csak kérdezem: a dolog nem úgy működik, hogy valójában akkor sem marad ki megszakítás, ha több forrása is lehet, csak a később érkezőnek a végrehajtása késlekedhet kissé as ISR futásidejének függvényében? Legalábbis a legegyszerűbb 8-bites uC-k esetén így történik: ha már az ISR kódja fut, egy beérkező újabb interrupt-igény miatt azt nyilván nem fogja újra megszakítani vagy újraindítani a kontroller. Szépen végigfut, de utána lényegében azonnal újraindul az interrupt kiszolgáló rutint, hiszen az újabb megszakítást jelző belső flag már beállt addigra, és az nem vész el (feltételezve, hogy az ISR-ben nem törlünk ész nélkül minden ilyen flag-et akkor is, ha az adott megszakítást nem az váltotta ki). És akkor még mindig csak a legegyszerűbb, egyetlen megszakítási vektort használó és többszintű prioritást nem ismerő kontrollerről van szó.
A minél rövidebb ISR persze mindenképp előny, hiszen időkritikus alkalmazásnál, pl. nagyobb felbontású időmérésnél nagyon nem mindegy, mikor kapja meg a vezérlést az ISR. -
And
veterán
válasz
Tomika86
#17409
üzenetére
"Azt ki tudom deríteni valahogyan, hogy a nextion küld e vissza valami hibát?"
Erre való a 0..3 között paraméterezhető bkcmd rendszerváltozó: [link]. Default értéke 2, vagyis hibás soros parancs esetén mindenképpen visszaküld egy byte-ot 0x00..0x23 közötti értékkel, melyek értelmezése a 7. pontban (Format of Nextion Return Data) látható. Ha a bkcmd értéke = 1, akkor csak a sikeres parancsok után küld visszajelzést a Nextion (0x01). Vannak olyan üzenetek is, amelyek nem tilthatóak, tehát a bkcmd = 0 beállítás után is megkapod azokat (0x24-től felfelé, lásd a linkelt oldal alján). -
And
veterán
válasz
Tomika86
#17407
üzenetére
Mármint hogy lehet-e egy picture elem globális? Elvileg igen, de csak egyetlen attribútuma módosítható futás közben a kódból, a .pic elem, a tárolt kép sorszáma. Kérdés, hogy mi lenne a cél. Az eltüntetés / megjelenítés például megvalósítható máshogy is (vis parancs).
Amúgy a p[ ].b[ ].val szekvencia helyett az eredeti néven is elérhető egy globális változó egy másik oldalról (elé kell írni a változót tartalmazó oldalt, pl.: page2.n0.val), de az előbbi indexelős módszerrel scriptből pl. több elem paraméterének vagy értékének módosítása for vagy while ciklusban is megoldható. -
And
veterán
válasz
Tomika86
#17403
üzenetére
"Azt is próbáltam, hogy első ciklusban elküldök minden adatot a kapcsolós oldalra, de ha nem azon vagyok akkor hiába küldöm el."
Milyen formában küldöd olyankor? Megfelelő a változók neve? Mert ugye hiába globális egy változó, ha nem azon az oldalon vagy, amelyiken létrehoztad, akkor az eredeti nevével nem tudsz rá hivatkozni, csak a p[x].b[y].val formátummal, ahol x az oldal sorszáma, y pedig a változó eredeti (a létrehozó oldalon kapott) id-je. -
And
veterán
válasz
Tomika86
#17401
üzenetére
Nálam is nyilván a uC küldi az adatokat, csak más szervezéssel, de nem ettől függ a végeredmény. Biztos megoldható a default parancsküldős módszerrel is + oldalanként szeparált adatokkal, csak akkor késleltetett lesz az oldalváltás (ugye meg kell várni az adott oldal összes változójának beérkezését), vagy mindig az összes adatot el kell küldeni a Nextion felé, oldaltól függetlenül. Emlékeim szerint ezzel volt problémád az elején is, mondván úgy nem lehet túl gyors a frissítés, hosszúra nyúlhat a ciklusidő. Erre írtam akkor, hogy - az egyébkén elég hiányosan dokumentált - reparse-mód lehet erre univerzális megoldás, mert azzal jóval kevesebb adatot kell mozgatni a kontroller és a Nextion közt. Én utóbbinál maradtam, így minden ciklusban beesik egy ugyanakkora, de nem túl terjengős méretű tömb a Nextion vevőpufferébe, amely az összes létező adatot tartalmazza, nem csak azokat, amelyek egy adott oldalon fordulnak elő. Oldalváltáskor ezzel már eleve rendelkezésre áll ad adat pufferben, csak ki kell tenni a megjelenítendő változóba a preinit-ben.
-
And
veterán
válasz
Tomika86
#17399
üzenetére
Én úgy oldottam meg, hogy az adott oldal preinitialize event szekciójában szépen feltöltöttem a változókat megjelenítő mezőket a vételi pufferből ( u[ ] tömbből ) kivett adatokkal. Mondjuk nálam a normál megjelenítés is hasonlóképp történt, csak akkor egy időzítő által indított timer event script végezte ugyanezt. Eleve reparse-módban használtam a kommunikációt, vagyis pufferből halásztam elő az adatokat (master felőli parancsküldés helyett).
Gondolom olyan módon is megvalósítható - alapértelmezett / parancsküldős kommunikáció mellett -, hogy az 'új' oldal változóit globálisként definiálod, és az 'előző' oldal elhagyásakor (page exit event segítségével) azokba beleírod a szükséges értékeket. -
And
veterán
Ez egyébként igaz (ipari PLC-k sem szokták óriási impedanciával fogadni a DI-jeleket), de nyákon vagy készülékházon belül megteszi a belső fel/lehúzó. Lehet persze bolondbiztosra tervezni, de azért túlzásokba nem kell esni. Egy hidegítő, pl. kerámia kapac lehet, hogy hasznosabb a bemeneten, mint a túl alacsony felhúzó.
-
And
veterán
válasz
Tomika86
#17374
üzenetére
Már csak az a kérdés marad, hogy ezekhez ilyen célra minek egyáltalán bármilyen külső ellenállás? Az ESP32 adatlapja szerint a portok nagyobbik része fel- és lehúzásra is programozható (45 / 45 kΩ), az MCP23..-as sorozatnál pedig mind a 8 vagy 16 porton támogatott a belső pull-up (100 kΩ), ha az adatirány inputnak van állítva..
-
And
veterán
válasz
Tomika86
#17372
üzenetére
Látatlanban, a konkrét áramköri részletek ismerete nélkül nehéz meghatározni a 'jó' értéket, de a korábbiak értelmében a tartomány elég tág lehet, inkább csak a nagyságrendet kell belőni. Például egy nagy impedanciás uC bemenetére kötött nyomógomb fel/lehúzója széles ellenállás-tartományban rendben lesz. Ilyen helyen a rajz szerinti 4,7 kΩ simán helyettesíthető 10 kΩ-mal. De mondjuk egy I2C-busz felhúzóinál már necces lehet ekkora eltérés (relatív nagy busztávolság és sebesség esetén különösen).
-
And
veterán
válasz
Tomika86
#17370
üzenetére
Értelemszerűen változik tőle a fel- vagy lehúzóáram. Ezen túl a következőket befolyásolja: bemeneti impedancia ill. áram (ha bemenetet van), kimeneti terhelőáram (ha pl. OC / OD-kimeneten). Alapértelmezett szinttől és az elhúzás irányától függően a nyugalmi fogyasztásra is hatással van, ami telepes / akkus táplálásnál lehet érdekes. A fel- vagy lehúzó értéke általában kompromisszum eredménye: az ellenállás nem lehet túl alacsony a nagy áramigény miatt, de adott körben túl magas sem, mert akkor a feladatát - határozott szintre húzás - sem feltétlenül látja el.
-
#17325
And
veterán
tonermagus
#17322
And
veterán
válasz
tonermagus
#17322
üzenetére
Itt egy lehetséges és igen általános védőáramkör: [link]. A graetz híd felesleges (meghamisítaná a mérést), viszont az ellenállásosztó a mérendő tartomány miatt nyilván nem hagyható el a linkelt megoldás bemenetéről. Arra ügyelj, hogy a kontroller analóg bemenete felől nézve a forrásimpedancia - az Rs ellenállás plusz a rajzon nem szereplő feszültségosztó tagjainak párhuzamos eredője - lehetőleg ne legyen nagyobb 10 kΩ-nál.
-
#16930
And
veterán
razorbenke92
#16921
And
veterán
válasz
razorbenke92
#16921
üzenetére
Kösz (gyapo11-nek is), ma is okosabb lettem. Látszik, hogy Arduino-val még nem PWM-eztem sosem
.. -
#16920
And
veterán
tonermagus
#16917
And
veterán
válasz
tonermagus
#16917
üzenetére
Még mindig nem világos, hogy pontosan mit (milyen megoldást) szeretnél. Dimmeléssel indítottál, amiből ezen hsz-ed alapján kapcsolgatás lett - bár az igaz, a PWM-es dimmelés is 'kapcsolgatás' -, eggyel előtte pedig analogwrite-os lehetőség. Tehát: analóg vagy PWM? A közvetlen mosfet-es analóg vezérlés több okból is problémás, a lehetséges erős disszipáció miatt és az átviteli karakterisztika nem teljesen lineáris jellege okán sem tökéletes. A pozitív ág vezérlése sem előny, mert a rendelkezésre álló uC kimeneti feszültségnél nagyobb vezérlő (gate-) feszültséget és / vagy p-csatornás mosfetet igényel külön meghajtással, vezérlőszint-eltolással. A PWM-es meghajtásnál nincs - jelentős - disszipáció és a vezérelt eszköz átlagárama is lineáris összefüggésben marad a PWM kitöltési tényezőjével.
"Továbbá az ellenállás/kondi méretezés sem annyira világos."
Itt milyen ellenállásra vagy kondenzátorra gondolsz? Alapesetben (lásd a #16910-es rajzot) egy mosfethez egyik sem kell. Kapac kifejezetten hátrány egy PWM-es vezérléshez, nagyobb frekvenciájú vezérlésnél eleve probléma lehet a mosfetek gate-kapacitása, mert meghajtóáramot igényelhet. Mod: gate-source (n-csatornás gate-et GND felé húzó) ellenállás nagyságrendileg 100 kΩ.
Mosfet típus nagyon sokféle szóba jöhet határadatok (disszipáció, Uds_max, Id_max), Rds_on érték, kivitel, tokozás, vezérlési mód szerint. -
And
veterán
Egy aktív kapcsolat nélküli AP kizárólag beacon frame-eket sugároz, abban pedig legjobb tudomásom szerint nincs abszolút / RTC-időkód. Csak egy mikroszekundum alapú, a bekapcsolástól számított időzítőt (timestamp) tartalmaz, ami az egyes állomások közötti szinkronizálást segíti.
-
And
veterán
válasz
ekkold
#16866
üzenetére
Használtuk régebben mindkét félét. Először persze nem voltunk tisztában vele, hogy egyáltalán többféle mechanikai osztással is létezik
. A megoldás az lett, hogy nem tettünk különbséget a kódban a rotary típusa szerint. Itt eleve többféle értelmezés is lehetséges, a korábban említett csupán két él figyelése szerintem például nem teljesen korrekt. A teljes és egyértelmű kapcsolási periódus mindenképp négy élből áll, csupán kettőt figyelembe véve félútról visszatekerhető az encoder, ami helyzettől és ízléstől függően furcsán hathat (mivel ekkor az általad 'dupla lépésesnek' nevezett kivitel anélkül ad egy-egy teljes oda-vissza jelzést, hogy akár egyszer is fix mechanikai állapotba lépett volna). A tapasztalat viszont az volt, hogy ha mind a 4 él meglétéhez kötöttünk egy lépést, akkor viszonylag gyakran hibázott, ezért kompromisszumként három éllel megelégedtünk. A hibázás (lépés kihagyása) ekkor elhanyagolható lett, és elmaradt a téves előre-hátra működés is. Persze hardverből is rásegítettünk, ahogy írtad, RC-szűrést (2,7k / 1nF) kialakítva. Gyári készülékeken sem mindig tökéletes a rotary, a mi megoldásunk sem lett annál rosszabb, egész nagy tekerési sebességig használható maradt. -
And
veterán
válasz
Dißnäëß
#16785
üzenetére
(Hogy jó hír is legyen, maga a koncepció működőképes lehet, csak nem azzal a nyamvadt HEstore-os típussal. Abból a doksiból, amit belinkeltem az is látszik, hogy létezik olyan szuperkapacitás is, ami jelentősebb áramokat képes leadni. Például ezzel a sorozattal készített valaki egy 'UPS-t' DIY-projektként: [link]. Ebben 6 db 2.7V / 100 F-os kapaccal a leírás szerint 12V-on 1 perces áthidalást ért el kb. 600 mA-es terhelés mellett. Az egyetlen szépséghiba a kapacitások ára, jelenleg 20 GBP körül lehet beszerezni 6 db-ot ebből a fajtából az ebay-en. Ennyiből meg már Li-io cellás mini UPS is építhető, és a szuperkondik élettartama sem végtelen.)
-
And
veterán
válasz
Dißnäëß
#16776
üzenetére
Próbálkozhatsz egy ilyen szuperkapacitással, de csalódni fogsz. Érdemes végigböngészni az adatlapját egy ilyen alkatrésznek, és itt nem a HEstore által linkelt egyoldalas ismertetőre gondolok, hanem pl. erre: [link]. Ez a doksi elég jól tisztába teszi a felépítését és a képességeit, ebből leszűrhető, hogy nem alkalmas az általad elképzelt célra. Eredetileg valóban készenléti táplálásra való, de jóval kisebb terhelésekhez. Egy gombelemet képes kiváltani, de a hasznos terhelhetősége még annál is jóval kisebb. Amit linkeltél, egy standard kivitelű alkatrész (NF-sorozat), ebből az 1 F-os típus maximális kisütőárama 1 mA lehet, lásd a 15. oldalon. Eléggé összetett a helyettesítő áramköre, amelyben a névleges kapacitáshoz meglehetősen nagy belső ellenállás tartozik (pontosabban sok eltérő apró részkapacitás és az azokkal soros szintén eltérő értékű ellenállások). A nyers kapacitásadat 'nagy' terhelésnél itt nem sokat jelent. Úgyhogy az általad felsorolt összetevők közül - jó esetben - egyedül az RTC-t lenne képes értelmes ideig elvinni, vagy magát az MCU-t, de utóbbit is inkább csak alvó állapotban, az SRAM-tartalmat megtartva.
-
And
veterán
Először is fordítsuk vissza a nevezéktant. A tranzisztor állapotait egy szelephez hasonlíthatjuk: nyitva van, ha áram folyik rajta, és zárva, ha nem folyik az áram. Azon a rajzon a relé a vezérelt eszköz: ha a tranzisztor kinyit, a relé meghúz. Vagyis a relével párhuzamos dióda (gondolom ezt akartad írni) dolga nem a relé 'földre húzása'. Az a dióda csak akkor nyit ki (-> kezd el vezetni), ha a katódja negatívabb az anódnál. Belátható, hogy ez alapesetben, statikus állapotban sosem következik be, hiszen nyitott tranzisztor / meghúzott relé esetén záróirányú feszültség van rajta, zárt tranzisztor / elengedett relé mellett pedig konkrétan nulla. A dióda dolga annyi, hogy a relé behúzótekercsén a kikapcsoláskor (a relé elengedésekor) megjelenő tranziens, negatív irányú feszültségcsúcsot eltüntesse. Ezért ellenállással több okból sem lenne helyettesíthető: utóbbi egy lineáris alkatrész, nem félvezető, és a relével párhuzamosan kapcsolva csak a bekapcsolt / nyitott tranzisztoron átfolyó áramot növelné mindenféle lényegi haszon nélkül.
-
And
veterán
válasz
Dißnäëß
#16522
üzenetére
Nem bonyolítod túl, illetve csak egy kicsit. Például felesleges LC-szűrés, ha a PWM frekvencia elég magas és a vezérelt eszköz egy tranzisztor / mosfet. Bőven elegendő lehet egy sima egy RC-tag is. Az is számít, hogy mekkora felbontás kell, de az eredendően a PWM-nél sem alacsony, illetve a konkrét áramköri környezet is behatárolhatja a megvalósítást. A digitális potméter sem csodaszer, a szimulált ellenállás / csúszóérintkező potenciálja nem lóghat ki az IC tápfesz tartományából. Sokszor használtam már RC-szűrt PWM-et DC vezérlőjel helyett, az adott célra tökéletesen megfelelt.
-
And
veterán
válasz
Tomika86
#16148
üzenetére
Alapban jónak tűnik, bár a ciklusban így nem nagyon van késleltetés. A command-ként beküldött 0x0C viszont nem oké, ha single ended konfigurációban kapcsolod az ADC-re a mérendő feszültséget. Utóbbi esetben a COM-pin a negatív referencia (= GND), ehhez pedig az SD-bitet 1-be kell állítanod (COM = 0x8C).
-
And
veterán
válasz
Tomika86
#16143
üzenetére
(Ezt csak úgy megkérdezem: miért kell annyira library-függővé tenni ennek az ADC-nek a működtetését? Az összes I2C kommunikáció 2 byte /cím + parancs, utóbbi mindössze hat hasznos bitet tartalmaz/ beírásából majd 3 byte /cím + 2 byte eredmény/ kiolvasásából áll. Nem lenne egyszerűbb ezt natív I2C-parancsokkal megoldani? Tényleg nem tudom, mit ad még ehhez hozzá a library, mert nem ismerem. De az ADC nyers kezelése sem egy űrtudomány.)
-
And
veterán
válasz
Tomika86
#16125
üzenetére
Ja, hogy ez még mindig a mutatós / Nextion-os projekt
. Nem halott ügy, de akkor sincs szükséged sok ezer minta / szekundumos sebességre, maximum néhányszor 10-es nagyságrendben. Igen, az ADC maximális sebessége 50 kSps, de ez csak az általa támogatott legnagyobb I2C-órajelnél realizálható, mivel utóbbi gátat szab a nagyobb konverziós rátának. A standard 100 kHz-es I2C mellett a ADS7828 legnagyobb elérhető sebessége adatlap szerint 2000 sample/sec.
Az ADS111x-ek 16-bites, nem is túl gyors ADC-k, szerintem 'analóg' kijelzéshez túlzás ekkora felbontás. Jó az ADS7828 is, de nagyobb sebességnél valóban kis forrásimpedanciát igényel, vagy egy külső követő / puffererősítőt (pl. 1x-es rail-to-rail OPA-kapcsolás formájában). -
And
veterán
válasz
Tomika86
#16122
üzenetére
Az adatkiolvasás (amit megelőz a command byte beküldése, ami ténylegesen indítja a konverziót) sebessége annyi, amennyit az I2C-master konfigurációnál megadsz. Valójában nem a kiolvasás sebessége az érdekes, hanem a teljes A/D-konverziók egy másodperc alatti száma, bár lehet, hogy te eleve ezt értetted alatta. Ez egy SAR-regiszteres ADC belső pufferfokozat nélkül, vagyis a bemeneti mintavevő és -tartó kapac töltési / kisütési rátája határozza meg a bemenőáramot - ez a túlságosan nagy forrásimpedancián keresztül meghamisíthatja a mérés eredményét -, ami így végső soron az SPS-értéktől függ. Te eleve egy lassan változó DC-szintet szeretnél konvertálni, nincs szükséged őrületes mintavételi sebességre.
#16115: mivel az A/D-konverziónak része a mintavétel, ami egy konverziós ciklus alatt egyszer történik meg, ezért a kettő ekvivalens. Az ADC adatlapja is hol így, hol úgy hivatkozik rá. -
And
veterán
válasz
Tomika86
#16110
üzenetére
Azért én csak megnézném, mit produkál tized akkora ellenállásokkal (így az osztó árama még mindig csak 1mA körüli lesz). Ha a konverziós ráta alacsony, vagy relatív hosszú időközönként veszel csak egy-egy mintát, akkor nem ezzel lehet a fő probléma. A bemeneti COM és a táp GND-je amúgy össze van kötve?
-
And
veterán
-
And
veterán
válasz
Tomika86
#16105
üzenetére
Ha belső referenciát használsz, mindenképp 2,5V lesz a mérés vége. Viszont konfigurálható pl. a bemenet típusa (szimpla vagy differenciális) a referenciaforráson felül. Pontosan milyen értéket küldesz be a command byte-on keresztül? [mod: valamint melyik pin-ekre van kötve a bemeneti forrás?]
Az adatlapon nem látok követelményt vagy ajánlást a forrásimpedanciára vonatkozóan, de kicsit túlzónak érzem a külső feszültségosztó - ha jól értem, az van a bemenet előtt - és az azt követő RC-szűrő ellenállásértékeit. Annyit említ, hogy a bemeneti áram a konverziós ráta függvénye, és hogy a belső mintavevő kapacitás 25 pF értékű. -
And
veterán
válasz
gyapo11
#16026
üzenetére
Nem igazán. Léteznek nagyobb áramú OPA-k, de egy ilyenből biztos nem tápot szoktak csniálni
. Amúgy a rail-to-rail műverősítők is csak nem túl magas terhelőáramig képesek tartani ezt a tulajdonságukat.
Ha rendelkezésre áll valóban stabil (!) 6V-os tápforrás, amit a terhelőáram nem ránt le olyan szintre, amiből egy LDO sem képes már 5V-ot gyártani, akkor nincs gond a korábban felsorolt csomó lehetséges LDO-típussal. -
#16023
And
veterán
tonermagus
#16021
And
veterán
válasz
tonermagus
#16021
üzenetére
Egy LDO minimális feszültségesése terhelőáramfüggő, de több olyan típus is létezik, ami 1V alatti drop-pal működik. Pl. TS1117, LM2940, SM-tokban MIC5205 (ez eleve max. 150 mA-es), stb.
"Vagy esetleg nagyon luxus lenne, de létezik olyan ami ha 5V akkor nem nyúl hozzá, ha 6V akkor már 5V-ra csökkenti? "
Annyira luxus lenne, hogy ilyen lineáris LDO nincs, feszültségesés / drop mindig velejárója a működésüknek. Kapcsolóüzemű buck-boost (felfelé és lefelé is konvertálni képes) DC-konverterek képesek lehetnek ilyesmire, utóbbiak 5V-nál alacsonyabb feszültségből is tudnak 5V-ot előállítani. -
And
veterán
Hardveresen nem tűnik bonyolultnak (TTL UART + 485 driver), de szoftveresen érdekes lehet, és pár kérdést felvet. Pont-pont kapcsolathoz lesz, vagy egy master (a 'szerver') és több slave-eszköz van / lesz a buszon? Utóbbi esetben csak a master kérése és címzése után lehet adatot küldeni. A protokollt - vagy legalább valamilyen adatkeretezést - is ki kell találnod, vagy az már adott?
-
And
veterán
Itt annyi történik, hogy a felső dióda vezetni kezd, hogy mekkora áramot, azt a bemenettel soros ellenállás illetve a túlfeszültség mértéke határozza meg. Eleve pár mA-es lehetséges max. árammal szoktak ilyenkor tervezni. A táp (ami eredendően ugye feszültséggenerátor) jó esetben annyival találkozik, hogy a túlfeszültségű forrásból származó minimális árammal csökken az eredeti kimenő árama. Természetesen a soros ellenállásnak és a diódáknak hátrányai is vannak (előbbi enyhén meghamisíthatja mérést, offszetet okozhat), de az ilyen nem precíziós méréseknél általában elhanyagolható.
-
And
veterán
válasz
Sebiferi
#15931
üzenetére
Klasszikus védőáramkör (clamping) a bemeneten:
Ez mindkét irányú túlfeszültség ellen védelmet ad. Speciális eseteket kivéve - pl. ahol követelmény az extrém magas bemeneti impedancia - megfelelő. A diódák lehetőleg kisjelű Schottky-k legyenek, az Rs értéke pedig a lehetséges hibaáram és a maximális Vin függvénye, pár kΩ-os nagyságrendben (uC analóg bemenethez legfeljebb 10 kΩ ajánlott). A fix Zener-es megoldással szemben a vágási feszültségszint itt a tápfeszültség(ek)hez kötött, a V- értéke adott áramkörnél természetesen 0V / GND is lehet. Ilyen diódák valószínűleg léteznek a kontroller pin-eken a tokon belül is, de azért a külső védelem ilyen esetekben nem túlbiztosítás.
#15932: Azt a rail-to-rail OPA-k sem szeretik, ha jelentősen, több volttal túllépjük a bemeneti szintjüket a tápjukhoz képest. Ráadásul egy csomó OPA (még az egészen precíziós kivitelűek közül is) bizonyos körülmények között külső védelem híján hajlamos a phase reversal jelenséget produkálni a kimenetén, néha még akkor is, ha a bemeneti potenciál amúgy a saját táptartományán belülre esik, de ahhoz közel van. -
#15916
And
veterán
Drótszamár
#15912
And
veterán
válasz
Drótszamár
#15912
üzenetére
-
#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.
-
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. -
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. -
#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
#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.
-
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
#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
#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
#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ó. -
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
#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
#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
#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). -
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.
-
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
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
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.) -
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
(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
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
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. -
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
"[..] 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]. -
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. -
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
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
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
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
#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
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
#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
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.
-
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
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
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
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. -
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.
).
.
..
![;]](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
Hirdetés
- Apple Watch SE 2 44mm, Újszerű, 1 Év Garanciával
- Intel Core 2 Quad Q9550 2.83GHz LGA775 Processzor
- Telefon felvásárlás!! Samsung Galaxy A14/Samsung Galaxy A34/Samsung Galaxy A54
- Dell és HP szerver HDD caddy keretek, adapterek. Több száz darab készleten, szállítás akár másnapra
- Konzol felvásárlás!! Nintendo Switch
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: PC Trade Systems Kft.
Város: Szeged