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
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
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
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.
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
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
> 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
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.
@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
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.
@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
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.
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.
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
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.
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
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
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.
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
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
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
@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
@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
@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
