ATMega I2C, funktioniert das sicher?

Am 24.10.2012 18:39, schrieb Joerg:

Ich hab einige hundert Systeme mit verschiedenen ATmegas draußen, wo ein I2C EEProm und ein RTC verbaut sind. Nach den üblichen Anfangsschwierigkeiten läuft das einwandfrei. Mit dem 2560 hab ich allerdings keine Erfahrungen. Der größte, den ich einsetze ist ein 128.

Gruß

Stefan

Wenn es irgendwie geht würd ich es per Bitbang machen. Die Hardware ist schon recht zickig.(ich habs nicht stabil hinbekommen)

--
MFG Gernot

Danke. Ich muss damit einen Mehrfach-DAC betreiben. Der hat jedoch ein EEPROM sodass er nach dem Aufwachen in einen definierten Zustand geht bis der Datenstrom eingetrudelt ist.

So wie ich im Web gelesen habe bedeutet bei diesem uC 400kHz beim TWI beinahe schon "Fuss in der Oelwanne". Nicht gerade ueppig, reicht hier aber.

--
Gruesse, Joerg 

http://www.analogconsultants.com/

Der funktioniert sehr gut, wenn man einen ganzen Bus voller Devices dranhängen hat. Warum sollte er also ausgerechnet bei nur einem einzelnen Probleme machen?

Diesen konkreten Chip von Atmel kenne ich nicht, aber leider hatte ich beim AT91SAM9G45 Probleme mit dem TWI-Modul, wie auch die Linux Kernel Entwickler, die daher das Hardwaremodul des Chips nicht verwendet haben, sondern es für Linux per Software emulieren:

Aber vielleicht läuft das auf dem ATMega auch wunderbar stabil. Ich würde aber vielleicht dennoch empfehlen, erstmal die 191.000 Ergebnisse bei Google für "ATMega2560 i2c problem" durchzulesen :-)

Wenn du nicht viel Daten überträgst und sonst auch noch was Rechenzeit hast, kannst du das ja auch recht einfach per Software mit Interrupts emulieren (oder gar blockierend, wenn du viel Zeit hast), insbesondere wenn nur ein Device dranhängt, was vielleicht auch kein Clock-Stretching auslösen kann, sodaß man die Implementierung dann noch etwas einfacher halten kann. Das sollte dann sehr stabil laufen.

Übrigens immer wichtig, die Erratas von Atmel durchzulesen. Weitere Probleme, denen ich begegnet bin: die USB-Initialisierung funktionierte nicht zuverlässig: Errata Vorschlag: Initialisierung zweimal durchlaufen lassen. Und dann noch ein Problem bei hohen Übertragungsraten mit dem SSC-Interface: Man konnte laut Datenblatt erlaubte Datenraten programmieren (je nachdem, an welcher Stelle des Datenblatts man nachlas), die bei hoher restlicher Last nicht zuverlässig funktionierten: es wurden Bytes verschluckt (waren aber so ziemlich alle Interfaces recht gut ausgelastet, und wurde massig Speicherbandbreite benötigt, mit PDC-Transfers im Hintergrund).

--
Frank Buss, http://www.frank-buss.de 
electronics and more: http://www.youtube.com/user/frankbuss

Quatsch. Die tut genau das, was sie lt. Doku tun soll.

Das ist 'ne völlig andere Sache...

Das ist Unsinn. Jedenfalls ohne zusätzliche Spezifikation der physischen Gegebenheiten des Busses. Wenn der drei Meter lang ist, ja dann ist man natürlich bei 400kHz schon mit dem Fuß in der Ölwanne.

Zitat aus dem Code:

/*

585 * Prefer the GPIO code since the TWI controller isn't robust 586 * (gets overruns and underruns under load) and can only issue 587 * repeated STARTs in one scenario (the driver doesn't yet handle them). 588 */

Oh-oh, nicht so toll. Oben im Kopf steht (c)Atmel, heisst dass dass dieser Code und damit auch diese Kommentarzeilen von Atmel selbst kommen?

Ich denke wenn ich Bit-Banging machen muss kann ich auch gleich SPI Devices nehmen. Das ist so gut wie immer gusseisern robust.

Heiko und Gernot, vielen Dank auch fuer Eure Antworten, auch an Stefan. Jetzt habe ich vier Meinungen, zwei positive und zwei nicht so erbauliche. Das macht mir als Nicht-uC-Spezi nicht gerade Mut :-)

--
Gruesse, Joerg 

http://www.analogconsultants.com/

Werden nur 5-10cm sein. Aber die TWI Engine kann m.W. nicht viel mehr und 16MHz ist max Clock bei diesem uC.

--
Gruesse, Joerg 

http://www.analogconsultants.com/

