Forum: Mikrocontroller und Digitale Elektronik 10Mbit/s Datenempfang Flexrey


von yamamoto (Gast)


Lesenswert?

Hallo,
ich bin Student und bräuchte eure Erfahrung und Hilfe bei der 
realisierung eines Datenempfangs bei 10Mbit/s mit einem AVR atmega8.

Es geht darum, das zwei Flexray-Transceiver mit jeweils einem uC 
gesteuert mit einender kommunnizieren zu lassen. Einer soll senden, der 
andere empfangen.

Es soll einfach nur eine festgelegt Bitfolge gesendet und vom anderen 
empfangen und auf Korrektheit überprüft werden.

Das Problem besteht darin, dass die uC mit 10Mhz betrieben werden. Das 
heisst, dass pro Taktperieode ein Bit gespeicher werden soll. Die 
überprüfung soll erst nach Empfang geschehen.

Da das ganze sehr zeitkritisch ist will ich den Teil des Codes für das 
Senden und Empfangen in Assembler schreiben.
Das senden dürfte kein Problem darstellen. Der Code müsste dann so 
aussehen:
1
"out %[addrPORTD], %[txen_h_txd_h]"  "\n\t"
2
"out %[addrPORTD], %[txen_l_txd_l]"  "\n\t"
3
.......
Jede Instruktion braucht doch eine Taktperiode, oder seh ich das falsch?


Die schwierigere Sache ist der Empfang.
Meine Idee war zunächst einen externen Interrupt auszulösen sobald sich 
was auf der Datenleitung tut. Leider geht das nicht weil die beiden 
Interruptpins des uC schon belegt sind.

Ausserdem müsste man dann auch hier pro Taktperiode ein Bit speichern.
Die Bits könnte man in ein 8Bit Register schreiben. Hier weiss ich auch 
noch nicht wie man jeweils die Stelle 0 bis 7 mit dem jeweiligen Zustand 
des empfangenen Bits belegt.


Ich wäre echt dankbar für Vorschläge.
Schöne Grüße

von Gast (Gast)


Lesenswert?

Ohne näher nachzudenken/nachzufragen: ein ATmega8 ist mit dieser Aufgabe 
schlicht überfordert.

von Filth _. (filth)


Lesenswert?

Du wirst das mit nem Atmega nicht hinbekommen. Niedrigste zulässige 
Übertragungsgeschwindigkeit bei FlexRay sind 2.5mbit

von yamamoto (Gast)


Lesenswert?

Doch, das geht. Ich hab schon ein fertiges Programm, das im kHz-Bereich 
sendet. Das hab ich aber nicht geschrieben.
In dem Programm wird es mit timern realisiert. Allerdings weiss ich noch 
nicht wie.

von Schrotty (Gast)


Lesenswert?

10 MBit/s  mit einem Atmega? Wird wohl kaum möglich sein!
Wenn du den Atmega mit 10 MHz betreibst, dann hast du ja schon selbst 
erkannt, dass du pro Bit nur einen Takt zur Verfügung hast.
Und in diesem EINEN Takt willst du einen IRQ erkennen, in die ISR 
springen und dort dann einen Befehl ausführen???

Ganz abgesehen davon wird der alte Onkel Shannon ganz schön beleidigt 
mit dir sein, wenn es dir gelänge ein 10 Mbit Signal mit 10Mhz 
abzutasten.
Das gelingt dir nur, wenn du deinen µC-Takt und den Takt des Datenstroms 
in eine definierte Phasenlage bekommst UND beide Takte EXAKT gleich 
schnell sind.

Kurzum: Das wird so nix!

von Gast (Gast)


Lesenswert?

Na ja, wenn das schon alles im kHz-Bereich funktioniert, muß man den 
Mega8 ja nur mit 10GHz Takten. Das ist doch logisch!

von Schrotty (Gast)


Lesenswert?

@Gast:
Stimmt, warum bin ich da nicht selber drauf gekommen.. einen 10GHz-Quarz 
aus der Krabbelkise dran und ab geht die Post gg

von yamamoto (Gast)


Lesenswert?

@Schrotty
Hmm, jetzt wo du es sagst wird Onkel Shannon wirklich böse auf mich sein 
sollte ich das schaffen.
Leider haben wir das Abtasttheorem in Nachrichtentechnik noch nicht 
gehabt. Kommmt bald;)

von yamamoto (Gast)


Lesenswert?

Aber mir geht es eher darum, das er nur einmal ein IRQ erkennt und in 
die ISR springt.
Danach soll er nur noch z.B. 8 mal den Status des Pins, wo der RxD 
ankommt, in ein Register speichern.
Ausserdem sind die Interruptpins sowieso belegt, also wird das sowieso 
nichts.

Muss ich mir wohl was anderes einfallen lassen :(

von Schrotty (Gast)


Lesenswert?

>Leider haben wir das Abtasttheorem in Nachrichtentechnik noch nicht
>gehabt. Kommmt bald;)

Das ist natürlich dann blöd :-)

Also selbst wenn es dir gelänge, in deiner ISR mit jedem Prozessortakt 
einfach den Pegel, der am Port anliegt, in ein Register zu schieben 
wirst du dennoch ein Problem haben:
Der Takt, mit dem du Abtastest und schiebst, ist nicht in Phase mit dem 
Takt, mit dem deine Daten ankommen. Somit kannst du nicht gewährleisten, 
dass du immer genau dann schiebst, wenn deine Daten am Port stabil sind.
Es könnte also sein, dass du dummerweise genau dann schiebst, wenn sich 
am Port der Pegel ändert und dann geht´s in die Hose (Stichwort 
Setupzeit, Metastabilität...)
Dazu kommt noch, dass deine Quarz und der Flexraytakt zueinader driften, 
da sie nicht exakt identisch sind. Somit wirst du eine "Schwebung" 
bekommen, wo immer wieder mal ein paar Daten korrekt übernommen werden 
und dann wieder nur mist ankommt.

