Hallgatózás I2C buszon (sniffer)

ESP8266, ESP32 chipek és az ESP-xx modulok. Programozási nyelvek, trükkök, hardware tippek.
Avatar
aaszabo
Tranzisztorgyógyász
Hozzászólások: 164
Csatlakozott: 2012. január 22. vasárnap, 7:00
Tartózkodási hely: Budapest

Hallgatózás I2C buszon (sniffer)

HozzászólásSzerző: aaszabo » 2020. szeptember 20. vasárnap, 19:00

Sziasztok!

Szükségem lenne egy megoldásra, ami I2C buszon hallgatózik és visszafejti az ott folyó kommunikációt.
Nem kell semmi rosszra gondolni, csupán egy meglévő eszköz funkcionalitását szeretném kibővíteni a lehető legkisebb beavatkozással.

Adott egy berendezés, ami többek között méri a hőmérsékletet és ki is jelzi.
Ugyanakkor jó lenne, mondjuk távolról is tudni, hogy mit mér, hogy ne kelljen helyben leolvasni.
A berendezésben a hőmérséklet mérő rész I2C buszon csatlakozik a fő panelhez.
Itt kellene "hallani", hogy mit beszélnek és a hőmérséklet adatot egy webes felületen megjeleníteni, amit telefonról is el lehet érni.

Tipikus feladat egy ESP32-es panelnak.
Az ESP32 panelt összeföldelem a mérő panellal (3.3V, tehát nem kell illeszteni) és rácsatlakozok az SCL és SDA lábakra. Figyelem a kommunikációt és kiolvasom az adatokból a hőmérsékletet. Majd az adatokat WiFi-n keresztül elérhetővé teszem egy egyszerű weboldalon.

Elvben egyszerű a megoldás, de gondban vagyok az I2C lehallgatással.
A következő megoldásokban gondolkodom:
[1]Rácsatlakozva az I2C buszra egy mekhekkelt I2C lib-vel csak figyelek és kiolvasom az adatoakt.
[2]Az SCL felszáló ágra megszakítást kötök. Amikor SCL felszálló ág megszakítása bejön, akkor kiolvasom az SDA lábon a jelet és tárolom. Így elvileg megkapom a bitsorozatot SDA vonalon. Ebből viszonylag könnyen visszafejthető a kommunikáció és az adat.
[3]A loop-ban egy állapotgépet valósítok meg, ami folyamatosan olvass az SCL és SDA lábakat az aktuális állapotnak megfelelően és átlép a következő állapotba. Közben regisztrálja az SDA értékét, amikor az adatot tartalmaz.

Azt gondoltam, hogy az első esetre számtalan lib lesz elérhető, de nem találtam.
A harmadik esetre találtam megoldást, ami folyamatosan olvassa a lábakat, de nem tudtam működésre bírni.
A másodikkal kapcsolatban azt olvastam, hogy a megszakítás vezérlés átadása több mint 50 ciklust késik az AVR-eken. Emiatt a 400kHz-s I2C jelsorozat feldolgozásához nincs elég idő. Még nem próbáltam, hogy miként működik ez ESP32 környezetben. Épp most fogok neki.

Közben arra gondoltam, hogy hátha a pákatársak között akad valaki, akinek már volt dolga hasonló helyzettel és sikerült is megoldania. Így hát segítségül hívom a TAVIR élő tudásbázisát.
Előre is köszönöm a segítséget.

Avatar
pipi
Biztosítékgyilkos
Hozzászólások: 56
Csatlakozott: 2008. július 6. vasárnap, 6:00
Tartózkodási hely: Budapest
Kapcsolat:

Re: Hallgatózás I2C buszon (sniffer)

HozzászólásSzerző: pipi » 2020. szeptember 21. hétfő, 13:42

Ez valami gyártmányban lenne fixen, vagy csak debug-hoz?
Ha csak debug akkor van Saleae logikai analizátor(ebay/ali) ami a kommunikációt visszafejti...

Avatar
kapu48
Elektronbűvölő
Hozzászólások: 3358
Csatlakozott: 2008. augusztus 29. péntek, 6:00
Tartózkodási hely: Újkígyós

Re: Hallgatózás I2C buszon (sniffer)

HozzászólásSzerző: kapu48 » 2020. szeptember 22. kedd, 8:57

