Hallo,
ich will mit einem AVR über dessen seriellen UART-Port Daten mit einer
bestimmten Frequenz ausgeben. Es müssen allerdings zwei verschiedene
Taktraten ausgegeben werden. Dazu braucht der AVR zwei umschaltbare
Eingangsfrequenzen, 9,6MHz und 16MHz. Diese beiden Frequenzen wären ein
Teiler von 48MHz. Da der AVR maximal 20MHz Taktfrequenz verträgt, kann
ich einen 48MHz-Quarzoszillator nicht direkt anschließen, sondern müsste
dessen Takt durch drei oder durch fünf teilen. Wie mache ich dies? Gibt
es dafür einen Chip (74..) und, wenn ja, wie müsste er beschaltet
werden? Zwei Pins des AVRs wären fürs Umschalten frei.
Danke
Also durch Zweierpotenzen teilen kann man gut mit einem Counter, z.B.
74AC163 wenn ich das Datenblatt richtig lese. Durch fünf ist schon
kniffliger ...
Kannst du keinen µC mit integriertem Teiler benutzen oder einfach zwei
Oszillatoren verbauen?
Hat ATMEL keine Mikrocontroller mit integrierter PLL? Würde die Sache
stark vereinfachen...
Kann ein AVR überhaupt eine Frequenz am UART ohne Jitter (Pause zwischen
Bytes) ausgeben?
Sven B. schrieb:> Also durch Zweierpotenzen teilen kann man gut mit einem Counter,> z.B.> 74AC163 wenn ich das Datenblatt richtig lese. Durch fünf ist schon> kniffliger ...> Kannst du keinen µC mit integriertem Teiler benutzen oder einfach zwei> Oszillatoren verbauen?
Ich kann leider nur AVRs programmieren und die vertragen 48MHz nicht.
Wie könnte ich denn zwischen zwei Oszillatoren umschalten?
Aus TTL-Zeiten ist mir noch bekannt, dass man mit Presettable
Binary Counter-n, wie 74160/-161 durch 2, 3, 4, 5,..15 teilen
konnte. Sollte mit 74HCxx auch möglich sein.
Musste man da für 3, oder 5 den Preset auf 12 / 10 stellen?
Dann würden 2 Port-Pins reichen.
Muss ich mal nachsehen...
Jim M. schrieb:> Hat ATMEL keine Mikrocontroller mit integrierter PLL? Würde die> Sache stark vereinfachen...
Zumindest der MEGA1284 hat dies nicht.
> Kann ein AVR überhaupt eine Frequenz am UART ohne Jitter (Pause zwischen> Bytes) ausgeben?
Die USART im SPI-mode ist double-buffered; somit sollte dies kein
Problem sein.
An 74HC4017 habe ich auch gedacht.
Erst mal wollte ich ihm keine 48 MHz zutrauen, doch bei
5 V / 25° schafft er das wohl.
Aber, ohne zusätzliche Logik kannst du ihn (auch) nicht
vom AVR aus umschalten.
Anno Tobak konnte das der SN7490. Möglicherweise gibt es den auch in den
aktuellen Prozessen. Der konnte u.a. Div 5 und Div2 (Div 10).
Ob allerdings mit einem so "holprigen" Takt irgendetwas anzufangen ist,
wage ich zu bezweifeln.
When applying an external clock, it is required to avoid sudden changes
in the applied clock frequency
to ensure stable operation of the MCU. A variation in frequency of more
than 2% from
one clock cycle to the next can lead to unpredictable behavior. If
changes of more than 2% is
required, ensure that the MCU is kept in Reset during the changes.
Mit einem Counter 74hc4017, oder 74hc93 o.ä. plus einem quad NAND,
oder NOR sollte das zu bewerkstelligen sein.
Man muss doch nur (über die NANDs, oder NORs vom AVR gesteuert)
die 3, oder 5 dekodieren und damit den Reset auslösen.
Der RESET-Puls (vielleicht mit RC etwas gedehnt) geht an den
ext-Clk-Input für die UART des AVR.
Erfordert etwas Boolsches Tüfteln.
Aber heute nicht mehr...
Jochen schrieb:> ich will mit einem AVR über dessen seriellen UART-Port Daten mit einer> bestimmten Frequenz ausgeben. Es müssen allerdings zwei verschiedene> Taktraten ausgegeben werden. Dazu braucht der AVR zwei umschaltbare> Eingangsfrequenzen, 9,6MHz und 16MHz.
Das glaube ich nicht. Überhaupt ist es eine ziemlich blöde Idee <tm>,
ausgerechnet die Taktfrequenz des ganzen Controllers umzuschalten, nur
weil man verschiedene Baudraten auf der UART Schnittstelle braucht.
Beschreib lieber dein eigentliches Problem und nicht das was du für die
Lösung hältst (und womit du nicht weiterkommst).
Danke für diese vielen guten Tipps.
Das Ganze ist doch komplizierter als ich dachte. Vielleicht überlege ich
noch mit 74HC163 oder 74HC193.
Vielleicht könnte man kurz vor dem Umschalten der Frequenz den Watchdog
einschalten. Stürzt der AVR beim Umschalten nicht ab, dann könnte er den
Watchdog wieder abschalten und weiter machen; andernfalls würde ihn der
Watchdog aus dem Absturz wieder erwecken. Das ist aber alles deutlich
komplizierter als gedacht. Die minimale Länge der Low- oder High-Phase
des externen Taktsignals muss auch noch 20ns sein. Auch dies ist nicht
so einfach...
Axel S. schrieb:> Beschreib lieber dein eigentliches Problem und nicht das was du für die> Lösung hältst (und womit du nicht weiterkommst).
Ich überlege gerade, ob man mit einem AVR nicht ein Floppy-Disk-Laufwerk
ansprechen kann. Die Taktrate ist mit 250kHz bei DD und 500kHz bei HD
nicht das Problem. Das Problem ist die Precompensation, die bei DDs
125ns ist. Dies sollte mit 8MHz zu erreichen sein. Bei HDs sollte dies
die halbe Zeit sein, was mit 16MHz möglich sein sollte.
Bei 3.5"-Laufwerken dreht sich die Disk sowohl bei DD- als auch bei
HD-Laufwerken immer mit 300 U/min. Hier sind 16MHz immer richtig.
Schwieriger ist es bei 5.25"-Laufwerken:
Ein 5.25"-DD-Laufwerk hat 300 U/min. Hier ist 16Mhz (8MHZ) korrekt.
Ein 5.25"-HD-Laufwerk hat allerdings 360 U/min.
Für 5.25"-HD-Disks in HD-Laufwerken ist 16MHz perfekt.
Eine 5.25"-DD-Disk in einem HD-Laufwerk würde sich allerdings 20% zu
schnell drehen (360 statt 300 U/min). Dadurch müssen auch alle Daten,
inklusive 125ns-Precompensation, 20% schneller auf die Disk geschrieben
werden, also 9,6 statt 8MHz.
Ich weiß, dass es sinnlos ist heutzutage über Floppydisks nachzudenken,
aber es interessiert mich eben.
Moin,
Jochen schrieb:> noch mit 74HC163 oder 74HC193.> Vielleicht könnte man kurz vor dem Umschalten der Frequenz den Watchdog> einschalten. Stürzt der AVR beim Umschalten nicht ab, dann könnte er den> Watchdog wieder abschalten und weiter machen; andernfalls würde ihn der> Watchdog aus dem Absturz wieder erwecken.
Schlechte Idee. Im Datenblatt steht ja: "unpredictable behaviour". Das
heisst, er muss nicht abstuerzen; er kann sich einfach nur mal
"verrechnen". Oder von irgendwo anders lesen als gedacht, oder irgendwo
anders hinschreiben als gedacht. Da wird der Watchdog nicht mal leise
knurren und trotzdem kann beliebiger Mumpitz die Folge sein.
Gruss
WK
Hallo,
eins verstehe ich noch nicht so ganz möchtest du den Pin nutzen worüber
die UART kommuniziert oder nur die komplette UART??
Sollte zweiteres gemeint sein, gibs das Baudratenregister worüber
verschiedene Geschwindigkeiten generiert werden können. Da muss man aber
ins DB schauen welche Abweichungen bei welcher Taktfrequenz gewollt
sind.
Sonst mal schauen wie die serielle Schnittstelle funktioniert
https://de.wikipedia.org/wiki/RS-232 denn im Bild mit dem
SpannungsZeitverlauf sieht man es recht gut wie die Bits übertragen
werden... ähnlich wie dem 1wire-Protokoll von Maxim
Also 48 MHz mit einem alten 7490, das halte ich für ziemlich wacklig.
Auch die Trickserei mit asynchronem Reset z.B. beim 4017 ist
unzuverlässig. Besser ist der synchrone Reset beim schon genannten 163
oder 193, der hat dann immer fast eine Taktperiode zur Vorbereitung
Zeit. Nicht der 74161, der hat asynchronen Reset. Wenn möglich eine
schnelle TTL-Familie, also AC, FCT, AS, F usw., die können eher 48 MHz.
Die Xmega Controller haben einen PLL Taktgeber, den man auch im
laufenden Betrieb umkonfigurieren kann.
Ob du damit auf die spezielle gewünschten Frequenzen kommst, kann ich
allerdings nicht einschätzen. Ich hatte bisher nur eine Anwendung mit
einem Xmega.
Xmega würde ich als gepimpte AVR's bezeichnen.
> Ich überlege gerade, ob man mit einem AVR nicht ein> Floppy-Disk-Laufwerk ansprechen kann.
Da würde ich aber nicht das ganze Rad in allen Details neu erfinden
wollen und einen fertigen Floppy Controller benutzen. Ich hatte mal
einen Chip von Western Digital (WD1771) verwendet, den ich von einer
alten I/O Karte für einen Floppy-Streamer abgezogen hatte.
Mit 74xx163 geht es ohne zusätzliche Gatter, wenn man das oberste
Zählbit mit dem synchronen Preset verbindet. Der ist active low, d.h.
nach Zählerstand Null wird auf den Preset-Wert gesetzt. Für einen Teiler
durch fünf werden also Zustände 12...15 und 0 durchlaufen, für Teilung
durch drei nur 14,15,0. Preset also auf 12 oder 14, = 1100 oder 1110.
Somit lässt sich der Teiler über das zweitniedrigste Presetbit
umschalten, vermutlich ohne Störungen.
Jochen schrieb:> Axel S. schrieb:>> Beschreib lieber dein eigentliches Problem und nicht das was du für die>> Lösung hältst (und womit du nicht weiterkommst).>> Ich überlege gerade, ob man mit einem AVR nicht ein Floppy-Disk-Laufwerk> ansprechen kann. Die Taktrate ist mit 250kHz bei DD und 500kHz bei HD> nicht das Problem. Das Problem ist die Precompensation, die bei DDs> 125ns ist.
Du möchtest also mit dem AVR direkt den Schreibdatenstrom erzeugen?
Wieso glaubst du, ausgerechnet die UART wäre dazu hilfreich?
Wenn überhaupt, dann wäre das SPI das Werkzeug der Wahl. Mit hinreichend
schnellem Takt und softwaremäßiger Vervielfachung der Datenbits könnte
es den Datenstrom wohl erzeugen. Allerdings hast du dabei mindestens
zwei Probleme:
1. der Aufwand, die Bits passend zu vervielfältigen, dürfte deinen AVR
überfordern
2. da das SPI bei den AVRs senderseitig nicht gepuffert ist, hast du
extreme Anforderungen an das Timing, weil du ja lückenlos senden mußt
SPI über die USART hat einen Puffer. Von daher macht UART schon etwas
Sinn, auch wenn man die USART wohl eher im SPI Modus nutzen wird.
Die Precompensation ist eine analog Sache, also unabhängig vom Takt.
Jochen schrieb:> Das Problem ist die Precompensation,
Sooo genau kommt es auf die Precompensation nicht an. Ob nun
präkompensiert 100ns oder 150ns verschoben der Flankenwechsel
stattfindet ist egal.
Schlimmer ist das Synchronisieren beim Lesen. Man muss per PLL der
Drehgeschwindigkeit der von jemand anderem Disk folgen damit man den
Bitzustand immer inmittig der Bitwechsel ausliest.
Diese PLL kann man digital machen, aber dazu muss man die Zeitpunkte an
denen der UART die Eingangsleitung abfragt einerseits kennen und
andereseits zumindest beim nächsten Byte um us verschieben können.
Beispiel: Dein UART liest einen 500khz (2us) Datenstrom mit 500ns
Auflösumg ein
00000111111110000111000001111111
. . . . . . . .
Man sieht, dass er knapp nach den Flankenwechseln abtastet.
Zuverlässiger wäre das Lesen wenn er den Samplezeitpunkt um 500ns
verschieben würde
00000111111110000111000001111111
. . . . . . . .
Das macht die PLL, typisch mit 16-facher Auflösung, nicht bloss 4 wie
hier.
Hätte nicht gedacht, dass es garnicht so leicht ist, mit einem,
oder auch zwei ICs und ein bis zwei Bit Ansteuerung 1/3, oder 1/5
einer HF-Frequenz > 40 MHz darzustellen.
Aber ich wundere mich über die hirnrissige Idee, den µC-Takt
umzuschalten!
Mega-AVRs haben einen XCK-Eingang für den Baudratengenerator.
Tiny-AVRs haben (Ausnahmen bestätigen die Regel) sowieso
keine UART.
Jakob schrieb:> Hätte nicht gedacht, dass es garnicht so leicht ist, mit einem,> oder auch zwei ICs und ein bis zwei Bit Ansteuerung 1/3, oder 1/5> einer HF-Frequenz > 40 MHz darzustellen.
Ist auch nicht kompliziert. Aber man möchte es scheinbar kompliziert.
Stichworte für fertige 1-Chip-Lösungen wurden von mir genannt.
Hier noch ein Beispiel ohne HF und Spezialchips:
> Schlechte Idee. Im Datenblatt steht ja: "unpredictable behaviour".
Stimmt; das hätte ich vorher nachlesen gesollt. Somit ist das Umschalten
der Eingangsfrequenz eine ganz schlechte Idee, auch wenn es machbar
wäre.
> Die Xmega Controller haben einen PLL Taktgeber, den man auch im> laufenden Betrieb umkonfigurieren kann.
Es soll auf alle Fälle ein Hobby-Projekt werden, sodass ich keine
SMD-Chips benutzen möchte. Somit scheidet ein Xmega leider aus.
> Ich hatte mal> einen Chip von Western Digital (WD1771) verwendet, den ich von einer> alten I/O Karte für einen Floppy-Streamer abgezogen hatte.
Es würde mich (momentan gedanklich) reizen alles mit einem leicht
erhältlichen Chip zu erreichen.
Ich wollte eigentlich schon die USART im SPI-Modus benutzen; denke aber
inzwischen, das selbst die zu langsam sein könnte.
> Schlimmer ist das Synchronisieren beim Lesen. Man muss per PLL der> Drehgeschwindigkeit der von jemand anderem Disk folgen damit man den> Bitzustand immer inmittig der Bitwechsel ausliest.
Ich hätte es gedanklich ohne PLL, nur in Software gemacht, ungefähr so:
ReadData ist z.B. mit Int0 verbunden. Jede fallende Flanke löst einen
Interrupt aus. Es wird nicht die Interrupt-Routine angesprungen, sondern
nur das Interrrup-Flag ausgewertet. Anhand der Zeit, die zwischen zwei
Interrupsts (magnetischen Richtungswechseln) ist, würde entschieden, ob
es ein 0- oder ein 1-Bit ist.
Danke für Eure wertvolle Hilfe.
