-         
Seite 3 von 3 ErsteErste 123
Ergebnis 21 bis 24 von 24

Thema: AT Mega 128 und P82b715 / P82b96 Probleme ??

  1. #21
    Erfahrener Benutzer Robotik Einstein Avatar von Moppi
    Registriert seit
    18.03.2018
    Beiträge
    1.620
    Blog-Einträge
    9
    Anzeige

    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

  2. #22
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    11.08.2009
    Ort
    Süden
    Alter
    65
    Beiträge
    342
    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

  3. #23
    Benutzer Stammmitglied Avatar von modtronic
    Registriert seit
    14.05.2011
    Ort
    Hagen
    Alter
    42
    Beiträge
    66
    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

  4. #24
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    07.03.2011
    Beiträge
    1.756
    Zitat Zitat von modtronic Beitrag anzeigen
    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

    Klicke auf die Grafik für eine größere Ansicht

Name:	LA_1MHz.jpg
Hits:	2
Größe:	31,2 KB
ID:	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

    Klicke auf die Grafik für eine größere Ansicht

Name:	PIC_0022.jpg
Hits:	3
Größe:	100,1 KB
ID:	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.

    Klicke auf die Grafik für eine größere Ansicht

Name:	BUS_350cm.jpg
Hits:	2
Größe:	42,8 KB
ID:	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.

    Klicke auf die Grafik für eine größere Ansicht

Name:	P82B96_LongBus.jpg
Hits:	2
Größe:	36,7 KB
ID:	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.

    Klicke auf die Grafik für eine größere Ansicht

Name:	I2C_Crosstalk.png
Hits:	2
Größe:	31,1 KB
ID:	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
    Strom fließt auch durch krumme Drähte !

Seite 3 von 3 ErsteErste 123

Ähnliche Themen

  1. Case Probleme mit Mega 16
    Von MasterMX im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 4
    Letzter Beitrag: 06.01.2010, 09:41
  2. Probleme mit Hardware Twi an Mega 16
    Von dreadbrain im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 3
    Letzter Beitrag: 07.01.2007, 22:26
  3. Probleme mit Lcd und Mega 16
    Von dreadbrain im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 6
    Letzter Beitrag: 10.04.2006, 17:11
  4. Probleme mit Mega 8 und USART
    Von Panzer im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 2
    Letzter Beitrag: 16.12.2005, 16:35
  5. Probleme mit Parity bei Mega 162
    Von Simon79 im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 3
    Letzter Beitrag: 17.05.2005, 08:01

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •