Bildmuster-Generator Programm mit Bascom erstellen möglich?

[Micha]

Hallo,

an alle:
Ich frage mich, ob die Erstellung eines Programms (für AVR-Controller), welches Bildmuster (Testbilder für TV) erzeugen kann, nur den Assembler-Programmierern vorbehalten bleibt.

Ich selbst programmiere gerne in BascomAVR, welches ein Inline-Assembler hat. Natürlich stellt sich für mich die Frage, ob das mit BascomAVR auch realisierbar ist.

Die Frage geht also an alle AVR-Programmierer, die in C, Assembler und/oder mit BascomAVR Programme erstellen.

Ist es möglich mit BascomAVR ein Programm zu erstellen, das verschiedene Bildmuster als RGB (Farbbild) und als BAS (Graustufen) ausgeben kann.

Gruß Mitch.

 

[Nomis3000]

Ich denke schon dass es möglich ist.
Du musst nur die Timings für die zeilen und bildweise Synchronisation mit den TimerCounter Interrupts richtig treffen und dazwischen beispielweise mit Zählwerten, die in den Interrupts für die Zeilensynchronisation hochgezählt und in bei der Bildsynchronisation rückgesetzt werden, einen Farbverlauf von Oben nach Unten erzeugen.

 

[Dirk]

Hallo Mitch,

ich denke man kann schon Testmuster darstellen, wie Nomis schon erwähnt hat: Wichtig ist das Timing.

Mit Assembler hat man hier natürlich Vorteile, da man die Anzahl der Machinenzyklen für jede Instruktion kennt, man hat hier das Timing eher im Griff.

Ich wähle einfach mal den Punkt "ich kann es nicht ausschließen", lieber hätte ich gewählt "bedingt möglich" oder ähnliches

Grüße,
Dirk

 

[dino03]

Also die Wahrscheinlichkeit das es mit BASCOM funktioniert ist meiner
Meinung nach unter 50%. Ein Bildmustergenerator für TV arbeitet schon mit
ziemlich hohen Frequenzen (Pixeltakt). Da ist nicht mehr viel Platz für
irgendwelchen Firlefanz vom Compiler. Um ein stabile Bild aufzubauen
kommt es dabei schon sehr genau auf das Timing an. Ich weiß beim besten
willen nicht, ob das mit dem BASCOM-Compiler wirklich sichergestellt ist.

Selbst bei C würde ich da nicht die Hand für ins Feuer legen.

Bei Assembler kann ich genau bestimmen, wieviele Taktzyklen welche
Routine benötigt und kann sie notfalls genau anpassen oder etwas
verbiegen damit es vom Timing paßt. So viele Eingriffsmöglichkeiten
hat man bei BASCOM oder C nicht.

Rechnen wir mal ganz grob ...
25 Vollbilder/sec , 256 Zeilen , 256 Pixel/Zeile => 1,64MHz Pixeltakt
oder anders ausgedrückt => ca 0,6us pro Pixel Zeit (600ns)

Einen 20MHz Prozessor (ATmega48,88,168,328,644) wüürde ich da
auf jeden Fall empfehlen. Eventuell sogar übertakten.

Wieviel sich die Teile übertakten lassen weiß ich aber nicht
(will ich irgendwann mal interessenhalber testen).

Bei 20MHz hast Du dann 12 Taktzyklen (Befehle) pro Pixel zur Verfügung.
Unterprogramme kannst Du vergessen (zuviele Push/Pop die Zeit brauchen).

Einzigste Chance sehe ich in einem Farbbalken-Generator wo jede Bildzeile
in der Farbe unverändert bleibt. Also ohne Pixel-Gewurschtel.

Denn mal viel Spaß mit C oder BASCOM

Gruß
Dino

 

[Dirk]

Ich meine Markus hatte sich mal bei einem Bascom-Beispiel den resultierenden Code angesehen im Bereich eines Interrupt-Events. Bascom hatte hier ALLE 32 Register in den Stack gesichtert Da geht natürlich einiges an Zeit verloren Es kann natürlich sein, dass man dies auch bei Bascom irgendwie verhindern oder die Anzahl der gesicherten Register minimieren kann, das weiß ich jetzt leider nicht.

Dirk

 

[Micha]

Hallo,

das sind ja interessante Meinungen, die sich da rauskristallisieren.

Bis jetzt sieht es ja fast so aus, das Bascom-Programmierer offensichtlich in der Minderheit sind.

Keiner glaubt offensichtlich wirklich, dass es mit Bascom möglich ist. Natürlich müste man den Inline-Assembler verwenden. Ohne gehts bestimmt nicht.

