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.
Ich habe mir kein "kurioses Protokoll" selber ausgedacht, das ist vorgegeben und Quasi-Standard: http://www.newson.be/Files/TD_XY2-100_R0703.pdf
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.
Lupo schrieb: > Man müßte nur suchen, ob es andere Protokolle mit 5 Byte gibt. Quatsch. Ich konnte gerade nicht rechnen - 4*8=32 :-)
@ 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.
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.