Fórum témák
» Több friss téma |
A klónok CH340 Soros-USB illesztőjének drivere (Letöltés)
Hát nem tudom, magyarázd el a kedves kollegának, hogyan lehet egy SPI-t bemérni egy szkoppal. És azt hagyd meg magadnak, hogy másokat minösitgess. Arra ott a tükör
Alapvetően ezért kell digit szkóp, és lehetőleg nem analóg, hogy az egyszeri lefutású jeleket is kényelmesen tudd vizsgálni, ne kelljen ciklikus trükközésekkel valami látható állapotot elérni!
A digitális szkópok manapság fel vannak erre készülve, tartalmaznak protocol decodert, amivel nem csak a hullámformát nézheted meg, hanem az elküldött byte-okat dekodolva, illetve akár csomag szinten is egy event táblában.
Itt egy példa I2C-re: Bővebben: Link Egy konkrét I2C címre küldött csomagra triggerel: adott cimre adott adat irása esetére. A hozzászólás módosítva: Feb 6, 2023
S ki vonta ezt kétségbe?
Tudod ez olyasmi mint amikor agyuval lövöldözünk verébre. ( vagy aktuálisan egy müholdvezérelte méregdrága föld levegö lövedékkel lönnek szét egy állo hidat). Amit az ilyen szkop tud, annak a nagyrészét tudja - és jobban, (mert nagy képernyön dolgozol, áttekinthetö grafikával és gyakran jobb beállitásokkal ) egy 10 euros logikai analizator is. És az ilyen áramkörök vizsgálata közben kimondottan zavaró lehet egy szkop idöbeli grafikája, mint a te képeden a felsö sárga képrészlet ( föleg ha még a szinkronizácio is bizonytalan), mert megtévesztheti a felhasználot a szörös kép, a sok tüske, aminek egy részét maga a szkop okozza stb. Szoval igen vannak esetek amikor kell a szkop is, de egy mikropcesszoros szerkezetben az esetek 90%-ban a logikai analizátor többet ér meg némi agyzsir, ami ahhoz kell, hogy rájöjjünk miért nem megy valami ugy ahogy kellene. És ezt aligha lehet egy szkoppal kideriteni. Itt is érvényes az alapszabály, minden feladathoz a megfelelö szerszám kell. A hozzászólás módosítva: Feb 6, 2023
Amikor nem megy egy kommunikáció, vagy bizonytalan..., ott analizátorral nem sokra mész! De szkópon jobb esetben látni fogod, hogy kritikusa szintre van csúszva valahol valami vezérlőjel, vagy adatfolyam, vagy bármi más, ami miatt hol jó, hol nem jó az egész....
Ha jó minden, nincs szükség szkópra, tény..., de akkor analizátor sem kell
Ez nem igaz.
Még a legocskább analizator is kijelzi, ha a szintek nem stimmelnek ( legalább is nekem még olyanhoz nem volt szerencsém, ami ezt nem tudta.). A logikai analizator legalább 8 jelet tud egyszerre mérni és ott azonnal láthatod, ha valamelyik jel huncutkodik ( de vajon mitöl változhat egy ilyen áramkörben a jelek szintje? És azzal mit lehet kezdeni? S ha ilyen gond van az inkább a rossz tervezés kérdése s nem az áramkör hibája). S hány olyan áramkör van, ahol pontosan bizonyos mennyiségü impulzus után kell valaminek történnie. Azaz végig kell számolnod egy sereg impulzust ami azután kiválthat egy másik állapotot. De a programban elszámoltad magad, vagy csak egy éllel tévedtél stb. Mivel fognál neki egy ilyen hiba kideritéséhez? A hozzászólás módosítva: Feb 6, 2023
Hát ez az Analizátorral csak annyit látsz, hogy nem megy, vagy bizonytalan! De hogy miért, azt már nem tudod megmondani, mert az információ hiányzik a mérésből! Szkóppal látni fogod, hogy valamelyik jel fázisa nem megfelelő, hangolni kell rajta, késleltetni, stb... Ha elvonatkoztatsz az i2c kommunikáció csigatempójától, máris belefuthatsz ilyenbe..., de akár még ezen az interfészen sem lehetetlen helyzet egy ilyen! Bonyolultabb, gyorsabb interfészeknél pláne gyakori helyzet tud lenni....
Az az érzésem, te protokoll szintű hibakeresésre gondolsz csak, mert feltételezed, hogy fizikailag minden rendben van! Én viszont a fizikairól beszélek, ami ha nem jó, nyilván a protokoll szintjét is maga után vonja... A hozzászólás módosítva: Feb 6, 2023
Köszönöm a felvilágositást.
Ugye ezért volt a valamikori fejlesztö osztályon 20 mérnöknek 2 jo szkopja meg 40 logikai analizátora. A hozzászólás módosítva: Feb 6, 2023
Uno alaplappal szenvedek.Összeraktam próbapanelen egy loggert, ami a vízóra állását rögzíti SD kártyára, LCD kijelzővel, valós idejű órával. Szépen működik, beépítettem egy kibuherált Datcon műszerdobozba, huzalok beforrasztva, első feltöltés az alaplapra OK, de módosítottam a programon, újra akarom tölteni és hibát dob az alaplapra feltöltéskor. Az ellenőrzés ok , egy másik ugyanúgy összedrótozott panelre feltölti. Mi lehet a baj? Egyáltalán a hibaüzenetet részleteiből kideríthető a tényleges hiba?
Ellenőrizni kell hogy az alaplap tipusa pontosan van-e beállitva. És ha tudsz készits printscreen-t a hibáról, vagy másold be a hibaüzenetet.
Próbáld meg így:
Lenyomod a reset gombot, és ott is tartod... Elindítod a feltöltést, és kisvártatva elengeded a reset gombot...
Uno az alaplap, az biztosan jó.
Mellékelem a hibaüzenetet...
Próbáltam...ugyanaz: probléma az alaplapra feltöltéskor.
Látod az UNO-t a gépen ( ID szám port stb)?
Sajnos nem tudom miért, nálam is elöfordul, hogy a PC-n elveszik a Arduino lap. Gyakran kell ujra inditani a programot, kikeresni a megfelelö COM portot, hogy ujra felismerje az Arduinot. Néha 1/4 ora is elmegy mire ujra összeáll a rendszer. Ha valaki tudja mi lehet a hiba, segithetne.
Köszi!
Másik porton volt, erre nem gondoltam...feltöltötte rendben!
Másik ezzel kapcsolatos:
5V DC -t felhasználnám a régi Datcon tápjából, ezt az USB +/- tápjára kössem vagy az Arduino táp bemenetére(de oda többet kér mint 5V úgyemlékszem)
Rá kellene nézni szkóppal... Bocs! De viccen kívül, a problémáknak mindig van valami konkrét oka, de ezt nagyon nehéz megsejteni távolról.
Kovács Tibor: az Arduino a fényképen eredetinek látszik, ez már jó. Az Arduino IDE-t rá lehet venni, hogy a szöveges logot is mutassa, arra volna szükség a közelebbi analízishez. A tippem az volna, hogy az áramkör valamilyen módon visszahat a programozás folyamatára. A serial lábakra ugye nincs rákötve semmi? Az UNO programozása így működik: * A lapon van egy USB-Serial átalakító csip. * Az USB serial DTR (data ready) lába egy Reset áramkörre van kötve és egy lefelé jelváltás resetet okoz az ATMega328p-n * Reset után az Atmega328p-n a bootloader indul el, és egy rövid ideig a serialon várja a felprogramozás megkezdését jelentő parancsot. * Ha programozó módba lépett, akkor a serialon keresztül feltölti a programot a PC szegmensenként, utána visszaellenőrzi, végül újraindítja a csipet. Általánosságban az okozhat problémát, ha a serial RX TX lábakra rá van valami más is kötve ami bezavar, vagy ha a reset van elrontva. A többi láb elvileg lényegtelen, a reset a többitől függetlenül érvényre jut, és nem tudják zavarni a serial kommunikációt sem. Esetleg még azt el tudom képzelni, hogy valahogy a csipet SPI programozó módba lehet hozni reset után véletlenül, ha pont olyan jelforma jön az SPI programozó lábakon. De ezt nem tartom valószínűnek. Amire még vigyázni kell az a földhurok: ha kábelesen van megtáplálva az áramkör, és rádugunk egy asztali PC-t, akkor talán előfordulhat ilyesmi. Én úgy szoktam csinálni, hogy töltőről lehúzott laptopról programozok fel mindent, amit úgy kell programozni, hogy közben például dugasztápos áram alatt van. Nem sikerült még teljesen megfejtenem, hogy pontosan hogyan működik ez a probléma, de úgy tapasztaltam, hogy ez lehet hibaok. Szerk.: látom mire beírtam megoldódott, de most már itthagyom. A hozzászólás módosítva: Feb 6, 2023
Az Arduino tetején lévő csatlakozósoron van olyan feliratú, hogy:
RAW - ez a dugasztáp + jával van összekötve, ez egy elég sok voltot elvesztegető regulátorra van kötve, tehát erre több mint 5V-ot kell kötni. Specifikáció szerint ha jól emlékszem 7-et, valójában kevesebbel is elindul, de gondolom a specifikáció szerinti áramokat nem tudja leadni. +5V - ez a processzor tápja direktben. Regulált 5V-ot ide is be lehet kötni. Ha jól emlékszem az USB 5V is direktben hozzá van ehhez kötve. És persze sok változata van a boardoknak, úgyhogy akár el is térhet ettől.
Itt nem ilyen gondrol van szo, hanem vagy a Windows vagy a PC vagy az IDE nem tartja meg a beállitást. Néha elég kihuzni az arduino USB kábelét és már valami átprogramozza a portokat. Sokszor megjelenik olyan, hogy COM11, COM14, holott amikor programoztam utoljára COM4volt.
Érdekes modon ha ujra inditom az IDEt akkor rendszerint eltünnek a magas számu COM portok. Néha viszont megtalálja a COM11-en is az Arduinot. Eddig nem sikerült rájönni mi okozhatja ezt a jelenséget. Ehhez nem kell semmilyen müszer, mert nincs mit mérni, sokkal inkább ismerni kellene a PCk meg a programok belvilágát.
Az Arduino DC bemenete kb 12 Voltiig jo. Ugyanez a bement elérhetö a Vin tüskén is. A lapon van egy 5Voltos stabilizator.
ARDUINO PINOUT Az 5 V-s pinek a stabiliizator utáni tápok, egyenesen a processzor lábaira mennek illet az USB + 5 Voltos bemenete is ide megy. A 3V3 pin meg a belsö 3,3V-s táp kimenete.
Szerintem cserélni kellene USB kábelt is. Lehet egy pillanatra nem ad ki tápot, az Arduino megáll, a Windows meg úgy látja, hogy le lett választva az eszköz. Utána megint kap tápot, és azt már egy másik COM-ra teszi.
De ezt okozhatja a PC kopott USB portja is. Hátha ilyesmi a gond.
Hi
Ismeri valaki EZT az IC-t? Egy nano lábai számát lehetne ezzel az IC-vel kibőviteni de nem ismerem. Azt látom , hogy I2C-vel kommunikál. Van ehhez arduino könyvtár , vagy elég csak a "Wire.h "? Önmagába használható, vagy kell hozzá valamilyen kiegészitő alkatrész? Akár PWM képes lábakat is lehet vele nyerni? Hogy lehet a lábakra hivatkozni?
Pont ezt nem ismerem, de van egy hasonló, a PCF8574. Például : Link Nem kell külön alkatrész, csak tápot kell adni. Van lib is hozzá, de magában is használható. Rendes IO lábként lehet kezelni, megadhatod hogy ki vagy bemenet legyen, és tud megszakítást kérni ha változás van a lábain. Alapvetően gombok kezelésére, ledek relék kapcsolgatására lehet használni. Ez az IC is hasonlónak tűnik, csak nagyobb.
A PWM-et nem tudom hogy gondolod, de az I2C már eleve egy sebességkorlátozó tényező, szóval azt inkább natív hardverrel kezeld, és delegáld ki a nem kritikus feladatokat a portbővítőre!
Én a PCF8575-t használom és már közel 100 portot használok ( Be - és kimenetet).
Itt van a fejlesztö verzio a kész már be van épitve. A kapcsolok állapotát jelzi ki egy nagy LED-s táblán. S valoban csak a wire.h kell hozzá. A hozzászólás módosítva: Feb 7, 2023
100 port az jó sok. Nekem ha 10-15-el több lenne mint a nanon már az is jó.
A kép jobboldalán láthatod, hogy egy PCF-el 16 nyomogombot kezelek ( 8 piros, meg 8 fekete) és ha jol emlékszem 8 ilyen modult lehet az arduinora akasztani ( ennyi cim van ).
Ha csak kontaktus bemenet kell akkor 512db tudok kezelni 2 De/Multiplexer (4-16) áramkörrel és igaz 10 db IO porttal . és sok diódával ... hacsak 256 db kontaktus kell akkor nem kell sok dióda és 9 port elég. Igaz ezek csak inputok és nem definiálhatóak tetszőlegesre.
A hozzászólás módosítva: Feb 7, 2023
Ha nem akarsz plusz csipet, de van egy rakás diódád, akkor Charlieplexing is megoldás lehet. N pin-nel lehet N*(N-1) ki vagy bemenetet csinálni.
Egy másik megoldás a shift regiszter: ezeket tetszőlegesen hosszan lehet sorolni mind bemenetre, mind kimenetre. Van belőle olyan is, ami nagyobb áramot is le tud adni. A mikrovezérlőn pedig a shiftelést könnyen meg lehet írni bit állítgatással is, vagy az SPI hardver tudja kezelni mind a kimenetet, mind a bemenetet. Chip Select, clock, data in, data out, beolvasás engedélyezés, kimenet engedélyezés, latch: hét láb kell a teljes értékű működtetéshez. A hozzászólás módosítva: Feb 7, 2023
Azokat a diodamátrixokat már régen használom. A képen láthato fejlesztö HW csak arra kellett, hogy a diodamátrixok kimenetét ( optocsatival leválasztva) megfelelöen kezelje. A fekete gombok ( bemenetek) kiválasztják a megfelelö LEDet ( LEDeket) a piros bemenetek meg azok státuszát világit/villog) és 4 vezetékel eljuttatják a kb 3 méterre levö panelhez.
|
Bejelentkezés
Hirdetés |