Porterweiterung per SPI

Michael Schwingen :

Eigentlich sollte man mit einer Sequenz "Start-Stop" alle I2C-Geräte wieder reseten können.

M.

Hallo Henning,

"Fully Static" bedeutet fuer mich aber nicht, dass er sich aufhaengen darf.

Joerg schrieb:

Hallo,

na wenn aufhängen kein statischer Zustand ist, was dann? ;-)

Bye

Hallo Uwe,

ROFL!

Erinnert mich an kuerzlich gelesenes: "Der Tod ist der schaerfstwirkende Faktor, der zur Dienstunfaehigkeit fuehren kann". Nein, das habe ich nicht erfunden, es stand wirklich irgendwo hochoffiziell.

Wenn ein Slave SDA dauerhaft auf Low zieht, wird es für den frisch resetteten Master schwierig, eine Start-Bedingung auf den Bus zu legen - da hilft nur, blind Clocks zu erzeugen und zu hoffen, daß der Slave irgendwann SDA losläßt. Ich hatte auch schon Fälle, wo ein Slave ausreichend verwirrt war, daß das nicht mehr helfen wollte - und viele I2C-Bausteine haben leider keinen Reset-Eingang.

cu Michael

Das Problem hatte ich mal.

Ein Kollege hatte auf einer BAugruppe ein EEPROM von Atmel, das zum Laden eines FPGAs diente. Das Teil beherrscht das serielle Protokoll zum Laden der 4000-er FPGAs von Xilinx, und an den selben beiden Pins, per weiterem Pin selektierbar, alternativ auch I2C. Damit die Daten für das FPGA im Betrieb aktualisiert werden können, klemmte er diese Pins also mittels zweier Analogschalter als Buskoppler an den I2C-Bus der Baugruppe. Die Analogschalter wurden von einem I2C-Bus-Expander gesteuert. Nach dem Einschalten der Baugruppe war das EEPROM vom I2C-Bus getrennt, wodurch das Laden des FPGAs mit seinem speziellen Protokoll lief, ohne mit dem I2C-Bus ins Gehege zu kommen. Manchmal schlug aber das Lesen aus dem EEPROM fehl, und zwar nur dann, wenn der Baugruppe ein Reset verpasst wurde, ohne dass die Versorgungsspannung unterbrochen wurde.

Die Fehlersuche blieb an mir hängen, weil der Kollege in ein anderes Projekt verschoben wurde.

Was passiere also? Nach dem Booten des Microcontrollers auf der Baugruppe las dieser aus einigen EEPROMS am I2C-Bus diverse Tabellen aus, um die Gerätedaten zu erfahren. Darunter war auch besagtes Atmel-EEPROM. Dazu schaltete er per Kommando an den Bus-Expander die "Buskoppler" ein, las die Daten aus dem EEPROM und schaltete anschließend die Buskoppler wieder aus. Dummerweise erscheinen die acht Bits, die man in den Bus-Expander schreibt, nicht am Ende des Schreibzyklus gemeinsam an seinen Ausgängen, sondern direkt mit der jeweiligen Taktflanke an SCL, also eins nach dem anderen. Damit wurde das Atmel-EEPROM mitten in einem I2C-Datenzyklus vom Bus getrennt. Noch dazu begab es sich dadurch, dass an SCL und SDA durch das (fast) gleichzeitige Öffnen der Analogschalter und die Pullups manchmal die (steigenden) Flanken so ungünstig zueinender lagen, dass das EEPROM autistisch wurde.

Die Sache mit Start-Stop versuchten wir in allen denkbaren Kombinationen. Sowohl vom I2C-Controller im MPC860 generiert, als auch per Software zu Fuß. Es half nichts, außer Strom weg.

Das Ganze wurde dann so umgebaut, dass das FPGA mittels seines HDC-Pins die Analogschalter steuert.

Es reagieren also nicht alle Bausteine auf Start-Stop mit einem Reset der I2C-Statemachine.

Grüße,

Günther

Hallo Michael,

... und viele Chip Designer sind offenbar unfaehig, einen gut funktionierenden POR/BOR zu entwickeln. Ohne selbigen ist ohne Reset Leitung keine gescheite Zuverlaessigkeit erreichbar.

SPI ist mir da doch lieber. Nur muss man leider fast immer einen Address-Bus dazu selbst zimmern. Doch mehr als einen Dollar und einige Quadratzentimer kostet er nicht.

Der reicht nicht: wenn der Master (z.B. per Watchdog) mitten in einem Buszyklus einen Reset bekommt, muß man die Slaves auch zurücksetzen - ein POR tut das nicht.

cu Michael

Hallo Michael,

Muesste man den uC dann nicht besser so programmieren, dass der Watchdog Handler die ordnungsgemaesse Beendigung der I2C Zyklus erlaubt? Bei vielen meiner SPI Geschichten waere ein harter Reset beinahe mit einem Polterabend vergleichbar.

"Joerg" schrieb:

