AT Mega 128 und P82b715 / P82b96 Probleme ??

[modtronic]

Mahlzeit

Zum Verständnis.
ich betriebe die MCP23017 nur als Outputs
Von der Schaltung ist das ganze so aufgebaut

AT-Mega 128 -> P82B715 -> P82b715 -> MCp23017
Sender Empfänger

Der Empfänger mit dem MCp23017 sitzt mit dem Spannungsregler auf einer Platine

Als Kabel wird ein 4 poliges abgeschirmtes Kabel verwendet
auf der Empfängerplatine ist ein 78s05 verbaut für die Versorgung der dez. Platine
Der Schirm ist nur am Sender auf Masse gelegt

Die Pull Ups auf der Treiberseite als LSCL und LSDA sind immer vorhanden gewesen. (330 Ohm)
laut dem Datenblatt soll es angeblich nicht nötig sein, auf der Senderseite am I2C Bus (CPU)
also scl und sda an der CPu diese einzubauen
So läuft es allerdings auch bei zb dem Mega 16 Problemlos. Hier wird nur die Empfängerseite, also das zurückwandeln des Busses auf den I2C mit Pull Ups versehn, die Senderseite hat die 330 Ohm.

Am At-mega 128 habe ich nun als Pull Ups des I2C Busen 1,5K genommen
da läuft es. Ohne geht es auch nicht.

Ich habe nun auf der Dezentralen externe Platine die Pull Ups auf 2,2K (i2c) geändert.
so läuft alles stabil

das der Mega 128 irgendwie anders sein muss, zeigt schon die Hardwaretechnische Sache
das ich die Pullups anpassen mussn bzw das erprobte und Funktionierende am Mega 16, 32 und 8 am Mega 129 nicht funktioniert.
Kabellänge ist ca 4m, das ganze drei mal in die Gleiche Richtung verlegt, daran kann es als nicht liegen.

Wenn es so läuft, lasse ich das laufen, weil ich habe mich jetzt fast 1 Woche damit befasst.

Grüsse
Patrick

[Moppi]

FRAGEZEICHEN

Vielleicht hängt das damit zusammen, was im Datenblatt des ATmega128 steht:

SCL, Two-wire Serial Interface Clock: When the TWEN bit in TWCR is set (one) to enable the Two-wire Serial Interface, pin PD0 is disconnected from the port and becomes the Serial Clock I/O pin for the Two-wire Serial Interface. In this mode, there is a spike filter on the pin to suppress spikes shorter than 50ns on the input signal, and the pin is driven by an open drain driver with slew-rate limitation.

