Hallo Forum, ich habe folgendes Problem. Ich bekomme DMX Daten über eine UART mit 921.6k in einem speziellen Frame verpackt. Daraus muss ich dann ein gültiges DMX Signal, welches mit 250k gesendet wird, erzeugen. Ich habe den µC derzeit mit 16 MHz getaktet, was für das Eingangssignal ein Fehler von ca 8% ergibt, für das Ausgangs Signal aber 0%. Gibt es eine Möglichkeit beide Signale mit einem Quarz zu generieren, ohne zu hohe Fehlerquoten?! Syncronisieren sich DMX Geräte vielleicht an jedem Byte neu, wenn ich eine entsprechende Inter-Byte-Gap Zeit einfüge?! (So, dass ich den Fehler auf das DMX Signal abwälze?!) Ich würde mich dann für ein 14.7456MHz Quarz entscheiden und somit einen Fehler von 5% auf der DMX Leitung besitzen. Hat jemand eine bessere Idee, bzw. weiß jemand, ob mein Vorhaben überhaupt klappt? Was wäre die Alternative? Zwei µC?! Das Eingangssignal könnte ich auch auf 460.8k stellen, aber da ist der Fehler identisch hoch... :-(
Ich habe mal gerechnet: 1. Der ggT von 921.6k und 250k ist 400. 2. Bleiben also 2304 und 625 3. Das kgV von 2304 und 625 ist 144000. Du hast damit drei Alternativen: 1. Suche einen Quarz mit dieser resp. einer vielfachen Frequenz davon 2. Lasse Dir einen anfertigen. Das soll wohl garnich so teuer sein, wie man denkt. (Weiss aber nichts genaues). 3. Lass Dir die Frequenz von einem DDS erzeugen. 4. Implementiere Dir selbst einen Teiler mit gebrochenem Teilverhältnis.
Hallo Fabian! Deine ganzen Zahlen im Prozentbereich machen mir Sorgen. Kannst du vllt. den Empfang auf 500k stellen? mfg mf
Hallo, ich takte meine Systeme oft mit 9830400 Hz, das ist ein handelsüblicher Quarz. Daraus sollte sich alle üblichen Baudraten (die Vielfachen von 9600) ohne Fehler und 250 kBaud mit weniger als 2% Fehler ableiten lassen. Fast alle UARTs können den Baud-Takt auch woanders her beziehen als vom Systemtakt, z.B von einem Eingang, manche haben sogar zusätzliche Quarz-Oszillatoren für jeden Kanal. An den Quarzkosten kann es heute nicht mehr scheitern. Gruss Reinhard PS probiers mal mit 14745600.
Vielen Dank für die hilfreichen Antworten. Ich hatte vergessen zu schreiben, dass ich ein ATMEGA128 verwenden. Dieser hat ja in der Tat einen separaten Takt-Eingang für die UART. Wenn ich es richtig verstehe, so muss ich doch jetzt nur statt UART den USART Modus nutzen und an XCK0 den entsprechenden (zusätzlichen) Takt bereitstellen. Wenn dem so ist, in welchem Zusammenhang steht dann die Frequenz an XCK0 zur Baudrate?!
Wenn nun der Takt von XCK0 verwendet wird, benötige ich an diesem Pin für 250kbps also ein 250kHz Signal?! Wenn dem so ist, könnte ich doch mit einem 14.745600 MHz Systemtakt über eine Timer/Compare Funktion diesen Takt durch 59 Teilen und würde eine Baudrate von 249925bps erhalten. Und stelle ich mir das nun zu einfach vor?
Fabian schrieb: > Und stelle ich mir das nun zu einfach vor? Ja. Du willst eine Frequenz von 250kHz, Periodendauer 4µs. Das heisst eine halbe Periode (Low|High) dauert 2µs. Außerdem wäre der Timer im CTC Modus mit Toggle OCx am Einfachsten. Das entspräche so ungefähr einem Compare Wert von 29 für eine halbe Periode von 1,9667µs. Damit bist Du dann 1,69% vom Idealwert 250kbit/s entfernt. OCx mit ClockIn verbinden und fertig. Achtung: Das geht laut Datenblatt nur bei synchroner Datenübertragung und die unterscheidet sich deutlich von Async. Du wist dich möglicherweise selbst um die Generierung von Start/Stop Bits kümmern müssen.
Angehängte Dateien:
-
USART.gif
7,5 KB
schau dir mal das Datenblatt an, du kannst nicht einfach ein von den Daten losgelöstes Signal an XCK einspeisen. Da muss dann schon vom USART-Sender der Gegenstelle kommen! Sascha
Richtig. Wie soll das funktionieren? eine UART (also asynchron) hat noch eine Synchronisierungsschaltung eingebaut, beziehungsweise tastet das Signal mehrfach ab. Das fehlt dann.
1. Auf der 250kb/s Seite will er doch nur senden, dh. die Geschichte mit der Abtastung ist irrelevant. 2. Auch eine synchrone Schnittstelle kann man 'missbrauchen' um einen asynchronen Datenstrom zu erzeugen. Man muss dann nur das Start und Stopbit als Teil des Datenstromes ansehen. Die Gegenstelle (empfangende Seite) bekommt davon gar nichts mit. Da sich der ganze Vorgang zur Empfangsseite hin als asynchron darstellt, braucht's auch keinen Takt von dort.
Norbert schrieb: > 1. Auf der 250kb/s Seite will er doch nur senden, dh. die Geschichte mit > der Abtastung ist irrelevant. Das ist allerdings ein Argument.
Um es noch ein wenig deutlicher zu beschreiben: Bei einer synchronen Übertragung werden kontinuierlich bits übertragen. Es gibt keine Einteilung in Datenbytes, Parity, Startbit, Stopbit. Wenn man nun im AVR einen synchronen Modus von zb. 5Bit Breite nimmt, kann man im ersten 5Bit Frame das Startbit sowie vier Datenbits übertragen. Im darauf folgenden Frame bringt man nun die anderen vier Datenbits unter sowie das Stopbit. Plötzlich sieht der von der anderen Seite empfangene Datenstrom wie ein asynchrones Start + 8Bit + Stop aus.
Der Mega128 hat doch zwei UARTs. Da nimmst Du halt einen zum Senden und einen zum Empfangen, und den Sende-UART versorgst Du eben mit einem externen Takt. Wenn Du den zweiten UART brauchst: Der Mega 1280/2560 hat 4 UARTs. Oder Du realisierst den Sende-UART softwaremäßig. Oder Du nimmst einen MAX3100 SPI-UART. Irgendwie wirst Du garantiert zum Ziel kommen.
Vielen Dank für alle Hinweise und Tipps! Der Max3100 wäre schon eine gute Lösung, aber kostet ca. 3 bis 4 mal soviel wie ein Atmega 8. Die Kommunikation über beide Uarts ist immer bidirektionel, weshalb ich nicht eine als USART die andere als UART laufen lassen kann. Konkret geht es bei mir um die Ein- und Ausgabe von DMX Daten, weshalb ich an die 250k gebunden bin. Mein Fazit, ist nun, dass ich meine vorhandene Leiterplatte noch einmal redesignen werde. Ist zwar schade drum, aber alles andere kommt mir derzeit wie "gewollt und nicht gekonnt" vor. Deshalb sieht mein neues Konzept wie folgt aus: Der Atmega128(14.7456MHz) bekommt seine Daten über eine UART mit 921.8k, verarbeitet diese und leitet das Ergebnis über SPI an einen Atmega8 (16MHz) der alleine für die Ein- und Ausgabe der DMX Daten auf den Bus zuständig ist, weiter. Dies schafft zusätzlich den Vorteil, dass ich problemlos auf mehrere Universen erweitern kann. Dies kommt mir auserzudem zu gute, da der Atmega128 auch noch für ein Grafik-Display und die Benutzerführung zuständig ist und der sich über die zusätzlichen Resourcen freut... Nochmal vielen Dank für eure Unterstützung!
Hi
>Deshalb sieht mein neues Konzept wie folgt aus: ....
Eine andere Variante wäre ein ATMega164...1284 mit 22MHz etwas
übertaktet. Die haben 2 UARTs und mit den 22MHz kannst du beide
Baudraten mit ausreichend geringen Fehler erzeugen.
MfG Spess
Fabian schrieb: > Die Kommunikation über beide Uarts ist immer bidirektionel, weshalb ich > nicht eine als USART die andere als UART laufen lassen kann. > Konkret geht es bei mir um die Ein- und Ausgabe von DMX Daten, weshalb > ich an die 250k gebunden bin. Hallo, da liegt wohl ein Irrtum vor: ein UART/USART ist eine Einheit mit Sender UND Empfänger, die müssen schon im gleichen Modus arbeiten - aber ein ATMega128 enthält 2 Uarts (also 2 Sender und 2 Empfänger), die beiden sind unabhängig, also kann wohl einer als asynchron und der andere als synchron programmiert werden. 2 Prozessoren zu verwenden, ist ziemlich sinnfrei, weil dann die Interprozessor-Kommunikation dazu kommt, daher läuft sowas genausogut auf einem. Was anderes ist es natürlich, wenn man unbedingt das System so kompliziert wie möglich machen will, ich wüsste aber nicht, mit welcher Motivation - ich würde als Lehrer dafür eine schlechtere Note vergeben und nicht etwa eine bessere. Gruss Reinhard
Na ja, zu den Informationen und der Frage vom 4.9. hat er wenigstens am (fast) 7.9. einige Feinheiten hinzugefügt, die sämtliche Hilfestellungen vorher ins Nichts laufen liessen. Einige Leute hier haben sich Gedanken gemacht, ein bisschen gerechnet und versucht Hilfestellungen zu geben nur um jetzt festzustellen das alles für den Sack war. Ich muss konstatieren: Es macht zunehmend weniger Spass hier im Forum aktiv mitzuhelfen.
@Reinhard Kern und @Norbert: Ich denke, dass ihr mich jetzt falsch versteht. Ich muss: - Eine bidirektionale Verbindung mit 921.8k betreiben (RX / TX) - Eine bidirektionale Verbindung mit 250.0k betreiben (RX / TX) Das heißt, dass ich nicht zwei Uarts für eine Verbindung verwenden kann. Die Interprozessorkommunikation über SPI erzeugt weniger Overhead als die direkte Ausgabe der Daten. Ich freue mich, wenn mir hier geholfen wird. Auch die Ansätze sind sehr gut und hilfreich. Und genau diese Ansätze haben mir gezeigt, dass es nicht ohne "Krückstock" geht. Ich verstehe daher eure jetzige Kritik nicht.
Welche Möglichkeit ich im Übrigen auch noch nicht ganz ausschließe ist die von Spess53: spess53 schrieb: > Eine andere Variante wäre ein ATMega164...1284 mit 22MHz etwas > > übertaktet. Die haben 2 UARTs und mit den 22MHz kannst du beide > > Baudraten mit ausreichend geringen Fehler erzeugen. Hier muss ich aber erst durchschauen, ob ich mit der Anzahl der IO-Pins und der sonstigen Peripherie auskomme, da der Professor ein paar Abstriche gegenüber dem 128 besitzt.
Fabian schrieb: > Ich verstehe daher eure jetzige Kritik nicht. Ganz einfach, hättest Du im ersten Beitrag das hier geschrieben: - Eine bidirektionale Verbindung mit 921.8k betreiben (RX / TX) - Eine bidirektionale Verbindung mit 250.0k betreiben (RX / TX) und nicht (im übertragenen Sinne) das hier: - Eine unidirektionale Verbindung mit 921.8k betreiben (RX) - Eine unidirektionale Verbindung mit 250.0k betreiben (TX) dann hättest Du ab dem zweiten Beitrag lösungsorientierte, zielgerichtete Hilfe bekommen. So haben wir uns eine nicht unerhebliche Zeit lang mit unnützen und nicht zielgerichteten Dingen beschäftigt.
Das die Informationen nicht zielgerichtet waren halte ich für übertrieben. Außerdem lebt ein solches Forum nicht davon spezielle Probleme im Detail zu klären, sondern grundsätzliche Möglichkeiten zu eröffnen und aufzuzeigen. Da dieser Thread nicht nur mir, sondern auch anderen helfen soll, die nicht unbedingt genau das gleiche Problem haben, ist es vom Vorteil, wenn ein breites Spektrum an Lösungsvorschlägen aufgezeigt wird.
Fabian schrieb: > @Reinhard Kern und @Norbert: > Ich denke, dass ihr mich jetzt falsch versteht. > Ich muss: > - Eine bidirektionale Verbindung mit 921.8k betreiben (RX / TX) > - Eine bidirektionale Verbindung mit 250.0k betreiben (RX / TX) Du hast 2 Verbindungen und dafür 2 UARTs zur Verfügung, wo ist das Problem? Gruss Reinhard
das er die 250k Verbindung nur mit USART nutzen könnte, aber eben nur als TX aber nicht als RX da er vom Sender keinen Takt bekommt (bzw. der keinen Takteingang hat). Sascha
Sascha Weber schrieb: > das er die 250k Verbindung nur mit USART nutzen könnte, aber eben nur > als TX aber nicht als RX da er vom Sender keinen Takt bekommt (bzw. der > keinen Takteingang hat). > > Sascha Ach, und das ist mit 2 ATMegas anders? Man lernt nie aus. Gruss Reinhard
Ja, ist es. Da der "Eingabe" Prozessor ein Baudraten-Quarz bekommt (14.7456MHz) und der "Ausgabe" Prozessor einen "graden Wert" (16.0000 MHz). Die Datenübertragung zwischen diesen beiden Prozessoren läuft dann über eine synchrone SPI Schnittstelle.
Fabian schrieb: > Ja, ist es. Da der "Eingabe" Prozessor ein Baudraten-Quarz bekommt > (14.7456MHz) und der "Ausgabe" Prozessor einen "graden Wert" (16.0000 > MHz). Die Datenübertragung zwischen diesen beiden Prozessoren läuft dann > über eine synchrone SPI Schnittstelle. Hallo, das ist hirnverbrannter Quatsch und widerspricht ausserdem Saschas Aussage, dass es am fehlenden Takt liegt. Ich beteilige mich hier nicht mehr, das ist einfach zu blöd. Gruss Reinhard
Ich verstehe die Aufregung nicht. Wenn die Verwendung eines anderen ATMegas nicht grundsätzlich ausgeschlossen ist, nimm doch einen ATXmega. Da kannst Du so ziemlich jede Baudrate mit ausreichender Genauigkeit bei 16 bzw. 32MHz Systemtakt einstellen. Und 2 UARTs haben die meisten xMegas außerdem. Z.B. der ATXmega64A3 hat 2 UARTs im TQFP64 Gehäuse. Oder nimm gleich den ATXmega128A1 im TQFP100 mit 4 UARTs. Ansonsten ist IMHO nur die Lösung mit 2 ATmegas mit unterschiedlichem Takt (18.432MHZ / 16.000 MHZ) möglich.
Verwirt schrieb: > Autor: Verwirt (Gast) > > Datum: 08.09.2010 14:49 Danke! Du hast es anscheind verstanden! Und genau das ist nun auch mein "hoffentlich" letzter Entschluss. Leider sind die XMegas nicht pinkompatibel. Aber dadurch, dass ich sie (auch bei 3.3V) bis 32 MHz Takten kann, für mich schon sehr sympathisch!
Thread beobachten
Seitenaufteilung abschalten
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.