Hallo,
ich kommuniziere per SPI zwischen einem STM und einem Atmel. Der Atmel
ist hier der Master und würde laut Datenblatt einen SPI-Takt bis zu
66MHz schaffen. Die Daten werden bei steigender Flanke am clock
übernommen.
STM: STM32F105RC; core-clock = 72MHz
Atmel: AT32UC3A0512
www.atmel.com/Images/doc32058.pdf
core-clock = 66MHz
Nun ist es in meinem Fall so, dass meine Kommunikation nur bis ca. 20MHz
funktioniert. Bei höheren Frequenzen „empfängt“ der Atmel nur noch
falsche Werte. In die andere Richtung ist es allerdings so, dass der STM
(=slave) immer das richtige empfängt.
Ich konnte mal ein Screenshot vom Oszi machen. Hier legt der Slave den
Wert 0x34 bei einem Takt von 22MHz auf die MISO-Leitung. Der Atmel
glaubt in diesem Fall jedoch ein 0x1E erkenne zu müssen. So wie ich das
sehe, sollten die MISO-Werte aber zur richtigen Zeit anliegen und ich
verstehe gar nicht, wie der Atmel hier auf 0x1E kommt.
Hat jemand einen Tipp wie ich bei der Fehlersuche weiter vorgehen
sollte?
Zum Oszi: Es hat eine Auflösung von 500MHz bzw. 2,5GS/s
Deine Hilfslinien sind aber alle bei einem unterschiedlichen
Spannungspegel auf CLK eingezeichnet.
Wenn ich die roten Linien alle etwas nach links verschiebe komme ich auf
0x1E.
Blitzbirne schrieb:> Deine Hilfslinien sind aber alle bei einem unterschiedlichen> Spannungspegel auf CLK eingezeichnet.> Wenn ich die roten Linien alle etwas nach links verschiebe komme ich auf> 0x1E.
Hmmm... ich fand es auch schwierig die tatsächlich richtige Position der
Linien zu bestimmen, da ich ja nicht weiß wann der Master der Meinung
ist die Daten übernehmen zu müssen. Ich finde auch, dass die Flanken
recht unregelmäßig ausschauen.
Das mit dem nach links verschieben ist schon mal ein super Hinweis.
Danke schön (auch wenn ich noch nicht weiß was ich nun ändern könnte).
//pdca_enable(SPI1_PDCA_CHANNEL_TX); //already enabled at init
15
}
16
portEXIT_CRITICAL();
17
}
Ich stelle allerdings gerade (leider erst jetzt) fest, dass ich mit der
Funktion spiRWCam1() die Daten sogar bei 30MHz auslesen kann. Mein
Problem ist dann also nur dann, wenn ich per DMA auslesen möchte. (also
mit der Funktion: spiRBuffCam())
STM32 Reference: SPI Slave Frequency <= PCLK/2. Mehr als 36MHz sind also
sowieso nicht drin. Bei den SPIs am APB1 mit halbem PCLK <= 18MHz.
Wie sieht die Kabelei aus? Versorgungsspannung? SPI Pinmode vom STM32?
A. K. schrieb:> Massefeder an der Tastkopfspitze
Was es alles gibt... Hardware und Messtechnik sind leider nicht meine
Stärke. Habe auch ein wenig gebraucht um zu kapieren wo/wie die
Massefeder an den Tastkopf angeschlossen werden soll. Hier mal ein Bild,
falls sich jemand anderes mal die gleiche Frage stellen sollte:
http://images.vogel.de/vogelonline/bdb/464000/464042/25.jpg
Neue Messungen sind zur Zeit leider nicht möglich, da ich kein eigenes
Oszi besitze.
A. K. schrieb:> Mehr als 36MHz sind also sowieso nicht drin.
Ja, 36MHz wären mein Ziel.
Mittlerweile habe ich herausgefunden, dass schon ein delay von einem
einzigen Takt zwischen den einzelnen Bytes ausreicht um die Übertragung
mit 32MHz laufen zu lassen. Atmel bietet diese Möglichkeit netter weise
per Konfiguration der Schnittstelle an:
Das mit der Kabelei könnte vielleicht wirklich der Grund sein, warum ich
noch nicht ganz auf die 36MHz komme. Ich habe mal versucht den Aufbau
meiner beiden Platinen/MCU's auf einer Skizze darzustellen.
spi schrieb:> Nochmal das Bild im Anhang...
Bei solchen Signale kann man die Fehler gut verstehen. Grundsätzlich ist
SPI eine digitale Signalübertragung und so sollten die Signale dann auch
aussehen, bevor man erwarten kann, dass die Gegenstelle die richtig
empfangen kann. Entweder liegt das an der Messtechnik oder die Signale
sind tatsächlich so unsauber. Bevor die nicht ordentlich sind, ist da
ohne Signalregenerierung nicht mehr zu erwarten.
spi schrieb:> Zum Oszi: Es hat eine Auflösung von 500MHz bzw. 2,5GS/s
Was du da angibst, ist vermutlich die Analogbandbreite und die
Abtastfrequenz.
Hast du einen 1:10 Tastkopf verwendet?
Welche Impedanz und Länge hat dein Kabel?
Wie sehen Treiberimpedanz und Empfängerimpedanz/Leitungsabschluß aus?
spi schrieb:> Ich konnte mal ein Screenshot vom Oszi machen.
Da sieht es für mich so aus, wie wenn sich die Daten annähernd
gleichzeitig mit den steigenden Taktflanken, die an sich auch nur
rudimentär und nach Erklärung sichtbar sind! Das wäre dann aber der
falsche Zeitpunkt zur Abtastung. Besser wäre hier die fallende Flanke.
Verwendest du den falschen SPI Modus?
BTW: Wenn das Signal am uC-Pin wirklich so aussieht, dann gibt das nie
eine sichere Übertragung.
Hallo,
Bedenke auch, dass die Kabellaufzeit eine Rolle spielt. Bei 50MHz sind
deine Zeitreserven sehr gering (10ns): die Taktflanke muss zum ST hin
und die Datenflanke zum ATMEL zurück - bei 6ns/m geht das schon
theoretisch nur bis weniger als 1m.
Praktisch eher noch weniger, weil der ST auch noch Zeit braucht, seine
Daten zu setzen. Probleme können also schon früher auftreten, z.B. bei
20cm.
Schau dir mal die Setup und Holdzeiten im Datenblatt an und rechne dein
Timing mal durch - mit Kabellaufzeit.
Der ST hat dagegen nie ein Problem: der bekommt Takt und Daten
gleichzeitig.
Abhilfe: Frequenz runter, Kabel kürzer oder asynchrone Kommunikation.
spi schrieb:> Das mit der Kabelei könnte vielleicht wirklich der Grund sein,
Die Länge der Kabel ist extrem wichtig, wenn du sie nicht passend mit
Treiber versehen und abgeschlossen hast. Jenseitig einiger zig cm ist
das nötig und angesichts RJ45 gehe ich davon aus, dass du weit jenseits
davon liegst. Siehe Wellenwiderstand.
Auf die Laufzeitfrage wurde ja schon hingewiesen. Mögliche Lösung wären
2 SPI-Master. Einer für AVR32=>STM32 und einer andersrum, jeweils
unidirektional betrieben. Dann treten keine Laufzeiteffekte auf.
Blöderweise gibts beim STM32 wohl nur ein SPI mit 36MHz, die anderen nur
mit 18MHz.
Oder Ethernet.
> [c]/* _ SPI1 configuration
Sorry, ich meinte die GPIO Pinkonfiguration der SPI-Pins. Die
Grenzfrequenz der STM32 Pins hängt davon ab - und von der Höhe der
Versorgungsspannung. Daher die Frage.