Würde bedeuten, dass SCL (Pin#25 PD0) für I2C-Betrieb dann als Open-Drain geschaltet wird und einen externen Pull-UP benötigt(?)
Dann hättest Du einen Pull-UP am Pin#25 des ATmega128, wegen dem Open Drain. Der andere Pull-UP am Pin#26 entspräche dann dem R1 im Datenblatt des P82B715, wie unter Figure 5. Single Pullup Buffered Bus gezeigt. Allerdings halte ich 1.5kOhm für ein bißchen wenig. Ich würde es mit größeren Werten versuchen >=4.7kOhm. Dieser R1 wird im Beispiel des P82B715 mit 10kOhm angegeben.

/FRAGEZEICHEN


Beim ATmega328 steht dasselbe drin:

SCL/ADC5/PCINT13 – Port C, Bit 5– SCL: 2-wire Serial Interface Clock. When the TWEN bit in TWCR is set (one) to enable the 2-
wire Serial Interface, pin PC5 is disconnected from the port and becomes the Serial Clock I/O
pin for the 2-wire Serial Interface. In this mode, there is a spike filter on the pin to suppress
spikes shorter than 50 ns on the input signal, and the pin is driven by an open drain driver
with slew-rate limitation.

Und beim ATmega16 steht dasselbe drin:

SCL, Two-wire Serial Interface Clock: When the TWEN bit in TWCR is set (one) toenable the Two-wire Serial Interface, pin PC0 is disconnected from the port andbecomes the Serial Clock I/O pin for the Two-wire Serial Interface. In this mode, there isa spike filter on the pin to suppress spikes shorter than 50 ns on the input signal, and thepin is driven by an open drain driver with slew-rate limitation.

Also wieder keine richtige Erklärung, irgendwie.

MfG

[modtronic]

Hallo

ja darüber bin ich schon gestossen, habe es aber nicht weiter beachtet weil... das ich generell immer die Pull Up Widerstände am I2C Bus auf meine CPU Platinen vorsehe.
In der Regel nehme ich 4,7K, damit läuft am Mega 128 der I2C Bus, direkt zb den MCp angeschlossen Problemlos, bzw auch alle anderen Mega bei mir.
Früher habe ich 10K genommen auch das ginge.

Es ist das erste mal, das ich solch ein Problem hatte mit dem I2C Bus.
ich weiss nur, wenn die Pull Ups nicht da sind, läuft der Bus generell nicht, daher sehe ich sie immer vor.
Das sie zu Gross sind (4,7K) hätte ich nicht gedacht

Grüsse
Patrick

- - - Aktualisiert - - -

FRAGEZEICHEN

Vielleicht hängt das damit zusammen, was im Datenblatt des ATmega128 steht:


Würde bedeuten, dass SCL (Pin#25 PD0) für I2C-Betrieb dann als Open-Drain geschaltet wird und einen externen Pull-UP benötigt(?)
Dann hättest Du einen Pull-UP am Pin#25 des ATmega128, wegen dem Open Drain. Der andere Pull-UP am Pin#26 entspräche dann dem R1 im Datenblatt des P82B715, wie unter Figure 5. Single Pullup Buffered Bus gezeigt. Allerdings halte ich 1.5kOhm für ein bißchen wenig. Ich würde es mit größeren Werten versuchen >=4.7kOhm. Dieser R1 wird im Beispiel des P82B715 mit 10kOhm angegeben.

/FRAGEZEICHEN


Beim ATmega328 steht dasselbe drin:


Und beim ATmega16 steht dasselbe drin:


Also wieder keine richtige Erklärung, irgendwie.

MfG

Wie ich oben geschrieben hatte
läuft das ganze mit 4,7K nicht, was ich als Standard Wert immer hatte
Bei 2,2K hatte ich es auch versucht, da ging es mal ja, mal nein

[Klebwax]

ich betriebe die MCP23017 nur als Outputs

Das spielt für den I2C Bus keine Rolle.

Als Kabel wird ein 4 poliges abgeschirmtes Kabel verwendet

Schon mal die Signale auf diesem Bus angesehen? Wie sieht es mit Cross Talk, Übersprechen, zwischen SCL und SDA aus?

Die Pull Ups auf der Treiberseite als LSCL und LSDA sind immer vorhanden gewesen. (330 Ohm)

Woher stammt dieser Wert? Ich halte ihn für zu klein. Da fließen bei 12V mehr als 30mA in jedem, der Teiberbaustein muß also über 60mA liefern. Das ist ja mehr als der ganze Rest der Schaltung braucht.

laut dem Datenblatt soll es angeblich nicht nötig sein, auf der Senderseite am I2C Bus (CPU)

An einem I2C-Bus müssen Pull-Ups sein, sonst wird keine Leitung je High. Das ist eine Binse, ob das extra im Datenblatt eines Treiberchips stehen sollte?

Kabellänge ist ca 4m, das ganze drei mal in die Gleiche Richtung verlegt, daran kann es als nicht liegen.

Wenn es so läuft, lasse ich das laufen, weil ich habe mich jetzt fast 1 Woche damit befasst.

4m schaffe ich ohne Treiber mit einem geteilten Pullup von je 4,7k auf beiden Seiten. Mit den Treibern und 12V soll man 100m und mehr erreichen. Du hast also ein anderes Problem, daß du mit extrem niederohmigen Pullups überdeckt hast. Nach meiner Erfahrung fällt einem sowas auf die Füsse, wenn man es am wenigsten braucht.

MfG Klebwax

[Moppi]

Du hast also ein anderes Problem, daß du mit extrem niederohmigen Pullups überdeckt hast.

Das denken wohl mittlerweile alle, die irgendwie helfen wollen. Aber die Frage ist doch: was für ein Problem soll diese Symptome verursachen? Deswegen hatte ich ja auch schon getipt, dass es evtl. ein Softwareproblem ist (setup()-Code).
Mich interessiert brennend, was es ist. Dafür gibt es einen Grund und der scheint so schwer nicht zu finden zu sein, da man es gut eingrenzen können sollte.


MfG

[Achim S.]

Hallo
wenn ich das richtig sehe arbeitest du mehr mit dem I2C Bus. Habe ebenfalls verschiedene Module mit dem Bus aufgebaut und betreieb sie auch damit. Nutze auch verschiedene Prozessoren SAM und Ati 841.
achim

[modtronic]

ich verwende den b715.
Den Betreibe ich, wie oben auch geschrieben mit 5V.
Der Wert 330 Ohm stammt aus dem Datenblatt.

Ich habe 4M mit dem I2C Bus noch nie geschaft. ich
baue an der Steuerung bereits 6 Jahre, bze entwickel daran.
ich bezweifel das der Bus in einer Modellbahn wo nach andere Spannungen herrschen dauerhaft sauber läuft.
Umsonst wird so ein Baustein ja auch nicht angeboten

ich habe At-Mega 8 laufen da habe ich vor dem Sender keine Pull Ups verbaut.
ist auch laut Datenblatt beider Extender/Buffer so beschrieben

Mit dem Oskar habe ich geschaut, auch oben geschrieben
Sieht alles gut aus !

Grüsse
Patrick

[Klebwax]

Ich habe 4M mit dem I2C Bus noch nie geschaft.

Das hab ich nicht einfach nur dahin gesagt, das hab ich verfiziert. Ich beschäftige mich mit I2C schon eine Weile. Vollständig verstanden, wie da alles zusammenspielt, habe ich den Bus, als ich einen Master in Software (bitbanging) geschrieben habe. Und da nicht nur hier der I2C Bus den Ruf hat, nur für ganz kurze Strecken brauchbar zu sein, habe ich selbst einige Versuche gemacht. Ein paar Aufzeichnungen hab ich gefunden.

Der Testaufbau war ein PIC24 mit Hardware I2C. Da der einen eigenen Baudrategenerator für I2C hat, kann man da beliebig leicht an der Frequenz drehen. Er hat außerdem zuschaltbare Pullups an den Pins, man kann also leicht mit internen und externen Pullups testen. Als Slave habe ich damals einen LIS3LV02 Accelerometer auf einem Breakouboard genommen. Da musste man nicht viel löten. Die Software ist simpel: man erzeugt ein Start, schickt die richtige Adresse und ein WRITE und dann ein Stop. Kommt ein ACK, hat der Slave die Adresse erkannt. Ansonsten ist der Bus gestört. So machen das die I2C-Bus Scanner.

Ein Bild, das ich gefunden habe ist dies vom LA



Es zeigt, daß der LIS3L auf kurzer Strecke mit 1MHz funktioniert. Das ist das 2,5 fache des garantierten Wertes von 400kHz. Hier der Testaufbau dazu



Und auch mit diesem Aufbau waren mehr als die 400kHz erreichbar. Hier habe ich zwei Pullups von 4,7k jeweils an den Enden verwendet. Das Kabel war rund 3,5m lang, ein gewönliches Telefonkabel mit 4 Adern.



Das einzige was da zählt ist die Kombination von Kabelkapazität und Pullup. Diese bilden einen Tiefpass für die steigende Flanke des Signals. Je länger das Kabel, desto flacher wird der Anstieg und desto niederohmiger muß der Pullup werden. Ansonsten erreicht der Highpegel bei gegebenem Takt nicht mehr gültige Werte. Aufgrund der I2C Spezifikation gibt es eine theoretische Grenze: der Treiber muß 3mA liefern können, daraus errechnet sich je nach Busspannung ein minimaler Pullup. Und er muß 400pf treiben können, daraus errechnet sich die mögliche Kabellänge. Nimmt man mal typische 50pf pro Meter und weitere 50pf für die übrigen Kapazitäten an, kommt man auf 5m. Praktisch habe ich auch 10m erreicht, dann aber nicht mehr mit 1MHz.

Das diese Überlegungen nicht ganz daneben liegen, zeigen käufliche HDMI Kabel. In denen liegt ein normaler I2C Bus, über den der PC die Daten des Monitors aus einem I2C-EEPROM liest. Und die gibt es bis 5m.

Die Treiber, wie der P82B96, habe mehrere Funktionen. Als erstes erhöhen sie den Strom von 3mA auf 30mA und die Kapazität von 400pF auf 4000pF. Damit kann man also ein längeres Kabel mit größerer Kapazität mit kleineren Pullups und damit gleicher Zeitkonstante betreiben. Aus den 5m werden so 50m. Deine 330Ω stammen aus einer solchen Rechnung, als Kabelkapazität wird hier 3000pF, also eine Länge von rund 60m, angenommen.

Gleichzeitig sind sie auch Levelshifter. Die Busse an beiden Seiten können verschiedene Spannungen haben. Daraus ergibt sich eine interessante Möglichkeit.



Man betreibt den Bus im Kabel mit 12V und benutzt diese gleich als Versorgung für den Slave. Wenn man dort einen Schaltregler einsetzt, kann man dort mehr Strom entnehmen, als im Kabel fließt. Da spielt dann auch der Widerstand des Kabels keine Rolle, der Schaltregler kommt auch mit weniger als 12V klar. So verwende ich diese Treiber. Meine I2C Slaves sind typisch Prozessoren mit eigner Umgebung, die über den 12V I2C-Bus gesteuert und versorgt werden. Im einfachsten Fall werden dort Tasten entprellt, Drehencoder ausgewertet und LEDs angesteuert. Es gibt noch einen weiteren positiven Effekt. Der low-Pegel muß jetzt nicht mehr kleiner als 30% von 5V bzw 3,3V sein sondern 30% von 12V. Das Gleiche gilt für den High-Pegel. Der Störabstand wird also massiv größer. Und zu guter letzt schleppt man nicht die direkte Versorgung vom µC und vom Device durch die Gegend und fängt sich dabei Störungen ein.

Und nun zum größten Problem mit längeren Leitungen, dem Übersprechen. Je länger SDA und SCL parallel verlaufen desto größer kann das werden. Hier mal ein SDA Signal, das komplett unbrauchbar ist. Da schlägt SCL voll durch.



Das Problem wird noch dadurch verschärft, daß manche die beiden Leitungen des I2C Busses mit differentiellen Signalen verwechseln und auf einem verdrillten Adernpaar führen. Die Beispiele z.B. aus dem P82B96 zeigen aber daß SDA und SCL mit je einer Versorgung ein Paar bilden sollten.

Sorry, ist etwas länger geworden

MfG Klebwax