AT Mega 128 und P82b715 / P82b96 Probleme ??
Mahlzeit
Die beiden ICs P82b715 und P82b96 sollen den i2c Bus Verstärken um längere Busleitungen zu ermöglichen.
Beide Extender/Buffer arbeiten Problemlos am Atmega 16 oder 32 ect, jedoch nicht am 128er Typ.
Ich brauche pro Sender und Empfänger seite immer ein Päärchen.
Hat jemand ähnliche erfahren damit gemacht und evlt ein Problem damit gehabt und gelöst ?
Das Problem äussert sich, das sobald nur ein IC am BUs hängt dieser nicht mehr sauber arbeitet.
ich habe leider im Netz sehr wenig dazu gefunden, ein Telefonat mit einem Elektroniker brachte leider auch nicht
den gewünschten Erfolg.
Der 128 ist eine SMD variante, ich denke nicht das dass Problem ist ? oder ?
Hoffe jemand weiss Rat
Grüsse
Pat
Liste der Anhänge anzeigen (Anzahl: 1)
Guten Morgen,
Zitat:
was ist am MCP anders als an dem P82b715
Ich dachte die ganze Zeit, Du setzt P82b715 ein.
Dafür gibt es dieses Bild für die Beschaltung:
Anhang 34554
Da brauchst Du die beiden Pull-UPs an den Treiber-Ausgängen.
MfG
- - - Aktualisiert - - -
Beim MCP23017 steht im Datenblatt:
Zitat:
3.5.7 PULL-UP RESISTOR CONFIGURATION REGISTER
The GPPU register controls the pull-up resistors for the port pins. If a bit is set and the corresponding pin is configured as an input, the corresponding port pin is internally pulled up with a 100 kOhm resistor.
Der 100k-Pull-UP ist also offenbar nur zuschaltbar, wenn ein Port des MCP23017 als Input konfiguriert wird. Je nach Leitung (-länge) können 100k aber zu viel sein. So dass Du einen extra Pull-UP an der Leitung benötigst.
Für den Fall, dass Du etwas nachrechnen willst:
Für den P82b715 steht unter 9.2.2 Detailed Design Procedure genau, wie man die Pull-UPs berechnet, welche Auswirkungen dies auf das Signal hat, dass man bei mehreren Widerständen an einer Leitung die gegenseitige Beeinflussung berücksichtigen muss (Parallelschaltung), und dass vom Prinzip her nur ein Pull-UP an einer Leitung notwendig ist.
Liste der Anhänge anzeigen (Anzahl: 5)
Zitat:
Zitat von
modtronic
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
Anhang 34555
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
Anhang 34556
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.
Anhang 34557
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.
Anhang 34558
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.
Anhang 34559
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
