1. Home
  2. Electronics (German)
  3. ATMega I2C, funktioniert das sicher?
  4. Page 3

ATMega I2C, funktioniert das sicher?

Ja, dann verletzt das Teil die IIC Spec.

Ja jenun, es ist naturgemäß anspruchsvoller höhere Takte zu verarbeiten als niedrigere.

Bis DC.

Ist ja gut, zu meinen Aufgaben gehört eben nicht nur die Feststellung, daß etwas nicht funktioniert, sondern auch die Erklärung, warum es nicht funktioniert.

Ja SPI macht da häufig weniger Probleme.

Ich hatte vergleichsweise wenig Probleme mit IIC. Es gab einige EEPROM, die ein seltsames timing an den Tag legten, aber das dürfte mittlerweile auch Geschichte sein.

Reply to
Eric Brücklmeier
Loading thread data ...

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

Reply to
Eric Brücklmeier

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 :-)

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

Eben, und das tun inzwischen IME etliche Bauteile.

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

50MHz, ohne Gangschaltung. What's the problem? Ich weiss auch nicht warum sie das bei I2C oft nicht hinkriegen.

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.

[...] 
--
Gruesse, Joerg 

http://www.analogconsultants.com/
Reply to
Joerg

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.

--
Gruesse, Joerg 

http://www.analogconsultants.com/
Reply to
Joerg

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.

--
Gruesse, Joerg 

http://www.analogconsultants.com/
Reply to
Joerg

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.

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

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.

--
Gruesse, Joerg 

http://www.analogconsultants.com/
Reply to
Joerg

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.

--
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL 

http://www.sax.de/~joerg/                        NIC: JW11-RIPE 
Never trust an operating system you don't have sources for. ;-)
Reply to
Joerg Wunsch

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

Reply to
Markus Faust

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.

--
Gruesse, Joerg 

http://www.analogconsultants.com/
Reply to
Joerg

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

Reply to
Michael Baeuerle

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 :-)

--
Gruesse, Joerg 

http://www.analogconsultants.com/
Reply to
Joerg

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

Reply to
Heiko Nocon

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

--
Gruesse, Joerg 

http://www.analogconsultants.com/
Reply to
Joerg

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.

--
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL 

http://www.sax.de/~joerg/                        NIC: JW11-RIPE 
Never trust an operating system you don't have sources for. ;-)
Reply to
Joerg Wunsch

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.