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
> 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 ;)
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
Ich hab ihn meinen Source geschickt. Keine ahnung ob er es ans laufen bekommen hat. 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
Gebe Dir ja Recht, nötig ist die Trennung nicht. Schön wärs trotzdem......
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.