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

was für ein krankes Forum.

Vermutlich hat in dieses Forum auch der Blitz eingeschlagen - und alle
Beiträge genau dieses threads gelöscht.
Kann ja vorkommen.
Das haben wir ja gestern im tv gesehen.

Gast

@ 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

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

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

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

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

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

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

>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

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

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?

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

Hallo Wolfgang,

ich hätte Interesse an einem Layout.

Gruß

Michi Müller

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

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.

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.

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

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

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.

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

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

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.

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

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

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

Ich bin auch mit 1-2 Platinen dabei !

Da sich das jetzt ja zu konkretisieren scheint :-) 2 Platinen nehm
ich.... Gerne auch per Vorauskasse.

cu, Michael

Ich würde 4x USB nehmen.

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

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

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

Hallo,

wäre auch mit je einer Platine dabei!

Servus,
Helmut.

@ 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

Da der Tiny lt. Schaltplan mit 14,xxMHz getaktet wird, kann es Probleme
mit den 3,3V geben!

@ 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

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