mikrocontroller.net

Forum: Projekte & Code I2C (TWI) Sniffer mit AVR


Autor: Peter Dannegger (peda)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: gastleser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: gastleser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: gastleser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: gastleser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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 ?

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
>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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wolfgang Birner (logox2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wolfgang Birner (logox2)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wolfgang Birner (logox2)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michi Müller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Wolfgang,

ich hätte Interesse an einem Layout.

Gruß

Michi Müller

Autor: Wolfgang Birner (logox2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sven K. (svenk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wolfgang Birner (logox2)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Wolfgang Birner (logox2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael Z. (incunabulum)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sven F. (sven0876)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wolfgang Birner (logox2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Benjamin Schmidt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wolfgang Birner (logox2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Benjamin Schmidt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wolfgang Birner (logox2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Benjamin Schmidt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michi Müller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin auch mit 1-2 Platinen dabei !

Autor: Michael Z. (incunabulum)
Datum:

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

cu, Michael

Autor: Tim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde 4x USB nehmen.

Autor: siegmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wolfgang Birner (logox2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wolfgang Birner (logox2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Helmut -dc3yc (dc3yc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

wäre auch mit je einer Platine dabei!

Servus,
Helmut.

Autor: Sven F. (sven0876)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Ron Hille (kurzschlusshandlung)
Datum:

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

Autor: Wolfgang Birner (logox2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Wolfgang Birner (logox2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wolfgang Birner (logox2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wolfgang Birner (logox2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michi Müller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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 ...

Autor: E. M a t t h i a s (hias)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Ich würde gerne auch eine USB Version nehmen, falls noch möglich.

MfG Hias

Autor: Wolfgang Birner (logox2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wolfgang Birner (logox2)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Neuer Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wieso soll es bei PDF Probleme mit feinen Strukturen geben?

Autor: Ron Hille (kurzschlusshandlung)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ron Hille (kurzschlusshandlung)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sag mal Wolfgang, für welches Gehäuse hast Du das Layout erstellt ?

LG, Ron

Autor: Ron Hille (kurzschlusshandlung)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat sich erledigt, vermute mal ein Adaptergehäuse für 2x 9polSUB-D (bei 
Reichelt COM942), oder ?

Autor: Wolfgang Birner (logox2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wolfgang Birner (logox2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wolfgang Birner (logox2)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, hier mal die "Bauanleitung"

Autor: Michi Müller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meine Platinen sind heute angekommen.

Vielen Dank nochmal !

Autor: Helmut -dc3yc (dc3yc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wolfgang,

wäre es möglich, dass du die Nicht-USB-Version hier auch als pdf 
reinstellen könntest?

Herzlichen Dank,
Helmut.

Autor: Wolfgang Birner (logox2)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Schon erledigt. Siehe Anhang ...

Autor: Michael Z. (incunabulum)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch hier kam heute Post. Wolfgang, danke dir!

cu, Michael

Autor: Helmut -dc3yc (dc3yc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke!

Servus,
Helmut.

Autor: Timo R. (tire)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Post war schnell und Wolfgang noch schneller - Danke!!

Autor: TI Freak (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: TI Freak (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier noch die erweiterte Version mit Timestamp.


Peter

Autor: TI Freak (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christoph Klein (hyla)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christoph Klein (hyla)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: Wolfgang Birner (logox2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
gibt es hier noch weitere Interessenten für eine Sammelbestellung von 
Platinen?

Grüße,
Alf

Autor: Benjamin B. (bennie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Alf,

falls es noch eine Bestellung gibt (bzw. noch Platinen übrig sind würde 
ich auch eine (? oder zwei?) nehmen.

Gruß,
Bennie

Autor: Jürgen A. (jaja)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
ich hätte auch Interesse an einer Platine.

Danke und Grüße,
Jürgen

Autor: Helmut -dc3yc (dc3yc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Würde mich auch dranhängen!

Helmut.

Autor: ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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!

Autor: groovie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo,

also ich wuerde auch eine platine nehmen.
gruss
groovie

Autor: Christian Berndt (chrisbe3)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde je eine mit USB und eine mit RS232 nehmen.


Danke

Christian

Autor: Bruno (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Würde auch je eine USB und RS7232 nehmen.

Danke
Bruno

PS: Bin aus Österreich wegen der Versandkosten.

Autor: Robert S. (razer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich wäre auch an 2x der USB Variante interessiert.

Bin auch aus Österreich
lg Robert

Autor: Peter H. (phansen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich nehme auch eine Platine mit USB-Variante.

Gruß & Dank
Peter

Autor: Jo Fi (chosn)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bodo Gravert (bodo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich wäre auch an 2x der USB Variante interessiert.

Wer bekommt das Geld?

lg bodo

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wolfgang Birner (logox2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Helmut -dc3yc (dc3yc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: egberto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
muss erst "ratsnest" machen, damit die Masseflächen gezeichnet werden.

Schönes We,

egberto

Autor: Jürgen A. (jaja)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wolfgang Birner (logox2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: neulich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo an alle Teilnehmer,
ich bin auch an je einer Platine pro Version interessiert.
schönen Gruß

Autor: Jürgen A. (jaja)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: ronja.schmid (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: ronja.schmid (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Klaus Leidinger (klausleidinger)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: ronja.schmid (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke der Vorteiler war drin und invert dann doch falsch.

1000 Dank an den hatte ich nicht gedacht!

ronja

Autor: groovie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Helmut -dc3yc (dc3yc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch von mir herzlichen Dank! Die Platinen sind da!

Servus,
Helmut.

Autor: groovie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo

wollte noch mal zum aufbau fragen der ferrit(L1) wieviel µH oder welche 
bezeichnung hat der denn?

gruß, groovie

Autor: Herr Mann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: SappErich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: groovie (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: groovie (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
so, und die seite 2

Autor: groovie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also meiner Sieht genau so aus und hat noch keine Rauchzeichen von sich 
gegeben...

Alle angeaben wie immer ohne Gewähr!

Autor: Tim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: groovie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: groovie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
vielen dank klaus, hatte ich ausgeschlachtet.

mal sehen wie es funzt, melde mich wieder.

Autor: groovie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: SappErich (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg H. (idc-dragon)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier von der anderen Seite, im Gehäuse. Zugentlastung und Kabel kommen 
natürlich noch dran.

Jörg

Autor: siegmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
super !!!!!!!!!!

Autor: Hartmut Semken (hsemken)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Kevin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jörg Hohensohn: Hast du vielleicht einen Schaltplan zu deiner 
Miniversion des Sniffers? Der sieht ja echt putzig aus.

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: RePi! (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Denny S. (nightstorm99)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Denny S. (nightstorm99)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Denny S. (nightstorm99)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Eugen W. (ewiebe1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wolfgang Birner (logox2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: tsaG (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
geht das eigentlich nur mit dem tiny86 oder kann man das auch mit einem 
mega32 machen?

Autor: Bingo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hugo Portisch (portisch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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??

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Attiny2313 hat doch ne UART, da brauchst Du die SW-UART doch 
garnicht.


Peter

Autor: Thomas Forster (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Hugo Portisch (portisch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Hugo Portisch (portisch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
s28wss20wss28wss20wss28wss28wss28wss28wss28wss28wss28wss28wss20wa00as20r 
a0Aa00np
s28wss08wss28wss20wss28wss28wss28wss28wss28wss28wss28wss28wss20wa00as20r 
a0Aa00np
s28wss28wss08wss28wss28wss28wss28wss28wss20wss28wss28wss28wss21wa02a00a5 
Aap

Da muss ich wieder einmal mit dem Logic Analyser drann um zu 
vergleichen.

Autor: Hugo Portisch (portisch)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hugo Portisch (portisch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hugo Portisch (portisch)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Hugo Portisch (portisch)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sepp O. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Harpax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sniffer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Versuch mal die Option -xc oder nenne alle Files in klein um.
Default ist groß C++.


Peter

Autor: Sniffer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Walter Tarpan (nicolas)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,
sehe ich das richtig, daß der Assemblercode eigentlich auch im ATtiny45 
ohne weiteres laufen sollte? Ich frage nur deshalb, weil ich den gerade 
da habe.

Viele Grüße
Nicolas

EDIT: Hat sich erledigt, in meiner Bastelkiste sind nur noch 
14,31818Mhz-Quarze und kein 14,7456MHz Quarz. Bestellen muß ich also so 
oder so.

Autor: Rudi M. (rudimentaer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nicolas S. schrieb:
> sehe ich das richtig, daß der Assemblercode eigentlich auch im ATtiny45
> ohne weiteres laufen sollte? Ich frage nur deshalb, weil ich den gerade
> da habe.

Prinzipiell ja, allerdings hat der 45 weniger SRAM, und das begrenzt den 
Sendepuffer.

Gruß,
Rudi

P.S. 18,432 MHz würde auch gehen und sniffert noch schneller ;-)

Autor: Walter Tarpan (nicolas)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ah, interessant. Im Datenblatt von 2008 auf Seite 5 steht, daß beide 
256bytes SRAM hätten und nur Flash und EEPROM unterschiedlich wären. Auf 
anderen Seiten steht allerdings 256 und 512 Bytes. Ist wohl ein 
Tippfehler. Also ist meine Frage erst Recht sinnlos gewesen.

Viele Grüße
Nicolas

Autor: Jörg Esser (jackfritt)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@Peter

wieder einmal vielen Dank für deinen Code.
Ich habe in main() noch den Portpin für die serielle auf Ausgang
gesetzt damit dort was raus kommt.
Habe mal alles in eine Datei gepackt und noch um F_CPU erweitert.
Der Code sollte mit einem atiny85 bei 8Mhz internem Quarz, 57600 Baud 
und PB0=SDA,PB4=TX,PB2=SCL laufen.
Zumindest funktioniert es hier prima.

Gruss,

Jörg

Autor: sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi,

läuft das programm auch auf nem atmega, zb m168 (arduino nano) oder geht 
das mit der twi nicht?

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Läuft nur auf AVRs mit USI.

Peter

Autor: sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab ich nach dem wälzen des Datenblattes auch bemerkt. Hab mir schon 
Tiny85 bestellt. Bin mal gespannt :-) Danke schonmal

Autor: sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Excellente Software. Läuft zuverlässig!

Frage: ich versuche gerade das ASM programm zu verstehen :-)

Wenn ich es richtig verstanden habe wird der String im Fifo abgelegt, 
bis der Fifo voll ist, oder der Transmission beendet ist.

puts gibt den String auf der UART aus.

Hat jemand eine Idee, wie man den String an ein Bascom Programm 
übergeben könnte?  Also das assembler programm in ein Bascom Programm 
einbetten, und die routine puts soll das Bascom Programm sein.

Autor: sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
achso.... und das ganze wird nur einmal ausgeführt.

Einschalten -> Daten -> Bascom -> ausgabe (software UART von Bascom) -> 
END

Autor: Raimund (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie müssen denn jetzt die FUSE-Bits gesetzt werden?
Ich benutze AVRDUDE in Verbindung AVR8-burn-o-mat und komme nicht 
weiter.
Bin für jeden Hinweis Dankbar!

Autor: sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
CKIV/8 auf OFF
und High frequency crystal

Autor: sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
und nicht vergessen, clock unt baud, sowie inverted/non inverted in der 
software zu ändern, vorm compilieren

Autor: Michi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe den Sniffer nachgebaut, bräuchte noch eine kleine Erläuterung 
wie das Log zu interpretieren ist. Das log ist von einer RTC DS1307

ist das so richtig?

sD0a00ap

s = start
D0 = adresse
a = acknowledge
00 = Daten ?
ap = ?


sD1a57a25a17a07a27a04a13np

s = start
D1 = adresse? wiso eins mehr?
a = acknowledge
57 = daten?
a = acknowledge
25 = daten
a = acknowledge
17 = daten
a = acknowledge
07 = daten
a = acknowledge
27 = daten
a = acknowledge
04 = daten
a = acknowledge
13 = daten
np = ?

wie sehe ich ob die Daten nun lesend oder schreibend zur adresse gehen?

Autor: Josef D. (jogedua)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
n= not acknowledge
p= stop

Der Rest ist im Datenblatt des RTC DS1307 (in deinem Link S. 11)
beschrieben:
Das letzte Bit der Adresse ist das R/W-Bit (0=schreiben, 1=lesen).

sD1a57a25a17a07a27a04a13np
                        ^
Hier sagt der Master dem Slave: habe genug gelesen, aufhören zu senden.

Autor: Michi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,,

habe nun alles soweit hinbekommen und verstanden :)

Nun habe ich scheinbar das problem das der Logger nicht so zuverlässig 
mitliest, ich habe einen LM75 angeschlossen und lese diesen aus. Die 
Temperatur wird konstant gelesen keine veränderung, aber im Log ändern 
sich die Daten:

37460: s91a1Da00np
37783: s90a00ap
37783: s91a1Da00np
38106: s90a00ap
38106: s91a1Da00np
38429: s90a00ap
38429: s91a19a00np    <<< Falsch
38752: s90a00ap
38752: s91a1Da00np
39077: s90a00ap
39077: s91a1Da00np
39400: s90a00ap
39400: s91a1Da00np
39723: s90a00ap
39723: s90a1Da00np    <<< Falsch
40046: s90a00ap
40046: s91a19a00np    <<< Falsch
40369: s90a00ap
40369: s90a1Da00np    <<< Falsch
40692: s90a00ap
40692: s91a1Da00np
41015: s90a00ap
41015: s91a19a00np    <<< Falsch
41337: s90a00ap
41338: s91a19a00np    <<< Falsch
41660: s90a00ap
41661: s91a19a00np    <<< Falsch
41983: s90a00ap
41983: s91a1Da00np

Die Temperatur wird vom Master richtig gelesen. Der Logger ist auf dem 
Tiny85 mit dem 14,7456 MHz Quarz angeschlossen, das Uart läuft mit 
256000 Baud.

Autor: HansKoch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
die Funktion des Programmes hört sich super an, nur habe ich leider das 
Problem, nur einen Arduino Uno als Programmer zu haben. Gibt es eine 
Möglichkeit, dass Programm auch auf diesem Wege auf den Tiny zu 
bekommen? Bislang habe ich versucht, Main.C oder ICSNIFF.C in .ino 
umzubenennen und dann zu öffnen ... ein so dilettantischer Versuch wird 
aber natürlich nur mit einem Haufen von Fehlermeldungen bedacht.

Autor: Neo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo
Ich habe auch ein Problem mit der Datenkorrektheit.

Ich habe folgenden Empfang:
s 3Ca 00a 03a 84a 64a 0Aa p
s 3Ca 0Aa s 3Da 02a 04a 44a 00n p

und es sollte so aussehen:
s 3Ca 00a 03a 84a 64a 0Aa p
s 3Ca 0Aa s 3Da 0>3<a >8<4a >6<4a 00n p

es wird ein Slave eingestellt und danach zurück gelesen.
Mit einem Logicanalayser hab ich die Daten geprüft und der I2C Master 
stellt den Slave solang ein, bis die Daten korrekt zurück gelesen 
wurden.
Es werden also Daten falsch verarbeitet.

Ich habe ein Spacezeichen eingefügt und Baud auf 115200, 14,756MHz.
Ist ein ATTiny45.

Habe ich etwas übersehen, ist die C Version?

Autor: Neo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da scheinbar außer ich und Michi das Problem haben, liegt es wohl an 
mein Hardwareaufbau.
Werde ich nochmal genauer prüfen..

Autor: Neo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe nun den knackpunkt gefunden, es lag an der polarität der 
Datenerkennung zu liegen, ich habe es auf eine positive Flankenerkennung 
gestellt und nun kommen die Daten korrekt an.
Habe nebenbei noch die Schaltung auf ein ATTiny2313 aufgebaut.

Vielen Dank für den Sniffer.

Autor: Walter Tarpan (nicolas)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

irgendwie hat sich mein I2C-Sniffer dazu entschieden, mich in den 
Wahnsinn zu treiben. Ich mache auch gerade ein paar Stunden den Test mit 
dem LM75. Es wird, obwohl ständig die gleichen Daten über den Bus gehen, 
eine 0x91 abwechselnd als 0x90 und 0x91 erkannt. Mit unterschiedlicher 
Polarität habe ich auch gebaut. Zum Schluß habe ich an die drei (vier) 
beteiligten Beinchen des ATtiny85 einen Logic-Analyzer geklemmt.

Wie man auf dem Bild sieht, wird eine 0x91 als 0x90 und eine 0x15 als 
0x11 erkannt.

Den Build habe ich mit den Assembler-Optionen BAUD = 460800 und INVERT = 
0 gemacht. Da dieses schicke Teil schon hunderte Male aufgebaut wurde: 
Was kann eigentlich noch schiefgehen, wenn man die Daten direkt an den 
Beinchen vergleicht?

Viele Grüße
W.T.

: Bearbeitet durch User
Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo
Inzwischen ist viel Zeit vergangen.
Es gibt arduino nano Atmega 328. dieser kann USI. Jetzt müsste man doch 
das auch auf einem arduino laufen lassen können ? Hat da schon jemand 
Erfahrung ?

Danke.
Sebastian

Autor: Heiner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sebastian schrieb:
> Hat da schon jemand
> Erfahrung ?

Nö.

lg. Heiner

Autor: Boris Hightech (Firma: omfbv) (hightech75)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, habe ich kurze einfache Fragen:

Der Sniffer ist slave und hört nur mit oder ?

Nehme ich besser Spannung von FT232, also 3,3V für PullUp oder besser 
doch die Spannung von i2c Bus den ich mitlesen will ?

Das ist für den slave doch Prinzip egal ob 3,3 oder 5V, nur nie darf man 
+Ub von den Sniffer und +Ub vom i2c Bus zusammen legen.

Dann, aus Sicherheit, mache in die Leitung von i2c Bus zum AVR besser 
noch 100R hinein ? Obwohl kann ja passieren eigentlich nichts, er liest 
ja nur und schreibt nichts.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es sollte funktionieren, die Pullups mit 3,3V zu betreiben.
Wenn der Puffer voll ist und die UART die Daten nicht mehr rechtzeitig 
los wird, geht der Sniffer in den Clock-Stretching Mode, d.h. zieht SCL 
auf low, bis die UART wieder bereit ist.

Autor: hightech (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ah, danke schön, ich hatte gedacht es gäbe Probleme wegen der kleinen 
Spannung. Hatte mich zudem gewundert warum der SCL als Ausgang definiert 
ist. Wir der zwischendurch auf Eingang geschaltet? Habe ich im code 
nicht gesehen, dort nur scl-ddr =1. Den scl muss mann doch auch mitlesen 
oder?

Autor: hightech (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und : toll das du mit einer solchen Geduld auch immer wieder auf Fragen 
Antwortest.
Vielen vielen Dank!

Autor: Alter Meister (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hightech schrieb:
> Und : toll das du mit einer solchen Geduld auch immer wieder auf Fragen
> Antwortest.
> Vielen vielen Dank!

Er hing sowieso gerade mit 2 Leitungen am Forum...
;)

Autor: Boris Hightech (Firma: omfbv) (hightech75)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit SDA und SCL ?

: Bearbeitet durch User

Antwort schreiben

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

Wichtige Regeln - erst lesen, dann posten!

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

Formatierung (mehr Informationen...)

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




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

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