www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ATMEGA32 gnadenlos übertaktet mit 40MHz


Autor: Winne Z. (rugbywinne)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tilo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann es sein, dass das Quarz gar nicht anschwingt? Schon mal mit nem 
Oszi gemessen?

Autor: Bernd das Brot (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bild!!??

Autor: Winne Z. (rugbywinne)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
ja Bild

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Winne Z. (rugbywinne)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Tilo
Quarz schwingt - beide Oszilatoren sehen auf den Oszi gleich aus.

Autor: mr.chip (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Algorithmus verbessern? Wohl kaum. Pro Pixel hat man selbst bei 20 MHz 
nur wenige Taktschritte, da gibts nichts mehr zu optimieren.

Autor: Jochen Müller (taschenbuch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dieter Werner (dds5)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: winne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)).

Autor: Winne Z. (rugbywinne)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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".

Autor: Gunni H. (gunni)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Versuchst du auch alles mit dem gleich AVR, oder hast du immer andere?
nicht, das plötzlich der andere auf internen Takt eingestellt ist.

Autor: Winne Z. (rugbywinne)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.)

Autor: raoul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Atmelhasser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-))

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Atmega8 Atmega8 (atmega8) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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.

Autor: Winne Z. (rugbywinne)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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)

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: 3362 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Normalverteilung?

Autor: Winne Z. (rugbywinne)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: peter-neu-ulm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: lkmiller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: peter-neu-ulm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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<

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: Hannes Lux (hannes)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

...

Autor: Hannes Lux (hannes)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

...

Autor: Hitzkopp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>sondern ein stinknormaler Mega8

Normal ist langweilig! höher, schneller, weiter

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hannes:

Wie sieht denn die Schaltung zu dem OSD-Generator aus?
(Bin wieder da, hehe :) )

Autor: Hannes Lux (hannes)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

...

Autor: Hannes Lux (hannes)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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... ;-)

...

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm - ist ja einfach... Im Code stecht die wahre Intelligenz, nehme ich 
an ;-)

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

...

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na wenn´s weiter nichts ist ;-)...

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Travel Rec. wrote:
> Na wenn´s weiter nichts ist ;-)...

Eben... - Mit "WAITms 20" gehts allerdings nicht... ;-)

...

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Höhö - is klar! Immer druff!

Autor: Winne Z. (rugbywinne)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Könnte es vielleicht hilfreich sein, den Takt mit einer PLL auf den vom 
LM1881 gelieferten HSync zu synchronisieren?

Autor: Winne Z. (rugbywinne)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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 ?

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

...

Autor: Winne Z. (rugbywinne)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)))

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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%2...


Peter

Autor: Winne Z. (rugbywinne)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Winne Z. (rugbywinne)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
> 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 ?

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Winne Z. (rugbywinne)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hannes Lux (hannes)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

...

Autor: Winne Z. (rugbywinne)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was hast Du nur immer mit dem "Power-Down"?

Der ist für diesen Zweck nicht erforderlich...

...

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

...

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ah, jetz ja, Danke!
Mann hätte es ja auch TEB nennen können ....

Autor: bettla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo , das was du machst funktioniert nicht wegen dem luftfilter ....

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.