Tartalom:
- Mire használható egy logikai analizátor
- PulseView logikai analizátor kezelő program letöltése és telepítése
- PulseView használatának lépései, példák a használatra
- I2C, soros port adatfolyam, prelles nyomógomb vizsgálata az analizátorral
—————————————————————————
Hosszú ideig nem éreztem nagy szükségét egy logikai analizátor beszerzésének. Nem is igazán tudtam, hogy mire lehetne használni. Megesett azonban egy alkalommal, hogy egy MAX7219 meghajtóval működő LED mátrix kijelzővel nem boldogultam. Furcsa jelenségeket produkált, nem úgy működött, ahogyan a nagy könyvben meg volt írva. Ekkor fogalmazódott meg bennem először, hogy milyen jó lenne látni a az Arduino kivezetéseken, hogy mi is történik. Fellelkesedtem, és meg is rendeltem egy ilyen műszert az Aliexpress-en: https://www.aliexpress.com/item/1005001571657033.html?spm=a2g0s.9042311.0.0.39b64c4dYYnRCI
Ára akkoriban (2020) 1600Ft szállítással együtt, így ennyit megért. Már egy kicsit drágább, de érdemes keresgetni, mindig van akinél olcsóbb. Mint utólag kiderült, nagyon kevés dologra tudom használni. Azonban érdemes volt megismerni más okból, de erről majd később. Érdemes a cikket végigolvasni, a végén megtudhatod, miért volt érdemes megvenni ezt a kütyüt. Ha azonban 10.000Ft-os nagyságrendet kellene fizetned érte, akkor nem ösztönözlek a vásárlásra.
Lássuk mire is lesz jó ez a kicsi gyufásdoboz méretű valami! Először is van rajta 10 csatlakozási pont. Az egyik a GND, ezt biztosan össze kell dugni az Arduino (vagy a vizsgált áramkör) GND kivezetésével. Van rajta egy CLK kivezetés, bevallom nem tudom mire jó, de jelenleg nem is igazán érdekel. Valamint van 8db CH1-CH8 kivezetés, amik nyilvánvalóan bemenetek, hiszen ezeken keresztül vesz mintát a kütyü az Arduino kivezetéseken lejátszódó folyamatokról. Arra fogjuk használni, hogy megjelenítsük a számítógépünk képernyőjén a a kimenet vagy éppen bemenetek pillanatnyi állapotát. Amikor megrendeltem, még az a félreértés is vezérelt, hogy majd látni fogom a kimenet valódi jelalakját is, vagyis a négyszögjelek felfutó élét, az esetleges tranzienseket stb. Nem tudom ezt honnan vettem?! 1500Ft, ért nem lehet digitális oszcilloszkópot kapni! Elégedjünk meg azzal, hogy a bemenet állapotát rögzíti a jelanalizátor, LOW és HIGH állapotokat tud megkülönböztetni, tehát digitális jelanalizátor, ahogyan a nevében benne is van. Azonban ha a bemeneten (mondjuk egy Arduino bemeneten) hatalmas tranziensek vannak, akkor feltehetőleg ez a kütyü is rossz jelsorozatot fog beolvasni, így nyomokban mégis csak lehet majd látni, ha valami nem stimmel. Pl. a nyomógombok prell jelenségét is biztosan meg lehet vele figyelni!
Tudunk róla néhány lényeges vagy éppen kevésbé lényeges infót:
- Az eredeti eszközt Saleae gyártotta, de az enyéb biztosan egy klón. Ezért olcsó.
- Az erdeti Cypress CY7C68013A mikroprocesszorral működik. Ez a proesszor 48Mhz órajellel működik, videó jelfeldolgozásban használják. Mivel az én általam vásárolt eszköz egy klón, így nem vagyok biztos banne, hogy ugyanaz a processzor van benne
- Mintavételezési frekvencia: 24 MHz (beállítható: 24MHz. 16MHz, 12MHz, 8MHz, 4MHz, 2MHz, 1MHz, 500KHz, 250KHz, 200KHz, 100KHz, 50KHz, 25KHz) egyszerre 8 csatornán.
- Mintavételek száma 100-tól 10 milliárd-ig csatornánként, illetve az operációs rendszer által biztosított tárolókapacitás szerint.
- Csatornák száma 8
- Bemeneti feszültség tartomány: -0.5V to 5.25V. FIGYELEM!! egy szabványos RS232 portot ne akarj vele vizsgálni, mert az +/- 12V tartományban működik.
Alacsony (LOW) bemeneti szint érzékelés tartománya: -0.5V to 0.8V
Magas (HIGH) bemeneti szint érzékelés tartománya: 2.0V to 5.25V - Felhasználható 5V, 3.3V, 2.5V, 2.0V feszültségű rendszerekben, de az 1.8V-os feszültség már nem javasolt (1.5V a küszöbfeszültség). Nekem Arduino illetve ATmega chipek-hez, esetleg 3.3V os modulokhoz kell, így tökéletes.
- Bemeneti impedencia: 1Mohm || 10pF. Ez a 16Mhz-vel működő Arduino környezetben tökéletes.
- A beépített kvarcz kristály pontossága: +/-20ppm, 24MHz
- Impulzus szélesség mérés pontossága: +/- 42ns (24MHz es mintavételnél).
- Túlfeszültség védelem +/- 15V feszültség tartományban.
- Áramfelvétel az USB portról 50mA illetve 75mA mintavétel közben.
A szükséges szoftverek telepítése
Operációs rendszer Windows és Linux is lehet. Nekem csak Windows-ban van tapasztalatom, Windows10 64bites verzióra minden probléma nélkül települtek a szükséges szoftverek. A klón vásárlásakor semmilyen telepíthető szoftvert, vagy drivert nem adtak meg. Az egyedüli kiinduló ont az volt, hogy a Google (az egyre gonoszabb barátunk) kidobta a kütyü fényképét és a a Saleae gyártó honlapját, valamint a PulseView nyilt forráskódú program nevét. Elsőként a PulseView-et töltöttem le. Itt található: https://sigrok.org/wiki/Downloads
A letöltést követően a programot telepíteni kell. A telepítés teljesen szokásos next-next módszerrel történik:
… és készen is van. Azonban a program elindulás után még nem teljesen üzemkész, ugyanis az eszköz használatához driver is kell. Ehhez praktikusan a Saleae weboldaláról az eredeti hardver kezelő szoftver telepítő csomagját érdemes letölteni. Ezt a programot telepítés után nem fogjuk tudni használni, mert a klón nem tartalmaz valamilyen belső kulcsot és a szoftver nem működik vele, de telepítéskor feltelepül a driver, és nekünk ennyi pont elég. Itt találjuk a telepítő csomagot: https://www.saleae.com/downloads/
Ezt next-next módszerrel lehet telepíteni. Rendszergazdaként kell belépni, és végig csinálni a telepítést. Azonban ha Neked kedves olvasóm szintén Windows10 oprendszer van a gépeden, akkor innen le tudod tölteni az általam kimásolt drivert. Tapasztalatom szerint elegendő csak a drivert telepíteni. A letöltött és kibontott állományt másold elérhető helyre. Lépj be rendszergazda felhasználóval az eszközkezelőbe, dugd az USB portba az eszközt, és ezt fogod látni:
Kattints jobb egérgombbal az ismeretlen eszközre, és haladj a képek szerint sorban:
A mikor a driver könyvtárát kell kitallózni a harmadik lépésnél, azt a könyvtárat add meg, ahová kibontottad a rar állomány tartalmát. …és az eredmény így néz ki:
Ha mindez készen van, azt hiszem kell egy szokásos gép újraindítás, és készen is vagyunk. A PulseView program indításkor felismeri az eszközt, és azonnal üzemkész. Ezt fogjuk látni a nyitóképernyőn:
Én úgy kezdtem az ismerkedést, hogy beüzemeltem az Arduino Uno alaplapomat, I2C buszon összekötöttem a karakteres LCD kijelzőmmel. Sajnos nem sok látszik a képen a vezetékek bekötéséből, de ki lehet találni:
… és megírtam a következő programot:
#include <Wire.h> //I2C library
#include <LiquidCrystal_I2C.h> //I2C LCD kezelő könyvtár
LiquidCrystal_I2C lcd(0x3F, 2, 1, 0, 4, 5, 6, 7, 3, POSITIVE); //LCD paraméterek megadása, négysoros LCD-t használok
void setup()
{
lcd.begin(16,2); //LCD inicializálása
lcd.backlight(); //háttérvilágítás bekapcsolása
}
void loop()
{
lcd.print("A"); //A betű kiírása a cursor aktuális poziciójára
delay(10); //10msec várakozás
}
Amikor feltöltöttem a programot az Arduino-ra, a kijelző rögvest megtelt „A” betűkkel. Azt vártam, és ez így is lett, hogy az I2C buszon keresztül az Arduino 10msec időnként információkat küld a kijelzőnek. Ez egy oda-vissza kommunikáció, aminek a lényegét megismerheted itt, de a logikai analizátoron várhatóan látni is fogjuk mi zajlik a vezetékeken. Ennek érdekében a logikai analizátor CH1 bemenetét az Arduino SDA kivezetésére, a CH2 bemenetét pedig az SCL kivezetésére kötöttem párhuzamosan az LCD kijelző megfelelő kivezetéseivel. A PulseView RUN gombját megnyomtam (feljebb két képpel), és kis idő múlva megtelt a D1 és D2 címkével jelzett sor tartalommal.
Egyenlőre képen csak annyi látszik, hogy a D0 és D1 címkével jelölt sorokban szürke sávok jelentek meg. Mivel a többi bemenetet épp nem használom, de ezt a program nem tudja, érdemes kikapcsolni ezeket, hogy ne zavarjanak. Ehhez kattintani kell a kis piros érzékelő tű szimbólumra, és kivenni a pipát a nem használt bemenetek elől:
Áttekinthetővé tehetjük a képernyőt, ha a D0 és D1 bemeneteket nevesítjük is. Ehhez elegendő a kis színes címkére egy dupla klikk, és sok-sok standard megnevezésből kiválaszthatjuk a megfelelőt. Nem csoda, hogy DATA és CLK megnevezést is találunk:
Mivel tudjuk, hogy a vezetékeken I2C protokoll szerinti kommunikáció zajlik, hasznos lehet ezek adattartalmának visszafejtése a programmal. Ezt nem kötelező megtenni, csak ha már van ilyen szolgáltatás, ismerjük meg ezt is. Kattintsunk a zöld-sárga ikonra, és a rengeteg protokoll között keressük meg az I2C-t. Közben nézegessük, hogy miket is használhatnánk még. Még a közismert DS1307 RTC óra IC adatkommunikációját is ismeri, ami egyébként I2C buszon zajlik. De most maradjunk az I2C-nél:
Amikor dupla klikkel kiválasztottuk a protokoll-t, máris megjelent egy harmadik sor.
Piros felirat figyelmeztet, hogy a program még nem tudja értelmezni, hogy melyik bemeneten mi zajlik, ezért meg kell adnunk a bemeneteken zajló adatfolyam szerepét. Tehát dupla klikk a harmadik sorban látható I2C feliratú zöld ikonra:
Ebben az ablakban az immár nevesített bemenetek közül meg kell adnunk, melyik az I2C kommunikációban SCL és SDA jelvezetékeknek megfelelő bemenet. Máris megjelentek az adatok értelmezésére utaló zöld-sárga-piros sávok, de egyenlőre nem túl értelmes tartalommal. Ahhoz, hogy ezeket el tudjuk olvasni, kezdjük az egér görgető gombjával, vagy az ikon sávon a szürke „+” vagy „-„ jelekkel széthúzni a sorok tartalmát. Ha elegendően kinyújtottuk az ábrát, már láthatók a jelváltozások. Azonban ez távolról sem I2C kommunikáció! Vajon miért?
Egy nagyon fontos dologról megfeledkeztünk! Alapértelmezetten a mintavételi frekvencia 20Khz (bekarikáztam a képen). Viszont az I2C buszon az órajel frekvencia 100Khz, mint azt tudjuk. Máris megtudtuk, hogyan veszítünk információt, ha alul mintavételezünk egy jelet. Tanulmányaimból tudom, hogy a maximális frekvencia legalább kétszeresével kell minta vételezni a helyes eredményhez. Pl. a hang digitalizálásnál ezért 44 Khz a mintavételezési frekvencia. Ennek oka, hogy az emberi fül maximum 22 Khz hangot hall meg (mármint a fiatalok, nekem már a 15 Khz is hallhatatlan, kipróbáltam). Így 40 évvel ez előtt, amikor az első CD lemezt készítették, itt húzták meg a határt a HIFI hangtechnikában. Pl a telefonhang átviteléhez elegendő 2 khz, és máris érthető a duma. Sőt ezt még röptében tömöríteni is lehet, így a mobiltelefonokon 9600 baud-al simán lehet beszélgetni (úgy emlékszem).
Nézzük mit is tehetünk a mintavételei frekvencia beállítása érdekében. Két beállítást is látunk.
A „…samples” feliratú legördülő menü a mintavételek számának beállítására szolgál. Nekünk ugyan most nem ez kell, de ezt is érdemes beállítani. Én egymilliót (1M) állítottam be, ez néhány másodperc jelrögzítést fog eredményezni, ha a mintavételi frekvenciát 200Khz-ra állítjuk (pontosan 5 másodpercet). Természetesen előbb is leállíthatjuk a rögzítést, mert menet közben a RUN gomb STOP feliratra vált.
Csináljunk egy rögzítést (klikk a RUN-ra), és nyújtsuk meg az ábrát. A most követő képen az I2C sáv már piros címkével rendelkezik, ennek oka, hogy hiába állítottam be immár helyesen a mintavételi frekvenciát, értelmet len adatokat kaptam, pedig újra futtattam a mintavételt. Ennek oka szoftver hiba lehet, mert ha újra kiválasztottam az I2C protokollt a beolvasott adatokra, akkor már működött. A következő képen a két I2C sávból az értelmetlen tartalmat már el is töröltem. Így lett a zöld lila!
Annak érdekében, hogy a képen a részletek is láthatók legyenek, ketté vágtam a képernyő fotót, az alsó sáv a felső folytatása. Most azonban már kezdhetünk érdekes dolgokkal foglalkozni. Használjuk a program beépített időmérő szolgáltatását. Ehhez a kis kék ikonkára kell kattintani. Húzzuk a halovány kék jelölősáv kezdetét a jelsorozat elejére
Ezt nem tudtam értelmesen kettévágni, ezért kinagyítottam a lényeget ott középen:
Természetesen nem lepődünk meg nagyon, de most kaptunk egy kézzelfogható pontos adatot arról, meddig is tart egy „A” betű kiírása az LCD kijelzőre I2C buszon keresztül. Egészen pontosan 915 mikrosecundum-ig. Tehát kb ezer db „A” betűt írhatunk másodpercenként a kijelzőre. Azt is láthatjuk, milyen infó áramlik a buszon. Először az Arduino a kijelző címének buszra írásával kezd (3F), aztán jön egy adat. Azt is látjuk, hogy 4byte-ot írunk a kijelzőre, ebből én egyiket sem ismertem fel. Az A betű HEX kódja 41 (decimális 65), és ezt sehol nem látom. Ha részletesen tanulmányoznánk a kijelző adatlapját, feltehetőleg az is kiderülne miért nem azt látom, amire számítottam. Ráadásul vadul ismételgettem az A betűket, amit vagy a program könyvtár algoritmusa, vagy a kijelző helyezett el automatikusan a képernyőn, így a pozíciót meghatározó adatok is közlekedhettek az adatcsomagban. Ezek az infók esetleg minden adatcsomagban változhattak. De ez most kevésbé érdekel.
Házifeladat, írj karakter sorozatot a kijelzőre! Pl. lehetne találékonyan a „Hello World” szöveg! Vajon hatékonyabb a szöveg kiírás? Derítsd ki!
Azonban ne áljunk meg itt! Derítsük ki, hogy valóban 100 Khz-e az I2C busz alapértelmezett órajelfrekvenciája? Nyújtsuk tovább az ábrát, és jelöljük ki a SCL jelsorozat két felfutó jelét.
Ezen a képen talán már a számok is leolvashatók. Biztosan azon sem lepődünk meg, hogy 99.9Khz vagyis majdnem pontosan 100Khz.
Az érdekesség kevéért leszereltem az LCD kijelzőt, és felraktam egy DS3231 I2C busszal működő RTC óra chip-et. Ehhez már a modulokról szóló leírásokban van példaprogram, ezt töltöttem rá az Arduino UNO-ra. A program a loop()-ban öt másodpercenként lekérdezi a dátumot és időt, valamint rögtön ez után a hőmérsékletet. Mindkét lekérdezés jelsorozatát megtaláltam a rögzített idősávban viszonylag közel egymáshoz (hogy olvasható legyen, az első lekérdezés jelsorozatát kettévágtam):
Emlékezzünk, a dátum és idő BCD-ben van kódolva a chip memóriájában egymást követő byte-okban. Ugyanebben a sorrendben olvassuk ki ezeket. Sorban a következő adatok érkeznek (hátha nem látszik a képen): HEX 36, 39, 19, 05, 25, 12, 20. Tehát ezt a lekérdezést 2020.12.25.-én 19 óra 39 perckor csináltam csütörtöki (5) napon! Sajna csak a DS1307 IC-hez van dekódolási lehetőség, így nem tudtam kipróbálni, mi történt volna ha azt állítom be. Minden bizonnyal kiírta volna a pontos időt a logikai analizátor program is.
Soros port vizsgálata:
Most következzék a Soros port kommunikációjának vizsgálata. Ehhez most kihagytam az LCD kijelzőt, a CH1 bemenetet közvetlenül az 1-es Arduino kimenetre kötöttem, ami a soros port TX kimenete. A CH2 az Arduino 0-as kivezetésére került, ami pedig a soros port RX bemenete. Most csak a TX-en lesz jel, mert a következő programot töltöttem az Arduino-ra:
void setup() {
Serial.begin(9600);
}
void loop() {
Serial.print("A");
delay(10);
}
Végigcsináltam a bemnetek elnevezését. Nem meglepő, hogy van RX és TX is a választékben. Kiválasztottam a beépített protokollok közül az UART névre hallgatót! A protokoll értelmező sorában a cimkére kattintva a következő látható:
Ebben mindent automatikusan kitöltött, egyedül a port sebességet kellett beállítani, mivel a programban 9600-at adtam meg, az alapértelmezett nem ennyi volt. A kapott jelsorozat megfelelően kinyújtva:
Mérjük meg az átvitel sebességét is:
Sajnos a képen minden nagyon apró, de higgyétek el nekem, hogy középen 1049 mikrosec időt olvastam le. Tehát egyetlen byte átvitele 1049 mikrosec. Ez nem csoda, hiszen a 9600 boud az 9600 bit átvitele egy másodperc alatt. Egy byte az 8 adatbit + start + stop bit (paritás nem volt bekapcsolva), vagyis 10 bit. 9600/10=960 byte/sec, vagyis kb. 1/960=1040mikrosec-re számítottunk. Bejött!
Prelles nyomógomb vizsgálata:
És most következzék egy valós mérés, amiben a logikai analizátort sikerült új információk kiderítésére használnom. No itt sem értek gigantikus meglepetések, számíthattam az eredményre, de érdekes volt a saját szememmel látni. Írtam egy rossz prellmentesítő megoldást:
/*************************************************************************************************************
* Bemutató program arra, hogyan lehet úgy prellmentesíteni a nyomógomb lenyomást, hogy időzítéseket *
* használunk az első kontaktus észrevételét követően. Ekkor 50msec múlva újra megnézzük a nyomógomb *
* állapotát, é ha még akkor is nyomva volt, akkor már biztosan lenyugodott a kontaktus, és le van nyomva. *
*************************************************************************************************************/
void setup()
{
pinMode(3,INPUT); //nyomógomb bemenet
digitalWrite(3,HIGH); //felhúzó ellenállás bekapcsolva
pinMode(13,OUTPUT); //Nyomógombbal kapcsolt kimenet
Serial.begin(9600); //elindítjuk a soros portot
}
void loop()
{
if (digitalRead(3)==LOW) //első lenyomás érzékelése
{
delay(50); //várum 50msec-et, azonban itt elveszik 50msec ido, és nem történik addig semmi
if (digitalRead(3)==LOW) //még mindíg nyomva, tehát biztosan le van nyomva és nincs már prell,
{digitalWrite(13, HIGH);} //allapot változót bebillentjük kimenetet kapcsoljuk, ez már egy prellmentes jelzése
} //a nyomógomb lenyomásának
if (digitalRead(3)==HIGH) //első elengedés érzékelése
{
delay(50); //várum 50msec-et, azonban itt elveszik 50msec ido, és nem történik addig semmi
if (digitalRead(3)==HIGH) //még mindíg elengedve, tehát biztosan elengedtük és nincs már prell
{digitalWrite(13, LOW);} //allapot változót bebillentjük, ez már egy prellmentes jelzése
} //a nyomógomb elengedésének
}
Ennek lényege, hogy az első kontaktus záródás illetve elengedés után várakozik 50 millisecundumot, és ha még akkor is le van nyomva a nyomógomb, akkor lenyomottnak tekinti, és bekapcsol egy led-et az Arduino 13-as kimenetén.
Ha a prell jelenségéről többet szeretnél megtudni, akkor olvasd el az Arduino bemenetek kezeléséről szóló leírást, és a prellmentesítési programokról is találhatsz itt információt.
Nyilván kellett egy nyomógomb egy felhúzó ellenállással, erre kötöttem az analizátor egyik bemenetét, éppen a CH2-t. Valamint kellett az Arduino 13-as kivezetésére, erre került az analizátor CH1 bemenete. Miközben a kapcsolást összeraktam a kis próbapanelemen, ért egy meglepetés. A nyomógomb lenyomása után a 13-as kimenet bekapcsolva maradt, pedig elengedtem a nyomógombot. Nem szoftver hiba volt, az analizátor tréfált meg. Nem volt bedugva az USB portba, így nem kapott tápfeszültséget, és miután a bemenete 0V-ot kapott, lehúzta az Arduino 3-as kivezetését 0-ra. Nem értem hogyan csinálta, de amikor bedugtam az USB-be, megszűnt a jelenség. Tanulság: az analizátor legyen USB-be dugva, amikor már elindítod a vizsgált áramkört. Úgy tűnik az analizátor bemenete csak bekapcsolt állapotban 1Mohm, kikapcsolt állapotban istentudja mennyi!
Jó magas mintavételi frekvenciát állítottam be, 1Mhz-t. Valamint 5M mintavételt csináltam. Még egy trükköt vetettem be, beállítottam, hogy a mintavétel a nyomógomb lenyomásakor keletkező lefutó élre kezdődjön el. Azt azon a panelen lehet megcsinálni, ahol a bemenetet elnevezhetem.
A sor végén egy kis sárga lefutó él jelölést látunk. Ekkor a RUN megnyomására nem történik semmi, csak akkor indul a rögzítés, amikor először megnyomtuk a nyomógombot.
Vadul nyomkodtam a gombot, a lehető leggyorsabban. Ez egyébként egy panelbe ültethető pici kattanós nyomógomb, ami úgy tapasztaltam, kifejezetten nem sokat prellezik, tehát vélhetőleg nem is fogok sok impulzust találni. Így nézett ki a rögzített eseménysor teljes hosszában:
Az rögtön látható, hogy ez az időzítős prellmentesítő megoldás nem tökéletes. Ugyanis ha gyorsan nyomkodjuk a nyomógombot, megelőzhetjük az időzítőt, és kimaradhatnak érzékelések. Látható, hogy vannak az alsó soron olyan nyomógom lenyomások, melyek hatására a kimeneten (felső sor) nem történt semmi. Az is látható, hogy a kimenet, ha követi egyáltalán a bemenet eseményeit, azt 50msec késéssel teszi. Ez mondjuk általában nem baj.
Sajnos a nyomógombom túl jó, ezért nehezen találtam prell eseményt, de van. Úgy tűnik elengedéskor produkálja, mert két helyen is elengedéskor találtam:
A kimenet változása nem látszik, mert itt már nagyon széthúztam az idősávot, a látható eseménysor kevesebb mint 1 msec. Nosza mérjük is meg a paramétereket:
Annak érdekében, hogy a kék sávokban elolvasható legyen az adat, még jobban szét kellet húznom az ábrát. A prell impulzus hossza 174mikrosec, az ezt követő szünet pedig 573mikrosec, és csak azt követően kapcsolt a nyomógomb végleges állapotba. Hát bizony Arduino ez alatt rengeteg ciklust futtat le, így nem csoda, hogy többször is érzékelné a nyomógomb prellezését.
Válaszom a saját kérdésemre: miért volt érdemes megvenni a logikai analizátort? Mert érdekes!