Vielleicht sollte man dazu sagen, dass die gewünschten Testbilder keinen Text enthalten sollen.

Lediglich Testbilder wie Farbbaklen, Senkrechte Linien, Horizontale Linien, Gitter, Schachbrett und solche Dinge. Keine komplexen Bildmuster mit Kreisen usw.

Mitch.

 

[Dirk]

Doch doch,

man wird schon Testmuster erstellen können (behaupte ich jetzt einfach mal ), Dino ist auch der Meinung, bis jetzt hat noch keiner gesagt, dass es nicht geht Allerdings hat man hier mit Assembler erhebliche Vorteile.

Dirk

 

[dino03]

Hi Dirk,

Ich meine Markus hatte sich mal bei einem Bascom-Beispiel den resultierenden Code angesehen im Bereich eines Interrupt-Events. Bascom hatte hier ALLE 32 Register in den Stack gesichtert Da geht natürlich einiges an Zeit verloren Es kann natürlich sein, dass man dies auch bei Bascom irgendwie verhindern oder die Anzahl der gesicherten Register minimieren kann, das weiß ich jetzt leider nicht.

genau den Teil habe ich im Moment noch vor dem geistigen Auge. Das war
wunderbar eingerückt und so. Aber es waren tatsächlich alle Register
und das für so ein kleines wurzeliges Unterprogramm mit ein paar Assembler-
Zeilen. Ich möchte nicht wissen, wieviel Zeit BASCOM mit dem Sichern von
Registern auf dem Stack verbrennt. Ich schätze mal so auf min 5-10% der
Leistung gehen für PUSHs und POPs drauf. Die verbrauchen ja pro Befehl
2 Taktzyklen. Wenn man also ein Register sichert sind das 4 Taktzyklen
und damit bei 20MHz schon mal 200ns. Bei 32 Register + StatusRegister
sind das grob über den Daumen 6,4us Zeitverschwendung. Au weia !!!

Bei einem Farbbalken hast du bei 25 Vollbildern/sec und 256 Zeilen
pro Zeile 156us Zeit von der bereits für ein einfaches Unterprogramm
ca 6,4us verbrannt werden ohne auch nur ein bischen getan zu haben.

So viel zu BASCOM und zeitkritischen Anwendungen....

Ich fürchte, das du den Synchronimpuls am Anfang der Zeile nur mit
eingebettetem Assembler halbwegs stabil zum laufen bekommst.

Aber bei C sieht es wohl auch nicht sehr viel besser aus. Da muß man den
Compiler wohl auch sehr gut optimieren lassen.

Nicht das ich jetzt falsch verstanden werde. Ich will hier nix mies machen.
Versucht es einfach und wenn es läuft lasse ich mich gerne überzeugen.
Aber vor der Programmierung würde ich mir erst mal das Timing genau
zusammenrechnen um nachher nicht ins kurze Gras zu kommen.

Wär ja mal interessant rauszufiltern, wie groß der Anteil an PUSHs und
POPs prozentual zu anderen Assembler-Befehlen bei den verschiedenen
Compilern ist.

Gruß
Dino

 

[Nomis3000]

Selbst bei C würde ich da nicht die Hand für ins Feuer legen.

C hat aber eindeutig bewiesen dass es dazu fähig ist. (Es gibt genügend Beispiele im Netz.)

Und ich denke nicht dass es mit Bascom um soviel schlimmer wird.(und glaubt mir, ich bin ein Bascom-Hasser)
Auch wenn es wirklich so ist wie Dirk meint, was Markus behauptet, und bei Bascom vorher alle Register in den Stack gerettet werden, kann es immernoch funktionieren. Weil sich dadurch nur die Synchronieierimpulse (zeitlich)verschieben und während der Zeit in der die Register gerettet werden nur keine Veränderungen am Bild möglich sind.

Es ist daher durchaus möglich das mit Bascom ohne Inline-Assembler durchzuführen, auch wenn man den Bildschirminhalt am rechten Bildschirmrand(da werden die Stackoperationen druchgeführt)nicht mehr ändern können wird.

 

[Dirk]

Nomis, aber du möchtest ja nicht nur den horizontalen und vertikalen Synchronimpuls erzeugen, sondern im sichtbaren Bereich noch ein bisschen "Muster malen". Ich behaupte jetzt nicht, dass es mit C nicht geht! Wenn man weiß, dass da zum Beipspiel eine konstante Zeit für die Sicherung von Registern benötigt wird, kann man da drauf reagieren, bzw. dieses berücksichtigen, schwerer stelle ich es mir vor, wenn man nicht weiß, was der Compiler hier und da so alles noch macht.