Próbálkozzál pl. ezzel: ESP32_I2C_Slave
https://github.com/gutierrezps/ESP32_I2C_Slave

Avatar
aaszabo
Tranzisztorgyógyász
Hozzászólások: 164
Csatlakozott: 2012. január 22. vasárnap, 7:00
Tartózkodási hely: Budapest

Re: Hallgatózás I2C buszon (sniffer)

HozzászólásSzerző: aaszabo » 2020. szeptember 22. kedd, 20:00

pipi írta:Ez valami gyártmányban lenne fixen, vagy csak debug-hoz?
Ha csak debug akkor van Saleae logikai analizátor(ebay/ali) ami a kommunikációt visszafejti...


Egy meglévő eszköznek a funkcionalitását szeretném bővíteni, tehát fixre kell a megoldás

Avatar
aaszabo
Tranzisztorgyógyász
Hozzászólások: 164
Csatlakozott: 2012. január 22. vasárnap, 7:00
Tartózkodási hely: Budapest

Re: Hallgatózás I2C buszon (sniffer)

HozzászólásSzerző: aaszabo » 2020. szeptember 22. kedd, 20:08

kapu48 írta:Próbálkozzál pl. ezzel: ESP32_I2C_Slave
https://github.com/gutierrezps/ESP32_I2C_Slave


Slave libeket nézegettem. Itt az a gond, hogy a Slave I2C-ben aktívan kommunikál, mert visszaírja az ACK-t.
Ezt automatikusan visszajelzi a vonalon és nem kell külön programozni.
Tehát, ha csak hallgatózni akarok, akkor mindenképpen bele kell nyúlni a lib-be, hogy ne küldjön ACK-t. Vagyis nem úszom meg a masszív éjszakázást.
Lehet, hogy az ACK kezelés alacsonyabb szintről jön és akkor még macerásabb belenyúlni.

Azt reméltem, hogy ismer valaki már elkészült I2C "vámpírt" és nem nekem kell megírni.
Még nem adom fel...

vargham
Chipgyilok
Hozzászólások: 287
Csatlakozott: 2014. január 8. szerda, 8:32
Kapcsolat:

Re: Hallgatózás I2C buszon (sniffer)

HozzászólásSzerző: vargham » 2020. szeptember 23. szerda, 7:33

Szerintem erre az MCU-ba épített I2C periféria nem alkalmas.
Én így állnék neki: Gyors MCU (részemről STM32G4xx), timerekkel figyelni és mérni az SCL és a SDA vonalakon az állapotok hosszát. Ha ismert a busz frekvenciája, akkor már meg is van a bit idő. Ha nincs, akkor is rá lehet jönni. Ezután pedig megírnám a teljes I2C protokollt szoftveresen, kihagyva belőle a buszra írás részeit. Kiindulásnak jó lehet valamelyik open source soft I2C.
A végén valami ilyesmit kellne kapni:
Master->Slave(address)->write->length,data
Master->Slave(address)->read
Slave(address)->Master->length, data
Ha szükség van rá, akkor ezeket még ki lehet egészíteni az összes ACK-val meg hiba állapottal is, ha nem csak az adatra van szükséged.

Avatar
aaszabo
Tranzisztorgyógyász
Hozzászólások: 164
Csatlakozott: 2012. január 22. vasárnap, 7:00
Tartózkodási hely: Budapest

Re: Hallgatózás I2C buszon (sniffer)

HozzászólásSzerző: aaszabo » 2020. szeptember 24. csütörtök, 21:40

Igen, ez hasonló, mint amit a nyitó bejegyzésben 2. és 3. megoldásként említettem.
Megszakítás használatával, vagy folyamatos figyeléssel ( While(!SDA) ) nem kell az időzítéssel foglalkozni.
Mivel nem is akarok válaszolni, mert csak az adatra van szükségem, ezért az időzítés nem érdekes.

Avatar
aaszabo
Tranzisztorgyógyász
Hozzászólások: 164
Csatlakozott: 2012. január 22. vasárnap, 7:00
Tartózkodási hely: Budapest

Re: Hallgatózás I2C buszon (sniffer)

HozzászólásSzerző: aaszabo » 2020. szeptember 25. péntek, 22:38

