Hallo zusammen, ich arbeite viel mit dem Raspberry Pi am I2C Bus, wobei der RPi immer als Master fungiert. Ich suche nun nach einer Möglichkeit, einen (zweiten) RPi als Sniffer einzusetzen, der den gesammten Telegramm Traffic am Bus für alle beteiligten Adressen mitloggt, ohne natürlich in den Traffic aktiv einzugreifen. Dabei sollte der gelesene "Stream" etwas strukturiert dargestellt werden können - über Teminal in Echtzeit, aber auch als strukturierte Records in ein Logfile. Hat da jemand einen Link / Hinweis auf Software für mich? Vielen Dank im Voraus Gruesse
Gast
#6006198
Hendrik L. schrieb: > einen (zweiten) RPi als Sniffer einzusetzen Warum? Das ist doch eine prädestinierte Aufgabe für einen LA! Gruss Chregu
Einen 16Ch- Logicanalyzer mit I2C Decodierung habe ich, ich will aber die Historie auch noch loggen - das kann er nicht. Gruesse
Gast
#6006256
Hendrik L. schrieb: > Einen 16Ch- Logicanalyzer mit I2C Decodierung habe ich, ich will aber > die Historie auch noch loggen - das kann er nicht. https://sigrok.org/
Gast
#6016432
50c schrieb: > Hendrik L. schrieb: >> Einen 16Ch- Logicanalyzer mit I2C Decodierung habe ich, ich will aber >> die Historie auch noch loggen - das kann er nicht. > > https://sigrok.org/ Mega coole Sache, besten Dank für den Link :-) Als weitere Möglichkeit sei dem TO noch dieses Projekt genannt. Beitrag "I2C (TWI) Sniffer mit AVR" Ich suche aktuell auch nach sowas und habe erste code Zeilen für den BluePill geschrieben und habe so manche Ideen den i2c-Fehler, dem ich auf der Spur bin, damit sichtbar zu machen. Wenn man dann noch SCL + SDA anlog einliest und im Ring speichert (ggf. auf einem F407 mit mehr RAM und speed) läßt sich womöglich klären was schief lief.
Gast
#6043352
Hat das bei dir funktioniert? Ich suche einen logger, der auch gestörte I2C Leitungen aufzeichnen und decodieren kann.
Gast
#6043788
Die Frage ist die Geschwindigkeit, bei welcher i2c Geschwindigkeit wird dies gebraucht ? Bei 100khz komme ich mit AVR hin, aber dies sind Welten von 400Khz entfernt. Klar kann man 7bit ADC mit 100khz machen, und für 400khz die digitalen States hernehmen, Problem sind halt die State welche dann nicht menr exakt sind, eben nur mehr Schätzungen. Aber auch so ein Schätzteisen zu haben ist besser als keins zu haben. Man müsste die SW auf den stm32 anpassen, um entsprechende ADC geschwindigkeit zu haben. Ob die SW aber bei dieser Geschwindigkeit aber überhaupt noch funktioniert, keine Ahnung.
Gast
#6043886
chris schrieb: > Die Frage ist die Geschwindigkeit, bei welcher i2c Geschwindigkeit wird > dies gebraucht ? Ich brauche 400kHz und die Störungen liegen im Mhz-Bereich. (Nadeln).
Gast
#6044031
Ist es machbar die SW (100khz) auf Avr auszutesten. Derzeit wird ein 2Mbit rs232 link verwendet. Für Rpi ist SPI denkbar für mehr Durchsatz, damit sollte es dann auch zumindest vom Durchsatz her mit stm32 funktionieren. Der LA funktioniert mit 1M/S (4bit) nur digital sind die 400k Transaktionen zu sehen. Chris
Gast
#6044668
ok, ich werde mich mal umsehen und gfs aelbst probehalber implementieren
Gast
#6044761
Ich habe das mit einem BluePill (72MHz) aufgebaut und brauchte "nur" einen 100KHz Bus tracen was mir gelungen ist. Zykluszeit der loop 2..4µS. Doch - o Wunder - weitere Varianten des Chips kamen dann nichtmal mehr damit zurecht, die Zykluszeiten war ein Stück höher (bei gleicher SW !?!?) Habs noch nicht probiert wie schnell ein F407 mit ~160MHz das schaffen würde, auch noch keine ernsthafte Energie in Optimierung gesteckt, aber viel kann das eh nicht mehr sein. Wenn STOP erkannt wird kann ich den SysTick gerade mal mit 12bit in hex senden(3 Zeichen), für mehr langt die Zeit nicht, wobei das gebuffert ist. Ein 400KHz i2c Bus wird man wohl nur mit dediziertem HW Sniffer sicher erfassen können. Ein FPGA oder ein paar GALs (liegen hier noch rum) die man mit den Routinen füttert dürften da schon besser/schneller sein. Es nützt ja nix wenn ab und zu mal das Terminal komische Werte anzeigt und man unsicher ist ob es der Sniffer oder der Bus war.
Was will man da erwarten? 400kHz I2C ist ja schon recht schnell und erfordert entsprechende analoge Bandbreiten von wenigstens 4MHz, um Flanken gut abzubilden. Wenn man sich nicht irgendwie synchronisieren kann und will man Störungen sehen, weil z.B. ein ACK zu spät oder zu früh kommt, muss das jedes Bit auf 10% aufgelöst werden. Ich sehe da wenigstens 5Mhz oder besser 10MHz, also 25 samples pro Bit. Eine I2C Nachricht hat schon mal gut 5-6 Worte -> 1k/2k Samples für offline Betrieb. Für Echtzeit sehe ich für 4MHz eine Rate von 500kBps als 16 Bit Worte mit 250kWps. Ein Raspi kann das vlt. noch verarbeiten, wenn er es parallel bekommt, aber es muss ein digitales frontend davor.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.