ATMega I2C, funktioniert das sicher?

Da ist diese %&#!+ Version von Thunderbird...

Heiko meint wahrscheinlich eher, ob der ATMega den überhaupt in den grünen Bereich bekommt, also du soviel Daten rausschieben kannst, wie du brauchst, wenn da noch viel anderes nebenher läuft. Ist ja nur ein billiger 8-Bitter :-)

Eben, und das tun inzwischen IME etliche Bauteile.

Noe. Der SPI Chip der jetzt drin ist geht einwandfrei von Null bis

Bei mir nur wenn meine Kunden diesen zweiten Teil der Untersuchung bezahlen 8-)

Denn das kostet oft viele Stunden an Korrespondenz mit einem Hersteller welcher u.U. nicht sehr erpicht darauf ist dass sowas extern diskutiert wird.

Ah, deshalb. Das erklaert vermutlich auch warum das gleiche bei zwei Leuten aus der s.e.design NG geschieht. Die hatten wohl auch ein TB Update gemacht.

Ganz lustig soll ein Update auf Windows 8 sein. Ich hoffe dass ich das noch Jahre rausschieben kann, da graust es mir echt vor.

Das schoene bei SPI ist dass der gruene Bereich echt bis Null Hertz runtergeht, es gibt (normalerweise) kein Time-Out solange man den /SYNC Pin nicht loslaesst. D.h. wenn der ATMega einen Schweissausbruch bekommt und die Datenuebertragung mittendrin zaeh wird macht das nichts, es kommt dennoch alles an. Irgendwie ist mir da wohler bei.

Das war schon klar. Aber wenn die DAC-Ausgabe dann wie wild jittert oder nur sehr langsam aktualisiert wird, kann das problematisch sein. Aber kommt natürlich immer auf den Anwendungsfall drauf an. Temperaturregelung wäre unkritisch, aber eine Audioausgabe mit -120 dB Klirrfaktor geht so eher nicht.

In diesem DAC wird nur aktualisiert wenn das 24ste Bit durch ist. Glitches gibt es dadurch nicht, aber natuerlich Verzoegerungen. Einen ATMega wuerde ich auch nicht zum Rendering eines Mozart Concerto benutzen :-)

In meinem Fall geht es um Schaltregler-Steuerung, wobei jeder Regler noch einige Hardware-Poller hat. Ich gehe an sich bei jedem sicherheitskritischen Design davon aus dass der uC zu jedem Zeitpunkt tschuess sagen koennte oder falsche Kommandos loslaesst. Muss also alles abgedeckt werden.

Frank Buss schrieb:

"Sehr geehrte Damen und Herren, hier spricht Ihr Kapitän. Leider ist unser Temperatursensor ausgefallen, aber wir werden deshalb trotzdem ganz normal landen können, da unsere Software derartige Ausfälle kompensieren kann. Allerdings können wir Ihnen nicht sagen, wie kalt es draußen gerade ist."

Die Probleme tauchen ja nur dann auf, wenn was wirklich nicht funktioniert. Neben dem Ausfall des Sensors könnte das natürlich auch ein Blitzschlag oder sowas sein.

Die SPI-Schnittstelle (bzw. PDI/PDO) ist nur zum Programmieren. Debuggen geht beim ATmega2560 (soweit ich weiß) nur via JTAG.

Kann z.B. durch Glitches auf dem Bus passieren, dass Start-/Stop-Bedingungen inkorrekt erkannt werden. Ich hab mir mal eine Schaltung aus zwei retriggerbaren Monoflops gebaut, die den Oszi dann triggert, wenn der Bus klemmt, um das untersuchen zu können.

Markus

Warum haben die das denn so umstaendlich gemacht? Ich habe aber zur Sicherheit beides freigelassen, was netto sechs Port Pins kostet die man offenbar nur mit Klimmzuegen oder Risiken benutzen koennte.

Ein DSO hatte ich Anfang der 90er noch nicht als die ersten bockenden I2C Schaltungen auf meinem Labortisch aufschlugen. Ich liess den Logic Analyzer stundenlang mit fein eingestellten Schwellwerten drueberlaufen und dessen Output ging in den PC zwecks Auswertung. Es gab gelegentlich eine Schaltung wo die Leiterbahnfuehrung ungeschickt war und z.B. was von einem Flyback Uebertrager aufpickte. Aber das war nicht der Grund. Es gab schlicht Chips die schonmal ohne aeusserlichen Grund aufhingen.

Einerseits hat es wohl historische Gruende: Das ISP-Interface hatte bereits der allererste AVR (AT90S1200) an Bord und es sind massenweise Programmiergeraete dafuer im Feld. JTAG kam erst Jahre spaeter hinzu, und das auch nur in den groesseren Chips. Und JTAG ist vielleicht einfach intern ein anderes Modul und man wollte nicht zu viel auf die gleichen Pins legen.

Man kann aber beide Interfaces jeweils per Fuse abschalten. Wenn du z.B. alles via JTAG machst und das ISP Interface nicht benoetigst, dann brauchst du da auch keine Pins freihalten.

Micha

Danke, das ist schonmal einfacher. Muss ich nur sehen was der Kunde an Programmiergeraet hat. Sie sind jedoch offen fuer Bootloading was die Sache noch einfacher machen wuerde. Wobei es natuerlich sein kann dass man auch mal den Bootloader auffrischen muss.

Ist schon ein Kreuz mit all diesem Digitalkram. Da ich uC in Sachen POR/POR nicht ueber den Weg traue habe ich einen externen, mit eigenem Watchdog. Wenn der uC da nicht alle paar hundert msec "Knoeppschen drueckt" faehrt die ganze Kiste ueber eine diskrete Schutz-Mimik auf ueberall Null Volt runter. Das wir noch lustig beim Programmieren :-)

Ein vernünftiger Bootloader kann sich natürlich auch selber updaten.

Klar, aber ich habe mal einen Fall mitbekommen wo ... :-)

Michael Baeuerle schrieb:

Man kann die ISP-Leitungen auch so entwerfen, dass sie nicht mit dem ISP-Protokoll (bei dem der Controller ja im Reset gehalten wird) kollidieren, also insbesondere die Datenrichtung der angeschlossenen Peripherie nicht mit der ISP-Nutzung kollidiert.

Man kann auch auf die JTAG-Leitungen Status-LEDs oder dergleichen klemmen, die im Zweifelsfalle nicht wichtig sind und durch JTAG überschrieben werden können. Dann schaltet man das JTAG nicht per Fuse "hart" ab, sondern per JTD-Bit "soft". Damit bleibt die JTAG-Schnittstelle sowohl fürs Programmieren als auch Debuggen verfügbar; in der Debugversion setzt man dann entweder das JTD-Bit gar nicht, oder man geht im Einzelschritt über die entsprechende Anweisung, wodurch die zeitliche Bedingung (zweimal innerhalb von 4 Takten beschreiben) nicht mehr gewährleistet ist, sodass die JTAG-Schnittstelle weiter aktiv bleibt.