Ich denke, nein.

Aber man kann natürlich auch eine state machine fehler- haft auslegen ("endlicher Automat" ist immer noch meine bevorzugte Bezeichnung :) ...

jedenfalls ist mit "dead lock per design" bei I2C nicht bekannt.

Hallo Ruediger,

Was waere denn dann ein unendlicher Automat?

Das hoerte sich in diesem Thread aber schwer danach an. Wenn ein I2C Chip nicht mehr aus einem bestimmten Status rauskommt oder den Bus unter Wasser haelt, dass stimmt etwas im Design nicht. Entweder liegt der Wurm im Chip Design oder im Host, oder beiden.

"Joerg" schrieb:

Eine Frage der Taxonomie?

Na ja. Unter 'Automat' versteht man (zumindest verstehen einige Leute :) eine _gedachte_ Maschine, d.h. ein Modell von einer Maschine.

Man muss ein solches Modell also nicht zwangsläufig real abbilden, d.h. konkret aufbauen können. (Das nicht-aufbauen-können gilt übrigens auch für endliche Automaten, z.B. Turingmaschine.)

Zurück zur Frage:

"Ein Automat heißt endlich, wenn die Menge der Zustände, die er annehmen kann (später S genannt), endlich ist."

Und bei Automatenmodellen kann man sich ja auch zumindest vorstellen dass die Anzahl der Automatenzustände nicht begrenzt ist, wobei sich natürlich die Frage stellt ob man mit solchen Automaten überhaupt was anfangen kann.

Wüsste jetzt grad nicht, was.

Ich fürchte, ich würde auch 'Zustände bekommen' wenn ein Automat, den ich gerade bediene (Münze rein, Auswahl- knopf drücken...) anfängt, der Reihe nach unendlich viele Zustände zu durchlaufen... *g*

Aber wenn mal einer mit einem Pflichtenheft kommt in dem steht: "Eine Maschine, die einfach alles kann" dann wäre der unendliche Automat vielleicht ein überlegenswerter Ansatz? Obwohl ich mir da nicht so ganz sicher bin *g*

Ich schätze, implementiert werden state machines aus praktischen Gründen immer nur (oder zumindest meist nur) als endliche Automaten, obwohl es ja noch ganz viele andere Automaten(modelle) gibt, Kellerautomat, Registermaschine, Zellulärer Automat, Neuronales Netz... in 'reale' Automaten kann man dann auch Kombinationen dieser Modelle implementieren.

um Beispiel kann man eine Zwei-Stack-Maschine, genannt FORTH, die selbst wiederum einen endlichen Automaten, genannt 'innerer Interpreter' enthalten mag auf einer Registermaschine, genannt uC mit eingebautem Subset einer Kellermaschine (eigener hardware Stackmechanismus) aufsetzen und immer so weiterkombinieren...).

Aber für eine state machine auf Chipebene passt der lin. Automat alleine oft ganz gut. I2C z.B.

Ich würde sagen im Chipdesign d.h. in der implementierten state machine.

Die I2C-Spec. geht gar nicht bis zur Ebene des Automaten hinunter und warum sollte nicht einer als Übergangsbedingung z.B. einen time-out in seinem slave festlegen? Zumindest zur Busfreigabe?

Das Argument 'statisches design' verstehe ich nicht, deswegen muss eine state machine doch nicht gleich zwangsläufig ewig hängenbleiben in einem Zustand, nur weil auf höherer Protokollebene mal was schiefgegangen ist?

"Joerg" schrieb:

Upps. Na ja, der Kontext... war doch ne direkte Antwort auf deine Frage.

Ging ja um die Frage nach Fehlern, die die "Urväter von I2C" gemacht haben könnten.

Ich dachte bei "design" also an das design der Spec., nicht an irgendwelche der zahlreichen mehr-oder-weniger guten Umsetzungen auf Bausteinebene (das Elend auf Anwenderseite mal aussen vor :)

"dead lock per design" in irgendwelchen I2C-chipsen gibts sicher im Einzelfall, da hab' ich keinen Zweifel. Auch Entwickler von state machines können mal nen schwarzen Tag haben.

Ich glaube aber nicht dass es an einem Fehler der Spec. liegt, wie das vielleicht im thread schon anklang. Denke da jetzt an Formulierungen wie: " ... da es ein statisches Design ist... folgt daraus irgendwas zwangsläufig für das Verhalten der Bausteine..."

Andererseits kann ich mir gerade vorstellen dass Anwender ganz grosse Fehler machen, Riesenklöpse sozusagen z.B. indem sie SDA und SCL via transmission gates gelegentlich mal vom Bus so abklemmen dass diese beiden ports dann frei "floaten" können...

Was soll sich da eine state machine bei denken, frage ich mich?

(Gut, der Chiphersteller könnte ganz weake pull-ups intern vorsehen die zwar nicht Funktionalität herstellen können aber zumindest floaten verhindern, wenn er an die 'An\Abklemmer' denkt.)

