Hallo. Bin blutiger Änfänger was AVR+GCC abgeht ;-) Möchte diese beiden Projekte nachbauen: http://instruct1.cit.cornell.edu/courses/ee476/FinalProjects/s2004/kfm9/index.htm http://instruct1.cit.cornell.edu/courses/ee476/FinalProjects/s2005/gts7/index.html Habe winavr 4.1.1 installiert. Die Examples /twitest lassen sich ohne Probleme compilieren. Installation sollte also ok sein.. Ich habe den Makefile aus dem sample Ordner verwendet (mcu, f_cpu, target angepasst ;-). Aber ich bekommen eine 'Haufen' Fehlermeldungen.. #pragma ?? v1 v2 undefined? Fehle da was? Ist das evtl. für einen anderen C-Compiler geschrieben? Ich bin zu blöd (ziemlich sicher) Wäre toll, wenn mir da wer weiterhelfen könnte. Danke, Peter
Jo, das ist definitiv nicht für den AVR-GCC-C-Compiler geschrieben. Allein die #includes sind schon falsch. Könnte CodeVision sein, andere kommerzielle Compiler für AVR kenne ich allerdings nicht und kann sie deshalb auch nicht ausschließen.
Zitat: "For all examples, be sure to set the CodeVision compiler controls (in the Project:Configure... menu) to:..." Einfach nicht nur saugen, sondern auch mal die Links abklappern :-) Joachim
ok, sorry. Das habe ich auch jetzt beim 2ten schauen immer noch nicht gefunden..? Habe mir mal die Eval. Version geladen. Läßt sich compilieren ohne Error's.. Habe die Codesize liegt natürlich über den 2kb.. Und 90€ sind mir leider etwas zu viel.. Kann mir hier jemand das durch einen registierten CodeVision Compiler jagen und mir die HEX-Dateien senden (ATmega32 16MHz)? Kann man das rel. leicht nach winavr umsetzen? Danke, Peter
Hups.. Für ATmega reicht ja noch nicht einmal die Light Version.. Also Standard = 150 Teuro's - Wahnsinn.. Bin bereit einen kleinen Obulus für fertige HEX Dateien zu entrichten.. Trotz NTSC müßte ich doch eine S/W Darstellung sehen können..? Peter
Peter Sieg wrote:
> Trotz NTSC müßte ich doch eine S/W Darstellung sehen können..?
Naja, NTSC ist ja nicht alles. Es gibt ...zig verschiedene
Basis-Fernsehnormen, die sich insbesondere in den Bild- und
Zeilenfrequenzen unterscheiden.
Hmm. Habe jetzt fertige HEX-Dateien erzeugt. Wenn die nächste Reichelt Lieferung kommt, werde ich mal kurz aufbauen und einfach probieren, ob ich ein Bild bekomme... berichte dann an dieser Stelle wieder.. Danke+Gruß Peter
//cycles = 63.625 * 16 Note NTSC is 63.55 //but this line duration makes each frame exactly 1/60 sec //which is nice for keeping a realtime clock Das sagt eigentlich alles. Die 63.625 µs wären sicher verkraftbar (wir arbeiten mit 64 µs offiziell), aber 60 Hz Bildwiederholfrequenz wird deine Glotze wahrscheinlich nicht können. 50 Hz sind bei uns die Norm. Kann sein, dass es genügt, das hier anzupassen: if (LineCount==231) Hmm, knapp 3800 Zeilen Code in einer C-Datei, ist erstaunlich, dass da noch einer durchgeblickt hat.
1 | //cycles = 63.625 * 16 Note NTSC is 63.55 |
2 | //but this line duration makes each frame exactly 1/60 sec |
3 | //which is nice for keeping a realtime clock |
4 | |
5 | Das sagt eigentlich alles. Die 63.625 µs wären sicher verkraftbar |
6 | (wir arbeiten mit 64 µs offiziell), aber 60 Hz Bildwiederholfrequenz |
7 | wird deine Glotze wahrscheinlich nicht können. 50 Hz sind bei uns |
8 | die Norm. Kann sein, dass es genügt, das hier anzupassen: |
9 | |
10 | if (LineCount==231) |
11 | |
12 | Hmm, knapp 3800 Zeilen Code in einer C-Datei, ist erstaunlich, dass |
13 | da noch einer durchgeblickt hat. |
Nun, da ich auf reichelt warte, dachte ich mir ich könnte schon mal in den C-Code schauen.. falls ich doch von NTSC auf PAL umstellen muß/möchte.. Lt. wikipedia: NTSC - PAL 60Hz - 50Hz 525Z - 625 Zeilen was soll die cycles = 63.625 * 16 bedeuten? 63.625 = Zeitdauer für 1 Fernsehzeile in us. * 16 ??? von 16MHz, mit dem der AVR betrieben wird? Gesetzt wird die Variable: linetime=1018 mit dem Ergebnis aus 63.625*16 Für 64us * 16 würde sich hier 1024 ergeben..? Wäre das an dieser Stelle zu setzen für PAL? --- Dann kommt wohl die Stelle 'if (LineCount==231)' ab der unter anderem die Synchronisierung für die Fernseh-Seite generiert wird. Dies passiert wohl für NTSC alle 1/60 s. Aber wo wird das gesteuert? Da müßte doch ein Timer oder sowas getriggert werden..? Warum müßte ich linecount==? verändern? Dann vermutlich höher, damit der Aufbau 1 Seite länger dauert (eben nicht 1/60s, sondern 1/50s)? (Ja, ja.. schon wieder so ein Dummy, der lieber mal RTFM sollte ;-) Peter
Peter Sieg wrote: > Nun, da ich auf reichelt warte, dachte ich mir ich könnte schon mal in > den C-Code schauen.. falls ich doch von NTSC auf PAL umstellen > muß/möchte.. > Lt. wikipedia: > NTSC - PAL > 60Hz - 50Hz > 525Z - 625 Zeilen Naja, die Überschrift "NTSC vs. PAL" stimmt nicht ganz, es ist eher Norm B vs. Norm M: http://de.wikipedia.org/wiki/Fernsehnorm#Schwarzwei.C3.9F Aber ansonsten stimmt das. > was soll die cycles = 63.625 * 16 bedeuten? > 63.625 = Zeitdauer für 1 Fernsehzeile in us. > * 16 ??? von 16MHz, mit dem der AVR betrieben wird? Ja, du hast also 16 CPU-Takte pro Mikrosekunde. Das ist der Wert, der irgendwo dann in einen Timer gefüttert wird. Der liefert dann den Horizontal-Synchronimpuls, d. h. damit beginnt eine neue Zeile. > Für 64us * 16 würde sich hier 1024 ergeben..? Wäre das an dieser > Stelle zu setzen für PAL? Ja, kannst du probieren. > Dann kommt wohl die Stelle 'if (LineCount==231)' ab der unter > anderem die Synchronisierung für die Fernseh-Seite generiert > wird. Dies passiert wohl für NTSC alle 1/60 s. Aber wo wird das > gesteuert? Da müßte doch ein Timer oder sowas getriggert werden..? Es genügt, einen Teil mit dem Timer zu steuern, also die Zeilenfrequenz. Danach musst du nur noch die Zeilen zählen, damit ergibt sich die Bildsynchronisation von allein. Zu beachten ist, dass diese einfachen BAS-Generatoren keinen Zeilensprung generieren (englisch: interlace), daher sind die Zeilenzahlen in diesen Rechnungen nur halb so groß wie die, die der Fernsehnorm zu Grunde liegen. Das Norm-M-Bild hat als hier 262 Zeilen (zwischen den Vertikal-Synchronimpulsen), daher beginnt bei Zeile 231 die Bildaustastlücke (da wird für den Strahlrücklauf nach oben dunkel getastet). Das Norm-B-Bild hätte 312 Zeilen, da musst du nun (zum Beispiel empirisch nach ,,Aussehen'' -> kein schwarzer Balken oben oder unten) ermitteln, ab welcher Zeile die Austastlücke beginnt. Wenn ich mich dunkel an die alte selbstgebaute Bildschirmsteuerung meines ersten Eigenbau-Computers erinnere, so begann dort die Austastlücke nach 256 Zeilen (was sehr praktisch für den Aufbau des Bildwiederholspeichers war). Ich weiß nicht, ob sich der Rest dann von selbst ergibt in dem Programm. Kann natürlich sein, dass er einfach nicht in der Lage ist, die Zeilen von 231 bis 256 mit irgendwelchen Inhalten zu füllen, d. h. das Bild wird bei dir ein wenig ,,gequetscht'' aussehen. Du kannst auch probieren, die Bildwiederholfrequenz ein wenig nach oben zu ziehen, musst halt gucken, wie viel die Synchronisation deiner Glotze noch gewillt ist mitzugehen. Alte Glotzen mit von außen zugänglichem Vertikalfrequenzsteller sind da natürlich ein wenig im Vorteil. Gewissermaßen poor man's Multinorm-Fernseher. ;-)
Danke ersteinmal für die prompten und ausführlichen Antworten! Das macht mich doch zuversichlicht, das hin zu kriegen.. Ich habe den code jetzt mal so umgestellt und eine HEX Datei damit erzeugt: (Die Variablen TV_xxx habe ich natürlich weiter unten im code eingefügt und die Konstanten ersetzt ;-)
1 | //============================================================================== |
2 | // TV Variable Declarations |
3 | //============================================================================== |
4 | // for PAL comment the define NTSC 1 and uncomment the define PAL 1 |
5 | //#define NTSC 1 |
6 | #define PAL 1 |
7 | #ifdef NTSC |
8 | //cycles = 63.625 * 16 Note NTSC is 63.55 |
9 | //but this line duration makes each frame exactly 1/60 sec |
10 | //which is nice for keeping a realtime clock |
11 | //NTSC uses 262 lines, PAL uses 312 lines (for half picture) |
12 | #define lineTime 1018 |
13 | #define ScreenTop 30 |
14 | #define ScreenBot 230 |
15 | #define TV_BOT 231 |
16 | #define TV_VSS 248 |
17 | #define TV_VSE 251 |
18 | #define TV_SNF 263 |
19 | #endif |
20 | #ifdef PAL |
21 | //cycles = 64 * 16 = 1024 |
22 | #define lineTime 1024 |
23 | //312 - 262 = +50 |
24 | //need to adjust screen painted area to the middle by adding 50/2=25 lines to top and bottom |
25 | #define ScreenTop 55 |
26 | #define ScreenBot 255 |
27 | //NTSC value +50 |
28 | #define TV_BOT 281 |
29 | #define TV_VSS 298 |
30 | #define TV_VSE 301 |
31 | #define TV_SNF 313 |
32 | #endif |
Mal sehen.. kann ich leider erst probieren, wenn die Hardwareteile da sind.. Evtl. bekommt ja hier jemand Lust, sich die Teile auch nachzubauen.. Peter
Kurzer Zwischenstand. Gerät ist aufgebaut und geht. NTSC Version läuft am CBM BAS Grünmonitor. Bei der versuchten PAL Version ist die Bildschirmanzeige ca. 3-5cm nach oben verschoben und der untere Bildschirm enthält 'Schmutzzeilen' etc. Da muß ich also noch mal schauen.. genauso wie mir das Ganze am TV anzusehen.. Peter
So.. auch am PAL TV läuft die NTSC Version ohne jedes Problem..? Ist ein älteres 37cm TV. Anschluß über Cinch-Scart Adapter.. Hmm.. also geht bei mir zumindestens ohne Softwareanpassungen.. Peter
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.