Ich arbeite momentan an einem Programm zur Videosignalerzeugung. Ich
möchte nämlich einen Fernseher als Display benutzen. Ich habe dafür
einen at90S8535 bei 8 MHZ eingesetzt. Programmiert wird das ganze mit
dem GNU Compiler, also in C. Und da liegt auch schon der Haken. Ich habe
es zwar mittlerweile geschafft, mehrere Rechtecke auszugeben, doch dies
gelang mir nur über sehr umständliche Wege. Dabei war das Hauptproblem,
dass in If-Verzweigungen oftmals die Variablenwerte nicht richtig
abgerufen wurden bzw. nicht aktualisiert wurden. Die Folgen kann man
sich ja denken. Meine erste Idee bestand darin jeweils ein Delay vor
eine Abfrage zu setzten, doch das half auch nicht weiter. Dann machte
ich jedoch eine merkwürdige Entdeckung: Ich verwendete statt eines
Delays einen einfachen Timer-Reset, also eine Zurückstellung auf 0, und
all meine Probleme waren gelöst. (Der entsprechende Befehl lautet:
start_timer_8();) Die Variablenwerte wurden nun korrekt aktualisiert
und das Programm lief flüssig. Kann sich das jemand erklären?
Der Code, und ein Testbild befindet sich im Anhang.
Ich hab' mir Dein Programm jetzt nicht näher angeschaut, aber die
Symptome mit den nicht aktualisierten Variablen deuten eigentlich auf
das übliche Variablen-im-Interrupt-verändern hin:
Der C-Compiler geht davon aus, daß sich Variablen nicht "einfach so"
ändern. D.h. wenn man z.B. sowas schreibt:
a = 3;
a += 1;
Dann geht der Compiler davon aus, daß sich a zwischen der ersten und
zweite Zeile nicht verändert hat. Das ist auch meistens so, außer wenn
man z.B. die Variable im Interrupt ändert.
Dagegen hilft, daß man die Variable als "volatile" deklariert, dann
stimmt das wieder.
bye
Markus
Hmpf - ich stehe mit C auf dem Kriegsfuß. Für mich sieht das immer so
aus, als ob ein Haustier auf der Tastatur rumgelaufen ist...
Mal ne Frage: Wenn ich das richtig interpretiere, dann war Dein Delay
vorher per Verzögerungsschleife realisiert. Dann könnte auch die Ursache
sein, daß ein "dazwischengeschobener" Interrupt das Delay verlängert
hat. Solche zeitkritische Geschichten sollte man immer mit einem Timer
machen.
Ich bin dem Rat gefolgt und habe volatile vor die
Variablendeklerationen geschrieben und die Interuptmethode abgeschafft.
Doch das Ergebnis ist, wie auf dem Bild zu erkennen immer noch
unzureichend (stark verzerrt). Könnt ihr euch den Code mal genauer
ankucken? Ich vermute, dass ich einfach etwas unsauber geschrieben
habe.
kurze frage ich bin grade dabei mir den urschleim von c reinzuziehen,
ich verwende avredit weil das wegen der ide so leicht zu bedienen ist,
mit der thematik externe variablen, bin ich schon recht gut zurecht
gekommen, jedoch ist in einem codebeispiel mir etwas sehr fremdes
aufgefallen,
da ist ein funktion die als extern deklariert,
extern inline funktion(), was das extern nun heist, ist mir klar aber
die bedeutung von inline, hab ich nirgend wo finden können, kann mir
einer sagen welche bedeutung dies hat ?
Inline gibt dem Compiler die Empfehlung den Code "einzubetten" also
nicht zur Funktion zu springen, diese auszuführen und zurückzuspringen
sondern den Code an jeder benötigten Stelle zu wiederholen. (Etwas
schneller da keine Sprünge gemacht werden müssen verbraucht halt mehr
Platz)
Keine Ahnung ob und welcher Compiler dies für die AVR's überhaupt
beachtet.
mfg
SiSt
Ja, es liegt eindeutig an der AVR-Programmierung. Mit der anderen
Version läuft es ja auch halbwegs. Es muss irgendwas mit dem Timing zu
tun haben. Ich will nicht wissen, wie lange ich schon dran rumprobiert
habe, ohne wirklichen Erfolg; daher hoffe ich ja auf Hilfe.
Hi, vielleicht helfen Dir die beiden Links weiter:
http://instruct1.cit.cornell.edu/courses/ee476/video/index.html (Mehr in
C)
http://members.ozemail.com.au/~intello/video_s_w.htm (ass)
Zumindest die Screenshots sehen sehr sauber aus.
Auf einer Uni-Seite (habe leider den Link verhauen) stand etwas von den
Problemen mit den Verzerrungen. Das Videosignal ist etwas empfindlich,
was das Timing angeht. Es soll am Besten funktionieren, wenn das Bild
vorberechnet wird und der AVR das Bild als Ganzes im Sleep-Mode
rausschickt.
(Nach knapp 8-jähriger Lötkolbenabstinenz, wird dies wohl mein erstes
Projekt werden.)
Hi, ich wieß nicht ob dir das weiterhilft aber
in der Juni Ausgabe von Elektor ist ein TV-Tennis Spiel mit dem
AT90S8515 realiesirt worden.
Das Programm ist aber in Assembler geschrieben.
Ich hab dir das ZIP mal drangehängt.
Viel Erfolg
Simon
Die Projekte kenne ich bereits. Ich habe auch sehr viele verschiedene
Methoden ausprobiert.
habt ihr euch schon mal meinen Code genauer angekuckt? Ich vermute, dass
ich einfach irgendeinen blöden Fehler gemacht habe, den ein erfahrener
Programmierer sicher finden wird.
Hallo,
hat jemand noch die Elektor Ausgabe Juni 2003 und kann mir
den Artikel zukommen lassen? - ich bin sehr interessiert an der
vollständigen Beschreibung der Schaltung und der Software.
Tobias.
ich trau mir mal folgende Aussage zu: "vergiss c für diese Anwendung
und die 8MHz werden bald 16 werden"
Bei 8MHz braucht ein einzelner Maschinenbefehl 125ns, der sichtbare
Teil einer Zeile hat 50us -> 400 Maschinenbefehle pro Zeile. Wenn eine
if Abfrage des "Video-Rams" & Ausgabe auf den Port-Pin 10
Maschinenbefehle braucht kommst du auf eine horizontale Auflösung von
40 Pixel. Für eine Videoausgabe würde ich das als unbrauchbar
einstufen.
Ich glaube du wirst um folgende Realisierung nicht herumkommen:
in der Austastlücke (Sync, etwa 12us) vom Video-Ram in Register
kopieren und dann die Register auf einen Port shiften. Alle Varianten
von if oder anderen Abfragen verursachen ein Jittern oder bei Korrektur
eine schlechtere Pixelanzahl.
grüsse leo9
Hallo Ng,
sowas hatte ich auch schon vor, daher suche ich den "richtigen"
Prozessor ...
Das das bei 8 MHz nicht hinhaut, habe ich auch schon rausgefunden...
Da von oben nach unten das Rechteck immer kleiner wird, kann mann davon
ausgehen, das das FBA-Signal nicht richtig erzeugt wird ...
Was ich vorhabe: Kantenerkennung mit dem uC ...
Hat da jemand eine Empfehlung was den Prozessor angeht ? (Habe vorher
mit PICs gespielt ...)
Danke
Christian
