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,
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.
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!