Initial wird der Code von Atmel selbst stammen. Aber bei Linux Quellen bleibt da nicht mehr viel von übrig nach einiger Zeit, hier die History für die Datei (geht per "more" unten über zwei Seiten)

Das ist die initiale Version gewesen, die den Kommentar schon beinhaltete:

Scheint also von Atmel gekommen zu sein.

Aber ich kann bestätigen, daß das I2C-Modul unstabil läuft, da ich meinen eigenen Linux-Treiber schreiben musste, da ich sehr viel I2C Daten übertragen musste und die per PDC im Hintergrund, möglichst ohne CPU Belastung, übertragen wurden und da gab es noch nichts in der Richtung. Die PDC-Übertragung blieb manchmal hängen (PDC ist sowas wie DMA). Habe dann ein Timeout eingebaut, der den I2C-Bus neu initialisiert hat und die Übertragung in so einem Fall neu angestossen hat. Kam ein paarmal pro Tag vor. Ein eigener Treiber von mir nach demselben Konzept, für SPI-Übertragung mit PDC, lief stabil.

--
Frank Buss, http://www.frank-buss.de 
electronics and more: http://www.youtube.com/user/frankbuss

Das ist kein gutes Zeichen.

Das klingt so wie die I2C Aufhaenger die ich mit anderen System gesehen habe. Wie frueher beim Opel Kadett Anlasser wo man ab und zu mit dem Hammer gegenschlagen musste damit er wieder tat.

Dann werde ich wohl doch wie ueblich SPI vorsehen, aber ueber Bit-Bang weil ausser dem TWI Block nichts mehr frei ist. Das wird beim Kunden nicht gerade einen Freudentaumel ausloesen weil die die Programmierung machen muessen.

--
Gruesse, Joerg 

http://www.analogconsultants.com/

SPI kann ja problemlos mehrere Devices ansprechen (bis auf ganz wenige Chips, bei denen der Entwickler geschlafen hat und wo ein deselect auf Chipselect nicht MISO auf Tristate schaltet), oder brauchst du die Schnittstelle permanent und mit der höchstmöglichen Übertragungsrate?

--
Frank Buss, http://www.frank-buss.de 
electronics and more: http://www.youtube.com/user/frankbuss

Maximaler TWI-Takt ist CPU-Takt durch 16, bei 16MHz also 1MHz.

BTW: Unbedingt Anmerkungen von Atmel zur Wahl des PullUp-Widerstands beachten.

Ich brauche sie um einen DAC Chip mit mehreren Kanaelen anzusteuern, die Update Rate liegt im Bereich unter 10kHz und es reicht wenn dabei nur ein Kanal veraendert werden kann. Wobei bei vielen mehr als 20 Bits pro Kanal rueber muessen inklusive dem ganze Verwaltungsgeraffel.

--
Gruesse, Joerg 

http://www.analogconsultants.com/

Die Chips moegen u.U. keine solchen "Zwischengeschwindigkeiten". Manchmal steht im Spec nur 100kHz, 400kHz und 3.4MHz fuer die I2C Anbindung.

Klar, da sind dann

Beim IIC-Chipkarten lesen ist das mit der Spezifikation so eine Sache...

--
MFG Gernot

Definitionsgemäß müssen I2C Slaves von fmax bis auf DC runter funktionieren. Mir ist noch nie ein IC untergekommen, das keine statische Implementierung des I2C Interfaces hatte. Kennst Du da wirklich ein Beispiel (Die Frage ist völlig ohne Hintergedanken ernst gemeint)?

Leider nicht immer, und das ist eines der Probleme. Es kommt darauf an welche Devices man dranhaengt:

Zitat Seite 32 "This means that an I 2C-bus running at less than 10 kHz is not SMBus compliant since the SMBus devices may time-out".

Was mich in diesem Fall stutzig machte war:

Zitat Seite 29 "The MCP4728 device does not acknowledge this byte. However, upon receiving this command, the device switches to HS mode and can communicate at up to 3.4 Mbit/s on SDA and SCL lines. The device will switch out of the HS mode on the next STOP condition".

Dieser Chip ist intern zwar wohl statisch, braucht aber offenbar erst ein spezielles Command, wie eine Gangschaltung. Was immer "up to" heissen mag.

Ich habe einige I2C Chips erlebt die z.B. bei 400kHz funktionierten, bei weniger als 100kHz jedoch seltsamerweise nicht oder nur unzuverlaessig. Da hingen sie manchmal den ganzen Bus auf. Kann Dir aber nicht mehr die Teilenummern sagen, das hatte ich alles rausgeworfen und durch SPI ersetzt.

--
Gruesse, Joerg 

http://www.analogconsultants.com/

Denk' aber dran, dass das ein _völlig_ komplett anderer Controller ist!

--
Thomas Kindler