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

[Willa]

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/Arduino-Pro-Mini-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....

[Willa]

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.... ](*,)

[oberallgeier]

... 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-RS 232 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.

[linux_80]

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.

[Willa]

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...

[steveLB]

verbindest du beim schrauben masse miteinander oder andere signale, so das ein rauschen überspringt ?

[Willa]

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!