Forum: Mikrocontroller und Digitale Elektronik Signalflanken bei Microwire


von Klaus W. (Firma: privat) (texmex)


Lesenswert?

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

von Kernighan (Gast)


Lesenswert?

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

von Klaus W. (Firma: privat) (texmex)


Lesenswert?

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.

von Kernighan (Gast)


Lesenswert?

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?

von Klaus W. (Firma: privat) (texmex)


Lesenswert?

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

von Klaus W. (Firma: privat) (texmex)


Lesenswert?

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
Noch kein Account? Hier anmelden.