Hallo liebe Forengemeinde,
ich möchte serielle asynchrone Daten mit 4MBit/s senden (Daten+CRC).
Diese müssten Manchester codiert werden und mit 8MBit/s den µC
verlassen.
Desweiteren soll das ganze auch rückwärts geschehen (simplex).
Asynchonen Manchestercode empfangen, decodieren, CRC check durchführen
und Daten verwenden.
Passt das ganze Vorhaben einigermaßen adäquat in einen STM32F407?
(Nebenbei soll noch eine Ethernetschnittstelle betrieben werden)
Ansonsten könnte ich mir auch vorstellen einen Zync zu verwenden, wenn
es mit dem µC zu eng wird.
Habt ihr diesbezüglich Erfahrungen/Ratschläge?
Beste Grüße
Hans
Wie oft willst Du die Daten senden? Bei durchgehend 8mbit/s ist der
STM32F4 wohl etwas überfordert, falls nicht andauernd Daten
gesendet/empfangen werden, sollte das so gehen:
Senden bekommst Du über DMA hin:
* DMA über Timer mit 16Mhz triggern
* und für jede Flanke (high->low und low->high) einen vorberechneten
Bitwert
aus einer Tabelle per DMA auf das GPIOx_BSRR ausgeben
Nachteil:
Du brauchst für jedes Bit 2 * 32Bit als AusgabePuffer für das
GPIOx_BSRR. Aber der STM32F4 hat ja etwas RAM.
Empfangen sollte über 2 Input-Capture Register, die per DMA eingelesen
werden, realsisierbar sein.
Gruß, Stefan
@ Stefan (Gast)
>Senden bekommst Du über DMA hin:>* DMA über Timer mit 16Mhz triggern>* und für jede Flanke (high->low und low->high) einen vorberechneten>Bitwert> aus einer Tabelle per DMA auf das GPIOx_BSRR ausgeben
Geht einfacher, mit SPI. DMA ist natürlich zusätzlich nett.
>Empfangen sollte über 2 Input-Capture Register, die per DMA eingelesen>werden, realsisierbar sein.
Ich würde lieber per Timer und DMA den Datenstrom einfach abtasten und
dann per CPU dekodieren. Wenn man es clever macht, könnte man sogar
einen dauerhaften Datenstrom empfangen und nebenbei noch andere Dinge
erledigen. Die DMA arbeitet dabei auf einen FIFO.
@ Stefan (Gast)
>Die Manchster-Ausgabe kannst Du auch mit einer SPI und einem externen>XOR-Gatter erreichen.
Wozu das Gatter? Das kann die CPU locker vorher berechnen, im
einfachsten und schnellsten Fall über eine Tabelle mit 256 16 Bit
Einträgen.
Ok, Du willst nur den SPI-Datenpin benutzen und zwar mit der doppelten
Bitrate. Geht auch, clever.
Die eigendliche Herausforderung dürfte das Empfangen sein. Und da kommt
es etwas darauf an, wieviel Daten der TS empfangen will.
Gruß, Stefan
Vielen Dank für die zahlreichen Antworten.
Das Senden über SPI finde ich eine sehr gute Idee, so werde ich das
denke ich auch machen.
Das Empfangen wird da sicherlich nicht ganz so einfach. Die zu
empfangenen Pakete sind 36Bit lang. Die Häufigkeit der Pakete werde ich
in Erfahrung bringen. Das Abtasten des Datenstreams ist halt nicht so
einfach. Der Takt ist bekannt, jedoch ist die Phasenlage unbekannt.
Könnte ich nicht im einfachsten Fall mit der ersten steigenden oder
fallenden Flanke einen Timer starten und dann den Datenstream auslesen?
Anschließend dekodieren und CRC-Checken. Ist die interne CRC-Check
Routine des STM 32F4 brauchbar?
Besten Dank...
@Hans (Gast)
>Das Empfangen wird da sicherlich nicht ganz so einfach.
Fast! Das machst du acuh mit SPI, nur halt mit höherer Datenrate.
8Mbit/s sollte man mindestens mit 32 MHz abtasten, besser 64 MHz. Schau
mal ob deine SPI so schnell arbeiten kann. Die DMA schafelt dazu die
Daten in den RAM.
> Die zu>empfangenen Pakete sind 36Bit lang.
Also praktisch nix.
> Die Häufigkeit der Pakete werde ich>in Erfahrung bringen.
36 Bit @ 8MHz = 4,5us. Selbst wenn die alle 100us kommen, schafft das
deine CPU locker. SOOO lange dauert die Dekodierung nicht.
> Das Abtasten des Datenstreams ist halt nicht so>einfach.
Doch, siehe oben. Wenn es deine SPI nicht schnell genug abtasten kann,
kann man auch einen Timer + DMA versuchen, der einfach einen
Eingangsport in den Speicher schreibt.
> Der Takt ist bekannt, jedoch ist die Phasenlage unbekannt.>Könnte ich nicht im einfachsten Fall mit der ersten steigenden oder>fallenden Flanke einen Timer starten und dann den Datenstream auslesen?
Vergiss es, nicht bei 8 Mbit/s. Abtasten heißt das Zauberwort. So machen
es alle. RS232, CAN, USB etc. Clock & Data Recovery.
>Anschließend dekodieren und CRC-Checken. Ist die interne CRC-Check>Routine des STM 32F4 brauchbar?
Kann sein, bei 36 Bit lohnt das aber kaum.
@ Hans (Gast)
>PS: Die Datenlänge die ich per SPI senden kann ist frei definierbar? Zu>senden sind ebenfalls 36Bit Pakete.
Niemand hindert dich, 36 Bit als 5x8 Bit zu senden. Die letzten 4 Bit
hängt man Dummydaten an. Beim Empfang ebenso.
Eine Sache hab ich bezüglich dem Einlesen über SPI noch nicht ganz
nachvollzogen.
Ich habe nur eine Leitung an der ich die Manchestercodierten Daten
empfange. Es ist keine SCLK oder SS Leitung vorhanden. Der Dateneingang
wird auf MISO gelegt und dann abgetastet. Wann weiß der SPI Controller
ab wann er abtasten soll. Erfolgt die Abtastung automatisch mit der
ersten Flanke mit dem eingestellten Takt und für die Dauer der gewählten
Datengröße?
Besten Dank...
@ Hans (Gast)
>Ich habe nur eine Leitung an der ich die Manchestercodierten Daten>empfange.
Reicht doch.
> Es ist keine SCLK oder SS Leitung vorhanden.
Brauchst du auch nicht.
> Der Dateneingang>wird auf MISO gelegt und dann abgetastet. Wann weiß der SPI Controller>ab wann er abtasten soll.
Er macht es einfach dauerhaft mit der eingestellten Bitrate. Dass dabei
weder SCK noch CS eine Rolle spielt, ist dem SPI-Modul egal. Es tastet
die Daten ab, schreibt sie ins Eingangsschieberegister und von dort
landen sie per DMA im RAM. Einkanal Logicanalyzer für Arme ;-)
Wenn die Daten mit 8Mbit/s empfangen werden und ich mit 32MHz Abtaste
erhalte ich vier Abtastwerte je Bit. Wenn die Nachrichtenbreite von
36Bit vierfach abgetastet wird, so erhalte ich 144Bit je SPI-Frame. Aber
wie stelle ich sicher, dass sich genau dort dann auch eine Nachricht von
Anfang bis Ende befindet, wenn ich dauerhaft einlese?
Ist es dann nicht einfacher ein 16Bit Schieberegister mit (SPI1) zu
füllen und auf 0x000F abzufragen (Siehe Anhang), das würde den Beginn
einer Nachricht kennzeichnen? Dann ein (SPI2) mit dem (SPI1) triggern um
den Payload auszulesen. Hat das Aussicht auf Erfolg oder übersehe ich
etwas? SPI3 würde ich dann zum senden benutzen.
@Hans (Gast)
>wie stelle ich sicher, dass sich genau dort dann auch eine Nachricht von>Anfang bis Ende befindet, wenn ich dauerhaft einlese?
Gar nicht. Du musst mehr Daten lesen und dann intelligent den Anfang
erkennen.
>Ist es dann nicht einfacher ein 16Bit Schieberegister mit (SPI1) zu>füllen und auf 0x000F abzufragen (Siehe Anhang),
Nein, das geht nicht. Denn dein SPI läuft nicht synchron zu deiner
Datenquelle.
> das würde den Beginn>einer Nachricht kennzeichnen? Dann ein (SPI2) mit dem (SPI1) triggern um>den Payload auszulesen. Hat das Aussicht auf Erfolg oder übersehe ich>etwas? SPI3 würde ich dann zum senden benutzen.
Ohjemine. Jetzt ist mir klar, wozu man 4 SPI Module in einem ARM braucht
8-0
SO NICHT! Es reicht EIN SPI-Modul.
Woran kannst du erkennen, ob ein Datenpaket geschickt wird? Passiert das
"zufällig" oder weiß man ungefähr, wann es gesendet wird? Denn in den
Pausen musst du auch Daten abtasdten und erkennen, ob nichts ankommt
oder eine echte Nachricht. Wenn auf dem Kanal zwischen den Nachrichten
dauerhaft LOW oder HIGH gesendet wird, kann man das in den abgetasteten
Daten als 0x00 oder 0xFF erkennen. Da es aber Manchesterkodiert ist,
könnte es auch sein, dass dauerhaft 0x55 oder 0xAA empfangen wird. Aber
auch das ist leicht erkennbar.
>>Ist es dann nicht einfacher ein 16Bit Schieberegister mit (SPI1) zu>>füllen und auf 0x000F abzufragen (Siehe Anhang),>Nein, das geht nicht. Denn dein SPI läuft nicht synchron zu deiner>Datenquelle.>>das würde den Beginn>>einer Nachricht kennzeichnen? Dann ein (SPI2) mit dem (SPI1) triggern um>>den Payload auszulesen. Hat das Aussicht auf Erfolg oder übersehe ich>>etwas? SPI3 würde ich dann zum senden benutzen.>Ohjemine. Jetzt ist mir klar, wozu man 4 SPI Module in einem ARM braucht>8-0>SO NICHT! Es reicht EIN SPI-Modul.
Ich habe deinen Ansatz verstanden dauerhaft abzutasten und dann den
Anfang einer Nachricht zu suchen und diese zu extrahieren.
Nochmal kurz zu meiner Idee:
Was spricht denn dagegen ein zweites SPI Modul zu verwenden? Das wäre
doch eher zum Vorteil, da ich die CPU weniger belasten würde. Mir ist
schon klar, dass die Daten asynchron sind, aber das macht doch keinen
Unterschied. In dem Anhang: Frame.png ist der Beginn einer Nachricht mit
einer einzigartigen Folge gekennzeichnet "0001". Diese Folge erfasse ich
doch in jedem Fall, da vier Abtastpunkte je Bit vorhanden sind um "000F"
zu erhalten. Auf diese Weise habe ich doch elegant den Beginn meiner
Nutzlast gefunden, ohne die CPU zu beanspruchen.
Beste Grüße
@ Hans (Gast)
>Was spricht denn dagegen ein zweites SPI Modul zu verwenden?
Es bringt keinerlei Vorteil.
> Das wäre>doch eher zum Vorteil, da ich die CPU weniger belasten würde.
Nein.
>Mir ist>schon klar, dass die Daten asynchron sind,
Wirklich?
>aber das macht doch keinen>Unterschied. In dem Anhang: Frame.png ist der Beginn einer Nachricht mit>einer einzigartigen Folge gekennzeichnet "0001". Diese Folge erfasse ich>doch in jedem Fall, da vier Abtastpunkte je Bit vorhanden sind um "000F">zu erhalten.
Aber die Grenzen des 1. Bytes sind NICHT synchron zu deiner Abtastung.
Du kannst als erstes 16 Bit Wort genausogut
0x00FA empfangen, weil das erste Nibble durch die beliebige Phasenlage
ins vorherige 16 Bit Wort gerutscht ist. Genauso wie
0x003C
Hier ist es eine Verschiebung um 2 Bit.
> Auf diese Weise habe ich doch elegant den Beginn meiner>Nutzlast gefunden, ohne die CPU zu beanspruchen.
Nö. Dazu musste eine Hardwarelogik exisiteren, welche immer nach 0x000F
sucht und dann "Hallo" ruft. Die gibt es aber in den SPI-Modulen nicht.
Falk Brunner schrieb:>>aber das macht doch keinen>>Unterschied. In dem Anhang: Frame.png ist der Beginn einer Nachricht mit>>einer einzigartigen Folge gekennzeichnet "0001". Diese Folge erfasse ich>>doch in jedem Fall, da vier Abtastpunkte je Bit vorhanden sind um "000F">>zu erhalten.>> Aber die Grenzen des 1. Bytes sind NICHT synchron zu deiner Abtastung.> Du kannst als erstes 16 Bit Wort genausogut>> 0x00FA empfangen, weil das erste Nibble durch die beliebige Phasenlage> ins vorherige 16 Bit Wort gerutscht ist. Genauso wie>> 0x003C>> Hier ist es eine Verschiebung um 2 Bit.
Die Idee ist nicht immer ein Byte einzulesen, sondern jedes Bit einzeln
und dann das Schieberegister zu beurteilen, oder funktioniert das bei
SPI nur Byteweise? Dann wäre mein Ansatz natürlich nicht sinnvoll.
Dann vielleicht über ein normales Schieberegister/Timer die Startsequenz
abtasten, dann SPI triggern für die Nutzdaten und anschließend nach der
Verarbeitung das Schieberegister/Timer wieder starten.
@ Hans (Gast)
>Die Idee ist nicht immer ein Byte einzulesen, sondern jedes Bit einzeln>und dann das Schieberegister zu beurteilen,
Bei 8 Mbit/s? Jaja ;-)
>oder funktioniert das bei>SPI nur Byteweise?
Das auch.
>Dann wäre mein Ansatz natürlich nicht sinnvoll.
Eben!
Ich greife mal deinen Vorschlag auf:
36Bit mit 4 Abtastwerten ergeben sich 144Bit je Nachricht.
Die 144Bit, die dann im Speicher stehen müssen nach dem Startmuster
untersucht werden. Diese 144Bit müssen aus dem Speicher in einen
weiteren Speicher umkopiert werden, bevor die neuen 144Bit da sind. Mit
den vorhandenen 288Bit ließe sich dann eine Nachricht extrahieren.
@Hans (Gast)
>Wie wäre es den mit einem "CMOS 4094" den Start einer Nachricht>abzutasten?
Unsinn, ausserdem ist der viel zu langsam.
>36Bit mit 4 Abtastwerten ergeben sich 144Bit je Nachricht.>Die 144Bit, die dann im Speicher stehen müssen nach dem Startmuster>untersucht werden.
Ja.
>Diese 144Bit müssen aus dem Speicher in einen>weiteren Speicher umkopiert werden, bevor die neuen 144Bit da sind.
Ja.
> Mit>den vorhandenen 288Bit ließe sich dann eine Nachricht extrahieren.
???
Den Speicher macht man sinnvollerweise um einiges größer, wir reden hier
nur übe ein paar Dutzend Bytes. Dabei nutztem man 2 DMA Kanäle
abwechselnd, welche zyklisch ZWEI Speicher immer wieder voll schreiben.
Während der eine Speicher geschrieben wird, kann man den anderen
durchsuchen und ggf. dekodieren.
8 Mbit/s mit 4 Bit/Bit gesampelt gibt 4 MByte/s. Ich bezweifle, dass Du
es schaffst, Dich mit einem F4 kontinuierlich durch den Datenwust zu
wuehlen....
@ Uwe Bonnes (Gast)
>8 Mbit/s mit 4 Bit/Bit gesampelt gibt 4 MByte/s. Ich bezweifle, dass Du>es schaffst, Dich mit einem F4 kontinuierlich durch den Datenwust zu>wuehlen....
Der Mensch wächst an seinen Aufgaben. Immerhin ist es ein 32 Bit
Prozessor mit 168 MHz. Da geht schon was. Klar, ein kleiner CPLD, der
als Dekoder + UART läuft macht das locker, da reichen 32 MHz. Ist aber
zu einfach ;-)
Ich versuche grade per SPI zu senden, jedoch läuft da was nicht ganz
richtig. Irgendwie sehe ich nicht was falsch ist, siehe (Anhang). An PE7
ist das CS korrekt zu sehen und an PA5 ein merkwürdiges SCK. PA7 zeigt
jedoch keine Nachricht.
@ Hans (Gast)
>richtig. Irgendwie sehe ich nicht was falsch ist, siehe (Anhang). An PE7>ist das CS korrekt zu sehen und an PA5 ein merkwürdiges SCK. PA7 zeigt>jedoch keine Nachricht.
Deine Signale sehr ziemlich schlecht aus. Das kriegt man deutlich besser
hin. Dazu muss man u.a. einen 10:1 Taskopf benutzen und die Masse kurz
halten.
Auf deinem CS SIgnal gibt es ziemlich viel Übersprechen vom SCK, auch
ein Indiz für eine schlechte Masseanbindung.
Ein remap der SCK MOSI UND MISO funktioniert irgendwie nicht. Woran kann
das liegen? Ich messe den SLK trotz remap immer noch an PA5... Das darf
doch nicht sein, oder?