Dirk

 

[dino03]

Hallo Nomis,

C hat aber eindeutig bewiesen dass es dazu fähig ist. (Es gibt genügend Beispiele im Netz.)

ok überredet

Und ich denke nicht dass es mit Bascom um soviel schlimmer wird.(und glaubt mir, ich bin ein Bascom-Hasser)
Auch wenn es wirklich so ist wie Dirk meint, was Markus behauptet, und bei Bascom vorher alle Register in den Stack gerettet werden, kann es immernoch funktionieren. Weil sich dadurch nur die Synchronieierimpulse (zeitlich)verschieben und während der Zeit in der die Register gerettet werden nur keine Veränderungen am Bild möglich sind.

Es ist daher durchaus möglich das mit Bascom ohne Inline-Assembler durchzuführen, auch wenn man den Bildschirminhalt am rechten Bildschirmrand(da werden die Stackoperationen druchgeführt)nicht mehr ändern können wird.

wie willst du zB vertikale Linien erzeugen ohne IF-Abfragen im Verlauf der
Zeile ? Und wenn bei den IF-Abfragen und den Befehlen in der Bedingung
zufällig der gesamte Registersatz gesichert wird sieht das vom Timing
echt eng aus. Bei 16 Linien pro Zeile liegst Du bereits bei 9,75us von
Linienanfang zu Linienanfang (ohne die Zeit des Sync-Pulses mitzurechnen).
Also bei einem Sichern bleiben dir davon nur noch gute 3us Rest.
Interrupts würde ich absolut außen vor lassen. Das wird mit absoluter
Sicherheit garnix da bei einer ISR mit absoluter Sicherheit der gesamte
Registersatz auf den Stack geschoben wird. Wenn dann kommt man nur
ohne Interrupts zu einem Ergebnis.

Darum meine ich ja :
- Farbbalken => OK
- Muster (Gitter, Vertikale Linien, ...) => sieht schlecht aus, aber nicht unmöglich.
- Schachbrettmuster wäre möglich (8x8 Felder)

Aber ohne genaue Timingberechnungen artet das sowieso alles in
Kaffesatzleserei aus. Also Timing für das gewünschte Muster bauen
und dann nen Test starten. Nur Ergebnisse zählen. Dann wissen wir
es genau

Gruß
Dino

 

[Micha]

Ich habe das gerade mal mit Bascom ausprobiert:

Push r24 (2 Takte)
Pop r24 (2 Takte)

Außerdem lassen sich Interruptaufrufe konfigurieren, ohne register-Sicherung

Config oc1a Label_Routine NOSAVE

Die Option Nosave machts möglich.

In der Routine ist man nach Auslösen des Interrupts nach 5 takten.

Gehts in Assembler schneller?

 

[Cassio]

Hallo zusammen!

Ich weiß nicht, ob mein PDF-Dokument etwas weiter hilft....
aber ihr könnt ja mal rein schauen.
(Wollte es anhängen..... was aber leider zu groß)

Video-AVR

Fragt mich nicht mehr wo ich das her habe.......
War auf irgendeiner CD mit BASCOM mal dabei.


Grüße,
Cassio

 

[Micha]

Hallo Cassio,
das Teil gibt zwar Text aus, aber nur schwarz/weis und das auf VGA-Monitor.

Farbe ist in der Beschaltung nicht möglich.

Schade, dass kein Code abgebildet ist. da könnte man sich bestimmt was abschauen.

Trotzdem danke für den Beitrag.

 

[dino03]

Hi Micha,

Ich habe das gerade mal mit Bascom ausprobiert:

Push r24 (2 Takte)
Pop r24 (2 Takte)

Außerdem lassen sich Interruptaufrufe konfigurieren, ohne register-Sicherung

Config oc1a Label_Routine NOSAVE

Die Option Nosave machts möglich.

wär ich vorsichtig. Kannst Du sicherstellen, das in deinem Hauptprogramm
andere Register verwendet werden als in deiner InterruptServiceRoutine ?
Sonst hast du schönen Datenmatsch in den Registern. Und um die
Sicherung des Status-Registers (Carry,Zero,...) kommst du nicht drum rum.
Das geht aber mit IN und OUT jeweils innerhalb eines Taktzyklus.

In der Routine ist man nach Auslösen des Interrupts nach 5 takten.

Gehts in Assembler schneller?

Ich glaube mal, das kann so nicht ganz passen

Das folgende hab ich mal in einem anderen Thread geschrieben nachdem ich
das Datenblatt eines ATmega168 genau gelesen hab. Da hab ich auch eine
schnelle Reaktion auf Interrupts benötigt. Also ähnliches Problem.

