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...
74HC4017 und MR wahlweise mit Q3 (für Teiler durch 3) oder Q5 (für Teiler durch 5) verbinden.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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
Nimm einen DDS-Chip, welchen Du mit einem µC ansteuerst. Oder eine PLL. Aber doch nicht sooooo ...! Gruß Jobst
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:
1 | _________ ___________ |
2 | | | | | |
3 | | 1,6 MHz |------------------------| øsoll | |
4 | |_________| __________ | PD |------, |
5 | | | | | | |
6 | / | Q2 |---------| øist | | |
7 | ,--o o--| Q6 | | _ _ _ _ _ | | |
8 | | | | | | R |
9 | | | CLK |----+----| Fout | | |
10 | | | | | | | | |
11 | '--------| R | | | VCOin |------+ |
12 | |__________| | |___________| | |
13 | 4017 V 7046 C |
14 | | |
15 | 9,6 / 16MHz GND |
Gruß Jobst
:
Bearbeitet durch User
> 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.
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.