Hallo Zusammen, ich habe mehr aus Zufall einen Mega32 mit 40 MHz übertaktet und es ging auf Anhieb. Aufgabe: Ich bau grad ein OSD mit dem Mega32. Dabei war mir der Chip bei 16Mhz zu langsam. - Der SPI ist für die Charakter-Ausgabe für kleine Zeichen zu langsam. - Die Zeilensynchronisation auf das Kamerasignal ist bei 16 MHz zu unsauber. Ich erzeuge aus dem Videosignal einer Kamera, mit einem LM1881 ein Zeilen-Sync., welches auf den INT1-Eingang gelegt ist. Egal wie ich triggere der eingeblendete Text hat ein "Jittern". Übertakten ?! Also hab ich erst mit 20 MHz probiert - lief, dann mit 40 MHz - lief und mit 60MHz - lief nicht. Ich verwendete Quarzoszillatoren aus meiner "Bastelkiste". Lief mit verschiedenen Prozessoren einwandfrei. Nun zum Problem !!!! Mutig geworden, bestellte ich mir weitere 40MHz Qszillatoren und es lief nicht mehr. Oszi. der funktioniert KOYO KCO-010T 40.000MHz OSzi. der nicht geht HO-12C 40.000MHz HOSONIC 601 Hat jemand einen Tip, wie ich den MEGA32 trotzdem zum laufen bringen kann ? Der MEGA32 scheint ja fähig dazu zu sein, nur der Takt-Oszillator muss richtig funktionieren. Hilft da ein Buffer ? Zum Bild: rechts mit 40MHz links mit 16 MHz bei unveränderter Software.
Kann es sein, dass das Quarz gar nicht anschwingt? Schon mal mit nem Oszi gemessen?
Ja, ich weiß, du hast was anderes gefragt, aber bist du dir sicher, dass du über deinen (einen anderen) Algorithmus nichts mehr rausholen kannst. Meist sind da deutlich größere Leistungssteigerungen drin als du durch übertakten je erzielen könntest. Zumal das deutlich zuverlässiger ist. Ansonsten: Ich wär für solche Versuche erstmal mitm Funktionsgenerator ran und hätte langsam die Frequenz erhöht. Sebastian
@Tilo Quarz schwingt - beide Oszilatoren sehen auf den Oszi gleich aus.
Algorithmus verbessern? Wohl kaum. Pro Pixel hat man selbst bei 20 MHz nur wenige Taktschritte, da gibts nichts mehr zu optimieren.
Winfried, egal wie Du den externen Int triggerst, Du hast KEINE Gewähr für eine immer gleiche Responsezeit. Es kann immer bis zu 1-3 Takte unterschiedlich sein, bis die ISR angesprungen wird. Je nach dem, was das Hauptprogramm gerade macht (OP mit 1,2 oder mehr Takten). Dazu kommt noch der Fakt, dass Du nicht weisst auf welchem Takt-Status der externe Int kommt. (Takt gerade angefangen/gerade vorbei). Diese unvorhersehbaren und unregelmäßigen Verzögerungen reichen für ein Jitter absolut aus. Jochen Müller
Selbst wenn beide Signale gleich aussehen ist wohl ein Unterschied vorhanden. Es könnte an der Flankensteilheit oder dem Verhältnis High zu Low Zeitdauer des Taktes liegen, bei so extremer Übertaktung ist vieles möglich.
Atmel gibt nicht umsonst eine bestimmten Frequenz bereich an, indem ihre Prozessoren sicher und sauber funktionieren. Ich könnte mir vorstellen, das die internen Speicher zu langsam sind. (RAM oder ROM) Oder der eine Quarz gerade noch an der unteren Toleranz grenze arbeitet ( z.B. 39,9999 MHz) und der andere an der oberen (41,99 MHz). Aber ist das ist doch sehr unwahrscheinlich. Mit welche Spannung arbeitest du? Je geringer die Spannung vom AVR, desto geringer die vom Hersteller sicher funktionierende Taktfrequenz. Daraus würde ich schlussfolgern, das vielleicht ein bisschen mehr Spannung ihn stabiler arbeiten lässt.
Ich vermute mal, dass der 2 Oszillator zusammenbricht, oder die Flankensteilheit nicht ausreicht. Nen Puffer, der ein ausreichendes stabiles Signal liefert ist sicher hilfreich. Besimmt ist die Kapzitive Last des XTAL1 für den Oszillator zu groß. Ersatzhalber könntest du ja den internen Oszillator mit nem Phasenschieber (2*RC) freischwingen lassen und mit dem Oszillator synchronisieren. Was aber ein technisches "Affront terrible" darstellte und einen Haufen Tests erfordern dürfte ;-)).
Also das mit der Spannung hat leider nichts gebracht. Mit dem "Zauberquarz" geht's von 3,9 V bis 6,6 V (egal was das Datenblatt sagt) Der andere schwingt zwar aber er schafft den MEGA32 nicht "anzuwerfen".
Versuchst du auch alles mit dem gleich AVR, oder hast du immer andere? nicht, das plötzlich der andere auf internen Takt eingestellt ist.
@Gutmar Nö ich wechsele nur den Quarz. Schaltung ist die Selbe und der AVR auch. (Natürlich habe ich auch andere AVRs mit der gleichen Programmierung probiert.)
Vielleicht solltest du mal andere Mega32 Versuchen. Ich bin mir nicht sicher ob das ganz vergleich bar ist, aber bei PC CPU's ist das Übertaktungspotenzial auch von CPU zu CPU unterschiedlich.
Mehr wie 10% wirst du aus dem Ding nicht rausholen. Wenn du die wirkliche Geschwindigkeit messen willst, musst einen Pin nach aussen legen und ihn toggeln lassen aber alles andere ist kein Beweis.
Wie starten die Oszillatoren denn? Kann sein, dass ein Oszi beim Anfahren nen ungünstigen Duty bringt und der AVR sich verschluckt, und der andere mit nem sauberen Signal startet? Schon mal mit den SUT-Fuses rumexperimentiert? VCC besser gepolstert, weil n Oszi evtl nen Ripple macht? Spannung sollte wie gesagt möglichst hoch sein und Temperatur möglichst niedrig (aber nicht so tief, dass der µC supraleitend wird ;-))
Das Ganze halte ich für praktisch wenig wertvoll. Kann laufen, muss aber nicht. Jaja, Eine Grafikanzeige mit AVR ist möglich und nett, aber ein CPLD kann das dreimal besser. Ohne übertakten. MFG Falk
Ich weiß zwar grade nicht, wie die Fuse sich nennt, aber zumindest der Atmega8 kann so eingestellt werden, dass der Oszillator mit höherer Leistung läuft und dadurch stabiler wird. Ich glaube die CKOPT Fuse müsste das sein... Steht aber bestimmt im Datenblatt
@ rugbywinne Probier es doch vielleicht mal mit einem atmega8, da ist der selbe Kern drin. Meiner Erfahrung nach läuft er bei: 2.05V mit 1MHz (atmega8L) 2.20V mit 1MHz (atmega8) 2.55V mit 12MHz (atmega8) ... gerade so an. Jetzt sagst du (Overclockingspezialist): 3,90V mit 40MHz ! :) Muss ich doch glatt mal ausprobieren, am besten mit dem Atmega8L.
@atmelhasser dann schau dir mal die beiden Bilder an. Nichts anderes ist dort zu sehen. Die horizontalen Linien werden aus einem seriellen Schieberegister geliefert das durch den internen Clock getaktet. Der AVR ist tatsächlich mehr als doppelt so schnell. @gast CKOPT Fuse ist für Quarze ich nehm einen Oszillator und cksel ist 0000 (Hab's aber trotzdem probiert) @Johann L. SUT Fuse sind für "Power Up Reset" ich mache laaange nach dem Hochfahren der Spannung ein Reset und für den Test sogar mehrfach. (Hab's aber trotzdem probiert)
Na ja ich würde externe 5V Quarzoszilliosatoren nehmen, saubre Pegel&genug Leistung. Wenn ich nen avr @5,25V oder 5,5 5,6V sehe werde ich zuerst an dich denken... oder igor... mehr powwwer.
Ich wuerd auch auf ein CPLD gehen, die haben Saft ohne Ende. Zum einen kann man fast alles parallel laufen lassen, zu anndern gehen auch guenstige kleine CPLDs locker auf 200MHz.
Ich hab die Lösung für das Oszillator-Problem. Zwischen Oszillator (klar ist ein fertiger für 5V) und dem XTAL1-Eingang muss ein klassischer Hochpass. Mit 10nF und 250 Ohm klappt's auch mit dem anderen Oszillator. Und wieder sind's 40 MHz bei 3,5 Volt. Der AVR läuft und läuft ... So ich hab hier noch ein 48 MHz Oszillator ??????? Na was sag ich Euch der "spielt" auch. Spannung muss aber mindestens 5,1 Volt sein.
Was heißt, der AVR läuft und läuft ? Ich selbst übertakte den atmega 8 gnadenlos, wenn ich ihn als DDS-IC missbrauche. Er macht am externen HF-Generator auch noch 65 MHz mit, weil er in einer einfachen Schleife mit 9 Takten läuft. Andere Funktionen, wie serielle Schnittstelle, Int's, AD-Wandler dürften da schon längst eine sinnvolle Funktion aufgegeben haben.
Die AVR's zu übertakten, finde ich eine sehr gute Idee. Endlich mal jemand, der ein wenig experimtierfreutig ist. >Ich wuerd auch auf ein CPLD gehen, die haben Saft ohne Ende. Zum einen >kann man fast alles parallel laufen lassen, zu anndern gehen auch >guenstige kleine CPLDs locker auf 200MHz. Echt? Gibt's den auch ein CPLD im Dip-Gehäuse für unter 2 Euro, mit dem man auch den kompletten Zeichensatz darstellen kann und noch ca. 1 K Ram für den Bildschirmbuffer übrig ist? Wenn nicht, dann vergiss das mit dem CPLD.
Ja, nee. Das ist zwar schön, dass man das auch mal gesehen hat. Aber Atmel garantiert für die Dinger eben nun mal 16MHz. Und wenn ich nicht den Chip aus der Mitte vom Wafer sondern einen vom Rand erwische, dann schafft er über die Spannung und die Temperatur sicher auch nicht mehr. Sonst wäre das Ding schon lange mit 20 oder 30MHz gestempelt. BTW: Ich habe mal ein FPGA-Design, das mit 90MHz bewertet wurde, schon ohne Funktionseinschränkung (aber mit schlechtem Gewissen) mit knapp 200MHz betrieben. Auf dem Labortisch.
peter-neu-ulm wrote: > Ich selbst übertakte den atmega 8 gnadenlos, wenn ich ihn als DDS-IC > missbrauche. Er macht am externen HF-Generator auch noch 65 MHz mit, > weil er in einer einfachen Schleife mit 9 Takten läuft. Interessant. Auch wenn ich das nur schwer glauben kann. Ich verwende einen tiny2313 für eine DDS, der lief bis etwa 30MHz. Darüber konnte man schön sehen, dass die Sinuskurve zunächst einige Aussetze bekam, also anscheinend Werte falsch aus dem Flash gelesen wurden, und nach ein paar Sekunden war er dann ganz weg. Einige stiegen auch schon bei 25MHz aus, andere gingen bis 35MHz. Aber >40MHz halte ich meinen Erfahrungen nach für unrealistisch, zumindest wenn das Ergebnis einigermaßen reproduzierbar sein soll und man nicht erst 10 AVRs testen muss, um einen zu finden der läuft. Das Problem ist nämlich ganz einfach die Zugriffszeit auf das Flash. Daher haben ARMs und andere schnellere µC meist einen Cache, und lesen z.B. 128bit parallel aus dem Flash um die Befehle schnell genug liefern zu können.
@ benedikt Bei dem DDS-Programm habe ich nur das MSB einer 24-Bit-Addition verwendet, also nur eine Rechteckspannung an einem Pin x,7 erzeugt, ohne Umsetzung über eine Sinustabelle, für einen Mischer hat die Rechteckspannung gereicht. Es war auch nur mal ein neugieriges Nachsehen wie weit der Spaß geht. Aber ein Funktionsgenerator mit 30 MHz Takt lief bei mir schon längere Zeit, nur ist inzwischen der atmega durch ein echtes DDS-IC abgelöst worden. Das ganze Stochern wegen der Taktfrequenz fing übrigens mit einem netten link an: >poor man's synthesizer<
peter-neu-ulm wrote: > Das ganze Stochern wegen der Taktfrequenz fing übrigens mit einem netten > link an: >poor man's synthesizer< Ja, bei mir auch. Damals noch auf einem 90S2313, den ich mit 20MHz betrieben hatte. Anschließend wurde auf einen tiny2313 mit 24MHz umgestellt, und mittlerweile läuft alles auf einem mega48 mit 24MHz.
Jochen Müller: >egal wie Du den externen Int triggerst, Du hast KEINE Gewähr für eine >immer gleiche Responsezeit. Es kann immer bis zu 1-3 Takte >unterschiedlich sein, bis die ISR angesprungen wird. Könnte man eventuell mit einer Polling-Routine eine genauere Synchronisation erreichen? Oder vielleicht wäre es für eine definierte Interruptresponsezeit nützlich, in einer Schleife auf den Innterrupt zu warten. Winfried Zühlke: >Mit 10nF und 250 Ohm klappt's auch mit dem anderen Oszillator. Ist es vielleicht ein Problem der Anpassung? Wie wäre es mit einen einfachen 50 Ohm Widerstand ?
Ich hatte (auf der Basis des 25x40 Zeichen-Bildschirms von Benedikt K.) auch mal ein OSD mit Mega8 gemacht, das hat allerdings kein Jitter und kommt mit 16 MHz Quarz aus. Der Schlüssel zur Jitterfreiheit liegt darin, immer die selbe Interrupt-Responde-Time zu garantieren, indem man dafür sorgt, dass der Controller bei jedem Zeilen-Interrupt garantiert aus dem IDLE-Sleep geweckt wird. Alle Mainloop-Routinen haben sind kurz zu halten (State-machinen) und müssen sich der ISR unterordnen. Zur besseren Lesbarkeit (Einsatz im ATV) wurde die Schrift auf 10 Zeilen je 32 Zeichen angepasst. Vielen Dank nochmal an Benedikt K. für seine geniale Vorlage. ...
Angehängte Dateien:
-
sync02.jpg
75 KB
Hier noch ein Foto vom TV mit eingeblendetem Zeichensatz. Die Helligkeit der Schrift kann justiert werden, ich wählte einen dezenten Wert. Wie bereits gesagt, kein übertakteter Mega32, sondern ein stinknormaler Mega8 (sogar ein L, da ich gerade keinen normalen hatte) mit 16 MHz Quarz, Flash etwa halbvoll, auch im RAM noch etwas Platz. Das Ding ist sicher noch verbesserungsfähig, aber es versieht seit über einem halben Jahr täglich seinen Dienst in Kombination mit einem DTMF-gesteuerten AV-Umschalter (Tiny2313, MT8870, 8 Kanäle) in einer Außenstation des ATV-Relais DB0WTB in Sachsen-Anhalt. ...
>sondern ein stinknormaler Mega8
Normal ist langweilig! höher, schneller, weiter
@Hannes: Wie sieht denn die Schaltung zu dem OSD-Generator aus? (Bin wieder da, hehe :) )
Angehängte Dateien:
-
osd02.png
12 KB
Travel Rec. wrote: > @Hannes: > > Wie sieht denn die Schaltung zu dem OSD-Generator aus? > (Bin wieder da, hehe :) ) Da ich nur einen Testaufbau habe und in Eagle nicht alle Teile hatte (keine Lust zu Selbstzeichnen, da TV nicht mein Ding ist), gibt es (bei mir) keinen Schaltplan. Im Anhang gibt's das Layout des Testaufbaus. Die im Zielobjekt von einem RFT-Fachmann realisierte Schaltung kann ich hier nicht veröffentlichen, da sie nicht auf meinem Mist gewachsen ist. ...
Angehängte Dateien:
-
DSCN0016a.jpg
170 KB
Habe noch ein anderes Bild gefunden. Und da das obige (nutzlose) Bild rund dreimal so oft angeschaut wurde wie der (hilfreiche) Quelltext, werfe ich es auch noch in den Raum... ;-) ...
Hm - ist ja einfach... Im Code stecht die wahre Intelligenz, nehme ich an ;-)
Travel Rec. wrote: > Hm - ist ja einfach... Ja sicher, ich mag einfache Dinge. > Im Code stecht die wahre Intelligenz, nehme ich > an ;-) Soooo schlimm ist es nun auch wieder nicht. Ich missbrauchte den ICP als externen Interrupt, um die Option zu haben, anhand des ICP-Zeitstempels an Benedikts Methode (IJMP in NOP-Bereich) zur Jitter-Korrektur anknüpfen zu können. Das war aber nicht nötig. Es genügt völlig, die restlichen Aufgaben des Programms so zu organisieren, dass sichergestellt ist, dass der Synchronimpuls während des Sleeps auftritt. Jeder Einzeljob muss also in die Lücke zwischen Zeilenende und H-Sync-Impuls passen. Mehrere Jobs werden über eine Taskscheibe reihum organisiert. Jeder Einzeljob macht als SM immer nur einen Schritt. ...
Na wenn´s weiter nichts ist ;-)...
Travel Rec. wrote:
> Na wenn´s weiter nichts ist ;-)...
Eben... - Mit "WAITms 20" gehts allerdings nicht... ;-)
...
Höhö - is klar! Immer druff!
@Chris ja du hast recht es ist ein Problem der Anpassung und da kann ich noch ne Menge optimieren. Ist sowieso erstaunlich das es überhaupt läuft, weil das Ganze noch "wackelig" auf einer Lochrasterplatte aufgebaut und der Oszi gesteckt ist. (Bitte jetzt keine Tips zum Schaltungsaufbau) Polling würde nichts bringen. Der Sprung zur Int.-Routine oder beim Polling ins Unterprogramm ist nicht schneller oder langsamer, was das Taktfenster betrifft. Zur Veranschaulichung: die einfache Befehlsfolge (schon in der Ausgabe-Subroutine) ... Portb.1 = 1 Portb.1 = 0 Portb.1 = 1 ... Gibt einen einen Impuls von 125ns Länge und erzeugt auf einem 17" TV-Monitor in der Horizontalen einen "Strich" von ca. 3-4 mm bei 16 Mhz. Bei 48 Mhz sind das "nur" noch 1 mm. Das verbleibende horizontale Zittern des "Strichs" liegt bei 48MHz UNTER 1 mm. Ist kaum noch zu sehen. Bei 16MHz sind 3 mm Zittern schon zu sehen. Schaltung: Portb.1 ist in das Fbas Signal über einen Transistor eingekoppelt. Der Transistor schaltet 1V also "weis" durch. Ein LM1881 liefert das Zeilen-Sync. welches auf Int 1 geschaltet ist. Ein Textdisplay zu bauen ist (wie die vielen Beispiele im Forum zeigen) kein Problem. Die Zeilensynchronisation wird dabei durch den AVR selbst erzeugt. Alle Zeilen starten taktsynchron und es gibt kein Zittern. Beim OSD wird aber auf das Zeilensync. der Quelle getriggert (Int 1) und da ist ein "Triggerfenster" von (offensichtlich) einem Takt nicht zu unterschreiten. Es geht auch anders - Klar fertige OSDs gibt's einige und CPLD und FPGA auch.
Könnte es vielleicht hilfreich sein, den Takt mit einer PLL auf den vom LM1881 gelieferten HSync zu synchronisieren?
@Hannes Lux Der Tip den AVR "anzuhalten" war goldwert. Es läuft bei 16 MHz Jitterfrei. ich hab den AVR in Powerdown gebracht und starte ihn wieder über den INT 1. Das mit dem ICP-Zeitstempel hab ich nicht ganz verstanden. Wie kann ein Register einen "Zeitstempel" enthalten, der kleiner als der Oszillator-Takt ist ?
Winfried Zühlke wrote: > @Hannes Lux > Der Tip den AVR "anzuhalten" war goldwert. Danke... > > Es läuft bei 16 MHz Jitterfrei. Bei mir auch. Zumindest ist es soooo gering, dass es nicht stört. > ich hab den AVR in Powerdown gebracht und starte ihn wieder über den INT > 1. > > Das mit dem ICP-Zeitstempel hab ich nicht ganz verstanden. > Wie kann ein Register einen "Zeitstempel" enthalten, der kleiner als der > Oszillator-Takt ist ? Schau Dir Benedikts Vorlage an: Beitrag "AVR Videogenerator, 40x25 Zeichen, nur 60% CPU Auslastung !" Er gleicht unterschiedliche Interrupt-Responsezeiten des Timer-Interrupts durch einen berechneten IJMP in ein NOP-Feld aus. Ich nutzte den ICP, damit ich (auch bei verzögertem Aufruf der ISR) einen Zeitstempel habe, der exakt die Flanke datiert. Aus diesem Zeitstempel kann bei freilaufendem Timer nach Benedikts Methode ein korrekter Start für das Aussenden der Pixelzeile berechnet werden. Ich habe es allerdings nicht genutzt, weil das Garantieren des Idle-Sleep beim Auftreten des Sync-Interruptes völlig ausreichte, Jitter zu vermeiden. Ich nutze übrigens bewusst nicht den Power-Down, sondern den Idle-Modus, denn der Timer soll weiter laufen, es soll nur durch Abschalten des CPU-Taktes dafür gesorgt werden, dass die Interrupt-Response-Time immer gleich ist. Sie muss nicht schnell sein, sondern nur exakt gleich, denn es ist noch verdammt viel Zeit zwischen Sync-Flanke und Beginn des Bitstroms. In der Praxis (im ATV-Switch) wird derzeit nur die untere Textzeile für die Bildquellenanzeige benutzt und eine obere Ecke für das Anzeigen der Akkuspannung der USV bzw. einer Alarmmeldung bei kritischer Spannung. ...
Zu früh gefreut. Der Jitter ist noch da aber nicht so leicht zu erkennen. Er läuft vertikal langsam durchs Bild, vergleichbar mit einem nicht synchronisierten Bild. Aber das ist es nicht. Das Bild läuft nicht durch. Ich bin auf dem richtigen Weg. Nochmals Danke Das mit dem Übertakten ist trotzdem noch interessant weil so noch eine höhere horizontale Auflösung (ob sinnvoll oder nicht) erreicht werden kann. z.B. ist bei einem schlichten Fadenkreuz mit einer horizontalen Linie die Senkrechte mehr als doppelt so dick. (jittern unbeachtet). Mich fasziniert die (Stör)-Sicherheit, die im AVR (Übertakten/Versorgungsspannung) steckt, selbst wenn man sich etwas außerhalb der Daten bewegt. Das sagt auch was über die Qualität unter normalen Betriebs-Bedingungen aus. Sonst hätte ich den Theard gar nicht eröffnet und Benedikts und Deine Schaltung einfach nachgebaut. Ist wie das Rad neu erfinden - klar, aber es ist mein eigenes Rad :-)))
Jochen Müller wrote: > egal wie Du den externen Int triggerst, Du hast KEINE Gewähr für eine > immer gleiche Responsezeit. Es kann immer bis zu 1-3 Takte > unterschiedlich sein, bis die ISR angesprungen wird. Nimm den ICP, dann hast Du den Zeitstempel auf einen Zyklus genau und kannst die Zeit kompensieren, z.B. nach DN046: http://www.avrfreaks.net/index.php?module=Freaks%20Tools&func=viewItem&item_id=409 Peter
@Hannes wollte mal Dein OSD aufbauen. wo gibt's den die Dateien ? pr_txt.inc ;Ausgabe von ASCII-Texten pr_debug.inc ;Ausgabe als HEX oder BIN pr_i2a8.inc ;Ausgabe von Integer 8 Bit pr_i2a16.inc ;Ausgabe von Integer 16 Bit Sind die von Dir ? Beste Grüße
Angehängte Dateien:
-
Linie.jpg
170 KB
> Peter Dannegger > Nimm den ICP, dann hast Du den Zeitstempel auf einen Zyklus genau und > kannst die Zeit kompensieren, z.B. nach DN046: Wenn ich das jetzt richtig verstanden habe, ist der Zeitstempel auf ein Zyklus genau. Bei 16 MHz also 62,5 ns. CBI PORTB,1 2 cycl. SBI PORTB,1 2 cycl. CBI PORTB,1 2 cycl. erzeugen einen Puls von 125 ns (bei 16MHz) und sind auf dem Monitor deutlich zu sehen ca. 3-4 mm. Wenn jetzt die Genauigkeit des Zeitstempels nur 62,5 ns ist dann bleibt das Problem. Weil, dass ist genau die Jitterbreite die mich noch stört. (Siehe Bild) Kann ich überhaupt genauer werden als ein Zyklus ?
Winfried Zühlke wrote: > CBI PORTB,1 2 cycl. > SBI PORTB,1 2 cycl. > CBI PORTB,1 2 cycl. > > erzeugen einen Puls von 125 ns (bei 16MHz) und sind auf dem Monitor > deutlich zu sehen ca. 3-4 mm. Nimm doch OUT-Befehle, die dauern nur einen Zyklus. Peter
Angehängte Dateien:
-
linie02.jpg
180 KB
Ich hab noch ein Lösungsansatz Den Oszi durch den INT 1 starten ! Geht über den internen RC-Oszillator leider nur bei 8 MHz Im Bild ist da eine "wie mit dem Lineal gezogene" Linie. Dann ist der Clock wirklich synchron mit jeder Zeile. Aber mit dem Tipp von Peter wird's noch einen Tick besser. Besten Dank
Winfried Zühlke wrote: > @Hannes > > wollte mal Dein OSD aufbauen. wo gibt's den die Dateien ? > > pr_txt.inc ;Ausgabe von ASCII-Texten > pr_debug.inc ;Ausgabe als HEX oder BIN > pr_i2a8.inc ;Ausgabe von Integer 8 Bit > pr_i2a16.inc ;Ausgabe von Integer 16 Bit > > Sind die von Dir ? Die fehlenden Dateien sind Bestandteil meiner LCD-Routinen, die ich in mehrere kleine Dateien gesplittet habe, da ich gern mit kleinen AVRs arbeite, bei denen mitassemblierte unbenutzte Routinen den Flash schon belasten. So brauche ich nur die Routinen assemblieren, die auch verwendet werden. Die Routinen sind übrigens nicht perfekt, dafür aber selbstgemacht... > > Beste Grüße Nunja, ich hatte den Quelltext nicht zum Nachbau des (für Normalanwender uninteressanten) Projektes gepostet, sondern zum Analysieren, Verstehen und Besser(als_ich)machen, dabei ging es eigentlich nur um die jitterarme Synchronisation. Einige Tipps, die ich für selbstverständlich hielt (z.B. OUT statt SBI/CBI) hat Dir ja Peter bereits gegeben. Übrigens erfolgt die Ausgabe des Pixelstroms nicht per normale Portzugriffe, sondern per Hardware-SPI. Anders wäre das Tempo gar nicht zu schaffen. ...
Angehängte Dateien:
-
linie03.jpg
320 KB
@Hannes > Übrigens erfolgt die Ausgabe des Pixelstroms nicht per normale > Portzugriffe, sondern per Hardware-SPI. Anders wäre das Tempo gar nicht > zu schaffen. Ist schon klar. Ich hab die Portausgabe nur zur Vereinfachung des Problems gewählt. Text kommt bei mir auch über SPI. Für ein einfaches Fadenkreuz brauch ich auch keinen SPI. Nunja, ich bitte um Nachsicht. Ich bin an diesem Projekt erst seit drei Tagen dran. Da ist noch Vieles (z.B. OUT statt SBI/CBI) nicht berücksichtigt worden. Die meisten Sachen programmiere ich in AVR-Basic und nur gelegentlich, wenn es notwendig ist in Assembler, deshalb bin ich da nicht so firm drin.
Was hast Du nur immer mit dem "Power-Down"? Der ist für diesen Zweck nicht erforderlich... ...
Hallo Zusammen, mir ist zwar klar, was die Schaltung macht, sieht man ja schön in den Bildern, aber ich rätsele die ganze Zeit, für was OSD steht? Gruß, chris
chris wrote: > Hallo Zusammen, > > mir ist zwar klar, was die Schaltung macht, sieht man ja schön in den > Bildern, aber ich rätsele die ganze Zeit, für was OSD steht? > > Gruß, > chris Texteinblendung, allgemein auch als On Screen Display bekannt... ...
Ah, jetz ja, Danke! Mann hätte es ja auch TEB nennen können ....
hallo , das was du machst funktioniert nicht wegen dem luftfilter ....
Da habe ich mal gegurgelt nach Übertakten von Ats, bin mal wieder hier im Forum gelandet und dachte mir nur so... ... wtf...??? Das ist 12 Jahre alt? Wieso hat noch niemand ne WaKü für Ats auf dem Markt? Wenn Der8auer das erfährt, bringt er ein At-System mit N2-Kühlung, auf dem FIFA 21 in HD mit 144 FPS läuft, samt GBit-LAN ^^ Im Ernst, extrem spannendes Thema. Ich wollte eigentlich nur von 16 auf 18,4320 MHz rauf, aber wenn ich das hier sehe... Baut ihr da was gegen Fehlertoleranz in den Code, oder lasst ihr es einfach krachen?
Von 16 auf 18,4 würde ich einfach so riskieren, da gibts eine sehr hohe Wahrscheinlichkeit, daß der das ohne Probleme packt. Bzw. es gibt ja generell AVRs, die 20Mhz packen - wieso nicht einen von denen nehmen?
Carsten P. schrieb: > Im Ernst, extrem spannendes Thema Was ist denn daran spannend, seine System so weit zu pimpen, bis sie nicht mehr zuverlässig funktionieren? Das kannst du mit allen Dingen tun: - Autos (ganz beliebt) - Computer jeder Art - Regale überladen (Stahlblech kracht besonders überraschend zusammen) - So viele Klaviere ins Obergeschoss stellen, bis das ganze Haus zusammen fällt - Oder das Badezimmer abdichten und voll laufen lassen Mal ehrlich, das ist nur was für dumme Teenager.
Die gnaze Nummer ist nur deswegen entstanden, weil der TE damals den Aufwand gescheut hat, das Jittern mit einem Genlock zu beseitigen. Da muss nichts übertaktet werden, da der Hauptoszillator selber auf H-Sync gelockt wird. Gut, man muss ne PLL bauen, aber das ist bei 16-20Mhz ja kein Hexenwerk. Lässt man den AVR mit 4*Fsc laufen (17,734MHz), geht sogar PAL Farbe. Auch AVRMario läuft mit lockeren 19,6MHz.
:
Bearbeitet durch User
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.