www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik I2C Sniffer + Software


Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich bin auf der suche nach einem fertigen I2C-Sniffer-System
(Schaltplan + PC-Software) für die Serielle Schnittstelle. Parallele
Schnittstelle würde aber auch gehen. Es sollte halt auf WinXP laufen.
Ich möchte ein I2C System aus einem Master Atmega32 und einem Slave
Atmega8 zum laufen bringen. Der Master soll Daten aus dem Atmega holen
und auch welche Schreiben können.

Aber irgendwie funzt meine Programmierung nicht ganz so wie sie soll.
Irgend etwas läuft zwar auf dem Bus, jedoch mit meinem Analogen Oszi
ist das schwer zu analysieren.
Deswegen dachte ich mit einem Sinffer könnte man das besser machen.

Kann mir jemand helfen?

Oder hat jemand ein Programm für einen Master Slave Datenaustausch
zwischen zwei Atmegas. Als Programmieroberfläche habe ich WINAVR.

Gruß,

Chris

Autor: Gerald (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo chris,

ganz einfach:
beim ATmega16 z.B. Manual ab Seite 170 lesen und dann die Routinen
abschreiben und schon läuft das problemlos ab...... wenigstens in
meinen Anwendungen.


Gruss

Gerald

Autor: Hauke Sattler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Ich habe vor einiger Zeit mal sowas gemacht.
War ein Mega8 mit 7,ungerade MHz Quarz.
Die daten wurden mit 115 kBaud über die Serielle Schnittstelle an ein
Terminal Programm (Bray) übergeben.
Lief auch auf einem STK500.
Daten wurden z.B. in Folgender Form augegeben:
sA0a12a34asA1a00a00np
Meint
sA0a
=Start mit Adresse $A0 und bestätigt (ackn)
12a = $12 gesendet und bestätigt
34a = $34 gesendet und bestätigt
sA1a
=Restart mit Adresse $A1 und bestätigt
00a = $00 gesendet und bestätigt
00n = $00 gesendet und NICHT bestätigt (nackn)
p = STOP

Ist allerdings extrem krude Programmierung.
Ich hatte schon immer vor das Ding mal sauber zu scheiben und via
FTDI245R an den USB anzubinden.
Sag bescheid wenn du es eilig hast dann kann ich dir ab Montag die alte
Version.schicken.


cu
Hauke

Autor: thkais (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andere Möglichkeit: Die Taktfrequenz des AVRs so weit runterschrauben,
bis man die Bussignale mittels zweier LEDs sehen kann. Damit habe ich
schon so manchen "Knoten" gefunden, die meisten Devices kommen mit
solch einem langsamen Takt zurecht.

Autor: Hauke Sattler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja um reine Protokoll Probleme zufinden ist das ok.
Aber wenn es um Timing Probleme geht dann muß man das schon mit der
geplanten Geschwindigkeit laufen lassen.

cu
Hauke

Autor: Axel R. (axelr) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hauke Sattler wrote:
> Hi
>
> Ich habe vor einiger Zeit mal sowas gemacht.
>
> Sag bescheid wenn du es eilig hast dann kann ich dir ab Montag die alte
> Version.schicken.
>
>
> cu
> Hauke

Ist zwar nicht ganz ein Jahr her, aber immernoch (oder wieder) aktuell.
Wenn der Hauke noch mitliest:
Ich bräuchte das Programm mal eben.

>Ist allerdings extrem krude Programmierung.

Schlimmer, als die Codevision-Variante auf AVRfreaks.net (DesignNote 48) 
wirds hoffentlich nicht sein.

Vielen herzlichen Dank

AxelR.

axel punkt ruehl ätt gmx punkt de
oder  - besser - als Zip hier ins Forum

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Deswegen dachte ich mit einem Sinffer könnte man das besser machen.

Dann hast du zwei Probleme, den Sniffer (der nicht auf Anhieb laufen 
muss) und deine Schaltung. Versuch es anders zu debuggen. Ggf. musst du 
dir irgendwo eine DSO leihweise besorgen. Selbst die USB-Scopes sollten 
dafür reichen.

MfG
Falk

Autor: Axel R. (axelr) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein DSO habe ich  - einen HP54645.
Die I2C Sinale lassen sich auch darstellen, aber 130Bytes passen eben 
nicht drauf. Triggern geht auch nicht wirklich toll. Kann ich zwar auf 
Start triggern (fallende Flanke und gleichzeitig Low Pegel auf den 
entspr. Kanälen), aber da ein Block aus mehreren Sequenzen besteht, 
triggert er halt immer nur auf die letzte Sequenz. Die besteht aus einem 
Byte(lesebefehl). die anderen Bytes sind dann "weg".
Der andere DSO, den ich hier habe, ein Agilent 54622D geht schon besser, 
aber es passt auch nicht alles drauf.

Ich würd' ja nicht fragen, wenns anders ginge.
Taktfrequenz runter geht auch nicht, da der Master (Q2686 GSM-Modul) das 
nicht zulässt.

Nun, evtl. liest der Hauke, oder jemand anders, meinen Post und hat was 
fertiges ;-)

MfG
AxelR.

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Axel Rühl

> Ein DSO habe ich  - einen HP54645.

Na bitte. Das ist doch die halbe Miete!

> Die I2C Sinale lassen sich auch darstellen, aber 130Bytes passen eben

Brauchst du wahrscheinlich auch gar nicht.

> nicht drauf. Triggern geht auch nicht wirklich toll. Kann ich zwar auf

Gewusst wie!!!

Nimm einen freien Pin am AVR und erzeuge in deiner Software einen kurzen 
Puls wenn deine Übertragung beginnt. Das Signal auf den 2. Kanal bzw. 
exteren Trigger vom Scope -> Ähhh voala.

Nun kannst du deinen Triggerpunkt in der AVR-Software hinlegen wo du 
willst

> Ich würd' ja nicht fragen, wenns anders ginge.

Du fragts, weil du ein paar Sachen nicht weisst oder kannst. Das ist OK.
Aber es geht fast immer. Man muss nur wissen wie.

> Taktfrequenz runter geht auch nicht, da der Master (Q2686 GSM-Modul) das
> nicht zulässt.

Ach so, der AVR ist Slave. Egal, es gilt das gleiche.

MFG
Falk

Autor: Axel R. (axelr) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja ich weisss - :-)

