Datum:
Angehängte Dateien:Manchmal will man wissen, was auf dem I2C Bus eigentlich los ist. Anbei ein sehr einfach aufzubauender I2C-Sniffer. Benutzt wird ein ATtiny85 mit 14,7456MHz Quarz. Damit ergibt sich ein besonders kleiner Aufbau, so daß der Sniffer bequem in einem D-Sub9 Gehäuse Platz findet. Das Sendebit kann invertiert werden, so daß kein RS232-Pegelkonverter benötigt wird. Die Ausgabe erfolgt als Text über die UART mit 255 Byte FIFO. Nach jedem Stop erfolgt ein Zeilenvorschub. Anbei der complette Programmcode. Das C-Programm erreicht max 230400 Baud. Das Assemblerprogramm läuft bis zu 460800 Baud und hat 501 Byte FIFO. Baudraten über 115200 Baud habe ich aber nur mit USB-RS232 Adaptern empfangen können. Die maximale Frequenz auf dem I2C ist XTAL/2, also >7MHz. Im Gegensatz dazu schaffen reine Softwarelösungen oftmals nur 100kHz. Ist der Sendepuffer voll, erfolgt über das USI automatisch die SCL-Verlängerung. Es geht daher kein I2C-Transfer verloren. Es ergibt sich also durch die Verwendung des ATtiny eine besonders leistungsfähige, platzsparende und preisgünstige Lösung. Peter
Datum:
@ Peter Dannegger Deinen sniffer (den in C) habe ich mal durchgesehen - leider ist deine Kommentierung sparsam geraten. Daher sind 2 Anmerkungen/Fragen geblieben. Die Datenpufferung habe ich wie folgt rekonstruiert: Wenn z.B. der Master einen nicht existierenden Slave adressiert, dann sendet er - Start-Condition, - Slave_Adresse, erhält kein ACK (also ein NACK) zurück und - beendet mit STOP, übertragen wird also 1 Byte (die Adresse) plus etwas Protokoll. Im TX-Buffer werden abgelegt: 1. Byte 's' Symbol für Start 2. Byte 'x' upper nibble des Adressbytes 3. Byte 'y' lower nibble des Adressbytes 4. Byte 's' Symbol für NACK 5. Byte 's' Symbol für STOP 6. Byte \r Steuerzeichen CR Carriage Return 7. Byte \n Steuerzeichen LF Linefeed Nach Adam Riese sind das 7 ganze Byte. In den ca. 500 Byte SRAM lassen sich (bei diesem Beispiel) unterm Strich 72 Byte Nutzdaten ablegen. OK, diese Betrachtung stellt den ungünstigsten Fall dar. Zeigt aber dennoch, dass die gewählte Form der Datenablage nicht gerade sparsam mit dem eh schon schlanken SRAM umgeht. Weiterhin habe ich nicht herausgefunden, mit welchem Trick es dir gelingt, einen Pufferüberlauf zuverhindern. Laut Datenblatt könnte man dafür einen USI-Modus (USIWM1 = 1, USIWM0 = 1) nutzen, der SCL nach einem USI-OVL solange auf low hält, bis der USIOIF manuell gelöscht wird. Dieser Weg wird aber nicht eingeschlagen (USIWM0 steht auf 0). Soweit ich sehe, werden die Flags USISIF, USIOIF und USIPF gepollt - und sofort ohne Prüfung auf einen Pufferüberlauf gelöscht. In der UART.C finde ich nur die Kontrolle des Indexüberlaufes. Vermutlich habe ich mal wieder wesentliche Zusammenhänge übersehen ? Zu meiner Entschuldigung - ich bin Anfänger und fakultätsfremder Freizeitprogrammierer ... Vielleicht gibt’s du ja trotzdem einen Tipp? gastleser
Datum:
gastleser wrote: > Zeigt aber dennoch, dass die gewählte Form der Datenablage nicht gerade > sparsam mit dem eh schon schlanken SRAM umgeht. Stimmt. Ich habe aber keinen Grund gesehen, da mehr Arbeit reinzustecken, weil ja die Anwendungen üblicher Weise nicht nur I2C-Daten umherschaufeln, sondern ne andere Hauptaufgabe haben. Es treten also auch immer lange Pausen auf, wo der Puffer gelehrt werden kann. Bzw. der Puffer wird ja auch während des Sniffens permanent geleert mit bis zu 460800 Baud. > Weiterhin habe ich nicht herausgefunden, mit welchem Trick es dir > gelingt, einen Pufferüberlauf zuverhindern. > Laut Datenblatt könnte man dafür einen USI-Modus (USIWM1 = 1, USIWM0 = > 1) nutzen, der SCL nach einem USI-OVL solange auf low hält, bis der > USIOIF manuell gelöscht wird. Stimmt, so mache ich es. > Dieser Weg wird aber nicht eingeschlagen > (USIWM0 steht auf 0). Doch, hier:
USICR = 1<<USIWM1^1<<USIWM0; // I2C, no counter |
> Soweit ich sehe, werden die Flags USISIF, USIOIF und USIPF gepollt - und > sofort ohne Prüfung auf einen Pufferüberlauf gelöscht. > In der UART.C finde ich nur die Kontrolle des Indexüberlaufes. Das putchar wartet, wenn der Puffer voll ist, bis wieder für ein Byte Platz ist:
while( i == vu8(tx_out)); // until at least one byte free |
> Zu meiner Entschuldigung - ich bin Anfänger und fakultätsfremder > Freizeitprogrammierer ... Ich bin auch kein Profiprogrammierer, sondern entwickle hauptsächlich Hardware. Und dabei programmiere ich dann auch einige MCs, die da drin sind. MCs sind ganz praktisch, denn oftmals wissen die Kunden selber nicht genau, wie die einzelnen Abläufe zu steuern sind. Und statt dann bei Änderungswünschen ein neues Layout fertigen zu müssen, programmiere ich lieber den MC um. Peter
Datum:
@ Peter Dannegger Sorry, offensichtlich hatte ich Tomaten auf den Augen, als ich das 1<<USIWM0 übersehen habe (deine Schreibweise mit dem XOR anstelle des schulbuchüblich OR und der Verzicht auf gliedernde Leerzeichen irritiert mich ein wenig). Aber dennoch, nach meinem Verständnis ist etwas mehr an Arbeit vonnöten, als lediglich das Setzen eines Flags: Nach dem ACK/NACK müsste geprüft werden, ob noch freier Puffer vorhanden ist. Wenn ja, dann kann USIOIF gelöscht werden - und dann gehts weiter in der TWI-Kommunikation. Ist kein Puffer mehr frei, dann muss solange gewartet werden, bis wieder Puffer frei ist, erst dann darf USIOIF gelöscht werden. Diesen Mechanismus sehe ich nicht. Daher vermute ich, dass dein Programm mitnichten den TWI-Bus unterbricht, sondern glatt von hinter her überfahren wird. Oder wie siehtst du das ?? Leider habe ich keinen tn85 zu ausprobieren. Übrigens kannst du das Linefeed sparen, ein normales CR (CHR 13) reicht aus, um auf dem Terminal eine neue Zeile zu beginnen. Das reduziert den SRAM-Bedarf (im günstigsten Fall) um 25% ! Das ist doch was. Manchmal ist weniger tatsächlich mehr. Leider nicht immer.
Datum:
gastleser wrote: > (deine Schreibweise mit dem XOR anstelle des schulbuchüblich OR und der > Verzicht auf gliedernde Leerzeichen irritiert mich ein wenig). Ja, als Autodidakt und Einzelkämpfer leiste ich mir den Spaß, nicht immer stur nach Lehrbuch vorzugehen :-) Programmieren kann ruhig auch Spaß machen. Manchmal setze ich auch Aussehen des Codes vor die Effizienz. > Ist kein Puffer mehr frei, dann muss solange gewartet werden, bis wieder > Puffer frei ist, > erst dann darf USIOIF gelöscht werden. > Diesen Mechanismus sehe ich nicht. > Daher vermute ich, dass dein Programm mitnichten den TWI-Bus > unterbricht, sondern glatt von hinter her überfahren wird. > Oder wie siehtst du das ?? Du denkst zu kurz. Wenn ich das Ereignis ausgewertet habe, dann darf ich auch das Flag löschen. Wenn nun aber das putchar für die Ausgabe wartet, dann verzögert das automatisch die Auswertung des folgenden Ereignisses. Der AVR-GCC ist ja auch ein Meister in Faulheit, d.h. im Ausführen zum spätest möglichen Zeitpunkt. Auch wenn er mir dadurch oftmals Optimierungen (kein else-Zweig) zunichte macht, mag ich das irgendwie. > Leider habe ich keinen tn85 zu ausprobieren. Ich versuche die Programme möglichst universell zu schreiben. Eine Anpassung an ATtiny25, 24, 2313 sollte daher leicht möglich sein. > Übrigens kannst du das Linefeed sparen, ein normales CR (CHR 13) reicht > aus, um auf dem Terminal eine neue Zeile zu beginnen. Ja, nem Terminalprogramm kann man das sagen. Ob aber jeder Textbetrachter das kann, wenn man die Ausgabe in ein File schreibt, habe ich nicht getestet. Ich hab es auch lieber, wenn jemand die Beispiele nicht stupid übernimmt, sondern auch versteht und sie dann seinen Bedürfnissen anpaßt. Peter
Datum:
@ Peter Dannegger, > Wenn nun aber das putchar für die Ausgabe wartet, dann verzögert das > automatisch die Auswertung des folgenden Ereignisses. OK, mit dieser Hilfestellung habe ich's verstanden. Genial ist es übrigens erst dann, wenn ein Programm nicht nur funktioniert, sondern auch noch ohne Klimmzüge lesbar ist. > Ich versuche die Programme möglichst universell zu schreiben. Eine > Anpassung an ATtiny25, 24, 2313 sollte daher leicht möglich sein. Das Portieren auf einen anderen Chip stellt sicherlich kein wirkliches Problem dar. Das Problem ist lediglich, dass die genannten mc's (at2313, at25) noch weniger SRAM haben als der at85. Leider gelingt es mir nicht, mit mehr als 38400 Baud lesbare Zeichen zu übertragen (hterm als Terminalprogramm). Neben der Software habe ich auch meine Hardware modular entwickelt. Gemeinsam kommuniziert alles über den TWI-Bus: TWI-LCD-Display, at2313 als PCF8574-Ersatz, at26 für AD-Wandler etc. Das TWI-LCD spart viel RAM auf der Master-Seite, insbesondere, weil ich alle Menü-Texte auf einem Eeprom gespeichert habe und somit nicht mit Buchstaben geizen muss. Und weil der Speicher eines TWI-LCD's ausreicht, um Bargraphen oder sonstige Schnörkel direkt auf dem Slave zu implementieren. Zum Aufbau einer Menüseite lade ich 4x 20 Zeichen vom Eeprom und schreibe sie auf das TWI-LCD, das sind 80 Byte * 2 an Daten zuzüglich Adressierung sowie Cursorpositionierung. Somit huschen hier immer mehr als 200 Byte (übrigens ohne wahrnehmbare Verzögerung) über den Bus. Und danach kommen womöglich erst die Daten, die ich unter die Lupe nehmen will. Hier hilft mir leider nur ein möglichst großer Puffer.
Datum:
gastleser wrote: > Genial ist es übrigens erst dann, wenn ein Programm nicht nur > funktioniert, sondern auch noch ohne Klimmzüge lesbar ist. Warum diese Bemerkung? Ich habe nirgends behauptet, daß der Code genial wäre. Man tut sich aber generell schwer, fremden Quellcode auf Anhieb zu verstehen, geht jedem so. > Leider gelingt es mir nicht, mit mehr als 38400 Baud lesbare Zeichen zu > übertragen (hterm als Terminalprogramm). Stimmt der Quarz? Es sollte unbedingt ein Baudratenquarz sein, sonst kann der Fehler zu groß sein. Die Fuses müssen auf >8MHz gesetzt sein. Ist der RS-232 Pegelwandler schnell genug und die Leitung nicht zu lang? Versuch mal nen USB-RS232 Konverter, die scheinen mir besser bei höheren Baudraten zu gehen. Der C-Code ist bei 230400 Baud getestet, der Assemblercode bei 460800 Baud. > Das TWI-LCD spart viel RAM auf der Master-Seite, insbesondere, weil ich > alle Menü-Texte auf einem Eeprom gespeichert habe und somit nicht mit > Buchstaben geizen muss. Was ist das für ein I2C-LCD? Ich habe bisher nur I2C-LCD gefunden, die wesentlich teurer als ein normales LCD mit zusätzlichen AVR sind. > Zum Aufbau einer Menüseite lade ich 4x 20 Zeichen vom Eeprom und > schreibe sie auf das TWI-LCD, das sind 80 Byte * 2 an Daten zuzüglich > Adressierung sowie Cursorpositionierung. In nem 8kB-AVR kannst Du dann auch Deine Menüs im Flash ablegen und brauchst keinen extra EEPROM. > Somit huschen hier immer mehr als 200 Byte (übrigens ohne wahrnehmbare > Verzögerung) über den Bus. > Und danach kommen womöglich erst die Daten, die ich unter die Lupe > nehmen will. > Hier hilft mir leider nur ein möglichst großer Puffer. Und wo ist das Problem? Ich dachte, Du hast verstanden, daß der Code SCL streckt, also auch bei vollem Puffer läßt sich alles sniffen. Man muß natürlich bei einem SW-I2C-Master das SCL Prüfen einbauen, HW-I2C hat das ja automatisch drin. Peter
Datum:
@ Peter Dannegger > Es sollte unbedingt ein Baudratenquarz sein .. Ist ein 7.xxx MHz Quarz. > Was ist das für ein I2C-LCD? Das ist ein USI-Slave (at2313 oder m8) mit angeschlossenem LCD. Der mc spielt den slave, initialisiert das LCD und reicht an ihn gesandte Daten ans LCD weiter. Im verbleibenden Flash kann man dann noch weitere Routinen unterbringen, die den Programmcode auf dem (oder den) master(n) sowie die notwendige Datenübertragung über den Bus reduzieren. Das kann man für teueres Geld kaufen - oder für wenig Geld selbst löten. > In nem 8kB-AVR kannst Du dann auch Deine Menüs im Flash ablegen und > brauchst keinen extra EEPROM. Sind aber schon ca. 16 Menüs mit je 4 Zeilen a 20 Zeichen mit steigender Tendenz. Wo lasse ich da den Programmcode ? Ich musste so schon auf einen m168 wechseln. > Ich dachte, Du hast verstanden, daß der Code SCL streckt, also auch bei > vollem Puffer läßt sich alles sniffen. Ja, dank deiner Hilfe. Aber ich möchte durch codestretching nicht das belauschte System beeinflussen! Der sniffer soll völlig transparent bleiben. Oder würdest du mit einem Voltmeter mit 1k-Ohm Innenwiderstand Spannungsmessungen durchführen wollen ?
Datum:
>der würdest du mit einem Voltmeter mit 1k-Ohm Innenwiderstand >Spannungsmessungen durchführen wollen ? Wenn der Innenwiderstand der Spannungsquelle auch 1k hat, dann einfach mal zwei. ;-) duckundweg
Datum:
gastleser wrote: >> Es sollte unbedingt ein Baudratenquarz sein .. > Ist ein 7.xxx MHz Quarz. Mit einem 7,3728MHz Quarz sind 115200 Baud kein Problem (C-Programm). > Aber ich möchte durch codestretching nicht das belauschte System > beeinflussen! Der sniffer soll völlig transparent bleiben. > Oder würdest du mit einem Voltmeter mit 1k-Ohm Innenwiderstand > Spannungsmessungen durchführen wollen ? Dein Vergleich hinkt, das Stretching ist ja Bestandteil der I2C-Spezifikation. Es gibt also keine Datenverfälschung. Da paßt dann eher der Vergleich: Du hast zwar ein 1kOhm Voltmeter, aber alle Meßpunkte haben einen Spannungsfolger nachgeschaltet. Mir hat der Sniffer jedenfalls geholfen. Es war mir wichtig (und zielführend), wer was mit wem quatscht und nicht, wie schnell er es macht. Konkret war der Fehler beim Retry nach Arbitrationsverlust. Multimaster ist schon etwas tricky. Wie schon gesagt, ein Bus-Design sollte nie auf 100% laufen, sondern immmer Reserven haben. Peter
Datum:
Hallo Peter, nach meinen Erfahrungen mit den Mega's wollt ich deinen Sniffer (der erste Tiny den ich verwende) nachbauen, da ich auch im Moment ein I2C Problem hab. Dazu sind mir ein paar Fragen gekommen: Kann man bei dem ATtiny85, wenn er mit der Sniffer-Firmeware programmiert ist, auch noch per ISP programmieren? Oder muss man die SPI-Fuse für einen normalen Betrieb als Sniffer löschen? (ähnlich den JTAG-Pins bei den Mega's, wo ich JTAG deaktivieren muss, um die Pins normal verwenden zu können) Oder gehts nur noch mit HVSP wenn einmal die Firmeware drauf ist? Einen Bootloader wollt nicht eigentlich noch nicht verwenden, das heb ich mir für ein späteres Projekt auf. Ich bin gerade dabei mir eine Platine zu machen, die in ein COM 942 :: Selbstbaugehäuse D-Sub, 2x 9-pol von Reichelt passt, auf der auch ein max232 mit drauf kommt. MfG Wolfgang PS: irgendwo hab ich schon einen Schaltplan für so einen Sniffer gesehen? Die Seite weiß zufällig keiner hier, oder?
Datum:
Wolfgang Birner wrote: > Kann man bei dem ATtiny85, wenn er mit der Sniffer-Firmeware > programmiert ist, auch noch per ISP programmieren? Ja, der Reset-Pin wird nicht benutzt. Peter
Peter Dannegger wrote: > Ja, der Reset-Pin wird nicht benutzt. Wenn ich das richtig verstehe heißt das also, sobald der Reset-Pin frei ist, geht ISP immer. Ich hab mal zwei Schaltpläne fertig gestellt, einmal mit max232 und einmal mit ft232r, vielleicht mag jemand einen Kommentar dazu abgeben? MfG Wolfgang
Und hier die USB-Variante. Die 10pol. Stiftleiste hat eigentlich die Standardbelegung für den 10pol. ISP-Anschluss. Leider liegen die SDA/SCL-Leitungen nicht direkt beieinander. Wenn keine krassen Fehler drin sind, werde ich noch ein Layout fertig machen und hier rein stellen. MfG Wolfgang
Datum:
Hallo Wolfgang, ich hätte Interesse an einem Layout. Gruß Michi Müller
Datum:
Guten Morgen Michi Müller, schön das sich wenigstens einer meldet, wenn die beiden Schaltpläne zusammen schon 99x heruntergeladen wurden. Das Layout für den Seriellen hab ich fertig, ich will schaun das ich den usb heute auch noch hin bekomme. Ich hoffe das es dann auch so geht, ich hoffte vom Peter Dannegger eine Rückmeldung zu bekommen. MfG Wolfgang
Datum:
Zur USB Variante: Warum hast Du C11 und C12 eingeführt ? Wofür sollen R10 und R13 sein ? In den Application Notes findet sich dazu nichts. Gruß Sven
Sven K. wrote: > Zur USB Variante: > Warum hast Du C11 und C12 eingeführt ? Die sind im Datenblatt, den App-Notes oder den Beispielschaltungen irgendwo drin. Diese USB-Grundschaltung hab ich so schon länger in Betrieb. Wenn ich mich recht erinnere sind die für die EMV. > Wofür sollen R10 und R13 sein ? R13 ist drin, da dieser Pin des MC's auf für ISP verwendet wird. Siehe App-Note AVR042: AVR Hardware Design Considerations von Atmel. Nur beim Wert bin ich mir nicht so sicher. Bisher hatte ich noch keine Schaltung, in der sich die Pins geteilt haben. R10 ist einfach der Pin, welcher vom FT232 mit über die Steckerleiste nach drausen geht. Kann man auch weg lassen. > Gruß Sven MfG Wolfgang PS: Im Anhang die Layouts soweit sie mal fertig sind. Die RS232 Variante hat die Bauteile nur auf einer Seite, mit Ausnahme des Quarz. Die USB-Variante ist beidseitig bestückt. PPS: Nochwas hab ich vergessen: die Bauteile sind alle 0805.
Datum:
Also, wenn's gewünscht wird, würde ich eine Sammelbestellung organisieren. Bestellt würde vermutlich bei Q-PCB. Je mehr mitmachen um so billiger wirds. Rentieren würde es sich vermutlich so ab 15 Stück. Ansonsten kann ich die Eagle-brd's für nicht kommerziellen Einsatz bereitstellen.
Datum:
Wolfgang Birner wrote: > Also, wenn's gewünscht wird, würde ich eine Sammelbestellung > organisieren. Ich vermute mal, du willst nur die Platine fertigen, oder? Hast du eine Preisvorstellung? Ich wär mit 1-2 Platinen mit bei. cu, Michael
Datum:
wenn jemand die platienen fertigen löst wäre ich auch gerne mit 2-4 stück der usb variante dabei. wäre aber super wenn du noch einen jumper für umstellung 3,3v und 5v vorsehen könntest. funktioniert hier im musteraufbau super mit versorgung über den ft232rl sven
Datum:
Ja, nur Platinen. Wenns Q-PCB wird (ich hab da schon ein paar mal bestellt) solltens (wenn ich mich nicht verrechnet hab) ca. 4,50-5,00 Euro/Platine (bei insgesamt 15 Stück, drüber vermutlich billiger) werden. Dazu halt die Portokosten zu den Leuten. Wenn jemand anderes möchte, kann auch der gern die Sammelbest. organisieren. Ich selbst würde auch 2-3 Stück nehmen.
Datum:
Hallo, bei geschaetzten Platinenmassen von 15mmx40mm muessten etwa 14 Platinchen auf eine Europlatine passen Mit dem http://www.haka-lp.de/html/zwillingsangebot.html waeren das dann 28 Platinen fuer 50 Euro + Versand. Aber ohne Bestueckungsdruck, wobei ich den eher nicht brauchen wuerde. Vielleicht eine Alternative. Die sitzen zwar bei mir praktisch vor der Haustuer, aber ueber die Qualitaet der Platinen kann ich nichts sagen. Gruss Benjamin
Datum:
Wolfgang Birner wrote: > ich > hoffte vom Peter Dannegger eine Rückmeldung zu bekommen. Wie gesagt, ich hab ihn ohne RS232-Treiber direkt an die COM geklemmt. Ansonsten fällt mir erstmal nichts Fehlerhaftes auf. Peter
Datum:
Benjamin Schmidt wrote: > Mit dem http://www.haka-lp.de/html/zwillingsangebot.html waeren das dann > 28 Platinen fuer 50 Euro + Versand. Aber ohne Bestueckungsdruck, wobei > ich den eher nicht brauchen wuerde. Aber da sind die Nutzen nicht gefräst und das will ich nicht selber machen.
Datum:
Was bedeutet beim Zwillingsangebot: “bei kleineren LP's werden entsprechend mehr geliefert”? Es werden automatisch so viele Leiterplaten geliefert, wie in die 2x 100x160mm passen. Normalerweise ist dabei ein Fräsabstand von 5mm notwendig, wird allerdings die Eurokarte nur einmal geteilt (z.B 80x100), so wird kein Fräsabstand berechnet. D.h. sie bekommen 4 LP zu 100x80mm. Wichtig: nur die Daten der Einzelleiterplatte senden! Haette ich so jetzt aus den FAQs so interpretiert, dass sie den Nutzen auseinanderschneiden, aber muss ja nicht unbedingt Haka sein, und jemandem zumuten, die kleinen Dinger so zu schneiden will ich auch nicht ;) Gruss Benjamin
Datum:
Ich hab mir das jetzt nochmal mit dem Zwillingsangebot angeschaut, leider haut der DRC nicht hin. Die Bohrungen könnt ich noch aufbohren auf 0,5mm aber der Kupferabstand zum Rand wird nicht erreicht. außerdem sollte die Platine in das Gehäuse vom Reichelt gehen, da kann ich die Platine nicht größer machen (im Moment werden die Löcher vom USB-Stecker angefräst). Ich werds aber für die Zukunft mal im Auge behalten. MfG Wolfgang
Datum:
Hallo Wolfgang, ok klar, so genau hatte ich mir das Layout nicht angeschaut, war auch nur als Idee gedacht... je nach Preis bin ich auch an nem Platinchen oder 2 intressiert. Benjamin
Datum:
Da sich das jetzt ja zu konkretisieren scheint :-) 2 Platinen nehm ich.... Gerne auch per Vorauskasse. cu, Michael
Datum:
Hi Leute, erst mal toll, wieviel Mühe ihr Euch gemacht habt und uns allen euere Arbeit zur Verfügung stellt. Eventuell ließe sich der Sniffer ja noch vereinfachen, indem man den AVR auch das USB Handling machen läßt. Es gibt ja einen tollen Softwarestack http://www.obdev.at/products/avrusb/index-de.html Wahrscheinlich wird es dann ein RAM problem geben, welches man aber durch ein schnelles FRAM lösen könnte. Man hätte dadurch eine größe Speichertiefe beim sniffen und könnte sich auch das Clock Streching sparen. Ich habe nämlich festgestellt, das oft das I2C Protokoll fehlerhaft implementiert wird ! Wünsche noch einen schönen Tag Gruß Siegmar
Datum:
siegmar wrote: > Eventuell ließe sich der Sniffer ja noch > vereinfachen, indem man den AVR auch das USB Handling machen läßt. ich glaub, eine Vereinfachung ist das nicht. Die Hardware würde es vielleicht vereinfachen aber die Software nur unnötig kompliziert machen. . > Wünsche noch einen schönen Tag > Gruß > Siegmar Ebenso, Wolfgang
Datum:
guten morgen, Sven F. wrote: > wenn jemand die platienen fertigen löst wäre ich auch gerne mit 2-4 > stück der usb variante dabei. wäre aber super wenn du noch einen jumper > für umstellung 3,3v und 5v vorsehen könntest. funktioniert hier im > musteraufbau super mit versorgung über den ft232rl Tut mir leid das ich deinen Text erst jetzt so richtig gelesen hab. Meinst du mit Jumper einen, womit man die Stromversorgung für den Tiny zwischen der externen-Spannung und den 3,3V vom FT232R 'umschalten' kann? Ich dachte so ist man flexibler. Der FT232 meldet sich an, sobald er eingesteckt wird und für den Tiny hat man die gleiche Spannung wie am Zielsystem, kann also nicht versehentlich zuviel oder zu wenig Spannung in Richtung USB-Port bringen. > sven Grüße Wolfgang
Datum:
@ Wolfgang Birner ich hab mir hier den sniffer aufgebaut und versorge den atiny via usb dabei benutze ich auch die erzeugung der 3,3v erzeugung vom ft232rl geht sehr gut was ich in der richtung besser finde ist das ich lediglich 3 signale "anzapfen " muß und nicht noch die richtige +ub vom i²c bus suchen. bzw hab dadurch keine beeinflussung des usb buses. wenn ich falsch liege oder es einfache geht lasse ich mich gerne eines besseren belehren. Ich sniffe damit zurzeit an verschiedenen geräten teilweise auch mit 3,3v pegeln und da hatte ich schonmal den eindruck das daten falsch bzw verschunden waren. sven
Datum:
Da der Tiny lt. Schaltplan mit 14,xxMHz getaktet wird, kann es Probleme mit den 3,3V geben!
Datum:
@ Sven F. Ich versteh deine Schaltung, nur frag ich mich, ob es nicht sicherer ist, wenn ich jedesmal die VCC des I2C suchen muss. So kanns dann nicht versehentlich passieren, das ich 5V I2C und 3V3 MC hab -> peng! Außerdem sind die Bedenken von Ron Hille berechtigt (Auszug aus Datenblatt): > Speed Grade > – ATtiny25/45/85V: 0 - 4 MHz @ 1.8 - 5.5V, 0 - 10 MHz @ 2.7 - 5.5V > – ATtiny25/45/85: 0 - 10 MHz @ 2.7 - 5.5V, 0 - 20 MHz @ 4.5 - 5.5V Grüße Wolfgang
Datum:
Also nachdem es jetzt ein paar Leute sind, findet die Bestellung statt. Kosten 4,50 Euro/Platine + 1 Euro Porto zu den einzelnen. Bisher hab ich hier aus dem Forum (von Bekannten hab ich auch noch ein paar): Sven F. (sven0876) - 4x USB (mit 3v3 jumper) Michael Z. (incunabulum) - 2x Benjamin Schmidt (Gast) - 2x Tim (Gast) - 4x USB Helmut -dc3yc (dc3yc) - 1x Wolfgang Birner (logox2) - 2x Bei denen nichts dabei steht, nehm ich einfach die einfache USB-Variante an, so lange niemand mir etwas anderes mitteilt. Bitte schreibt mir eine Email mit eurer Adresse an: logox2 (at) gmx.de Ich teile euch dann meine Bankverbindung für die Überweisung mit. Sobald alle eingegangen sind, geht die Bestellung raus. MfG Wolfgang
Datum:
Von folgenden Personen hab ich leider noch keine Email mit ihrer Adresse bekommen: > Sven F. (sven0876) - 4x USB (mit 3v3 jumper) > Benjamin Schmidt (Gast) - 2x > Tim (Gast) - 4x USB > Helmut -dc3yc (dc3yc) - 1x Bis morgen Abend haben noch alle Zeit sich zu melden, danach schreib ich Emails mit dem genauen Preis und meinen Bankdaten. Ich werde anschließend die Platinen gleich bestellen, in der Hoffnung das alle Zahlen. Versenden werde ich sie erst wenn das Geld eingegangen ist. MfG Wolfgang
Datum:
So, bis gestern Abend haben sich bei mir folgende Personen mit Adresse gemeldet: Michael H. 2x USB Michael S. 1x USB, 1x RS232 Michael Z. 2x USB Timo R. 1x USB Sven K. 2x USB Julian K. 4x USB Des weiteren hab ich noch folgende Freunde und Bekannte in der Bestellung dabei: Eduard B. 2x USB Marcus S. 1x USB Peter D. 1x USB Lars P. 1x USB Ich 1x USB, 1x RS232 Diese 18 + 2 werd ich jetzt bestellen und dann den Leuten meine Bankverbindung mitteilen. mfg Wolfgang
Datum:
>Michael S. 1x USB, 1x RS232 >Ich 1x USB, 1x RS232 Oh, da sind wir ja die beiden einzigen, die auch die RS232 Version haben wollen ...
Datum:
Hallo, Ich würde gerne auch eine USB Version nehmen, falls noch möglich. MfG Hias
Datum:
Hallo, die Bestellung ging heute um 11.32 raus. Alles andere konnte ich leider nicht mehr berücksichtigen. Morgen werde ich die Email mit der Bankverbindung rausschicken. Kosten 4,50 pro Platine + Porto (schreib ich jedem extra). Sollte nochmals jemand eine Sammelbestellung organisieren wollen, so stelle ich gerne das eagle.brd zur Verfügung. MfG Wolfgang
Datum:
Angehängte Dateien:Im Anhang die Layouts als Eagle.brd da jetzt mehr nachgefragt haben, bzw. leider zu spät dran waren. PDF's möcht ich nicht bereitstellen, da die Strukturen sehr fein sind.
Datum:
Was sind denn bei Dir "sehr feine Strukturen" ? Schade mit den PDF`s, da haben (wir) Target "odersonsteinelayoutsoftwarenutzer" ja mal wieder das Nachsehen .. :) Trotzdem danke für Deine Bemühungen ! LG Ron
Datum:
Sag mal Wolfgang, für welches Gehäuse hast Du das Layout erstellt ? LG, Ron
Datum:
Hat sich erledigt, vermute mal ein Adaptergehäuse für 2x 9polSUB-D (bei Reichelt COM942), oder ?
Datum:
Ron Hille wrote: > Was sind denn bei Dir "sehr feine Strukturen" ? Leiterbahnen mit 0,2032mm und Bohrungen 0,3mm. Bisherher hatte ich da bei Ausdrucken und so immer Probleme. > Schade mit den PDF`s, da haben (wir) Target > "odersonsteinelayoutsoftwarenutzer" ja mal wieder das Nachsehen .. :) Ich arbeite halt mal mit Eagle. Da die Platine nicht groß ist, sollte es für andere auch kein Problem sein, sich mit der Eagle-Freeware die Daten raus zu ziehen die er benötigt. > Trotzdem danke für Deine Bemühungen ! Danke. Gehäuse, ist das COM942 von Reichelt. Da passt aber ansich nur der RS232 Adapter rein. den USB musste ich ein wenig breiter machen, da es sonst bei der Entwicklung Probleme gegeben hätte. Außerdem war mir von einem anderen Projekt bekannt, das es nach der Montage "schöner" ist, den USB-'Stick' in einem Stück durchsichtigen Schrumpfschlauch einzuschweißen. Wer ihn doch noch in das Gehäuse rein bringen möchte, muss unter Umständen den Rand mit ein wenig Schleifpapier schmirgeln, Platz ist genug. > LG Ron Grüße Wolfgang
Datum:
So, Platinen sind da. Heut komm ich leider nicht mehr zum einpacken, werde ich morgen machen, gehen somit voraussichtlich am Donnerstag mit der Post raus. mfg Wolfgang
So, hier mal die "Bauanleitung"
Datum:
Wolfgang, wäre es möglich, dass du die Nicht-USB-Version hier auch als pdf reinstellen könntest? Herzlichen Dank, Helmut.
Schon erledigt. Siehe Anhang ...
Datum:
Hi, gibt es vielleicht ein Front-End zur Anzeige der Busdaten? Ich meine jetzt nicht ein Terminalprogramm, sondern ein Tool, dass die empfangenen Daten schon auswertet? Thanks, TI
Datum:
TI Freak wrote: > gibt es vielleicht ein Front-End zur Anzeige der Busdaten? Ich meine > jetzt nicht ein Terminalprogramm, sondern ein Tool, dass die empfangenen > Daten schon auswertet? Was meinst Du mit auswerten? Der Sniffer dient ja zum Debuggen, d.h. was die Daten bedeuten, kann er nicht wissen. Nur Du kannst wissen, welche Daten falsch sind. Daher werden alle Daten gesendet. Du kannst natürlich im AVR bestimmte Daten rausfiltern. Das Programm ist ja nicht sehr groß. Peter
Datum:
Hi Peter, wenn ich das ganze richtig verstehe, dann liest der Sniffer den Datenstrom auf dem I2C-Bus mit. Da gibt es Start-, Stop- und andere "Bedingungen", also klare Steuerzeichen. Dazwischen kommen die Daten. Sofern ich weiß ob 8 oder 10Bit kommen, kann ich am Ende sagen: Hier haben wir folgende Sequenz "Start Datenwort 0x90 Datenwort 0xFF Stop". Und wenn ein Tool das anzeigt ist es doch eine feine Sache? Oder wie wertest Du beim sniffen aus?? Diese Funktion bieten mittlerweile auch DSO, bei Agilent hab ich das mal gesehen - oder lass ich mich da zu sehr blenden? Ich finde es klasse, dass der Sniffer alles sendet, so ist man ja auch total flexibel. Gruß TI
Datum:
TI Freak wrote: > Hier haben wir folgende Sequenz "Start Datenwort 0x90 Datenwort 0xFF > Stop". Du hast Dir den Logger nichtmal angesehen, stimmts? So sieht ein Log aus.
08378: sA0a80a22a00a02ap 08380: s80aA0a24a03a00a03a04ap 08381: s80np 08381: s80np 08382: sA0a80a22a05a07ap 08394: s90a80a22a00a32ap 08395: s80aA0a24a06a00a1Da1Fap 08397: s80np 08397: s80a90a24a02aFFaFFa36ap 08399: sA0a80a22a01a03ap 08410: s90a80a22a03a31ap 08412: s80aA0a24a00a00a00a04ap 08413: s80aA0a24a04a00a00a00ap 08414: sA0a80a22a02a00ap 08416: s80np |
Ich hab noch nen Timestamp (1ms) eingefügt, geht bis 65535 (~1min). Peter
Datum:
Angehängte Dateien:Hier noch die erweiterte Version mit Timestamp. Peter
Datum:
Hallo Peter, nein, Du hast nicht recht, ich hab mir den Sniffer schon angesehen. Leider kommt bei der Übertragung nichts lesbares bei raus, weshalb ich ja auch die Frage gestellt habe. Jetzt muß ich mal auf die Suche gehen... Nichts für ungut, aber es gibt auch Leute (wie ich), die nicht gleich alles (über-)blicken und dann Fragen stellen. TI
Datum:
TI Freak wrote: > Leider kommt bei der Übertragung nichts lesbares bei raus, Vielleicht hast Du das Signal invertiert. Die SW-UART kann ja engestellt werden, ob über nen MAX232 oder direkt an die COM. Peter
Datum:
Hi, hab mal versucht den Sniffer nachzubauen, leicht abgewandelt. Eine Frage: SCL und SDA des Busses müssen ja über PullUps an VTG gelegt werden. An wessen VTG eigentlich? Ich habe zwar Master und Slave (die ich untersuchen will) an einer Betriebsspannung hängen aber der Sniffer wird von der USB-Schnittstelle versorgt. Auf meinem Stecker zum Prüfling habe ich nur MOSI/SDA, SCK/SCL und Gnd liegen ... Muss ich den Sniffer auf seine VTG hochziehen oder wie? Welche Funktion hat Rtx auf dem ISP-Stecker? Ist das nur, damit es da ist? Hübsches Projekt. Und wenn's dann erstmal geht ... :) Grüße, Christoph
Datum:
Christoph Klein wrote: > Hübsches Projekt. Und wenn's dann erstmal geht ... :) > Okay. Geht :) Nicht der Sniffer ist das Problemkind sondern meine I2C-Prüflinge :) Wie gesagt: hübsches Projekt. Gratuliere! Christoph p.s.: die Fragen (oben) würde ich nochmal stehen lassen ...
Datum:
Christoph Klein wrote: > Welche Funktion hat Rtx auf dem ISP-Stecker? Ist das nur, damit es da > ist? Ja. Der 10pol-ISP hat den Pin ja nicht belegt. > Grüße, > > Christoph Grüße Wolfgang
Datum:
Hi, gibt es hier noch weitere Interessenten für eine Sammelbestellung von Platinen? Grüße, Alf
Datum:
Hi Alf, falls es noch eine Bestellung gibt (bzw. noch Platinen übrig sind würde ich auch eine (? oder zwei?) nehmen. Gruß, Bennie
Datum:
Hi, ich hätte auch Interesse an einer Platine. Danke und Grüße, Jürgen
Datum:
@GGG: Nein dieses Forum ist nicht krank - nur die Leute hier haben mindestens die Grundschule erfolgreich besucht... vielleicht gggehst Du dort auch erst mal hin... Hier werden AVR Projekte vorgestellt und Erfahrungen ausgetauscht. Wen das nicht interessiert, der muss sich ja hier nicht tummeln!
Datum:
Ich würde je eine mit USB und eine mit RS232 nehmen. Danke Christian
Datum:
Würde auch je eine USB und RS7232 nehmen. Danke Bruno PS: Bin aus Österreich wegen der Versandkosten.
Autor:
Robert S.
(razer)
Datum:
Ich wäre auch an 2x der USB Variante interessiert. Bin auch aus Österreich lg Robert
Datum:
Ich nehme auch eine Platine mit USB-Variante. Gruß & Dank Peter
Datum:
Wenns wieder ne Bestellung gibt, würd ich auch gerne eine USB-Variante nehmen! Mal so in den Raum geworfen: Schon mal ins Auge gefasst auch SPI mit zu integrieren, ist das zu kompliziert oder nimmt das womöglich keiner ausser mir mehr her? ;-) Gruß, chosn
Datum:
Ich wäre auch an 2x der USB Variante interessiert. Wer bekommt das Geld? lg bodo
Datum:
Bodo Gravert wrote: > Ich wäre auch an 2x der USB Variante interessiert. > > Wer bekommt das Geld? Tja da muß sich erstmal einer bereitfinden. Ob der Wolfgang Birner (logox2) es noch einmal macht, weiß ich nicht. Vielleicht sollten Interesssenten besser ihn direkt fragen. Peter
Datum:
Ich hab zur Zeit keine Zeit die Sammelbestellung durchzuführen. Ich hab ja vor einiger Zeit schon die Eagle-brd-files hier rein gestellt. Da sind beide Versionen drin. Da müsste nur jemand die benötigte Anzahl der benötigten Versionen mit C+P drin erstellen und bei einem Fertiger in Auftrag geben. Ich hatte es damals von q-pdb.de machen lassen. Grüße Wolfgang
Datum:
@Wolfgang Birner: ich versuche gerade das Layout auf Target zu übertragen. Dazu habe ich mir die Freewareversion von Eagle installiert. Dabei fällt mir auf, dass viele Durchkontaktierungen nirgends angeschlossen sind und dass alle Masseverbindungen fehlen. Habe ich da irgendetwas falsch eingestellt? Die Masseverbindungen fehlen übrigens auch im pdf-File. Kannst du mir da helfen? Danke, Helmut.
Datum:
muss erst "ratsnest" machen, damit die Masseflächen gezeichnet werden. Schönes We, egberto
Datum:
Hi, ich würde eine Sammelbestellung mit Wolfgangs brd-files übernehmen. Ich habe bei Q-PCB angefragt. Sobald ich das Angebot habe, melde ich mich nochmals. Viele Grüße, Jürgen
Datum:
@Helmut -dc3yc: egberto hat bereits richtig geantwortet. Die Massefläche wird erst nach 'ratsnest' gefüllt, dann verschwinden die Luftlinien für Masse auch. In der pdf hat ich um es besser lesen zu können die Masse-fläche einfach weg gelassen. Grüße Wolfgang
Datum:
Hallo an alle Teilnehmer, ich bin auch an je einer Platine pro Version interessiert. schönen Gruß
Datum:
Hallo, ich werde eine Sammelbestellung mit dem Eagle-File von Wolfgang organisieren, allerdings nur die USB Variante. Wer Interesse hat, möge bitte eine Email an twi-sniffer@404-not-found.de schicken. Ich antworte dann mit meiner Bankverbindung für die Überweisung. Bitte die Adresse nicht vergessen. Eine Platine kostet 4,20 Euro, dazu kommt noch 1 Euro für den Weiterversand. Natürlich schicke ich die Platinen auch nach Österreich ;-) Viele Grüße und Danke an Wolfgang und Peter für ihre Mühen! Jürgen
Datum:
Hallo, ich hab beim nachbau probleme bekomme keinerlei vernünftige ausgabe nur "€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€" hab den atiny direkt an einem pl-2303 usb seriel wandler und die baudrate auf 115k herundergesetzt im quellcode hab auch schon die invert variante probiert abblockkondensatoren sind dran. hat einer noch nen tip? ist mein erster gehversuch in ASM ronja
Datum:
noch vergessen die änderungen am quelltext
.equ XTAL = 14745600 .equ BAUD = 115200 ;.equ BAUD = 230400 ;.equ BAUD = .equ INVERT = 1<<COM1A0 ; inverted ;.equ INVERT = 0 ; non inverted |
müsten doch passen oder? ronja
Datum:
ronja.schmid wrote: > noch vergessen die änderungen am quelltext >
.equ XTAL = 14745600 > .equ BAUD = 115200 > ;.equ BAUD = 230400 > ;.equ BAUD = > .equ INVERT = 1<<COM1A0 ; inverted > ;.equ INVERT = 0 ; non inverted > |
> > müsten doch passen oder? > > ronja Hast Du die Fusebits auch sicher richtig? (externer Quarz, kein vorteiler) Die Ausgabe sieht nach falscher Baudrate aus. Könnte auch vom USB Wandler kommen, dann mal die Baudrate weiter runtersetzen. HTH, Klaus
Datum:
Danke der Vorteiler war drin und invert dann doch falsch. 1000 Dank an den hatte ich nicht gedacht! ronja
Datum:
Wollte mich nur mal für die mühe vom jürgen bedanken. habe heute die leiterplatte bekommen. das ging alles superschnell. zum aufbau komme ich wohl erst naechste woche. gruß, groovie
Datum:
Auch von mir herzlichen Dank! Die Platinen sind da! Servus, Helmut.
Datum:
hallo wollte noch mal zum aufbau fragen der ferrit(L1) wieviel µH oder welche bezeichnung hat der denn? gruß, groovie
Datum:
Hallo in die Runde, habe mir diesen Tread durchgelesen und nun stellt sich mir die Frage: Mit welchem Hex-File wird der ATiny geladen? Ist das Hex-File für RS232 und USB gleich? Und noch eine Verständnisfrage: Der Sniffer wird parallel auf den I2C-Bus geklemmt, mit den Pins SDA und SCL am Stecker SV2 (liege ich da richtig ?). Aber was passiert mit den Kontakten RxD und TxD und Reset? Ich hoffe Ihr könnt eien Blinden zu einem Einäugigen machen. Liebe Grüße Erich
Hallo, so jetzt habe ich alles angelötet und wollte mal zeigen wie es fertig aussieht. Meine Frage an die Profis noch, auf der atiny-seite habe ich die elkos richtigrum angelötet? manchmal ist ja der plus, ein andermal der minus gekennzeichnet. kann mal jemand einen blick kurz bitte drauf werfen. dankösöhr. groovie.
so, und die seite 2
Datum:
hallo, klasse schon 15 downloads und keiner kann sagen ob die beiden dicken kondensatoren (gelb und schwarz) richtigrum angelötet sind hm ..... also da wo der streifen ist auf dem gelben und auf dem schwarzen C die seite habe ich auf die mit plus markierte seite der leiterplatte gelötet. ich würde es gern mal ausprobieren aber bevor ich das mit den kondensatoren nicht weiss wollte ich das nicht machen. gruß, groovie
Datum:
Also meiner Sieht genau so aus und hat noch keine Rauchzeichen von sich gegeben... Alle angeaben wie immer ohne Gewähr!
Datum:
@SappErich >Mit welchem Hex-File wird der ATiny geladen? Es gibt eine C und eine ASM version. Die ASM version ist schneller, C leichter zu erweitern. >Ist das Hex-File für RS232 und USB gleich? Die Software ist an sich gleich. Du wirst aber vermutlich Probleme mit der Baudrate bekommen. Nicht alle Pcs können die >400Kbit der ASM version verstehen. >Und noch eine Verständnisfrage: >Der Sniffer wird parallel auf den I2C-Bus geklemmt, mit den Pins SDA und >SCL am Stecker SV2 (liege ich da richtig ?). jo. +5V und GND brauch er aber auch noch. >Aber was passiert mit den Kontakten RxD und TxD und Reset? Nix.
Datum:
@groovie, wer suchet der findet... http://www.led-tech.de/downloads/smd_tutorial.pdf aber damit Du nicht so viel lesen mußt, der Balken ist plus bei den SMD Tantals, und ja, die stimmen. Klaus
Datum:
danke für die antworten und as pdf, das hatte ich auch schon, aber bei dem schwarzen elko ist auf dem streifen so ein kleines minus aufgedruckt und auch in dem pdf steht bei elkos das das minus gekennzeichnet ist. bei dem tantal(gelb) war gleich alles klar. also ist der schwarze demnach auch ein tantal? danke für eure hilfe.
Datum:
Ach herje, hast Du das Bild im pdf nicht erkennen können? Die flachen Plastikbomber sind Tantal, die runden Alubecher sind Elkos. Hier ein besseres Bild der Elkos: (Achtung, sind zwei Zeilen, ev. zusammenkopieren) Hast Du die Ausgeschlachtet oder weisst Du nicht mehr was Du gekauft hattest? http://www.reichelt.de/?;ACTION=3;LA=2;GROUPID=400...
Datum:
vielen dank klaus, hatte ich ausgeschlachtet. mal sehen wie es funzt, melde mich wieder.
Datum:
so, mit der invertierten variante läuft es wie geschmiert. besten dank an alle die daran gearbeitet haben. das ist echt mal ein nütliches tool!!!! groovie.
Hallo Gemeinde, habe mir nun den Sniffer aufgebaut. Aber bevor ich mit dem Programmieren beginne, wollte ich mich noch über die FuseBytes informieren. Stimmt meine Berechnung der Bytes. Im voraus besten Dank und einen großes Lob an die Entwickler des Sniffers. Erich
Ich möchte mich auch bei Peter für das nützliche Tool bedanken, mit einem Bild meines Aufbaus. Passt in ein D-Sub Gehäuse und wird über die serielle Schnittstelle mitversorgt (deshalb mit 2 Schottky-Dioden in einen Elko und eine Z-Diode darüber). Es war sogar Platz dafür, den uC luxuriös zu sockeln, falls Peter noch Software-Verbesserungen einfallen... ;-) Ich benutze die Assemberversion mit den Timestamps, vom 5.11.2008.
Hier von der anderen Seite, im Gehäuse. Zugentlastung und Kabel kommen natürlich noch dran. Jörg
Datum:
Auch von mir ein herzliches Dankeschön für das Tool. Wieder ein typischer Dannegger: ungewöhnlich codiert (was nicht schlecht sein muss: es zwingt zur Präzision beim Nachvollziehen) und funktioniert einfach. Jedenfalls wenn man dran denkt, die Clkdiv8 zu löschen :-) Aber wenn's auf Anhieb klappt, ist's ja kein Spass mehr sondern Arbeit. Aber noch eine Frage: ist #define XTAL 14.756e6 oder #define XTAL 14.7456e6 korrekt? Das sollte jedenfalls der 14er Baudratenquarz sein? Und noch eine Frage in die Runde: Ich laufe aktuell schaumgebremst auf 115kBaud, gibt es Erfahrungen mit den Prolific-Chips (USB-Seriell) und mehr als 115k? Oder kommt die Begrenzung gar aus meinem geliebten TeraTerm? Gruß hase
Datum:
Hartmut Semken schrieb: > Das sollte jedenfalls der 14er Baudratenquarz sein? Ja, das isn Tipfehler, sollte sich aber nicht auswirken (0,07%). > Und noch eine Frage in die Runde: Ich laufe aktuell schaumgebremst auf > 115kBaud Merkst Du das "schaumgebremst" überhaupt? > gibt es Erfahrungen mit den Prolific-Chips (USB-Seriell) und > mehr als 115k? Oder kommt die Begrenzung gar aus meinem geliebten > TeraTerm? Der Prolific kann das. Aber nicht jedes Terminalprogramm kann >115200 Baud. Ich habe Hyperterminal mit 460800 Baud benutzt. Peter
Datum:
@Jörg Hohensohn: Hast du vielleicht einen Schaltplan zu deiner Miniversion des Sniffers? Der sieht ja echt putzig aus.
Datum:
Kevin, wie, dafür brauchst du einen Schaltplan? Ich habe keinen gemacht, mir das nur so zusammengelegt. Die Verbindungen sollte man doch insbesondere aus dem ersten Foto gut erkennen können. Die 2 blauen Dioden sind Schottkydioden, z.B. BAT41, die gelbe quer über dem Elko (z.B. 100uF 6,3V) ist eine 4,7V Zenerdiode. Dann noch den Quarz an den uC und die Verbindungen herstellen. Elko richtigherum polen, der rote Draht in meinem Aufbau ist Plus. Jörg
Datum:
Hallo zusamme, ein super Projekt hier mit dem Sniffer. Ich bin auch grad dabei mir einen zusammen zu bauen. Natürlich musste ich feststellen, dass die eine Commport Karte keine 460800 Baud mitmacht, die andere lässt sich zwar drauf einstellen, die Daten kommen jedoch schon bei einem Loop Back Adapter falsch an. Habe aber noch ein fertiges FTDI FT232RL Eval Board mit bereits bestücktem Pegelwandler drauf und dahinter meine Platine ebenfalls mit Pegelwandler wieder zurück auf TTL. Diese ganze Geschichte geht jedoch einwandfrei bis 46800. Nun zu meinem Problemchen. Das C-Programm geht zwar recht gut, beim loggen von Schreib / Lesezugriff eines seriellen EEProms ist es zu langsam und der Busmaster meckert wenn der Sniffer den Bus ausbremsen möchte. Die ASM Version geht da schon besser, jedoch habe ich nur die beiden fertigen HEX Files (mit und ohne Timestamp) getestet und diese sind scheinbar "inverted" für den direkten Anschluß ohne MAX232 Pegelwandler. Kann mir jemand die beiden ASM Versionen (mit und ohne Timestamp) für 460800 Baud bei 14.7456 MHz als non inverted (für externen MAX232) fertig kompiliren? Ich progge sonst mit Bascom und habe mich mit dem AVR Studio nicht so richtig befasst. Danke vorab. RePi!
Datum:
Hallo! @Peter Dannegger Ich habe jetzt dein Sniffer mal nach gebaut, weil meine ganze Heizungssteuerung auf I2C basiert und ich mal ein wenig den Busverkehr beobachten will. Ich benutze den Tiny85 mit 14,7MhZ, habe aber folgendes Problem. Im Terminal wird Start und Stop angezeigt, aber mehr nicht und nach kurzer Zeit wird der ganze Bus lahm gelegt. So sieht die Ausgabe aus:
00000: s I2C-Sniffer: 00578: sp 00578: spp |
Was könnte da schief gehn? Gruß Denny
Datum:
Denny S. schrieb: > Im Terminal wird Start und Stop angezeigt, aber mehr nicht und nach > kurzer Zeit wird der ganze Bus lahm gelegt. Vermutlich benutzt Du keinen Hardware-Master, sondern einen SW-Master mit überkritischem Timing und ohne SCL-Abfrage. Der Sniffer funktioniert nur dann, wenn man sich an das I2C-Protokoll hält. D.h. SCL des Master muß ein Open-Drain mit externem Pullup sein und SCL-Stretching muß geprüft werden. Der Sniffer ist zwar schneller als viele andere SW-Lösungen, aber einige CPU-Zyklen braucht er doch. Peter
Datum:
Hallo! @ Peter Dannegger Ich benutze in allen meinen Controllern die Lib von Peter Fleury. Dort sind ja immer 2 Libs drin, einmal die "twimaster.c" und die "i2cmaster.S". Welche ist denn für Hardware TWI gedacht ? Oder muss ich noch was anderes ändern? Gruß Denny
Datum:
Denny S. schrieb: > Ich benutze in allen meinen Controllern die Lib von Peter Fleury. > Dort sind ja immer 2 Libs drin, einmal die "twimaster.c" und die > "i2cmaster.S". In der "twimaster.c" steht:
"Title: I2C master library using hardware TWI interface"
|
Also sollte es damit gehen. Peter
Datum:
Hallo! Hmm die benutze ich immer. Dann muss der Fehler irgendwo anders liegen. Ich benutze hier einen Buspuffer (P82B96) um 2 Zimmer zu verbinden. Das Kabel ist etwa 20m lang. Das läuft alles schon seid einem halben Jahr und ich damit nie Probleme, aber könnte es damit zusammen hängen? Es hängen hier RTC, 2x FRAM, ein Atmega als TWI-Slave, Tiny-USB und einige Atmegas die auf alles zugreifen! Alles funktioniert wunderbar, nur halt der I2c_sniffer nicht. Wollte damit den Bus mal abhorchen. Den Bus-speed habe ich in den Mastern auf 100Khz gesetzt. Hast du noch Idee? Danke und Gruß Denny
Datum:
Denny S. schrieb: > Ich benutze hier einen Buspuffer (P82B96) um 2 Zimmer zu verbinden. Das sollte nichts machen, der AVR kann ja genug treiben. Wenn man Puffer verwendet, muß auch jeder Teilnehmer seinen eigenen haben, nur am Master bringt nichts. > Es hängen hier RTC, 2x FRAM, ein Atmega als TWI-Slave, Tiny-USB und > einige Atmegas die auf alles zugreifen! Ist das dann Multimaster? Tiny-USB sagt mir nichts. Häng mal nur einen Master an den Sniffer, dann sollte ja Start, Adresse, Nack und Stop kommen. Der Sniffer sollte auch VCC haben, bevor der Master lossendet. Wenn FRAM und RTC auf der selben Platine sitzen, sollte man denen besser nen eigenen I2C (SW-I2C) spendieren, denn I2C hat ja keine Fehlererkennung. Peter
Datum:
Hallo Jungs, gute Arbeit. Will nicht jemand mal einen Mini-Shop aufmachen und dort die vorgestellten Varianten verkaufen? Oder gibt es so einen schon? MfG EW
Datum:
Hi, wenn sich jemand findet (Radig, Watterott, o.ä. ;) der die Platine in seinen Shop aufnehmen würde, dem stell ich die .brd gerne zur Verfügung. Grüße Wolfgang
Datum:
geht das eigentlich nur mit dem tiny86 oder kann man das auch mit einem mega32 machen?
Datum:
Ich glaube nur mit Tiny's oder andere AVR's mit "TWI USI" interfaces. Die M32 hast einer echte TWI "HW engine" , diser kan fehler detekteren. Aber kein "sniff" mache , wann die data sind fehl/ungültig. Hoffe du verstehe miner "schule" deutch. mfg Bingo aus Dänemark
Datum:
Hallo! Da ich auch ein bisschen Probleme mit einem I2C Device habe möchte ich mir gerne diesen Sniffer zusammen bauen. Ich habe aber einen ATTiny2313 zur Verfügung. Nun meldet mir AVR Studio natürlich Probleme, da er TCCR1, CTC1 und OCR1C nicht kennt. Kann mir damit helfen den Source für den ATTiny2313 umzuschreiben? Ist TCCR1 -> TCCR1A CTC1 -> WGM12 OCR1C -> OCR1B richtig??
Datum:
Der Attiny2313 hat doch ne UART, da brauchst Du die SW-UART doch garnicht. Peter
Datum:
Angehängte Dateien:> Ich habe aber einen ATTiny2313 zur Verfügung.
Diesen Code habe ich vor zwei Jahren mal für einen Tiny2313 geschrieben.
Die empfangenen Daten werden über USART ausgegeben. Das ganze ist nicht
auf Geschwindigkeit getrimmt, da mein TWI-Bus nur mit 1kBit läuft.
Datum:
Peter Dannegger schrieb: > Der Attiny2313 hat doch ne UART, da brauchst Du die SW-UART doch > garnicht. > > > Peter Ok! Da sieht man wieder, dass ich zu wenig Ahnung habe! Ich habe bis jetzt nur mit Atmega gearbeitet und somit kenne ich die Unterschiede der anderen Atmel nicht gut. Kann mir jemand dabei helfen dieses Projekt für den ATTiny2313 umzuschreiben? Danke!
Datum:
Hab es nun selber geschafft! anbei die Version GCC für den ATTiny2313. Auch habe ich die I2C Erkennung etwas erweitert: Nach dem Start wird die Adresse um 1 bit nach rechts geschoben. Das "alte" erste Bit ist ja das Read/Write Bit. Dies wird nun auch angegeben. Schaut so schon ganz gut aus s21wa02a00a5Aap s21wa06a00a00ap s21wa04a00a00ap s50wap s20wa00as20ra0Aa00np aber hier bin ich mir noch nicht sicher: s28wss20wss28wss20wss28wss28wss28wss28wss28wss28wss28wss28wss20wa00as20ra0Aa00np s28wss08wss28wss20wss28wss28wss28wss28wss28wss28wss28wss28wss20wa00as20ra0Aa00np s28wss28wss08wss28wss28wss28wss28wss28wss20wss28wss28wss28wss21wa02a00a5Aap Da muss ich wieder einmal mit dem Logic Analyser drann um zu vergleichen.
Datum:
Angehängte Dateien:Das Problem von vorhin war, dass der UART den I2C Bus geblockt hatte. Nun verwende ich die UART.c & .h von http://www.jump.to/fleury. TX Buffer 32, RX Buffer 0 gehen bei mir mit einer I2C Bus Frequency mit ~135KHZ. Das HEX-file ist für einen ATTiny2313; 11,0592MHz; 115200 Baud. Hier dann ein LOG der UART Ausgabe: s28wa98ap s28ra00a00np s28wa88ap s28ra00a00np s20wa00as20ra0Aa00np s21wap s3Cwap s50wap s28wa98ap s28ra00a00np s20wa88ap s28ra00a00np s20wa00as20ra0Aa00np Folgendes habe ich im Source (Danke @Peter Dannegger) noch geändert: Es wird nun die richtige I2C Device Addresse über UART ausgegeben. Zusätzlich auch noch 'r' für Read und 'w' für Write. mfg Portisch
Datum:
Hugo Portisch schrieb: > Das Problem von vorhin war, dass der UART den I2C Bus geblockt hatte. Das sollte eigentlich kein Problem sein. Wenn der Master ein HW-I2C ist, merkt er, wenn der Slave langsamer ist und synchronisiert sich auf den langsamsten Teilnehmer. Insbesondere wenn geplant ist, einen anderen MC als Slave zu benutzen, muß der Master das unterstützen. Ansonsten kracht es, wenn der Slave grad mal mit nem anderen Interrupt beschäftigt ist. Die SW-UART ist zwar gepuffert, wenn der Puffer aber voll ist, muß auch gewartet werden. Peter
Datum:
hi, jetzt habe ich noch eine kleine Frage zu dem I2C Sniffer: Manchmal bekomme ich diese Ausgabe: s08wa98ap s08ra00a00np richtig ist aber: s28wa98ap s28ra00a00np D.h. manchmal wird die Addresse vom AVR falsch erkannt. Warum passiert das? Weil wieder einmal der UART die I2C Erkennung einbremst. Der UART ist bei mir nur über TX mit dem PC verbunden. Werde es einmal mit der UART Fifo Buffer von Peter Dannegger probieren.
Datum:
Angehängte Dateien:zur Info: Ich habe nun statt den 11.0592MHz einen 18.432MHz im Einsatz. Nun wird die Device Adresse immer richtig erkannt! Zusätzlich kommt noch dazu, dass auf der RS232 Empfängerseite (PC) kein Flaschenhals entstehen darf. Sonst gehen Daten verloren! Anbei der aktuelle Source für den ATTiny2313 mit 18.432MHz und 230400 Baudrate!
Datum:
Angehängte Dateien:Da ich bei einem bestimmten Device ein Problem hatte brauchte ich einen Trigger für das Oszi. Also habe ich den Sniffer noch um einen Trigger über Device Adresse und/oder Daten Bytes erweitert! Mit einer Maske kann man zusätzlich bestimmte Bits ignorieren. Um auf eine Device Adresse zu Triggern muss man 3 Bytes per RS232 schicken: >data[0] = Gesamtlänge der gesendeten Daten >data[1] = Device Adresse >data[2] = Device Adresse Mask Um auch Daten zu überprüfen muss zuerst die Anzahl der Bytes angehängt werden: >data[3] = Anzahl der zu Überprüfenden Daten Bytes >data[4] = Datenbyte 1 >data[5] = Datenbyte 1 Mask Für jedes weiter Datenbyte dann so erweitern: >data[6] = Datenbyte 2 >data[7] = Datenbyte 2 Mask >data[8] = Datenbyte 3 >data[9] = Datenbyte 3 Mask Es sind maximal 3 Datenbytes möglich! Beispiel Device 0x21: >data[0] = 3 >data[1] = 0x21 >data[2] = 0xFF Beispiel alle 0x2? Devices: >data[0] = 3 >data[1] = 0x21 >data[2] = 0xF0 Somit werden durch die Maske die unteren 4 bits ignoriert. Beispiel Device 0x28, Data 0x88: >data[0] = 6 >data[1] = 0x28 >data[2] = 0xFF >data[3] = 1 >data[4] = 0x88 >data[5] = 0xFF Beispiel alle Devices Data 0x00, 0x00: >data[0] = 8 >data[1] = 0x00 >data[2] = 0x00 >data[3] = 2 >data[4] = 0x00 >data[5] = 0xFF >data[6] = 0x00 >data[7] = 0xFF Beispiel alle Devices 0x3? Data 0x?8: >data[0] = 6 >data[1] = 0x30 >data[2] = 0xF0 >data[3] = 1 >data[4] = 0x08 >data[5] = 0x0F Ich hoffe es sind keine Bugs mehr drinnen! mfg Portisch
Datum:
Wolfgang Birner schrieb: > Ich hab mal zwei Schaltpläne fertig gestellt, einmal mit max232 und > einmal mit ft232r, vielleicht mag jemand einen Kommentar dazu abgeben? Ich weisdass dieser Beitrag schon ziemlich alt ist, aber da ich mir auch einen I2C/TWI-Sniffer bauen will, habe ich noch die eine oder andere Frage. Währe es bei den von Wolfgang Birner gezeigten Schaltung nicht besser, die I2C Leitungen mit 100R bzw. 220R Widerständen zu schützen?
Datum:
Hallo zusammen, vor ca. 1 Jahr habe ich mir dieses prima Helferlein schonmal "aufgebaut". Nun stelle ich fest, das die Entwicklung immernoch weitergeht. LOB! Eine Frage habe ich aber doch noch. Hat sich der Hardware-Aufbau verändert? Müßte doch eigentlich, da ja nun ein Pin mehr für den Oszi verwendet wird. Gruss... Harpax
Datum:
Hallo, ich möchte den I2C-Sniffer nachbauen um etwas zu untersuchen. Allerdings kriege ich es nicht hin das Ding im AVR Studio zu "builden" Ich habe das komplette Projektverzeichnis auf meine Disk gelegt und die Projekt datei geöffnet. Im AVR Studio sind dann im Projektstruktru alle Dateien vorhanden. Klicke ich auf Build, dann erscheint folgende Fehlermeldung: Build started 3.4.2011 at 13:40:59 0 [main] sh 4544 sync_with_child: child 2124(0x12C) died before initialization with status code 0x0 75824 [main] sh 4544 sync_with_child: *** child state waiting for longjmp /usr/bin/sh: fork: Resource temporarily unavailable avr-gcc -mmcu=attiny2313 -Wall -gdwarf-2 -DF_CPU=18432000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT I2CSNIFF.o -MF dep/I2CSNIFF.o.d -c ../I2CSNIFF.C ../I2CSNIFF.C:176: fatal error: opening dependency file dep/I2CSNIFF.o.d: No such file or directory compilation terminated. make: *** [I2CSNIFF.o] Error 1 Build failed with 1 errors and 0 warnings... Ich bin sicher, dass das ein ganz einfaches Problem ist, allerdings weiss ich nicht wo ich zu suchen beginnen soll. Hab schon länger nichts mehr mit AVRs und C gemacht, deshalb brauche ich ein bisschen "Rostlöser" von eurer Seite. Vielen Dank!
Datum:
Versuch mal die Option -xc oder nenne alle Files in klein um. Default ist groß C++. Peter
Datum:
Hallo, habs rausbekommen: http://www.madwizard.org/electronics/articles/winavrvista Es liegt am Vista 64-bit, es muss nur die msys-1.0.dll ersetzt werden. Downloaden kann man sie unter: http://www.madwizard.org/download/electronics/msys... Jetzt muss ich nur noch das Ding auf ATtiny84 umstricken können.
E-Mail-Benachrichtigung einschalten
Neu: Seitenaufteilung einschalten