Vielleicht glaubst du es, wenn ihr mal das Abtasttheorem durchgenommen 
habt.

von yamamoto (Gast)


Lesenswert?

Danke für die gute Erklärung.
Mit 2,5Mbit/s müsste das dann doch eigentlich gut gehen, oder?
Kann kann man also pro Bit vier mal abtasten.

Aber irgendwie kann ich mir im Moment nicht ganz vorstellen wie ich 
diese vie abtastungen realisieren soll und daraus ein Bit bekommen.

von Gast (Gast)


Lesenswert?

>Aber irgendwie kann ich mir im Moment nicht ganz vorstellen wie ich
>diese vie abtastungen realisieren soll und daraus ein Bit bekommen.

WIR können uns das auch nicht vorstellen. Es geht nicht mit einem AVR!

Vielleicht hast Du ja einen Kumpel, der sich mit FPGAs o.ä. auskennt und 
auf diese Weise etwas erreichen kann.

von yamamoto (Gast)


Lesenswert?

An der Hardware kann ich leider nichts machen.

Ich dachte halt, dass man wenigsten mit vier takte pro Bit was machen 
könnte..

von Schrotty (Gast)


Angehängte Dateien:

Lesenswert?

Theoretisch kannst du mit 4 Takte/Bit was machen.. aber leider nur 
theoretisch.
Praktisch sieht das so aus:
So viel ich weiss, werden bei Flexray die Daten ohne seperaten Takt 
übertragen. Das heisst, dass du einfach einen Datenstrom erhältst, der 
so codiert ist, dass auf jeden Fall nach einer bestimmten Zeit mal eine 
Flanke kommt. Dies ist notwendig, damit du bei deiner ganzen Abtasterei 
immer wieder die Bitmitte finden kannst. Stell dir vor, es kämen 20 
Nullen, dann würde kein Datenwechsel mehr stattfinden, und somit würdest 
du irgendwann nicht mehr wissen, wo eigentlich ein Bit beginnt und 
aufhört. Daher bedient man sich eines Leitungscodes, der die Daten so 
umcodiert, dass immer wieder ein Signalwechsel erwzungen wird. (z.B. 
Manchester, 4B5B, 8B10B, Bit-Stuffing...)

Du musst also zuerst erkennen, dass eine Flanke vorliegt, indem du zwei 
aufeinanderfolgende Abtastpunkte auf ungleichheit vergleichst. Ist dies 
der Fall, dann weisst du, dass du gerade eine Flanke erfasst hast.und 
dann kannst du z.B. den nächsten Abtastpunkt als Datum übernehmen.
Dann musst du dir merken, dass dieses z.b. der Samplepunkt 2 war. Und da 
du weisst, dass du vier mal pro Bit abtastest, muss der nächste gültige 
Abtastpunkt bei 2 + 4= 6 sein.. der nächste bei 6 + 4 = 10, dann 10 + 4 
= 14.... UUUUUPS, haben wir jetzt nicht aus versehen Bit4 gar nicht 
erfasst????
Das Problem ist, dass nun dein Takt, mit dem du deine Samplepunkte 
zählst, wie ich auch schon beschrieben habe, zu deinem Flexraytakt 
driftet. Das heisst, irgendwann kannst du nicht einfach immer nur 4 
addieren, da du sonst irgendwann an eine Bitgrenenze stösst. Und genau 
aus diesem Grund werden im Datenstrom Flanken "erwzungen". Denn genau an 
diesen Flanken kannst du "nachsynchronisieren".

nachdem du z.B. zum Zeitpunkt 6 gesampelt hast, stellst du fest, dass 
bereits zwischen 7 und 8 ein Wechsel stattgefunden hat. also ist dein 
nächster Abtastpunkt der nächste "Gültige" (also der 9. und nicht der 
10., wie es sich automatisch ergeben hätten, wenn du einfach 
weitergezählt hättest).
Von diesem 9. Punkt addierst du dann immer 4 und samplest dort. so 
lange, bis du wieder eine Flanke erkennst. Dann wird wieder 
nachsynchronisiert.

Du musst also bei jedem Übernahmepunkt den nächsten Punkt berechnen und 
weiterhin musst du bei JEDEM Samplepunkt mit dem vorangegangenen 
Samplepunkt vergleichen, ob eine Flanke vorlag. Wenn ja, dann musst du 
deinen nächsten "Übernahmepunkt" neu berechnen.
Und das wird dir mit der dir gegebenen Hardware nicht gelingen!


Wenn sowas überhaupt gelingen soll, dann nur, indem du es schaffst, die 
Daten so schell es geht, einfach zu speichern und in Nachhinein dein 
komplettes Datenfeld systematisch zu analysieren und anhand der Einträge 
die Bits zu rekonstruieren. Die Methode wäre genau die gleiche, wie beim 
Samplen, nur eben "in aller Ruhe" mit dem fertig abgelegten Datenfeld.

Ich hoff, die Erklärung hat dir ein wenig auf die Sprünge geholfen und 
es wurde dir anschaulich, wo hier das Problem liegt..

von Schrotty (Gast)


Angehängte Dateien:

Lesenswert?

Mist, da ist mir doch in meinem Bild ein Fehler unterlaufen.. hier die 
korrigierte Version

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.