Möglicherweise steht sogar im datasheet des fraglichen chips, würde ich jetzt erwarten sozusagen dass das dort steht, dass erst enable/disable des Multifunktionsbus bedient werden muss bevor man pull-ups an/abklemmt für I2C. Eigentlich logisch.

In solchen oder ähnlichen Fällen ist aber nicht die Spec. schuld, meine ich. Zumal sie sich aus gutem Grund auch gar nicht auf dieser Ebene auslässt.

Ok, fehlerhafte chips/state machines gibts sicher auch, aber fehlerhaftes Design von I2C-Systemen durch Anwender sind sicher um Grössenordnungen häufiger schätze ich mal.

Fängt bei Leuten an die ihre Hausaufgaben nicht machen: Jumper richtig setzen und Software per copy-paste übernehmen, da fängt es an.

Zum Ausgangsthema: "Fehler (der Väter) in der Spec." fällt mir jetzt nix ein, grad' das würde mich aber besonderes interessieren.

Der Rest ist ja 'busy..bissi.. pityness as usual'.

Achja: Vergleich SPI und I2C. Meiner Meinung nach nicht vergleichbar.

SPI: Einfach, schnell und sonst gar nix. I2C: Verwendbar, wenn es über Basteleien hinausgehen soll.

(Und ich finde es mutig, SPI überhaupt als Bus zu bezeichnen. Schieberegister zu füllen ist schliesslich die erste und naheliegenste Idee, die Anfängern unter den Bastlern in den Sinn kommen könnte bzg. Datenaustausch zwischen Bausteinen. Dann kommt noch die Idee, Decoder für Adressierung zu verwenden und dann kommt nix mehr weil ausgereizt :)

Hallo Ruediger,

Aha, danke, also doch eine State Machine.

Mir hat mal ein SW-Ingenieur gesagt, dass das fuer alle Maschinen und sogar fuer meine analoge Welt gilt. Zumindest seit Max Planck.

Das sollten viele Automaten sein. Z.B. alle, die analoge Regelschleifen drin haben. PID Regler und so.

Windows schafft das sogar ohne Muenze. SCNR ....

Wuerde ich auch sagen. Ein Chip muss mit einem temporaeren Zusammenbruch eines Protokolls zurechtkommen.

Meist ist dann auf noch hoeherer Protokollebene etwas schiefgegangen, auf der Ebene des Design Review. Vielleicht war am Tag vorher Laenderspiel, die Leute waren entsprechend muede und haben das uebersehen ;-)

Hallo Ruediger,

Kenne ich. Eines meiner groesseren Designs war eines Montags fertig geworden und lief gleich nach Einstecken in den Card Cage. Haette ich fast einen Freundentanz hingelegt. Doch die Stimmung war gedrueckt. Der Chef und der leitende Ingenieur bei dem Kunden sind gebuertige Englaender und Manchester United hatte den Sonntag davor uebel verrissen.

Dafuer wurde der Widerstand erfunden :-)

Ist bedenklich, weil sich das summiert. Besser ist ein externer Pull-up. Aber eben nur einer.

Jumper sollte es in einem guten System genausowenig geben wie Trimmer. Das zerlegt sich beim Transport alles. Kommt bei mir in kein einziges Design. Dies ist so ziemlich das einizge, was ich Kunden auf jeden Fall versuche, auszureden. Vor einigen Monaten wieder gehabt. Kunde wollte Jumper zur Slot-ID. Dann habe ich es ganz leise so gemacht, dass die Boards alle immer gleich sind und den Slot, in dem sie stecken, selbst erkennen. Jetzt kann der Kunde einfach einstoepseln. Nix Jumper.

Noe. Mal eben in einem der letzten Designs nachgesehen. Etwa 50 Devices am SPI dran, fluppt wunderbar. Einige derer sind Speicher und man kann in jeden Romane schreiben. Mit den 400kHz eines I2C muessten wir eine Meldung mit Eieruhr ins Display bringen "Now would be a good time to make a fresh pot of coffee. Come back later." Wir roedeln das mit 4MHz ab und koennten sogar noch einige Schippen drauflegen.

Am Thu, 02 Aug 2007 11:06:39 -0700 schrieb Joerg:

Chuck Norris hat unendlich weit gezählt. Zweimal.

... meinte meine Tochter gerade.

Lutz

Hallo Lutz,

Der macht noch viel mehr. Hier ist ein kurzer Auszug:

Leider sind seine Filme uns zu brutal, und meine Frau mag so etwas nicht. Aber sonst scheint er, soweit das wenige, was ich gesehen habe, recht vernuenftige Ansichten zu haben.

Am Thu, 02 Aug 2007 13:26:06 -0700 schrieb Joerg:

Ich glaube die kennt die Filme auch nicht, nur die Sprüche.

Lutz

Die Bruce Schneier Facts

| Bruce Schneier can straighten out an elliptic curve with nothing but | his teeth

Gruß Henning