Ein I²C-Bus Monitor bis 200kHz (29.10.2009)

Es gab Probleme beim DB0QI mit der Software die den I²C-Bus bedient. Die einzige Möglichkeit diese Probleme einzugrenzen war, einen I²C-Monitor einzusetzen. Im Mikrocontroller-Forum bin ich dann fündig geworden. Sven Hauke heißt der gute Mann, der die passende Idee mit Software zur Verfügung stellte. Ursprünglich war das ein Monitor für die RS232-Schnittstelle, aber das ließ sich dann leicht auf USB umbauen. Das Ergebnis sieht so aus:

Zitat aus dem Forum:

I²C Sniffer ATMEGA8

Ich habe mich nochmal an den Code dran gesetzt und die größten Sünden
ausgebügelt.

Habe noch den FIFO verbessert.

Das Ding läuft jetzt auf 'nem Mega8 @ 14.7456MHz.

So wie es aussieht sind 200 kHz SCL jetzt kein Problem mehr.
Früher war lediglich 50kHz drin (wegen dem UART).

Anschlüsse wären:
PD2 = SCL
PD3 = SDA
PD7 = INT

RS232 Parameter:
115.200 Baud
8 Datenbit
keine Parität
1 Stoppbit

Beispiel der Datenausgabe:
Start
s41aE0aC1np

s = Start condition
41 = Adresse ($40 im lesemodus)
a = Acknowledged
E0 = übertragene Daten
a = übertragene Daten
n = not Acknowledged
p = Stop condition

cu
Hauke

Hier ist die Bauanleitung, die Software . ... und die Lösung der Probleme am QI war gefunden ... Die Visual-Basic-Software die am PC für Durchblick sorgt, hat Ernst, DJ7DA geschrieben und ist hier (Update 13.05.2013) zu finden.

Neues vom I²C-Sniffer (15.02.2023)

Es tauchen immer wieder mal ein paar Fehler auf dem I²C-Bus auf. Das hat mich jetzt bewogen noch einmal das Platinchen anzufassen und das ein oder andere noch zu ergänzen. Der getesteten Variante kamen jetzt noch 2 Jumper dazu die es ermöglichen PullUp-Widerstände eben zu nutzen oder nicht. Den Interrupt-Eingang habe ich übernommen.

Sollte schon eine Woche früher fertig sein, aber leider hatte ich mit der ersten Lieferung der FT232RL ICs kein Glück. Die 3,3V die in dem Chip erzeugt werden waren soweit da, aber kein Betriebssystem wollte die ICs erkennen. Erst musste ein anderer Lieferant gefunden werden, der die ICs zu realistischen Preisen hatte. Diese Lieferung war dann weitestgehend zufriedenstellend. Leider ließ sich das interne EEProm nicht beschreiben, aber sei's drum. Diese Platinen laufen schonmal. Anwendung soll dann folgende sein. Angeschlossen zwischen einem RasPi und dem I²C-Hauptbus sollen die Daten tageweise im RasPi in einer Datei gespeichert werden. Ein kleines Shellscript erledigt das, und, damit die SD-Karte nicht überläuft, wird die älteste Datei immer nach 4 Tagen gelöscht. Diese Datei sniffer.sh ist ausführbar und hat folgenden Inhalt:

#!/bin/sh

stty -F /dev/ttyUSB0 115200

while read Line; do

echo $Line >> /home/ich/Sniffer/$(date '+%Y.%m.%d')_sniffer.log
#nach 4 Tagen Datei löschen
#zuerst prüfen ob Datei Existiert
if [ -f /home/ich/Sniffer/$(date --date '-3day' '+%Y.%m.%d')_sniffer.log ]; then
rm /home/ich/Sniffer/$(date --date '-3day' '+%Y.%m.%d')_sniffer.log
fi
done < /dev/ttyUSB0

Damit hat man dann immer vier Tage Zeit ein Problem nachzuvollziehen, oder eben ned, wenn's denn auf dem Bus ein Problem gab.

Um das Skript dann automatisch starten zu können. wechselt man in das Verzeichnis /etc/systemd/system und erstellt eine Datei als Beispiel: nano sniffer-dienst.service
mit folgendem Inhalt:

[Unit]
Description= IIC_Monitor systemd service.

[Service]
Type=simple
ExecStart=/bin/bash /home/ich/Sniffer/sniffer.sh

[Install]
WantedBy=multi-user.target

Um jetzt zu veranlassen, daß das Skript auch gestartet wird fehlt noch folgender Befehl:
systemctl enable your-service.service
ab jetzt wird beim Neustart und reboot das Skript gestartet.

In den KiCad 7 Files sind zusätzlich noch ein Pin, der die TX-Daten aus dem ATMega8 bereitstellt, und RX/TX LEDs, die am FT232 angeschlossen sind. Hier noch die Baumappe. Die Software hat sich nicht geändert.

Viel Spaß beim Nachbau !!!

73 de Tomtom

Home