Ich wollte keine bits am Oszi abzählen, sonder die Sache im Klartext 
angezeigt bekommen.
Leider hat mein Chef den "LOGICPORT" von 
http://www.pctestinstruments.com/deutsch
(noch?) nicht bestellt. Das Ding täte mir gefallen.
Nun ich werde deinen Vorschlag erstmal aufnehmen und einen entspr. 
Triggerpunkt setzen.
Etweder im AVR oder im Oszi.
Das geht mit dem 54622 (I2C-Adresse,Daten,Lesen) ja ganz gut. Aber es 
bleibt dabei - alles passt nicht drauf...
Unterneinander schön formatiert innem Memofeld wär' schon besser.

Wenn ich was habe, kann ich mich ja mal melden.

Danke
AxelR.

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Axel Rühl

> Ich wollte keine bits am Oszi abzählen, sonder die Sache im Klartext
> angezeigt bekommen.

Häää? Aber nen I2C Sniffer bauen, das ist ja auch soooo viel einfacher.

> Unterneinander schön formatiert innem Memofeld wär' schon besser.

Sind die deutschen Entwickler mittlerweile soooo faul?
Aber "Ich würd' ja nicht fragen, wenns anders ginge."

Eieieieiei, diese Jugend heutzutage.
;-)

MfG
Falk