megírtam az I2C hallgatózót megszakításokkal.
Azt kell, hogy mondjam, hogy elegáns kód lett.
Egyelőre csak szintaktikailag jó, már késő van, nem merem tesztelni.
Ilyenkor már több hibát csinál az ember, mint javítást.
Ha működik felteszem ide a forrást és megírom a tapasztalatokat.

Avatar
aaszabo
Tranzisztorgyógyász
Hozzászólások: 164
Csatlakozott: 2012. január 22. vasárnap, 7:00
Tartózkodási hely: Budapest

Re: Hallgatózás I2C buszon (sniffer)

HozzászólásSzerző: aaszabo » 2020. szeptember 28. hétfő, 9:47

hát egyelőre nem hogy nem működik, de nem csinál semmit.
Egyetlen megszakítást sem érzékel.
Közben ránéztem oszcilloszkóppal a I2C vonalakra és nagyon furcsa jeleket látok ott. sokkal nagyobb amplitúdójuak, mint a hivatalos tápfesz megengedne. Csoda, hogy magában működik a berendezés.
Az is kiderült, hogy ha rácsatlakozok a hallgatózáshoz, akkor bizonytalanná válik a működése. Gondolom nem arra van kitalálva az I2C, hogy 10 centis lengő kábelekkel kommunikáljon. Bár az eredeti kialakításban is jó 5 centis szalagkábellel van összekötve a fő panel és a hőmérő panel.

Van ötletetek, hogy tudnék jól zavarszűrni?
Kellene az én I2C hallgatózómnál is felhúzó ellenállást rakni? Vagy elég lenne belső felhúzó ellenállást bekacsolni?
Vagy nem is szabad felhúzó ellenállást beraknom, hiszen ez a master eszköz dolga?

Avatar
aaszabo
Tranzisztorgyógyász
Hozzászólások: 164
Csatlakozott: 2012. január 22. vasárnap, 7:00
Tartózkodási hely: Budapest

Re: Hallgatózás I2C buszon (sniffer)

HozzászólásSzerző: aaszabo » 2020. szeptember 28. hétfő, 20:10

Mindig ugyan az a móka:
  • érintkezési hiba
  • Rossz lábak használata. Na de miért? A panel nem az aminek gondoltam. A felhasznált ESP32 panelnak van 1-es és kettes változata is forgalomban. Eltérnek lábkiosztásban és kicsit működésben. Csak annyira, hogy az egyikre nem lehet a másikra fordított kódot feltölteni. Kiderült, hogy nekem a 1.5-ös változat van. Ez lábkiosztásában a 2-es, de belsejében még az 1-es.
Amint helyére kerültek a lábak egyszer csak jöttek a bitek és nagyjából úgy ahogy gondoltam.
Vagyis működik az elv, hogy egy gyors processzorral a fel és leszálló ágakra ültetett megszakításokkal fel lehet dolgozni az I2C kommunikációt.

Az biztos, hogy az első részt jól dolgozom fel, mert a címet korábban kiolvastam egy I2C scannerrel.
  • Az első csomag részlet: S1101101W-
    Ahol S a start jele. Ezt az SDA leszálló ágára ültetett megszakításban ismerem fel, ha ilyenkor az SCL még magas.
  • Az 1101101 az IC címe, ami 6Dh
  • Utána jött egy W, vagyis a Master írni fog.
  • Erre jött NACK '-' (mínusz). Na ez már nem várt helyzet. ITT ACK (+) a várt érték.
Itt már látom, hogy utána kell járni az I2C protokollnak és a programnak is.
Az én tudásom szerint itt nem jöhet NACK (-), ha van azonnali további kommunikáció és működik a rendszer, márpedig működik.

Illetve az is látszik, hogy egy kommunikációs csomagban, amikor mér a műszer, akkor kb 20 byte adat közlekedik a buszon. A gond az, hogy a programom nem érzékel STOP jelet és össze vissza mennek az ACK/NACK (+/-) visszajelzések is a kommunikációban.

Most az jön, hogy kiveszek minden logikát (ACK, STOP, R/W, stb) és csak a nyers adatokat logolom le.
Azt sejtem, hogy nem tökéletes még a feldaraboló logikám és néhol olyan adatot várok, aminek nem is biztos, hogy ott jönnie kell.

Újabb éjszaka és nap jön, újabb kalandokkal...

