Hi,
ich möchte Datenpakete mit 20 Bit Länge seriell ausgeben. Dabei findet
jeweils am Beginn so eines Paketes eine Synchronisierung über einen
Sync-Impuls auf einer zweiten Leitung statt.
Im Prinzip also eine serielle Datenübertragung, nur dass sie 20 Bit lang
ist und keinerlei Start-/Stopp-/Paritätsbits von der Hardware gesetzt
werden sollen, sprich ich will das gesamte Paket selbst "in der Hand"
haben.
Meine Frage dazu: geht das mit irgend einem existierenden
Standardinterface? Oder muss ich mir zwei nackte Digitalausgänge selber
so programmieren, dass die das können?
Danke!
Krrkx schrieb:> Meine Frage dazu: geht das mit irgend einem existierenden> Standardinterface? Oder muss ich mir zwei nackte Digitalausgänge selber> so programmieren, dass die das können?
wenn man wissen würde auf welcher CPU oder µC das laufen soll, könnte
man eventuell weiter helfen.
@ Krrkx (Gast)
>ich möchte Datenpakete mit 20 Bit Länge seriell ausgeben. Dabei findet>jeweils am Beginn so eines Paketes eine Synchronisierung über einen>Sync-Impuls auf einer zweiten Leitung statt.>Im Prinzip also eine serielle Datenübertragung, nur dass sie 20 Bit lang>ist und keinerlei Start-/Stopp-/Paritätsbits von der Hardware gesetzt>werden sollen, sprich ich will das gesamte Paket selbst "in der Hand">haben.>Meine Frage dazu: geht das mit irgend einem existierenden>Standardinterface?
SPI, USI beim AVR.
Peter II schrieb:> wenn man wissen würde auf welcher CPU oder µC das laufen soll, könnte> man eventuell weiter helfen.
Board/CPU würde ich mir in Abhängigkeit von der Antwort aussuchen, es
müssten dann halt nur drei Interfaces dieses Typs drauf sein.
Krrkx schrieb:> ich möchte Datenpakete mit 20 Bit Länge seriell ausgeben. Dabei findet> jeweils am Beginn so eines Paketes eine Synchronisierung über einen> Sync-Impuls auf einer zweiten Leitung statt.
Warum musst du denn abseits aller Normen arbeiten? Ist das Protokoll so
vorgegeben?
Im Prinzip ist das eine synchrone Übertragung mit externer
Synchronisation, aber auch das passt nicht 100%ig. Ein USART im
Synchronmodus verlangt ein SYNC-Signal während der ganzen Übertragung,
und vor allem einen externen Takt. Asynchrone Übertragungen dagegen sind
auf etwa 10bit beschränkt, weil sie ohne übertragenen Takt arbeiten und
daher die Synchronisation bei längeren Worten wegläuft.
Gruss Reinhard
Krrkx schrieb:> ich möchte Datenpakete mit 20 Bit Länge seriell ausgeben.
Bevor man sich irgendein kurioses Protokoll selber ausdenkt, sollte man
erstmal prüfen, ob die konventionellen nicht ausreichen würden.
Krrkx schrieb:> Dabei findet> jeweils am Beginn so eines Paketes eine Synchronisierung über einen> Sync-Impuls auf einer zweiten Leitung statt.
Falsch. Laut den Unterlagen brauchst du 3 Leitungen (Daten, Takt, Sync),
nicht 2.
Gruss Reinhard
Krrkx schrieb:> ich möchte Datenpakete mit 20 Bit Länge seriell ausgeben. Dabei findet> jeweils am Beginn so eines Paketes eine Synchronisierung über einen> Sync-Impuls auf einer zweiten Leitung statt.
Das liest sich so, als gäbe es das vielleicht schon. IR-Fernbedienungen
arbeiten nach diesem Prinzip, z.B. hat das NEC-Protokoll nur 4 Byte im
Paket. Man müßte nur suchen, ob es andere Protokolle mit 5 Byte gibt.
@ Reinhard Kern (Firma: RK elektronik GmbH) (rk-elektronik)
>und vor allem einen externen Takt. Asynchrone Übertragungen dagegen sind>auf etwa 10bit beschränkt, weil sie ohne übertragenen Takt arbeiten und>daher die Synchronisation bei längeren Worten wegläuft.
Sag das mal den Millionen von Ethernetknoten, SDH Strecken und sonstigen
Protokollen ;-)
Krrkx schrieb:> http://www.newson.be/Files/TD_XY2-100_R0703.pdf
Wär ja auch Quatsch gewesen, das gleich zu sagen.
Laß die Leute ruhig erstmal rumraten.
Ist aber trotzdem sehr exotisch.
Welches Gerät benutzt sowas?
Da der 2MHz Takt ständig laufen soll, geht nur ein CPLD oder FPGA.
Falk Brunner schrieb:> Sag das mal den Millionen von Ethernetknoten, SDH Strecken und sonstigen> Protokollen ;-)
Du weisst natürlich wie immer alles besser, und dass alles überflüssig
ist was du nicht kennst - aber trotzdem ist hier ein Takt vorgesehen.
Natürlich völlig unsinnigerweise. Aber nach einem von dir definierten
Protokoll war nicht gefragt.
Gruss Reinhard
Das "Sync"-Signal ist hier wohl eher als eine Start-Stop-Kennung zu
interpretieren und nicht zur eigentlichen Synchronisierung auf
Bit-Ebene.
Diese erfolgt hier durch die synchrone Übertragung.
Daher kann hier das Datentelegramm beliebig lange sein.
Auf wieviel Bit eine asynchrone Übertragung beschränkt ist, hängt vom
Gangunterschied der Taktquellen von Sender und Empfänger zusammen.
Ist dieser gering, können auch mehr als 10 Bit vollkommen asynchron
übertragen werden.
Ethernet und co. sind nicht wirklich asynchron, da der Datenframe durch
seine Codierung eine Taktrückgewinnung im Empfänger ermöglicht. Daher
würde ich hier nicht von einer asynchronen Übertragung reden, auch wenn
keine explizite Taktleitung vorhanden ist.
Zum Thema des TO:
So wie ich das einschätze, handelt es sich um ein verkapptes
SPI-Protokoll.
Die Setup und Hold-Zeiten sind mit Mindestwerten versehen, was den
Schluss zulässt, dass man auch beliebig langsam werden kann. Daten
werden mit der Steigenden Flanke geschrieben und der fallenden gelesen.
Klingt alles nach SPI. Versuche doch einfach mal am uC per Bit-Banging
dieses Protokoll nachzubilden (wenn du der Master bist)
Peter Dannegger schrieb:> Da der 2MHz Takt ständig laufen soll, geht nur ein CPLD oder FPGA.
Das ist kein hinreichender Grund, USARTs die den Takt ausgeben gibt es
schon viele Jahrzehnte, z.B. den guten alten Z8530 SCC.
Es ginge aber auch mit einem kleinen, einfachen, aber schnellen
Microcontroller, der nix anderes tun muss.
Gruss Reinhard
@ Schlumpf (Gast)
>Das "Sync"-Signal ist hier wohl eher als eine Start-Stop-Kennung zu>interpretieren und nicht zur eigentlichen Synchronisierung auf>Bit-Ebene.
Synchronisierung auf Telegrammebene.
>Auf wieviel Bit eine asynchrone Übertragung beschränkt ist, hängt vom>Gangunterschied der Taktquellen von Sender und Empfänger zusammen.>Ist dieser gering, können auch mehr als 10 Bit vollkommen asynchron>übertragen werden.
Eben.
>Ethernet und co. sind nicht wirklich asynchron,
Doch, denn es gibt KEINE zusätzliche Taktleitung.
>da der Datenframe durch>seine Codierung eine Taktrückgewinnung im Empfänger ermöglicht.
Das muss JEDE Kodierung, so man sie irgendwann mal wieder empfangen
will.
> Daher>würde ich hier nicht von einer asynchronen Übertragung reden, auch wenn>keine explizite Taktleitung vorhanden ist.
Doch. Es ist asynchron.
>Zum Thema des TO:>So wie ich das einschätze, handelt es sich um ein verkapptes>SPI-Protokoll.
Es ist eines ser vielen selbstgestrickten Industrieprotokolle.
>Die Setup und Hold-Zeiten sind mit Mindestwerten versehen, was den>Schluss zulässt, dass man auch beliebig langsam werden kann.
Nö, dort steht was von kontinuierlich 100 ks/s
>Klingt alles nach SPI. Versuche doch einfach mal am uC per Bit-Banging>dieses Protokoll nachzubilden (wenn du der Master bist)
Kann man machen. Wenn man einen Mikrocontroller/AVR als Sender "opfert",
kann der das ewig und drei Tage tun, einfach ne kleine Endlosschleife
durchrattern. Ich würde lieber nen CPLD nehmen.
Falk Brunner schrieb:> Kann man machen. Wenn man einen Mikrocontroller/AVR als Sender "opfert",> kann der das ewig und drei Tage tun, einfach ne kleine Endlosschleife> durchrattern. Ich würde lieber nen CPLD nehmen.
Nö, leider nicht, da ich drei von diesen Signalen haben möchte - also
würde es schon ein etwas leistungskräftigeres Board benötigen.
Schön übrigens, dass meine Frage ein Grund für einen Kleinkrieg ist
:-(((
Peter Dannegger schrieb:> Da der 2MHz Takt ständig laufen soll, geht nur ein CPLD oder FPGA.
UART im SPI-Mode erlaubt es problemlos, einen kontinuierlichen 2MHz-Takt
auszugeben (bei z.B. 16MHz Systemtakt). Timer im Fast-PWM-Mode erlaubt
es problemlos, den dazu passenden Sync alle 20 Bit taktsynchron zur UART
auszugeben.
Bleibt das Einlesen des Statusbits: Pin-Change, auslesen und Reset in
Timer-ISR.
Die Grundlast des Systems ist natürlich recht hoch, aber noch längst
nicht in einem Bereich, wo's wirklich kritisch wird.
Keine Ahnung, wozu da ein FPGA nötig sein sollte.
Falk Brunner schrieb:> Doch, denn es gibt KEINE zusätzliche Taktleitung.
Die ist dann nicht nötig, wenn sich der Takt aus dem übertragenen Signal
zurückgewinnen läßt. Z.B:
> Der Manchester-Code ist ein Leitungscode, der bei der Kodierung das> Taktsignal erhält.
Damit ist einen Übertragung synchron ohne zusätzliche Taktleitung.
Falk Brunner schrieb:> Das muss JEDE Kodierung, so man sie irgendwann mal wieder empfangen> will.
Das ist ein Framesync, und hat mit dem Takt nichts zu tun. Es wird
sowohl bei synchroner als auch bei asynchroner Übertragung benötigt.
MfG Klaus
Klaus schrieb:>> Der Manchester-Code ist ein Leitungscode, der bei der Kodierung das>> Taktsignal erhält.>> Damit ist einen Übertragung synchron ohne zusätzliche Taktleitung.
Noe.
Synchron heisst Gleichlauf. Das ist bei Manchestercodierung nicht
gegeben.
Der aus dem kodierten Signal zurückgewonenen Takt ist nicht
gleichläufig mit dem Takt des Generators. Im Gegenteil! Manchester als
PSK basiert gerade darauf, dass der vermutete Takt nicht mit dem
tatsächlichen übereinstimmt.
Auch wenn sich der Takt am Start und Ende einer Übertragung gewinnen und
alle 2 Takte resynchronisieren lässt, ist dieser dazwischen nicht
synchron. Die Bitgrenzen müssen nicht durch eine Flanke gekennzeichnet
sein, sondern werden aus dem vermuteten Takt abgeleitet.
Klar ist es durch die ständige Resyncronisation alle 2 Takte deutlcih
unempfindlicher gegen Taktjitter. Er ist aber nicht synchron.
@ Klaus (Gast)
>> Doch, denn es gibt KEINE zusätzliche Taktleitung.>Die ist dann nicht nötig, wenn sich der Takt aus dem übertragenen Signal>zurückgewinnen läßt. Z.B:
Eben, darum ist es ASYMCHRON!
>> Der Manchester-Code ist ein Leitungscode, der bei der Kodierung das>> Taktsignal erhält.>Damit ist einen Übertragung synchron ohne zusätzliche Taktleitung.
Nix da, es ist ASYNCHRON! Was wäre denn deine Definition von ASYNCHRON?
Wenn man die Daten nicht wieder rückgewinnen kann?
>> Das muss JEDE Kodierung, so man sie irgendwann mal wieder empfangen>> will.>Das ist ein Framesync, und hat mit dem Takt nichts zu tun. Es wird>sowohl bei synchroner als auch bei asynchroner Übertragung benötigt.
Sicher, aber bei SYNCHRONER Übertragung wird auf Bitebene ein Takt
verwendet, auf Frame Ebene meist ein zusätzliches Framesignal. Bei
ASYNCHRONEN Übertragungen gibt es NUR das Datensignal, daraus muss, mit
mehr Aufwand als im synchronen Fall, Takt und Frame zurückgewonnen
werden. AKA CDR (clock & data recovery, in Kuba hat das noch ne andere
Bedeutung, Viva Fidel! ;-))
http://de.wikipedia.org/wiki/13._August#1901.E2.80.931950
Es gibt bei den neueren NXP uC (schau mal bei LPC4357 oder
LPC1857, oder auch LPC812) Features, die sich SGPIO bzw. SCT nennen.
Damit kann man an einen GPIO eine Art interne State-Maschine hängen.
Vielleicht kannst du es damit umsetzen?
Andere Möglichkeit: Es gab früher Bausteine, mit den man Bits
aus Zeitschlitzen raus holen konnte, ebenfalls mit einen Sync Signal.
Google doch mal nach (Siemens,Infineon) ESCC2/ESCC8.
Dort konnte man konfigurieren, dass man Bit 0 bis 19
(nach dem Sync Impuls) herausholt und in einen FIFO schiebt.
(z.B. die einzelnen Kanäle eines ISDN-Busses)
Ich weiß aber nicht, ob es diese Bausteine heute noch gibt.