Autor: Jörg S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Sind die deutschen Entwickler mittlerweile soooo faul?
Na ja, 130Byte sind schon mal recht viel zum zählen. Aber ich würde es 
wohl auch so machen ;)

Autor: Peter K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
im Funkamateur 1/03 wird ein " Lauscher am Bus:I²C-Monitor" als 
Selbstbauprojekt von Wolfram Harth vorgestellt.
Platinenvorlage und Software kann man
beim Verlag downloaden.Es handelt sich um ein kleines eigenstaendiges 
Geraet mit LCD-Anzeige fuer die Ausgabe des I²C-Protokolls.
Spannungsversorgung 5 V + SDA und SCL mehr wird nicht benoetigt.

MFG
Peter K.

Autor: Axel R. (axelr) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe beim Atmega168 jetzt die USART initialisiert und gebe im 
TWI-Interrupt die drei interessanten Register aus (Status, Control und 
Datenregister). Das funktioninert ganz gut.

Zu den 130 Byte.
Kurbel Du dich da mal durch und versuche mal, den Überblick zu behalten.
Hinzu kommt, das ich das schliesslich auch dokumentieren muss.
Ist ja auch egal - meine Frage ging in Richtung I2C Sniffer und ob 
jemand (speziell Hauke, da angeboten) seine Quellen zur Verfügung 
stellt.


@Peter
Den Funkamateurartikel sehe ich mir mal an.

Das gefällt mir! Ist mitm PIC? Mal sehn, ob es da einen Quelltext für 
gibt.

Ja - alles dabei: Schön
http://download.funkamateur.de/.download/i2cmon.zip

Danke
AxelR.

Autor: Hauke Sattler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oh Mann
"Uralter Thead aus dem Grabe gekrochen"

Ich müßte mal nach dem Code suchen. Der Code ist wirklich uralt (ca. nen 
halbes Jahr nach der DN48) und krude (deshalb ist er mir auch peinlich).

Ich müßte mal suchen und testen (damit ich dir auch eine funktionierende 
Version schicke)
Ich muß jedoch dabei sagen, daß ich keine galvanische Trennung verwendet 
habe, und auch mich wenig um die Logiclevel geschert habe. (war für 
meine Zwecke halt nicht nötig)

Schreib einfach welche Uartgeschwingkeit und welchen Quarz du vorgesehen 
hast.

cu
Hauke

Autor: Axel R. (axelr) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hauke, schön dass Du mit reinschaust :-))

Alter Thread, das hast Du wohl Recht - habe die Suchfunktion verwendet..

19K2 oder 9K6 als Baudrate scheint mir ausreichend.
Als Quarz nehm ich immer einen 3.6864 bzw. 4.9152Mhz. Wenn der hier zu 
langsam ist, hätte ich noch einen 18Mhz da.
Controller ist ein Mega168.
Logikpegel ist egal, kommt eh' ein Pegelwandler zwischen.

Danke einstweilen

AxelR.

Autor: Hauke Sattler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
m168 hmmmmm
Der Code ist in Assembler für den Mega8. Da müßte man mal mit den 
Registern schauen ob das passt.

Ich bevorzuge 7.3728 Mhz und 14,7456 Mhz.
Ich muß dazu sagen, daß 9600 und 19200 Baud sehr wenig ist. (im 
vergleich zu den 100.000 bit/s des I²C)

76,8kBaud bzw. 115,2kBaud wäre eher angebracht.

Muß mal schauen wenn ich den source gefunden habe.

cu
Hauke




Autor: Hauke Sattler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok

Ich hab mal geschaut und den Source gefunden.

Diesen bekomme ich jedoch nicht auf dem M168 lauffähig.
Irgendwie passen Datenblatt und Device nicht zueinander.
Ein paar Fehler hab ich schon gefunden. (z.B. Die ASM USART Routienen im 
M168 Datenblatt sind Blödsinn)

Aber mit den externen Interrupts macht das Ding zu Zeit nur Mist.

