-
        

Ergebnis 1 bis 7 von 7

Thema: Beliebige Pins für I2C (SDA & SCL) ...? (ATmega168)

  1. #1
    Erfahrener Benutzer Roboter Genie Avatar von Willa
    Registriert seit
    26.10.2006
    Ort
    Bremen
    Alter
    37
    Beiträge
    1.269

    Beliebige Pins für I2C (SDA & SCL) ...? (ATmega168)

    Anzeige

    Hi!
    Ich hab grad ein kleines Problem: Ich kann ohne Störungen mit meinem ATmega168 meinen RC-Empfänger auswerten (mit timer0 und Int1). Wenn ich aber drei auf I2C umgebaute Brushlessregler anschließe, bekomme ich im Empfängersignal ein Rauschen (bei einem angeschlossenem Regler wenig, bei zwei mehr, bei drei noch mehr. Auch wenn die Motoren nicht laufen). Jetzt frage ich mich woher das kommen könnte... Ich habe 10k und 5k Pullups versucht, macht keinen merklichen Unterschied.

    Erstmal hier der Schaltplan zum nachvollziehen:
    http://arduino.cc/en/uploads/Main/Ar...-schematic.pdf

    Am M168 werden 6 ADC Pins benutzt (ADC0-ADC5), darunter auch die Pins PC4 und PC5. Diese sind offiziell aber als SDA und SCL Pins angegeben. Ich kann sie also nicht für I2C benutzen. Für I2C benutze ich nun Pind4 und d5. Wie ich auf diese Idee gekommen bin weiss ich gar nicht mehr. In Bascom kann ich ganz einfach mit dem "Config SDA & SCL = ..." jeden beliebigen Pin für I2C angeben. Aber ist das auch gut so? Oder könnten meine Probleme daher kommen? Muss ich außer dem Festlegen der SDA und SCL Pins sonst noch irgendwas einstellen?

    Oder gibt es noch andere Ideen...? I2C Takt hoch-/ runtersetzen?

    Hätte mich auch gewundert wenn mal was problemlos funktioniert....
    Viele Grüße, William
    -> http://william.thielicke.org/

  2. #2
    Erfahrener Benutzer Roboter Genie Avatar von Willa
    Registriert seit
    26.10.2006
    Ort
    Bremen
    Alter
    37
    Beiträge
    1.269
    Ich glaube, ich habe gelesen, dass Bascom Software I2C benutzt sobald andere als die Standard Pins für I2C deklariert werden. Und wenn Software I2C benutzt wird, wird der Prozessor blockiert, solange Daten per I2C übertragen werden. Das würde erklären warum dann die Empfängerauswertung per INT1 nicht mehr zuverlässig funktioniert. Diese ist ja ziemlich zeitkritisch. Ist ein I2C Bus also nicht aktiv wenn keine Geräte angeschlossen sind? Merkt das der Master...? Oder feuert der einfach blind seine Signale ab? Letzteres scheinbar nicht, sonst könnte ich mir das Verhalten nicht erklären...

    Kann das jemand bestätigen?

    Jetzt werde ich wohl nicht drumrum kommen per Kupferlackdraht direkt am TQFP die ADC Pins 6 und 7 abzugreifen. Und dann Leiterbahn auftrennen und für I2C die Standard Pins benutzen... Wie ich das hasse... Jetzt habe ich doch extra so eine schöne Platine, und trotzdem muss ich wieder rumpfuschen [-( .
    Eigentlich finde ich die Mini Arduinos eine echt schicke Sache, aber sie haben nicht genug ADC Pins auf dem Breakoutboard, bzw. die Pins teilen sich ihre Funktion mit dem I2C. Seeeeeeeeeeeehr ärgerlich....
    Viele Grüße, William
    -> http://william.thielicke.org/

  3. #3
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    7.551
    Zitat Zitat von Willa
    ... Und wenn Software I2C benutzt wird, wird der Prozessor blockiert, solange Daten per I2C übertragen werden ...
    So sehe ich das auch. Bei Verwendung der von Atmel definierten I²C-Leitungen bist Du hardwaremässig an die interne I²C-Logik gekoppelt, ähnlich wie mit der Hardware-RS232 und die Kommunikation läuft über einen "isolierten" Hardware-Teil des Controllers, wie in solchen Dingen üblich, sozusagen nebenher. Aber Du hast ja den Vorteil bei dem TQFP mit den beiden zusätzlichen ADC´s. Sieht mir ja garnicht nach professionellem bzw. gutem Design aus, wenn zusätzliche Möglichkeiten nicht ausgeschöpft werden ! Da hat der Boarddesigner/Entwickler keine Lorbeeren verdient. Tröste Dich: Pololu ist ähnlich schlampig - aber nur halb so viel: die haben wenigstens ein Poti an den ADC7 gehängt.
    Ciao sagt der JoeamBerg

  4. #4
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    22.05.2005
    Ort
    12°29´ O, 48°38´ N
    Alter
    48
    Beiträge
    2.731
    Moin,
    Bascom verwendet die Hardware für TWI nur, wenn man die i2c-twi.lib einbindet. Aber auch da wird die komplette CPU-Leistung zum Senden/Empfangen verwendet, bringt von daher nicht unbedingt einen Vorteil.
    Besser wirds erst, wenn man das auch per IRQ behandelt, heisst aber selber proggen.

    Unabhängig davon kümmert sich Bascom nicht um das ob/was die Slaves machen, man muss dann schon nach jedem Byte den TWI-Status (TWSR) oder zumindest ERR abfragen obs geklappt hat.

  5. #5
    Erfahrener Benutzer Roboter Genie Avatar von Willa
    Registriert seit
    26.10.2006
    Ort
    Bremen
    Alter
    37
    Beiträge
    1.269
    Guten Tag! Ich habe mir die "Mühe" gemacht und die SDA & SCL Leitungen aufgetrennt und umgeroutet. Jetzt nutze ich die Standard Pins vom atmega168.

    --> Die Probleme sind weg!

    Erstaunlich... Jetzt muss ich noch auf einen Moment der absoluten Zitterfreiheit warten um ADC6 und ADC7 mit Kupferlackdraht zu versehen...

    EDIT:
    Es sieht grad so aus als wäre das doch nicht die Lösung... Solange die Platine neben dem Copter liegt treten keine Störungen auf, wenn ich sie aber drauf schraube kommen die Störungen wieder... grml...
    Viele Grüße, William
    -> http://william.thielicke.org/

  6. #6
    Erfahrener Benutzer Roboter-Spezialist Avatar von steveLB
    Registriert seit
    24.10.2005
    Beiträge
    481
    verbindest du beim schrauben masse miteinander oder andere signale, so das ein rauschen überspringt ?
    [X] <-- Nail here for new Monitor

  7. #7
    Erfahrener Benutzer Roboter Genie Avatar von Willa
    Registriert seit
    26.10.2006
    Ort
    Bremen
    Alter
    37
    Beiträge
    1.269
    Das Platine ist mit Kunststoffschrauben befestigt, auch sonst besteht kein Kontakt zum Chassis. Aber das Problem hat sich jetzt erledigt. Die I2C Leitungen lagen sehr nahe am Empfänger. Jetzt habe ich die Distanz erhöht und kann keine Störungen mehr feststellen. Außerdem habe ich die Kabel verdrillt. Ist es bekannt, dass I2C ziemlich stark "strahlt"...?
    Ich verwende weiterhin die "non-Standard" I2C Pins. Danke für eure Mithilfe!
    Viele Grüße, William
    -> http://william.thielicke.org/

Berechtigungen

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