Hallo!! Mir gibt das Thema Microwire und seine Kompatibilität zum SPI Mode 0 etwas Rätsel auf. Ich meinte das zwar bereits vor einer Weile verstanden zu haben, aber im Detail ist es nun doch wieder merkwürdig: SPI legt die Daten an der jeweils entgegengesetzten Flanke an als es liest. Das ist immer so. Egal welchen Mode ich konfiguriere. Auch in Mode 0: Lesen der Daten: steigende Flanke Anlegen der Daten: fallende Flanke Wenn Master und Slave das genauso machen ist alles ok. Problem: Laut National Application Note 452 1/92 macht Microwire aus Prozessorsicht folgendes: a.) SO will be shifted out upon the falling edges of SK (Clock) b.) SI will be shifted in upon the rising edges of SK passt also bestens zu SPI Mode 0. Nur wenn man sich jetzt ein beliebiges Microwire Slave Device anguckt (hier z.B. das serielle EEPROM AT93C86(A)), scheint es so, als ob dieses die Daten bei der steigenden Flanke sowohl ANLEGT als auch LIEST. Selbst in einem Orginal Datenblatt von National für das NM93C06A heisst es: "All commands, data in, and data out are shifted in/out on rising edge of SK clock" Ich frage mich: WARUM IST DAS SO? Und warum funktioniert das überhaupt? Kann eigentlich nur deshalb funktionieren, weil die alten Daten am Slave Device noch so lange anliegen, dass trotz gleichzeitigem Lesen durch den Master und Neusetzen durch den Slave noch korrekt gelesen werden kann. Atmel gibt bei den Microwire kompatiblem EEPROMs hier Maximalzeiten (!) von 250-500ns an. Was aber irgendwie auch keinen Sinn macht, denn es müsste ja eine Minimalzeit gewährleistet sein, innderhalb derer der Prozessor die Daten gelesen haben muss. Wo ist hier der Denkfehler? Viele Grüße, Klaus
Das muss so sein... Der Master ändert die Daten auf die fallende Flanke, der Slave liest diese mit der nächsten steigenden Flanke. Somit gibt es keine Probleme mit "setup and hold" time. Zeichen dir das doch mal auf! Cheers Ritchie
Kernighan wrote: > Das muss so sein... > > Der Master ändert die Daten auf die fallende Flanke, der Slave liest > diese mit der nächsten steigenden Flanke. Somit gibt es keine Probleme > mit "setup and hold" time. > > Zeichen dir das doch mal auf! seufz Ich weiss. Also ich zitiere nochmal aus National Application Note 452 1/92 "MICROWIRE Serial Interface": "All commands, data in, and data out are shifted in/out on rising edge of SK clock" Und demnach ist es eben NICHT so.
In der AN-452 Seite 2 lese ich: This means that: a) SO will be shifted out upon the falling edges of SK and will be stable during rising edges of SK. b) SI will be shifted in upon the rising edge of SK, and will be stable when executing, i.e., an XAS instruction. Die Datenblätter bzw ANs von National und Atmel über Micro Wire könnten besser sein... Was klappt dann bei dir nicht?
Kernighan wrote: > In der AN-452 Seite 2 lese ich: > > This means that: > a) SO will be shifted out upon the falling edges of SK and > will be stable during rising edges of SK. > b) SI will be shifted in upon the rising edge of SK, and will > be stable when executing, i.e., an XAS instruction. RICHTIG! Das bezieht sich aber auf den naja, nennen wir es in SPI Terminologie mal "Master". Ich hatte das ja in meiner ursprünglichen Mail auch schon zitiert. Aber auf Seite 6 findet sich dann (zum dritten mal :-) über die "MICROWIRE STANDARD FAMILY" am Beispiel des NM93C06A: "All commands, data in, and data out are shifted in/out on rising edge of SK clock" Und das stimmt auch mit den Timing Diagrammen aller Microwire slave devices überein, die ich exemplarisch mal angeguckt habe. Passt aber meinem Verständnis nach nicht zum "Master". > Die Datenblätter bzw ANs von National und Atmel über Micro Wire könnten > besser sein... > > Was klappt dann bei dir nicht? Funktioniert alles bestens, hängt aber meiner Meinung nach an ein paar ns. viele Grüße, Klaus
Also ich versuche es nochmal etwas abstrakter zu formulieren: Der zuverlässige Datenaustausch zwischen zwei "Stationen" bei SPI nach Motorola/Freescale basiert darauf, dass "setup" und "sample" auf jeder Seite in gleicher Weise entgegengesetzten Taktflanken zugeordnet ist. Welche das sind, ist egal. Es muss nur übereinstimmen. Dadurch ist das Timing völlig unkritisch. Mann hätte das gleiche unkritische Timing auch in einer zweiten Variante dadurch erreichen können, dass "setup" und "sample" auf jeder Seite der beteiligten "Stationen" zwar den gleichen Flanken zugeordnet ist, jede Station aber die jeweils andere Flanke verwendet. Das hätte allerdings den Nachteil, dass im Gegensatz zur ersten Variante sich die beiden Stationen nicht mehr symmetrisch bezüglich der verwendeten Taktflanken verhalten und man immer erst klären müsste, wer welche Flanke verwendet. (Was durch das ohnehin existierende Master/Slave Konzept natürlich auch kein Problem wäre) Schwierig wird es, wenn Stationen der ersten mit Stationen der zweiten Variante sprechen sollen. Das ist dann der Fall wenn ein SPI Master mit einem Microwire Slave spricht. Dann passt zwar das MOSI Signal zum Verhalten des Slaves (Master setup on falling edge, Slave sample on rising edge), aber MISO macht AUCH sample on rising edge, der Slave aber AUCH setup on rising edge. D.h. Clock-in und -out von Slave zu Master passiert an der gleichen Taktflanke. Man kann schon davon ausgehen, dass die Logik im Master den Zustand von MISO bereits eingelesen hat, wenn die Taktflanke kommt, oder dieses zumindest gleichzeitig macht. Und zum Beispiel das AT93C86A EEPROM lässt sich auch bis zu 250 ns Zeit um das neue Bit anzulegen. Deswegen wird es in der Praxis wohl auch meistens funktionieren. Sicher oder gar spezifiziert scheint mir das im Falle einer Hardware SPI Lösung aber nicht. Und ein wirklich korrektes Verhalten der SPI Schnittstelle gegenüber Microwire ist eigentlich nicht möglich, egal in welchem Mode. Daher erscheint mir die Aussage Microwire ist ein Subset von SPI etwas gewagt. Per Software kann man das SPI Interface (welches dann eigentlich eher ein Microwire Interface ist :-) natürlich microwire kompatibel implementieren. So dass entsprechend Variante zwei zwar die gleichen Flanken für "Sample" und "Setup" verwendet werden, aber die entgegengesetzte Flanke des Slave (also falling edge). Aber mit einem Hardware SPI Interface wie z.B. im ATmega16 realisiert ist das meiner Meinung nach nicht möglich. Viele Grüße, Klaus
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.