Nach der Berechnung des Timings ist das jetzt ...
- 4 Taktzyklen bis zur Auslösung des Interrupts (Eingang, Hardware)
- 4 Taktzyklen für die Ausführung des Interrupts (Push PC, Load Vector, ...)
- 3 Taktzyklen für den Sprung zur ISR (Jump INT0/INT1)
- 65 Taktzyklen für das Innere der ISR (maximal)
- 4 Taktzyklen für Rücksprung aus der ISR (RETI, Pop PC, ...)
damit habe ich 65*50ns => 3,25us Luft für die ISR

Selbst wenn Du den ersten Punkt wegläßt braucht der Prozessor für den
Aufruf der ISR 4+3 = 7 Taktzyklen (Absolutes Minimum!) Das ist nur das
Sichern des Programmzählers, das Laden des Interruptvektors und der
Sprungbefehl beim Interruptvektor ohne den Rücksprung, der nochmal
4 Taktzyklen benötigt. Also gesamt 11 Taktzyklen ohne jetzt die
hardwareseitigte Auslösezeit oder irgendwelche Registersicherungen
mitzurechnen. Bei 20MHz ist ein Taktzykus 50ns lang.

Gruß
Dino

 

[Nomis3000]

@Cassio: Das Beispiel nutzt aber den MOSI-Pin vom SPI, und ist deshalb nur Zweifarbig.
Edit: Zu spät.
@Dino: Auf IF Abfragen wird man zwar nicht ganz verzichten können, aber man kann sich damit sicher irgendwie auf den Anfang einer Zeile beschränken. Ich denke dabei daran den Ablauf jeweils der Zeilen, welche gleich aussehen, nur einmal auszuprogrammieren und am Anfang einer Zeile nur die entsprechende Zeilenroutine aufzurufen.

 

[Micha]

Wenn du bascom hast, kannst du es ja mal ausprobieren. der Simulator zeigt 5 Takte an für den Strung in die interrupt-Routine. Raus braucht er auch nach 2 oder 3 Takte (nicht sicher). Aber was sind 10 takte bei 20 MHz? - Ein Furz (sorry). 10 Takte = 0.5µs. Das ist doch schnell genug!

 

[Nomis3000]

Bei 20MHz ist ein Taktzykus 50ns lang.

Dann hast du, wenn man sich das Timing ansieht, mindestens 100 Taktzyklen Zeit dich auf die Zeilenausgabe vorzubereiten, 1000Taktzyklen die Zeile auszugeben und 30Zyklen den Interrupt für die Synchronisation aufzurufen. Für die Synchronisation selbst hast du dann Zeit genug.

 

[Micha]

Habe nochmal tetestet

Folgendes Programm zur ermittlung der Takte zum Sprung in die ISR und zurück ohne Register-Sicherung:

' Aufruf eines Interrupts
' Dauer der Interrupt-Routine

$regfile = "m48def.dat" ' ATmega88
$hwstack = 24
$swstack = 24
$framesize = 24
$crystal = 20000000 ' 20MHz Takt

' Interrupt definieren

on int0 ISR_INT0 NoSave ' Interrupt-Routine ohne Register-Sicherung
enable int0 ' Int0 erlauben

enable interrupts ' Global Interrupts erlauben

' Hauptschleife

do
nop
loop

end

' Dauer: 9 Takte einschließlich Rücksprung
ISR_INT0:
' ohne Inhalt
Return

---------------------------------------------------

Das Dauert genau 9 Takte (keine 11)
5 Takte rein, und 4 zurück.

 

[dino03]

Hi Cassio,

Ich weiß nicht, ob mein PDF-Dokument etwas weiter hilft....
aber ihr könnt ja mal rein schauen.
(Wollte es anhängen..... was aber leider zu groß)

Video-AVR

Fragt mich nicht mehr wo ich das her habe.......
War auf irgendeiner CD mit BASCOM mal dabei.

ich habs mal grob überflogen. Er hat den Pixeltakt mit dem Hardware-
Schieberegister des SPI-Interfaces erzeugt. In der Interrupt-Routine
wird anscheinend nur das Datenregister neu geladen. Aber alles in SW.
In Farbe wird man es nur mit AD-Wandlern (R2R-Ketten) hinbekommen.
Das VU-Signal (Farbphasen) direkt erzeugen wird bei Mustern wohl
eher gegen <5% Erfolgsaussicht gehen.

Aber wie gesagt. Wir können lange drüber quatschen aber im Endeffekt
wird nur ein Test zeigen ob es geht oder nicht

Gruß
Dino