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
@ 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:
1
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:
1
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
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
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
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
@ 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
@ 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
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
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
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
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.
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
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
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
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
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
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
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.
1
08378: sA0a80a22a00a02ap
2
08380: s80aA0a24a03a00a03a04ap
3
08381: s80np
4
08381: s80np
5
08382: sA0a80a22a05a07ap
6
08394: s90a80a22a00a32ap
7
08395: s80aA0a24a06a00a1Da1Fap
8
08397: s80np
9
08397: s80a90a24a02aFFaFFa36ap
10
08399: sA0a80a22a01a03ap
11
08410: s90a80a22a03a31ap
12
08412: s80aA0a24a00a00a00a04ap
13
08413: s80aA0a24a04a00a00a00ap
14
08414: sA0a80a22a02a00ap
15
08416: s80np
Ich hab noch nen Timestamp (1ms) eingefügt, geht bis 65535 (~1min).
Peter
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
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
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
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 ...
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
@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!
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
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
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
@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.
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
@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
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
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
ronja.schmid wrote:
> noch vergessen die änderungen am quelltext>
1
.equ XTAL = 14745600
2
> .equ BAUD = 115200
3
> ;.equ BAUD = 230400
4
> ;.equ BAUD =
5
> .equ INVERT = 1<<COM1A0 ; inverted
6
> ;.equ INVERT = 0 ; non inverted
7
>
>> 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
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
Hallo in die Runde,
habe mir diesen Tread durchgelesen und nun stellt sich mir die Frage:
Mit welchem Hex-File wird der ATiny geladen?
Ist das Hex-File für RS232 und USB gleich?
Und noch eine Verständnisfrage:
Der Sniffer wird parallel auf den I2C-Bus geklemmt, mit den Pins SDA und
SCL am Stecker SV2 (liege ich da richtig ?).
Aber was passiert mit den Kontakten RxD und TxD und Reset?
Ich hoffe Ihr könnt eien Blinden zu einem Einäugigen machen.
Liebe Grüße
Erich
Hallo,
so jetzt habe ich alles angelötet und wollte mal zeigen wie es fertig
aussieht.
Meine Frage an die Profis noch, auf der atiny-seite habe ich die elkos
richtigrum angelötet? manchmal ist ja der plus, ein andermal der minus
gekennzeichnet.
kann mal jemand einen blick kurz bitte drauf werfen.
dankösöhr.
groovie.
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
@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.
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.
so, mit der invertierten variante läuft es wie geschmiert.
besten dank an alle die daran gearbeitet haben.
das ist echt mal ein nütliches tool!!!!
groovie.
Hallo Gemeinde,
habe mir nun den Sniffer aufgebaut. Aber bevor ich mit dem Programmieren
beginne, wollte ich mich noch über die FuseBytes informieren.
Stimmt meine Berechnung der Bytes.
Im voraus besten Dank und einen großes Lob an die Entwickler des
Sniffers.
Erich
Ich möchte mich auch bei Peter für das nützliche Tool bedanken, mit
einem Bild meines Aufbaus. Passt in ein D-Sub Gehäuse und wird über die
serielle Schnittstelle mitversorgt (deshalb mit 2 Schottky-Dioden in
einen Elko und eine Z-Diode darüber).
Es war sogar Platz dafür, den uC luxuriös zu sockeln, falls Peter noch
Software-Verbesserungen einfallen... ;-)
Ich benutze die Assemberversion mit den Timestamps, vom 5.11.2008.
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
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
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
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!
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:
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
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
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:
1
"Title: I2C master library using hardware TWI interface"
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
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
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
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
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
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??
> 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.
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!
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.
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
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
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.
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!
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
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?
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
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!
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.
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 ;-)
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
@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
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.
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!
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?
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.
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.
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.
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?
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.
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.
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
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.
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.
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?
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...
;)
Oh ein Atmega328 mit nem schönen großen 2.4" Display würde mich auch
interessieren. Sowas hatte ich schon lange im Auge. I2C und als Sniffer
für Uart, damit man mal mithorchen kann auch ohne PC
Klaus schrieb:> kann dann noch mehr Protokolle.
Nope. Keine Gute Idee. Ein PC-Logikanalyzer ist kein vollwertiger Ersatz
für den I2C-Sniffer. Allein durch die Tatsache, daß die PC-Logikanalyzer
erst samplen und man sich die Telegramme danach anguckt, während der
I2C-Sniffer eine "Live-Ansicht" erlaubt.
Max schrieb:> Oh ein Atmega328 mit nem schönen großen 2.4" Display würde mich auch> interessieren. Sowas hatte ich schon lange im Auge. I2C und als Sniffer> für Uart, damit man mal mithorchen kann auch ohne PC
Ich hab mir einen Software Sniffer für einen Arduino Nano Clone
(Atmega328) gebaut. SCL an D2, SDA an D3. Gesampelt wird zunächst in den
internen Speicher und dann auf die serielle Konsole ausgegeben. Ausgabe
sieht in etwa so aus (Beispiel ES9028 DAC Control Unit):
1
90+ 40+ 91+ A1-
2
90+ 42+ 91+ A6-
3
90+ 43+ 91+ E6-
4
90+ 44+ 91+ 1C-
5
90+ 45+ 91+ 00-
6
90+ 64+ 91+ 02-
Hilfreich sind noch zwei Pull-Down Widerstände 47k und zwei Dioden zum
abblocken des zu sniffenden Busses.
Gruß
Heiko
Walter T. schrieb:> Nope. Keine Gute Idee. Ein PC-Logikanalyzer ist kein vollwertiger Ersatz> für den I2C-Sniffer.
Der Beitrag oben stimmt nicht mehr ganz. Die Live-Ansicht des Salea
Logic funktioniert mittlerweile ganz wunderbar.
Hallo, welche Lizenz hat der i2c-sniffer.c code ? MIT ?
Ich würde gerne etwas ähnliches als bl233 integrieren, in C , kein
Arduino.
https://www.i2cchip.com/pdfs/bl233_b.pdf
Chris
Darüber hab ich mir noch keine Gedanken gemacht. Aber ich bin damit
einverstanden den Code unter die MIT Lizenz zu stellen. Du kannst ihn
also gerne verwenden und nach deinen Bedürfnissen modifizieren.
Gruß
Heiko
Cederick schrieb:> Ließe sich das auch in ein PC-Programm übersetzen?> Welche HW würde benötigt werden, um das I2C einzulesen?
Übersetzen schon, aber mangelndes Echtzeitverhalten wird das keine
zufriedenstellenden Ergebnisse liefern.
Die Kombi aus hier vogestellten µCs an der seriellen Schnittstelle eins
normalen PCs ist die nötige HW.
Kannst auch beliebige andere µC hernehmen die schnell genug sind,
portierst die SW und gut ist.
NichtWichtig schrieb:> Übersetzen schon, aber mangelndes Echtzeitverhalten wird das keine> zufriedenstellenden Ergebnisse liefern.
ok, danke. Ich hatte gedacht, dass 400kHz machbar sein müssten, weil PCs
ja auch RS232 können (232). Müsste ich mich also nach einer
I2C-Lesehardware umsehen.
In diesem Beitrag ist zwar schon eine Weile nichts passiert, ich hoffe
er ist trotzdem noch aktiv.
Ich brauchte schnell einen I2C-Sniffer und habe kurz entschlossen die
Variante von teknoid nachgebaut, da ich noch einen Arduino Nano
rumliegen hatte. Leider funktioniert er nicht wie erwartet.
Zum Senden verwende ich einen USB-I2C-Adapter von ELV und die dazu
gehörende Testsoftware. Ich sende folgende Werte:
sC0 89 FF FF 00 00 00 00 a2 p (s und p stehen für Start/Stop)
Der Sniffer liefert allerdings folgende Rückmeldung:
Available memory size: 1653
1
Queue size: 1525
2
Queue was filled: 222
3
C0-
4
13-
5
00-
6
58+ 31+ 7F-
7
FF-
8
E0+ 20+ 20+ 20+ 34+ AC+ 18-
9
3F-
10
FF-
11
F0+ 10+ 10+ 10+ 1A+ 56+ 0C+ 9F-
12
FF-
13
F8+ 08+ 08+ 08+ 0D+ 2B+ 06+ 4F-
14
FF-
15
FC+ 04+ 04+ 04+ 06-
16
15-
17
03+ 27-
18
FF-
19
FE+ 02+ 02+ 02+ 03+ 8A-
20
81-
21
13-
22
FF-
23
FF+ 01+ 01+ 01+ 01-
24
45+ C0-
25
89-
Das sieht irgendwie nach Timing-Problem aus, ich bin aber inzwischen mit
dem Bustakt bis auf 10kHz runter. Die Kommunkikation mit anderen Geräten
funktioniert sauber, auch bei 100kHz.
Hat irgendjemand noch eine Idee ?
Vielen Dank
Mirko