Hallo zusammen, ich will/muss etwas ähnliches wie einen SPI-Slave implementieren. Ich würde mich dazu gerne erst einmal auf der Theorieseite ertüchtigen. Kann jemand dazu Lesestoff empfehlen? Viele Grüße W.T.
Walter T. schrieb: > ich will/muss etwas ähnliches wie einen SPI-Slave implementieren. Dann nimm Literatur die sich mit etwas ähnlichem wie einen SPI-Slave befasst. Durch die "Ähnlichkeit" ist leider keine genauere Aussage möglich.
Hättest Du denn Fachliteratur parat, in denen genau ein echter SPI und genau ein echter RS232 softwareseitig abgetastet erklärt werden?
Walter T. schrieb: > ich will/muss etwas ähnliches wie einen SPI-Slave implementieren. Gehört das zu deinem anderen Fred? Beitrag "Gesucht: Digitale Meßuhr" Dafür gibt es einige Lösungen im Netz. Such mal nach "Digital Messschieber auslesen"
Thomas F. schrieb: > Gehört das zu deinem anderen Fred? Ja, gehört es - aber: ich suche keine Lösung des konkreten Problems. Ich stehe bei diesem Mini-Projekt unter keinerlei Zeitdruck und würde das als Gelegenheit nutzen wollen, mich mal mit der Materie zu beschäftigen. Insbesondere hat mich schon länger interessiert, wie bei einer äquidistanten Abtastung die Taktrückgewinnung bei einem UART funktioniert.
Moin, Guck' dir halt die entsprechenden Projekte auf opencores.org an. Gruss WK
Walter T. schrieb: > Ich > würde mich dazu gerne erst einmal auf der Theorieseite ertüchtigen. Was gibt es da groß zu theoretisieren, schau z.B. einfach ins Datenblatt eines ATmega, Abschnitt SPI. SPI-Slave mit nem MC zu Fuß zu machen, hängt sehr vom SPI-Takt des Masters ab. Voraussetzung ist ein MC mit Priorisierung, dann kann man dem Flankeninterrupt die höchste Priorität geben, d.h. andere Interrupts zerstören nicht das Timing.
Walter T. schrieb: > Kann jemand dazu Lesestoff empfehlen? https://de.wikipedia.org/wiki/Serial_Peripheral_Interface Walter T. schrieb: > Insbesondere hat mich schon länger interessiert, wie bei einer > äquidistanten Abtastung die Taktrückgewinnung bei einem UART > funktioniert. Das hat jetzt aber nichts mit SPI zu tun
Walter T. schrieb: > Hättest Du denn Fachliteratur parat, in denen genau ein echter SPI > und > genau ein echter RS232 softwareseitig abgetastet erklärt werden? Einen "echten" SPI gibts eigentlich nicht. IMHO gibt es für ein Schieberegister, und mehr ist SPI eigentlich nicht, keinen geschriebenen Standard, nur das Datenblatt des jeweiligen Chips. Ein wichtiger Unterschied ist, daß RS232 asynchron und SPI synchron ist. Es macht daher keinen Sinn, beide auf ähnliche Weise erklären zu wollen. So wird bei SPI, einem Schieberegister, abgetastet, wenn das Clocksignal seine Polarität wechselt (egal wann). Bei RS232 gibt es eine fest vereinbarte Zeitbeziehung zwischen Sender und Empfänger. MfG Klaus
Klaus schrieb: > Es macht daher keinen Sinn, beide auf ähnliche Weise erklären zu wollen. Das erwartet auch keiner. Ich gehe aber mal davon aus, dass sich trotzdem beide im gleichen Buch oder Skript "Grundlagen von Bussystemen" oder so wiederfinden.
:
Bearbeitet durch User
Moin, Walter T. schrieb: > Ich gehe aber mal davon aus, dass sich > trotzdem beide im gleichen Buch oder Skript "Grundlagen von Bussystemen" > oder so wiederfinden. Die Hoffnung stirbt zuletzt... :-) Gruss WK
Walter T. schrieb: > Ich gehe aber mal davon aus, dass sich > trotzdem beide im gleichen Buch oder Skript "Grundlagen von Bussystemen" > oder so wiederfinden. In beiden Fällen handelt es sich nicht um einen Bus im eigentlichen Sinne. SPI und UART sind so trivial, dass ich mir nicht vorstellen kann, dass jemand über sowas ein Buch schreibt. Ich hab dir zu SPI einen Wikipedia-Artikel verlinkt. Hast du den gelesen? Wenn ja, hast du dann noch offene Fragen?
Walter T. schrieb: > Insbesondere hat mich schon länger interessiert, wie bei einer > äquidistanten Abtastung die Taktrückgewinnung bei einem UART funktioniert. Du musst einfach die "Äquidistanzen" hinreichend klein machen und das Signal "hinreichend" schnell abtasten. Normalerweise macht diese Überabtastung (weil sie simpel ist und schnell gehen muss) die Hardware... Klaus schrieb: > Einen "echten" SPI gibts eigentlich nicht. IMHO gibt es für ein > Schieberegister, und mehr ist SPI eigentlich nicht, keinen geschriebenen > Standard, nur das Datenblatt des jeweiligen Chips. Das englische Wiki beschreibt es ganz gut:
1 | The SPI bus is a de facto standard. However, the lack of a formal standard |
2 | is reflected in a wide variety of protocol options. |
https://en.wikipedia.org/wiki/Serial_Peripheral_Interface Schlumpf schrieb: > SPI und UART sind so trivial Du kennst die Dinger aus der (FPGA-)Hardware-Sicht. Du kannst dir nicht vorstellen, wie umständlich sich das manch einer vorstellt... ;-) Wenn man die Hardwarebetrachtung des SPI wie z.B. im Beitrag "Re: Erfahrung mit SPI Slave und Spartan 6 FPGA?" mal abgeschlossen hat, dann kann man den SPI natürlich auch einfach in Software gießen, wenn(!!!) der µC und die drauf laufende Software schnell genug ist.
Lothar M. schrieb: > Du kennst die Dinger aus der (FPGA-)Hardware-Sicht. Du kannst dir nicht > vorstellen, wie umständlich sich das manch einer vorstellt... ;-) Das könnte natürlich auch der Fall sein ;-) Mir kommt es auch so vor, als seien für den TO Begriffe wie SPI, UART, Abtastung, Takt(Rückgewinnung) extrem nebulöse Dinge. Und er hofft, jetzt ein Buch zu finden, wo das alles kompakt erklärt wird. Da ich nicht glaube, dass es EIN Buch gibt, das genau seine Fragen beantwortet, wär es vielleicht sinnvoll, wenn er mal etwas bekommt, womit er anfangen und dann ggf konkretere Fragen stellen kann. Daher auch meine Frage, ob er den Wiki Artikel gelesen hat und noch konkrete Fragen hat.
Lothar M. schrieb: > Du musst einfach die "Äquidistanzen" hinreichend klein machen und das > Signal "hinreichend" schnell abtasten. Das ist vom Verständnis der einfache Teil. Danach muss ich aus den Stützstellen die Nulldurchgänge gewinnen. Wenn ich n Abtastschritte pro Sekunde schaffe, und m davon zwischenspeichern kann, entsteht wohl eine Art binäres FIR-Filter m-ter Ordnung. Dann muss ich die Samplerate so dezimieren, dass genau der ursprüngliche Bit-Takt herauskommt. Das ist vermutlich alles keine Geheimwissenschaft - aber ich tue mich gerade schwer, mir das vorzustellen.
Moin, Walter T. schrieb: > Danach muss ich aus den Stützstellen die Nulldurchgänge gewinnen. Wenn > ich n Abtastschritte pro Sekunde schaffe, und m davon zwischenspeichern > kann, entsteht wohl eine Art binäres FIR-Filter m-ter Ordnung. Dann muss > ich die Samplerate so dezimieren, dass genau der ursprüngliche Bit-Takt > herauskommt. > > Das ist vermutlich alles keine Geheimwissenschaft - aber ich tue mich > gerade schwer, mir das vorzustellen. Nein, nicht bei UART oder SPI. Bei SPI tut sich immer nur was bei der Flanke des Clk Signals. Bei UART wartest du auf die (je nach pegel steigende oder) fallende Flanke des RxD und mutmasst, dass da jetzt der Beginn des Startbits ist. Also tastest du eine halbe Bitbreite spaeter nochmal ab und guckst, ob das immer noch Startbit ist. Danach tastest du jeweils nach einer Bitlaenge ab, bis das Byte und das/die Stoppbits durch sind. Das ist die Primitivversion. In der Standardversion wird ueblicherweise nicht nur genau in der Mitte des jeweiligen Bits abgetastet sondern noch 1/8 bitbreite vorher und nachher. Aus den 3 Werten wird dann eine Mehrheitsentscheidung gewonnen, die ist dann das empfangene Bit. Gruss WK
Dergute W. schrieb: > Nein, nicht bei UART oder SPI. Bei SPI tut sich immer nur was bei der > Flanke des Clk Signals. Bei UART wartest du auf die (je nach pegel > steigende oder) fallende Flanke des RxD und mutmasst, dass da jetzt der > Beginn des Startbits ist. Also tastest du eine halbe Bitbreite spaeter > nochmal ab und guckst, ob das immer noch Startbit ist. Danach tastest du > jeweils nach einer Bitlaenge ab, bis das Byte und das/die Stoppbits > durch sind. > Das ist die Primitivversion. Du warst schneller, deswegen nur noch eins: RS232 wurde für Fernschreiber (Teletype) erfunden. Die waren rein (elektro)mechanisch. MfG Klaus
Dergute W. schrieb: > In der Standardversion wird Okay...das ist die Hardware-Version. Nicht besonders kompliziert, aber ich muss die Bitrate der Quelle genau genug kennen. Bei einer Software-Abtastung müsste sich doch -hinreichende Überabtastung und ausreichend häufige Flankenwechsel vorausgesetzt- die Bitrate aus dem Signal selbst rekonstruieren lassen.
Bei SPI habe ich das Prinzip verstanden: Die Pegelwechsel für das Nutzsignal sind hinreichend weit vom Pegelwechsel des Taktsignals, dass weder ein Prellen des Taktsignals noch des Nutzsignals ein fehlerhaftes Bit entstehen kann.
Walter T. schrieb: > Danach muss ich aus den Stützstellen die Nulldurchgänge gewinnen. Und was soll daran ein Problem sein? > Wenn > ich n Abtastschritte pro Sekunde schaffe, und m davon zwischenspeichern > kann Warum solltest du abtasten, aber nicht abspeichern? > entsteht wohl eine Art binäres FIR-Filter m-ter Ordnung. Dann muss > ich die Samplerate so dezimieren, dass genau der ursprüngliche Bit-Takt > herauskommt. Ähmm. Nein. An der Samplerate wird genau gar nichts geändert. Und überhaupt denkst du viel zu kompliziert. Der Software UART kennt die Datenrate seines Gegenübers bereits. Er macht eine Überabtastung mit der n-fachen Geschwindigkeit (n>=2, typisch 4) aus zwei Gründen: 1. um Störimpulse (Spikes) rauszufiltern 2. um den Phasenversatz zwischen seinem Takt und dem Takt des Senders zu bestimmen. Punkt 1 passiert ständig. Stell es dir wie eine Entprellung vor. Punkt 2 macht man normalerweise nur beim Startbit. Man bestimmt einfach den Zeitpunkt (bezogen auf den eigenen Takt) der fallenden Flanke des Startbits und tastet dann die folgenden Bits immer in der Mitte ab.
Walter T. schrieb: > Danach muss ich aus den Stützstellen die Nulldurchgänge gewinnen. Wenn > ich n Abtastschritte pro Sekunde schaffe, und m davon zwischenspeichern > kann, entsteht wohl eine Art binäres FIR-Filter m-ter Ordnung. Dann muss > ich die Samplerate so dezimieren, dass genau der ursprüngliche Bit-Takt > herauskommt. Quatsch, Du wartest einfach auf die SCK-Flanken und schiebst dann das Bit rein bzw. raus. Siehe Anhang.
Walter T. schrieb: > weder ein Prellen des Taktsignals noch des Nutzsignals ein fehlerhaftes > Bit entstehen kann. Ein prellendes Taktsignal macht die Übertragung kaput. Beim Takt zählt jede Flanke, solange sie nur langsamer kommt als die Hardware sie erkennen kann. Es ist einfach ein Schieberegister: eine Flanke ist ein Bit. Ob das nun Prellen war oder gewollt. MfG Klaus
Moin, Walter T. schrieb: > Okay...das ist die Hardware-Version. Nicht besonders kompliziert, aber > ich muss die Bitrate der Quelle genau genug kennen. Jepp. Daher wird die bei UART-Verbindungen auch mal gerne mitangegeben. Genauso wie die Anzahl der Datenbits und Stopbits. > Bei einer Software-Abtastung müsste sich doch -hinreichende > Überabtastung und ausreichend häufige Flankenwechsel vorausgesetzt- die > Bitrate aus dem Signal selbst rekonstruieren lassen. Auch das geht, aber grad' UART ist da etwas unguenstig (Du kannst ja auch mal 10000 Bytes 0xff oder 0x00 uebertragen wollen). Bei Schnittstellen wie ASI oder SDI kann man sowas mit Ueberabtastung, FIR und Taktrueckgewinnung wie's dir vorschwebt, machen. Aber eher auch nicht mehr in Software sondern in Flipflops und LUTs. Gruss WK
Ich habe keine Ahnung, warum hier jede Menge negative Bewertungen vergeben werden. Das Thema müßte doch in irgendeiner Grundvorlesung im Elektrotechnik-Studium behandelt werden. Vermute ich. Also müßte es dazu auch Lehrmaterial in irgendeiner Form geben. Das suche ich. Ich finde es zwar nett gemeint, dass ihr in diesem Thread versucht, mir das Thema anhand von Beispielen zu erklären - aber ich suche eigentlich keine Implmentierungs-Beispiele. Ich suche guten Lesestoff.
Walter T. schrieb: > Bei einer Software-Abtastung müsste sich doch -hinreichende > Überabtastung und ausreichend häufige Flankenwechsel vorausgesetzt- die > Bitrate aus dem Signal selbst rekonstruieren lassen. Das funktioniert eben bei einem Interface, das keine definierten Pegelwechsel durch Stuffbits (wie z.B. CAN oder Ethernet oder Sercos) hat, nur unzuverlässig. Dergute W. schrieb: > Auch das geht, aber grad' UART ist da etwas unguenstig (Du kannst ja > auch mal 10000 Bytes 0xff oder 0x00 uebertragen wollen). Naja, nach jeweils 8 Bits tut sich sicher mal was. entweder am Startbit oder am Stopbit... ;-) Klaus schrieb: > Walter T. schrieb: >> weder ein Prellen des Taktsignals noch des Nutzsignals ein fehlerhaftes >> Bit entstehen kann. > Ein prellendes Taktsignal macht die Übertragung kaput. Wenn ein SPI-SCLK "prellt", dann muss man diesen Fehler beheben, und nicht mit Software dran rumbasteln... Siehe die Betrachtungen im Beitrag "Re: Serienwiderstand bei Hochfrequenz" Peter D. schrieb: > Du wartest einfach auf die SCK-Flanken und schiebst dann das Bit rein > bzw. raus. Wobei man "warten" nicht allzu wörtlich nehmen sollte. Man kann da bei entsprechend schnellem SCLK (z.B. 5MHz statt 5kHz) eher wegen "zu langsam" Probleme bekommen. ;-) Axel S. schrieb: > Und überhaupt denkst du viel zu kompliziert. Sagte ich schon: wer abstrakt in Software denkt, der sieht das zu umständlich. Walter T. schrieb: > Ich suche guten Lesestoff. Was ist an den Links im englischen Wiki schlecht?
:
Bearbeitet durch Moderator
Walter T. schrieb: > aber ich suche eigentlich keine Implmentierungs-Beispiele. Ich suche > guten Lesestoff. Weder SPI noch UART wird, wenn es sich irgendwie vermeiden lässt, in Software "abgetastet". Das macht Hardware. Und wie die gestaltet ist, ist hinreichend bekannt und dokumentiert.
Moin, Lothar M. schrieb: >> Auch das geht, aber grad' UART ist da etwas unguenstig (Du kannst ja >> auch mal 10000 Bytes 0xff oder 0x00 uebertragen wollen). > Naja, nach jeweils 8 Bits tut sich sicher mal was. entweder am Startbit > oder am Stopbit... ;-) Stimmt. Bloedes Beispiel. Ich probiers nochmal: Bei UART 8,n,1 uebertrag' ich mal einen Haufen 0xaa - dann kann die Gegenseite zwar prima die Clk zurueckgewinnen, aber das Bytealignment wird schwierig rauszukriegen sein. Bei ASI oder SDI gibts da unabhaengig von den Nutzdaten extra Daten, um das rauszukriegen. Walter T. schrieb: > Das Thema müßte doch in irgendeiner Grundvorlesung im > Elektrotechnik-Studium behandelt werden. Vermute ich. Das glaube ich nicht, Tim. Ist viel zu praxisnah. Da wird eher behandelt, wie sich bei Ueberabtastung die Signalspektren verhalten, etc. Clockrecovery wird da hoechstens mal in einem Nebensatz erwaehnt. Gruss WK
Lothar M. schrieb: > Was ist an den Links im englischen Wiki schlecht? Wenn Du die englischsprachige Wikipedia meinst: Nichts. Bis auf das klassische Wikipedia-Problem ( https://xkcd.com/214/ ). (Das heißt auch nicht, dass ich die Wikipedia-Artikel nicht schon lange gelesen hätte.) Aber ich mag Bücher.
:
Bearbeitet durch User
Walter T. schrieb: > Das Thema müßte doch in irgendeiner Grundvorlesung im Elektrotechnik- > Studium behandelt werden. Vermute ich. Also müßte es dazu > auch Lehrmaterial in irgendeiner Form geben. Das suche ich. Netzmafia.de wurde ja schon genannt. Ansonsten scheinst mir, dass du hier einige Fragestellungen zusammen wirfst und es deswegen unübersichtlich wird. Ich versuche mal, die Sachen etwas aufzudröseln: Weder bei SPI noch bei asynchron serieller Übertragung (aka UART, RS-232 etc.) ist eine Takterkennung im Sinne einer Ermittlung der Dauer eines Übertragungsschritts vorgesehen. Bei SPI kommt der Takt auf der Clockleitung. Der Zeitpunkt der Datenübernahme durch den Slave kann die fallende oder die steigende Flanke sein. Welche es ist, hat der Entwickler festgelegt. Die Zeitabstände zwischen diesen Flanken müssen nicht immer gleich sein. (Clock-Stretching durch den Master ist nicht "verboten"!) Der SPI-Slave achtet also nur auf die Taktflanke und übernimmt dann den anstehenden Bitwert. Und das war es auch schon. Störungen, Prellen etc. versauen die Übertragung. (Kurzer Einschub: Es gibt natürlich auch komplexere synchron serielle Übertragungsverfahren, bei denen es es Sachen wie Taktrückgewinnung und Taktsynchronisation gibt. SPI gehört aber nicht dazu.) Bei asynchron serieller Übertragung haben Sender und Empfänger je einen eigenen "Taktgeber", die (innerhalb einer bestimmten Toleranz) gleich schnell laufen müssen. Die Einstellung erfolgt "im Vorhinein", also nicht erst bei Kommunikationsbeginn. Ebenso muss im Voraus vereinbart werden, wie viele Datenbits (exakt: Schritte) ein Zeichen hat. (Meistens 8, es gab/gibt aber auch Abweichungen.) Die Übertragungsstrecke hat in Ruhe einen vordefinierten Pegel, der konstant anliegt. (Historisch als "Mark" bezeichnet, bei TTL-Pegeln "H".) Ein Zeichen beginnt IMMER mit einem Startbit, das "L-Pegel" ("Space") hat. Ab diesem ersten Flankenwechsel wird die Schrittdauer gezählt. Der Empfänger tastet immer in der zeitlichen Mitte eines Übertragungsschritts (nach der Zählung seines Taktgebers) den Leitungspegel ab (mindestens ein Sample, oft drei). Das ist das jeweilige Datenbit. Nachdem die vorgegebene Zahl an Bits "durch ist", ist der Empfang des Zeichens abgeschlossen und der Empfänger geht in seinen Ausgangszustand. Damit beim nächsten Zeichen in jedem Fall ein Pegelwechel H->L erfolgt, wird nach dem letzten Bit des Zeichens vom Sender für eine Schrittdauer Ruhepegel ausgegeben (das Stopbit). Mehr ist es vom Prinzip der Sache nicht. Jetzt ist die Frage: Beruhte deine ursprüngliche Frage auf einem Missverständnis, oder möchtest du etwas Zusätzliches erreichen? Viele Grüße Stefan
Walter T. schrieb: > Das Thema müßte doch in irgendeiner Grundvorlesung im > Elektrotechnik-Studium behandelt werden. Du bringst die Themen etwas durcheinander und glaubst, dass es ein Buch gibt, welches diese Themen, die eigentlich nichts miteinander zu tun haben, beleuchtet. 1. Du willst wissen, wie SPI funktioniert --> Dazu bekommst du auf Wiki Informationen 2. Du willst wissen, wie das mit der Abtastung funktioniert --> Bei SPI und UART grundsätzlich anders. SPI bringt den Takt mit. Da wird einfach mit der Flanke des SCK der Wert von MOSI übernommen Wie es bei UART funktioniert, wurde erklärt (Datenrate ist bekannt, Warten auf Flanke, halbe Bitzeit warten und prüfen, ob es ein Startbit ist, dann n mal nach jeweils einer halben Bitzeit abtasten) Das ist keine rocket science. Auch keine höhere Mathematik mit Filtern etc. Du brauchst dazu kein Laplace- oder Z-Transformation. Das kannst du dir einfach mit nem Zeitstrahl auf ein Karopapier zeichnen. Mach es nicht komplizierter, als es ist ;-)
Dergute W. schrieb: > Bei UART 8,n,1 uebertrag' ich mal einen Haufen 0xaa - dann kann die > Gegenseite zwar prima die Clk zurueckgewinnen, aber das Bytealignment > wird schwierig rauszukriegen sein. Das Verfahren wurde für einige Modem-Typen angewandt. Es gab aber immer auch ein Verfahren zur Zeichen-Synchronisation. Entweder (UART) folgte dem Sync-String eine Pause von mehr als einer Zeichenlänge oder es wurde ein spezielles "Flag-Pattern" verwendet (HDLC und Verwandte). Viele Grüße Stefan
Schlumpf schrieb: > dann n mal nach jeweils einer halben Bitzeit abtasten Sorry, muss natürlich heißen: dann n mal nach jeweils EINER Bitzeit
Angehängte Dateien:
-
SLLA383.png
12 KB
Stefan W. schrieb: > Dergute W. schrieb: >> Bei UART 8,n,1 uebertrag' ich mal einen Haufen 0xaa - dann kann die >> Gegenseite zwar prima die Clk zurueckgewinnen, aber das Bytealignment >> wird schwierig rauszukriegen sein. > > Das Verfahren wurde für einige Modem-Typen angewandt. Es gab aber immer > auch ein Verfahren zur Zeichen-Synchronisation. Entweder (UART) folgte > dem Sync-String eine Pause von mehr als einer Zeichenlänge oder es wurde > ein spezielles "Flag-Pattern" verwendet (HDLC und Verwandte). Bei LIN kommt die Pause vorher. Und es gibt Mikrocontroller, deren UARTs LIN unterstützen und die Baudrate automatisch einstellen.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.