Avatar
aaszabo
Tranzisztorgyógyász
Hozzászólások: 164
Csatlakozott: 2012. január 22. vasárnap, 7:00
Tartózkodási hely: Budapest

Re: Hallgatózás I2C buszon (sniffer)

HozzászólásSzerző: aaszabo » 2020. szeptember 28. hétfő, 23:22

A programozásban az a szép, hogy ha ugyan azt egymás után többször megírod, akkor egyre gyorsabb, egyszerűbb és szebb lesz a kód.
Harmadszor írtam át, mert belekavarodtam a feltételekbe.
Viszont most egész értelmes eredményt kapok.
Egy mérési ciklus eredményei:

Kód: Egész kijelölése

S1101101W+00110000+00001000+s
S1101101W+00000010+1S1101101R+00000001-s
S1101101W+00000110+1S1101101R+00010101-s
S1101101W+00000111+1S1101101R+00011110-s
S1101101W+00001000+1S1101101R+00011001-s
S1101101W+00110000+00001001+s
S1101101W+00000010+1S1101101R+00000001-s
S1101101W+00000110+1S1101101R+00000100-s
S1101101W+00000111+1S1101101R+11001010-s
S1101101W+00001000+1S1101101R+11001100-s


Az látszik, hogy egy mérési ciklusban két mérést hajt végre a berendezés.
Gyanítom, hogy azért, mert a kijelzőjén azt mutatja, hogy túl alacsony a hőmérséklet. Valószínű ezért megpróbálja még egyszer. Vagy csak lehet, hogy átlagol. Bár ahhoz én legalább 5 mérést vennék alapul.

Jelek értelmezése
S START
s sTOP
+ az ACK, a - a NACK
R/W pedig az írás vagy olvasás a Master részéről.
Van még valahol gond ezek alapján a STOP érzékelésével, mert S nem lehetne a sor közepén és azt közvetlenül egy STOP (s)-nek kellene megelőznie.

Úgy tűnik a hallgatózás lassan elkészül, viszont a gond az, hogy a rákötött hallgatózó miatt a berendezés nem jól működik. Nem szolgáltat rendes adatot.
Valami illesztési probléma lesz. Valahogy bezavar a két ráakasztott ESP32 bemenet és a sok lengő vezeték.

Az adatok alapján úgy tűnik, hogy 4 regisztert címez meg és 4 byteot olvas be.
Ha jó lesz az illesztés és nem zavar be a rákapcsolt hallgatózás, akkor már csak a bitek visszafejtése a feladat.

Avatar
aaszabo
Tranzisztorgyógyász
Hozzászólások: 164
Csatlakozott: 2012. január 22. vasárnap, 7:00
Tartózkodási hely: Budapest

Re: Hallgatózás I2C buszon (sniffer)

HozzászólásSzerző: aaszabo » 2020. október 24. szombat, 1:09

Elkészült a végső megoldás.
Tanulva a hibákból készítettem egy I2C buszt galvanikusan leválasztó kis panelt ISO1540 IC-vel.
Így nem vágom haza véletlenül azt amit éppen le akarok hallgatni.
Nagyon hasznos kis IC

Mellékeltem a programot is hozzá.
Én általában ESP32-t használok, Arduino platformon és PlatformIO-ban fejlesztek, ezért az első sorok egyike az Arduino.h includ-ja. Ha Ardunio környezetben akarja valaki kipróbálni, akkor ez a sor nem kell és a fájlt is nevezze át .ino-ra.
Illetve használok egy Serial.printf utasítást a processDataBuffer() rutinban. Azt nem minden környezet eszi meg. Ki is lehet kommentelni, vagy szétszedni println utasításokra.

A programjaim elég bőven tartalmaznak kommenteket, amiből a konkrét működés is megérthető.
A program használhatóságának feltétele, hogy elég gyors procin fusson, mert az I2C kommunikáció egy órajele alatt több utasítást is végre kell a programnak hajtania. Én ESP32-t használtam és azzal remekül működött. Az Arduino UNO kevés hozzá.

Ritkán van szükség ilyen eszközre, de ha kell valakinek használja egészséggel.
Nincs meg a kellő jogosultságod a hozzászóláshoz csatolt állományok megtekintéséhez.


Vissza: “ExpressIf WiFi”

Ki van itt

Jelenlévő fórumozók: nincs regisztrált felhasználó valamint 1 vendég