Hallo Leute, ich stehe vor einem Problem. Ich muss einen, nennen wir es mal Bitstream einlesen/ausgeben, der keine feste Baudrate hat, dafür aber einen Takt mit liefert. Die Geschwindigkeit des Streams liegt irgendwo variabel zw. 500k - 2MBits/s und kommen mit Start/Stopbit und 8Bit Datenlänge daher. Also weder die Geschwindigkeit noch die eigentlichen Daten machen mir sorge. Aber ich frage mich (da ich noch nichts entsprechendes gefunden habe) ob ein UART/USART eines STM32`s das kann, also Daten syncron zu einem externen Takt einlesen oder gar senden? Sonst muss ich doch wohl oder übel einen kleinen FPGA vorschalten, was ich mir gerne gespart hätte...
Ach so, no etwas vergessen. Wenn ich Daten Sende, bin ich der Treiber für den Takt Umgekehrt: Wenn ich Empfange natürlich der Empfänger für den Takt. Es gibt somit 4 Verbindungen. TX, TXClock, RX, RXClock
Hört sich für mich nach SPI an. Einmal "Receive Only Slave" und ein anderer hat mehrere Möglichkeiten, auch USART.
Man kann SPI als Slave betreiben, dann kommt der Takt auch von außen.
Falk B. schrieb: > Man kann SPI als Slave betreiben, dann kommt der Takt auch von außen. pegel schrieb: > Hört sich für mich nach SPI an. Okay, dan bräuchte ich aber jeweils 2 SPI Ports, einem zu senden mit ausgehendem Takt und einen weiteren zum empfangen mit eingehendem Takt, oder?
Es macht eine synchrone serielle Datenübertragung eigentlich erst aus das die Serialisierung einen Takt mitliefert, bzw. dieser bei der Parallelisierung benötigt wird, daswegen heißt das entsprechende Mopped dann auch USART weil er synchrone Übertragungsmodi beherrscht. Schau mal ins Reference Manual unter USART, ich habe gerade Besucht gekommen und muß erst mal weg.. Gruß, Holm
SPI ausgeben lässt sich, sofern keine besonderen Anforderungen an die Datenrate gestellt werden, auch leicht per "bit-banging", d.h. Pingewackel an I/O-Leitungen. Das ist harmlos, dafür brauchst Du keine dedizierte SPI-Hardware. (Es sei denn, Dein SPI-Takt soll im MHz-Bereich liegen)
Öhm zum Thema SPI noch eine Frage... Funktioniert das den hardwareseitig zu empfangen/Slave ohne einen aktive Beschaltung von außen des CS (Chip Select)?
Frickel schrieb: > Öhm zum Thema SPI noch eine Frage... > Funktioniert das den hardwareseitig zu empfangen/Slave ohne einen aktive > Beschaltung von außen des CS (Chip Select)? Kommt auf deinen uC an. Kann sein, muß nicht. GGf. muss man tricksen.
SPI und synchrone serielle Übertragung sind normalerweise 2 Paar Schuhe und eine SPI kommt mit Start- und Stoppbits normalerweise nicht zurecht. Im STM32 Reference Manual Punkt 27.3.2: "When the Transmit enable bit (TE) is set, the data in the transmit shift register is output on the TX pin and the corresponding clock pulses are output on the CK pin." Soviel zum Sendetakt. Punkt 27.3.9 beschreibt den synchronous Mode der USART und darin wird angemerkt das der CK Output nur beim Senden funktioniert..und somit die USART eigentlich total kaputt konstruiert ist: "The USART supports master mode only, it cannot receive or send data related to an input clock (CK is always an output). ..jede Z80 SIO kann das besser... Das muß nicht bei allen Cortex-M3 oder M4 so sein, die USART ist Herstellerspezifisch, die von STMs ist in der Hinsicht aber kaputt. Gruß, Holm
Holm T. schrieb: > SPI und synchrone serielle Übertragung sind normalerweise 2 Paar Schuhe > und eine SPI kommt mit Start- und Stoppbits normalerweise nicht zurecht. Welche synchrone serielle Übertragung nutzt Start- und Stopbits?
Rufus Τ. F. schrieb: > Welche synchrone serielle Übertragung nutzt Start- und Stopbits? Das frage ich mich auch. Frickel schrieb: > Die Geschwindigkeit des Streams liegt irgendwo variabel zw. 500k - > 2MBits/s und kommen mit Start/Stopbit und 8Bit Datenlänge daher. Vielleicht ist das mit den Start/Stopbits ja eine Falschinformation.
pegel schrieb: > Hört sich für mich nach SPI an. SPI mit Start- und Stopbit ist mir noch nie begegnet.
Rufus Τ. F. schrieb: > Welche synchrone serielle Übertragung nutzt Start- und Stopbits? Man kann etliche USART so programmieren. Vorteil ist hier dass man sich den Chip Select Pin einspart. Den braucht man bei SPI um den Bitzähler im Schieberegister zuverlässig auf Null zurücksetzen zu können (Clock Spike beim Einschalten etc).
Rufus Τ. F. schrieb: > Holm T. schrieb: >> SPI und synchrone serielle Übertragung sind normalerweise 2 Paar Schuhe >> und eine SPI kommt mit Start- und Stoppbits normalerweise nicht zurecht. > > Welche synchrone serielle Übertragung nutzt Start- und Stopbits? Keine mir bekannte, frag aber mal den TO der das erwähnte.Seltsam, ständig soll ich Sachen erklären, die Andere behaupten.. Gruß, Holm
Frank M. schrieb: > Rufus Τ. F. schrieb: >> Welche synchrone serielle Übertragung nutzt Start- und Stopbits? > > Das frage ich mich auch. Nicht jede synchrone serielle ist SPI. > Well, there are differences – important ones. The first difference between a > USART and a UART is the way in which the serial data may be clocked. A UART > generates its data clock internally to the microcontroller and synchronizes > that clock with the data stream by using the start bit transition. There is > no incoming clock signal that is associated with the data, so in order to > properly receive the data stream the receiver needs to know ahead of time > what the baud rate should be. > A USART, on the other hand, can be set up to run in synchronous mode. In > this mode the sending peripheral will generate a clock that the receiving > peripheral can recover from the data stream without knowing the baud rate > ahead of time. Alternatively, the link will use a completely separate line > to carry the clock signal. The use of the external clock allows the data > rate of the USART to be much higher than that of a standard UART, reaching > up to rates of 4 Mbps. Holm T. schrieb: > ..jede Z80 SIO kann das besser... So ist es MfG Klaus
Rufus Τ. F. schrieb: > Welche synchrone serielle Übertragung nutzt Start- und Stopbits? Was ist ein synchrones startbit?
W.A. schrieb: > A. S. schrieb: >> Was ist ein synchrones startbit? > > Wie kommst du auf so ein schräges Pferd? ..Versuch zu stänkern, nix weiter. Gruß, Holm
W.A. schrieb: > A. S. schrieb: >> Was ist ein synchrones startbit? > > Wie kommst du auf so ein schräges Pferd? Frickel schrieb: > Ich muss einen ... Bitstream einlesen/ausgeben, der > ... einen Takt mit liefert. Die > Geschwindigkeit des Streams liegt irgendwo variabel zw. 500k - 2MBits/s > und kommen mit Start/Stopbit und 8Bit Datenlänge daher.
Holm T. schrieb: > ..Versuch zu stänkern, nix weiter. Was soll das denn jetzt Alle (auch Du) überlegen, ob es eine synchrone Übertragung mit Start/Stopp überhaupt gibt, ... Ich wüsste nicht, was das überhaupt sein könnte. Ich kann mir keine sinnvolle Funktion oder Signalverlauf vorstellen.
Mit einem STM32Fxxx kann man einen SPI-Kanal auf 10 Nutzbits einstellen und diese bei der Auswertung von unnötigen Bits befreien. Was ist denn die Gegenseite, die das Format vorgibt?
Wie wäre es einen pin change interrupt auf den takt pin zu geben und beim auslösen dessen sich den Zustand von dem Datenpin anzuschauen?
Chris K. schrieb: > Wie wäre es einen pin change interrupt auf den takt pin zu geben Wie geht das denn? Bei 2 MHz Takt ist eine Software-Lösung nicht mehr angesagt.
A. S. schrieb: > Alle (auch Du) überlegen, ob es eine synchrone Übertragung mit > Start/Stopp überhaupt gibt Nicht wirklich, was der TO beschreibt, ist eine asynchrone Übertragung mit externem Takt (der natürlich schwanken kann, das ist dem UART ja egal). Aber wahrscheinlich ist das einfach nur falsch und daher alle Antworten für die Katz. Georg
georg schrieb: > A. S. schrieb: >> Alle (auch Du) überlegen, ob es eine synchrone Übertragung mit >> Start/Stopp überhaupt gibt > > Nicht wirklich, was der TO beschreibt, ist eine asynchrone Übertragung > mit externem Takt (der natürlich schwanken kann, das ist dem UART ja > egal). > > Aber wahrscheinlich ist das einfach nur falsch und daher alle Antworten > für die Katz. > > Georg Weiß nicht. Ich vermute einen freilaufenden RC-Oszillator in mehreren abgesetzten Controllern deren Daten verarbeitet werden sollen. Es ist richtig, es ist ein asynchrones Protokoll bei dem scheinbar Niemand für die Baudrate garantiert. Ich hatte als Auftragsarbeit auch mal eine Geschichte auf einem PIC16 zu programmieren, bei der wahrscheinlich unsinniger Weise im Pflichtenheft stand das das Teil eine Baudrate zwischen 1200 und 19200 Baud zu erkennen und sich darauf einzurichten hätte... Ich habe das Startbit ausgemessen und einen Timer entsprechend programmiert das ich jeweils in Bitmitte abtaste..hat funktioniert, war aber eben sehr wahrscheinlich Unsinn.. Von festen Baudraten stand da nichts.. Der externe Takt hier würde das vereinfachen, Unsinn bleibt es aber trotzdem und die STM32 USART bleibt trotzdem kaputt implementiert. Gruß, Holm
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.