Deshalb kann ich zur Zeit nur den M8 Code anbieten.

bis dann
cu
Hauke

Autor: Axel R. (axelr) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, denn nehm wir den M8.
Habe ich auch noch liegen.

Danke
axelR.

Autor: Hauke Sattler (hauke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sag bescheid wenn es läuft

cu
Hauke

Autor: ecslowhand (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und ??? Ist noch jemand an der Sache dran ???

LG EC

Autor: Hauke Sattler (hauke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab ihn meinen Source geschickt.

Keine ahnung ob er es ans laufen bekommen hat.

cu
Hauke

Autor: Axel R. (axelr) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Leute,

ja ist alles angekommen, habe es allerdings noch nicht probieren können.
Nachdem ich den blöden Fehler in meinem Programm fand, stellte sich 
raus, dass es garnicht an der IIC Kommunikation gelegen hatte.
Danach bin ich zum Tagesgeschäft übergegangen und habe gar nicht mehr 
drann gedacht... rotwerd.


Gruß
AxelR.

Autor: ecslowhand (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie stellt Ihr Euch denn die Kopplung an den I2C-Bus vor? Die Lösung aus 
der DN48 ist ja o.k., eine galvanische Trennung fände ich besser.
Jemand eine Idee ???

LG EC

Autor: Hauke Sattler (hauke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Galvanische Trennung bei einem I²C Bus ist nicht ohne. Da beide 
Leitungen bidirektional genutzt werden. (ja auch die Clockleitung wird 
vom Slave zum Senden benutzt. z.B. um einen Wartezyklus zu erzwingen)

Ich hatte vor Urzeiten mal in einem Buch 30* Schaltungen nen Vorschlag 
dazu gesehen. Aber das Design sehr abhängig von Timing und Logicleveln.

Da die Leitungen des Sniffers aber unidirektional genutzt werden, sollte 
das in diesem Falle möglich sein.

cu
Hauke

Autor: ecslowhand (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit dem Unidirektional ist schon klar. Geht einfach darum, den Bus nicht 
zusehr zu belasten. Die Lösung bei der DN48 ist praktikabel und 
akzeptabel...
Ich habe den folgenden Artikel gefunden:
www.circuitcellar.com/AVR2004/wabstracts/A3808abstract.pdf

Aber grob gerechnet 23mA pro Optokoppler ist schon happich.

LG EC


Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ecslowhand

>Mit dem Unidirektional ist schon klar. Geht einfach darum, den Bus nicht
>zusehr zu belasten. Die Lösung bei der DN48 ist praktikabel und

Und wieso dann optoentkoppelt? Ein einfaches HC Gatter belastet die 
Leitungen nicht wesentlich. Und wenn WIRKLICH Optoentkopplung notwendig 
ist, dann sicherlich erst ein Gatter und danach erst der Optokoppler.

MfG
Falk

Autor: ecslowhand (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Falk: "sicherlich erst ein Gatter und danach erst der Optokoppler" ?

Auch eine elegante Möglichkeit, den Optokoppler wegzuoptimieren.... :)

Soll heissen: Woher nimmst Du die Versorgungsspannung der Gatter ?

LG EC

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ecslowhand

>Auch eine elegante Möglichkeit, den Optokoppler wegzuoptimieren.... :)

Wieso wegoptimieren? In 99% aller Fälle braucht man keine galvanische 
Trennung für nen I2C-Sniffer.

>Soll heissen: Woher nimmst Du die Versorgungsspannung der Gatter ?

Entweder aus der Zielschaltung (die hat ja irgendwo 3,3 oder 5V) oder 
aus nem kleinen Trafo/DCDC Wandler. Aber wie gesagt, wozu galvanische 
Trennung bei nem I2C Sniffer?

MfG
Falk

Autor: ecslowhand (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gebe Dir ja Recht, nötig ist die Trennung nicht.
Schön wärs trotzdem......

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.