Stimmt, habe eben mal ins Datenblat geschaut und schon die Register und der Funktionsumfang ist komplett anders, wird also ein anderer I2C-Core sein. Und meine Probleme kamen bestimmt auch mit durch Wechselwirkung mit den anderen Modulen, da die AT91-Serie eine recht komplexe interne Bus-Matrix (basierend auf AHB von ARM's AMBA Design) mit FIFOs, Caches, Prioritäten usw. hat. Wenn da mal irgendwas länger blockiert, z.B. weil alle aufs externe SDRAM schreiben wollen, und irgendein FIFO zu klein ist, kann da schon was verlorengehen.
Wenn ich mir dagegen den ATMega so ansehe, dann sieht das nach einem recht entspannten Programmierjob aus :-)
--
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss
Ich könnte mir gut vorstellen, daß der Fehler erst später aufgefallen ist, oder vielleicht auch die Linux-Programmierer es nur nicht richtig hinbekommen haben, z.B. wegen Interrupt-Prioritäten im Linux-Kernel. Atmel bietet auch eine Low-Level Bibliothek an, wo das TWI-Modul ohne Linux direkt angesprochen wird und vermutlich haben die das damit getestet und freigegeben, und dann irgendwann den Linux-Programmierern gesagt "macht mal". Wäre natürlich auch kein gutes Zeichen für eine gute Planung und kann schon ein ungutes Gefühl aufkommen lassen.
Kannst du es nicht mehr irgendwo zwischenschieben beim SPI-Transfer? Bitbanging braucht immer relativ viel Rechenzeit. Aber sieht zumindest so aus, daß man den IO Clock für die Eingangssynchronisierung genauso hoch takten kann, wie den Systemclock. Bei manchen Microcontrollern bremsen ja leider Portzugriffe die CPU aus, scheint hier nicht so zu sein.
--
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss
I²C an sich funktioniert, egal ob mit dem TWI-Modul oder per Bitbang.
Das wesentliche Problem bei I²C ist immer, dass das Device dort ein Mitspracherecht hat ("Halt! Schluck! Ich kann nicht so schnell!"). Dies führt natürlich dazu, dass ein verklemmter Bus eine schlecht implementierte Software damit auf ewig aufhängen kann.
Man sollte halt das potenzielle Mitspracherecht des Devices auf eine bestimmte (plausible) Maximalzeit limitieren und dann stattdessen den Bus als derzeit nicht benutzbar deklarieren, wenn ein Device im Begriff ist, nicht mehr vernünftig zu reagieren (sprich, es reagiert zwar auf die address selection, aber danach verklemmt es). Wenn man das macht, bist du auch wieder robust damit.
Das Hardware-TWI selbst ist am ehesten nützlich, wenn man einen I²C-Slave implementieren will, für einen reinen Master ist es kaum mehr Aufwand, das gleich in Software zu zimmern.
Habe hier einen Temperatursensor laufen, der tagaus, tagein, alle 5 min einen SHT-21 per TWI-Modul abfragt und das Ergebnis dann via IEEE
802.15.4 in die Wohnung funkt. Die einzigen Probleme, die ich damit hatte, waren korrosionsbedingt, weil das Teil im Außenbereich eingesetzt wird und offenbar dann Flussmittelreste nach dem letzten Winter dort was versaut haben (genaue Ursache war nicht ermittelbar, aber es war *nicht* im Bereich I²C, sondern irgendwo in der Kommunikation zwischen Controller und 802.15.4-Transceiver). Jetzt habe ich den gleichen SHT-21 an einem ATmega128RFA1 auf einer eigenen Platine (statt gekauften Funkmoduls) verbaut; mal sehen, wie der den Winter dann überleben wird. (Der TWI-Block des ATmega128RFA1 ist der gleiche wie in deinem ATmega2560.)
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
Leider wird das Dingen schonmal ueber SPI programmiert und der Programmer bleibt dranhaengen. Moeglich dass ich da was abzwacken kann, aber da das unsicher ist muss ich zumindest ueber Selektorwiderstaende an einen Port gehen. TWI wuerde das vermeiden, ist mir aber nach dieser Diskussion etwas zu heikel.
Also unter "robust" würde ich was anderes verstehen. Man stelle sich nur vor: "Sehr geehrte Damen und Herren, hier spricht ihr Kapitän. Ich muß ihnen leider mitteilen, daß der Temperatursensor von seinem Mitspracherecht Gebrauch gemacht hat und wir daher das Fahrwerk nicht ausfahren können. Bitte machen sie sich auf eine etwas rauhere Landung gefasst."
--
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss
Also wie das Haemmerchen im Kofferraum der aelteren Opel Kadett :-)
Ich haette auch nur ein Bauteil dranhaengen, einen DAC. Aber ich bleibe lieber bei SPI, da gibt es beinahe keine Geschwindigkeitsbeschraenkungen weil man die Daten mit bis zu 50MHz in den DAC reinpruegeln koennte. Auch Unterbrechungen im Datenstrom machen dann nichts, der wartet einfach bis zur naechsten Taktflanke.
Der Programmer (zumindest die originalen von Atmel) ist hochohmig, wenn er grad nicht aktiv ist. Du kannst die Pins also auch für andere Zwecke verwenden. Sowohl für Eingänge, sofern Deine Quelle hochohmig ist beim Programmieren (z.B. Taster, man muss ja nicht gerade beim Programmieren drauf rum drücken), als auch für Ausgänge, sofern es der angeschlossenen Hardware egal ist, dass beim Programmieren mal was wackelt (z.B. LCD).
Ansonsten hab ich bei I2C die Erfahrung gemacht, dass man unbedingt kontrollieren sollte, dass man die Timing-Spezifikationen aller angeschlossenen Bausteine einhält, besonders die Anstiegszeiten, und zwar auch bei langsamen Bustakten! Besonders garstiges Beispiel: CS8420 (tr = 25ns). Andererseits: Wenn man die Spezifikationen einhält, kann man genauso gut mit 100kHz arbeiten...
Zweifellos. Ich wollte es nur mal erwähnen, weil man sich möglicherweise "gefühlsmäßig" zu der Annahme verleiten lassen könnte, dass man z.B. bei ausgedehnten Bussen mit besonders niedrigen Taktfrequenzen was erreichen könnte...
Aber sicher nicht mit einem 2560 @16MHz mittels reinem Bitbanging. Die schnellstmögliche Umsetzung (bidirektional) braucht 8 Takte/Bit, damit kommst du maximal auf 2MHz.
Sprechen wir von IIC oder SMB? SMB hat einen timeout, IIC nicht!
Hier wird die Umschaltung nach highspeed beschrieben, das hat aber nichts mit langsameren Takten zu tun.
Das dürfte eine andere Ursache gehabt haben.
Ich hatte viel mit IIC gemacht. IIC hat seine Probleme, z.B. Glitches auf dem Bus, aber eine zu kleine Taktrate hatte ich wirklich nie als Problem identifizieren können. Zu flache Flanken können allerdings Ärger machen.
Das ist natuerlich schoen, aber wenn der SW-Ingenieur Micro-Step zur Diagnose machen will da wird es eng, weil dann waehrend des Zugriffs durch den Programmer auch auf auf meine SPI Chose zugegriffen werden muss. Bin aber kein Experte in diesen Dingen, lasse mich gern belehren.
Einige Bausteine scheinen keine Musterknaben zu sein. Ich hatte welche (zum Rausentwickeln) die hielten den Bus wie beim Armdruecken fest.
Zum einen ist das nur ein Beispiel was passieren kann. Zum anderen ist das Problem dass immer mehr Port Extender und was nicht alles fuer beides ausgelegt ist. Damit kommt das Time-out Problem durch die Hintertuer ins System geschlichen. Beispiel:
formatting link
Zitat: "Finally, the system master can reset the CAT9557 in the event of a time-out by asserting a LOW in the reset input". Das ist dann "der dritte Pin" bei I2C, die Notbremse :-)
Nein, aber es zeigt dass es offenbar nicht so einfach ist, nach Rueckfall in niedrigere Datenraten nochmal eben Gas zu geben weil dann irgendwas intern ausrastet. Man weiss auch nicht wie weit der Takt abfallen darf _waehrend_ der IC im High-Speed Modus ist. Ich mag keine Chips wo man erst einen Haufen Fragen an den Hersteller loslassen und dann warten muss bis man es ins Design setzen kann. Habe gerade ein solches IC, dort aber keine Wahl, und ich warte seit Montag weil die Frage mal wieder was knifflig war und an die Chip Designer weitergeleitet werden musste.
Fuer meine Kunden zaehlte nur dass es nicht immer funktionierte und im Feld deshalb Aerger gab. Das kostet die handfest Geld und sowas auszubuegeln ist daher ein Teil meines Taetigkeitsfeldes.
Das war stets das erste was ich an den I2C Problemkisten untersuchte. War i.d.R. alles astrein, auch die Pull-ups. Eine Sache die oefter vorkam war dass ein I2C Chip eine Leitung mit aller Kraft festhielt. Ein Power-Cycle der ganze Kiste loeste das. Ganz selten konnte man einen festgefrorenen SDA Node durch das Senden eines Dutzend SCL Transitions "lockern" (mit dem Hammer dagegen hauen, sozusagen). In anderen Faellen tat es ein beherztes bzzzzt per Drahtbruecke, doch das alles ist fuer einen Kunden keine brauchbare Loesung. Nach Umstellung auf andere Strukturen wie SPI gab es diese Probleme nicht mehr. Kunde happy.
Mein Fazit ueber die Jahrzehnte ist, I2C ist eine sehr gute Idee weil man (zumindest in der Theorie) mit zwei Leitungen ein ganzes Arsenal verschiedener Chips bidirektional ansprechen kann. Das kann SPI nicht. Aber die Implementierung von I2C lief dann reichlich suboptimal ab sodass ich es aus Gruenden der Betriebssicherheit ungern benutze.
Klar. Ich meinte damit dass ich mit dem jetzt ins Design gesetzten SPI-DAC Reserven bis unter die Arme habe. Ein ATMega, egal welcher, bekommt den nicht bis in den roten Bereich. Soll heissen das Design ist sicher.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.