Ausgabe eines Textes auf TV

Hallo Peter,

Zitat:

---

dein sourcode dazu wäre interessant

---

Klar du bekommst den.
Aber warte erst, bis ich das fertig habe.
Das Sammelsurium an Bugs und unausgegorenen Ideen,
an dem ich zur Zeit rumbastele, möchte ich dir so nicht geben.
Wenn ich soweit fertig bin, werde ich darin aufräumen, optmieren
und kommentieren und dann werde ich die Source hier reinstellen.
So wie der Code jetzt aussieht, bringt er niemandem was,
der nicht meine Gedanken im Kopf hat.

Ich habe heute eine irrwitzige Idee verfolgt:
Ich habe versuchsweise die Videodaten aus dem SPI-Port herausgeshiftet.
Damit könnte ich die Auflösung horizontal und vertikal nochmal wesentlich steigern.
Klappt auch, geht schön schnell, und entlastet den Prozessor um einiges.
Leider ist dieses blöde SPI-Port lo-aktiv, so dass ich entweder einen
externen Inverter, Transistor oder so brauche,
oder ich muss das Signal quasi verkehrtherum erzeugen,
und die 5V-Leitung als Masse nehmen.
Beides gefällt mir nicht. Externe Bauteile ausser den Widerständen
kommen auf keinen Fall in Frage - da könnte man ja gleich einen
Grafikchip nehmen. Und so verkehrtherum anschliessen ist auch nicht schön.
Also hab ich es wieder gelassen. Ist sowieso nicht genug RAM da.
Aber eine geile Idee war es schon.

Schöne Grüße und Vielen Dank für dein großes Lob.
Mach nur weiter so! Das geht mir runter wie Öl. :-)

Bis dann...Jan

Was hast du denn gegen ein, zwei externe Bauteile? Selbst gemacht bleibt es trotzdem noch... :-)

Gruß, Trabukh

Zitat:

---

Was hast du denn gegen ein, zwei externe Bauteile? Selbst gemacht bleibt es trotzdem noch...

---

Also ich kann es zwar nicht genau einschätzen, wie groß der Vorteil wäre, aber wenn er doch Spürbar ist, warum nicht, einen Inverter könnte man ja mit einem Transistor bauen. Aber ich will ja auch nicht zuviel von dir verlangen.

Erstmal muss ich sagen, dass ich es super finde, dass du das gemacht hast! Da suche ich solange schon nach ner vernünftigen Lösung für sowas, und du schreibst die "einfach" mal, besser als alles andere, was ich im WWW finde dahin ;-)
Dickes Lob!

MFG Moritz

Hallo,

Zitat:

---

...ein, zwei externe Bauteile? Selbst gemacht bleibt es trotzdem noch...

---

Klar, anfürsich hast du Recht !
aber ich hab es mir nun mal so in den Kopf gesetzt.
Nur der kleine Atmega8 für unter 3 EUR. Und die Widerstände.
Und sonst nix, kein Quarz, kein Garnix.
Sonst macht es mir keinen Spaß, da gibt es dann bessere Lösungen.
Ich will zeigen, was der nackte AVR-Chip kann.

Übrigens - ich habe Ruhe reingebacht,
das blöde Zeilenwackeln ist endlich weg.
War viel Aufwand, aber jetzt steht das Bild schön ruhig.
Als nächstes kommt scrollen.

Gruß Jan

Hallo Moritz,

Zitat:

---

Da suche ich solange schon nach ner vernünftigen Lösung für sowas

---

Hast du es ausprobiert ?
Pebisoft ist der einzige, der es immer austestet,
und mir mitteilt, ob es klappt.
Bei ihm geht es.

Ich werde die Baudrate einstellbar machen, für langsamere
Übertragungsstrecken. Infrarot wie beim ASURO und so.

Gruß Jan

hallo jan, könnte man nicht einen 2. avr, der eh für die anderen aufgaben gebraucht wird am robby verwenden, der den1. avr (video) sozusagen anschupps, damit wieder etwas ausgegebn werden kann.
ich finde einen 2. avr nicht so abwägig, es ist eine heausforderung. der 1. avr soll dann nur die reinen video-aufgaben übernehmen bis zum letzten bit. ich bin gespannt auf das neue update mit dem scrollen und der einstellbaren baurate. ich staune nur, was du so aus einem kleinen avr rausholen tust. es lebe der assembler. hoffentlich kapiere ich das auch einmal.
mfg pebisoft

Hallo Peter,

Zitat:

---

könnte man nicht einen 2. avr, der eh für die anderen aufgaben gebraucht wird am robby verwenden,

---

Ja, gute Idee.
Ich glaube auch, das ist das Beste.
Einfach die serielle Schnittstelle des AVRs mit dem Video-AVR verbinden,
und dann kann man einfach und problemlos
auch von Bascom aus was an den Video-AVR schicken.
Was über den USART senden ist ja in Bascom kein Problem.
Und so ein ATmega8 ist nicht gross, und kostet auch nur wenig.
Wesenlich besser, als wenn die Software noch mit dem Bascom
zusammen in einem AVR läuft.
Diese Videosoftware würde sowieso alles andere total ausbremsen,
weil sie mindestens 80-90% der Prozessorzeit selbst braucht.
Ganz zu schweigen von den anderen Einschränkungen, die man
in Bascom hätte.

Neue Version morgen.
Sieht schon super aus, mit den Scrollen.

Gute Nacht... Jan

Ja, ich werde es morgen mal austesten, habe die Mega8s erst letzte Woche bekommen. Wäre es nicht sinnvoller, die Baudrate zu erhöhen, damit die übertragung schneller geht? Könntest du mir eine mit 19200 schicken? das würde einiges erleichtern, oder ist die Umstellung sehr aufwendig? Wenn du mal etwas Zeit hast, würde mich interessieren, wie das Programm überhaupt aufgebaut ist.

MFG Moritz

Hi Moritz,
gerne baue ich für dich die 19200 mit ein.
Ist kein Problem, ich wollte die Baudrate ja sowieso
einstellbar machen.

Allerdings entsteht bei hohen Baudraten das Problem, das man
schneller senden kann, als das Programm es verarbeiten kann.
Da kann es dann passieren, dass einzelne Zeichen verschluckt werden.
Dürfte aber bei normaler sinnvoller Verwendung nicht vorkommen.
Aber man kann es provozieren, wenn man will.

Der Eingangsbuffer ist 64 Zeichen groß, als Ringspeicher organisiert.
Wenn der überläuft, geht halt was verloren.

Das Programm kann z.Z. 15000 Zeichen/sek von der RSR232 lesen
und in den Eingansbuffer schieben.
Es kann aber nur 1500 Zeichen/sek vom Eingangspuffer in den
Zeichenspeicher übernehmen, wenn es darstellbare Zeichen sind.
1500 reicht für 9600Baud dicke aus. Da sind max. 900 Z/s zu erwarten.
Bei 19200Baud reicht das nicht, wenn man wirklich permanent
mit "Volldampf" sendet. Wenn es portionsweise kommt,
mit Pausen dazwischen, dann gibts kein Problem.
Und so ist es in der Praxis ja auch - normalerweise.

Wenn Steuerzeichen kommen, oder wenn Scrollen nötig wird,
dann bremst das erheblich. Besonders das Scrollen.
Da muss der gesamte Zeichenspeicher verschoben werden.
Gescrollt wird mit 1200 Zeilen/sek.
Es braucht also ca. 20ms um die 24 Bildzeilen um eins hochzuschieben
und unten eine neue Leerzeile einzublenden.
In diesen 20ms werden keine Zeichen aus dem Eingangsbuffer verarbeitet.
Es werden aber weiter Zeichen von der RS232 empfangen und in dem
Eingangsbuffer abgelegt.
In den 20ms sind bei 19200Baud ca. 40 Zeichen zu erwarten.
Es kommt also gerade so hin mit dem 64-Byte Eingangspuffer.
Bei 19200Baud kommen ca. 2000 Zeichen/s an, und alle 28 Zeichen
muss gescrollt werden, weil die untere Zeile voll ist.

Du musst bedenken, dass ja "nebenbei" noch ständig
die Videosignalerzeugung syncron weiterlaufen muss.
Und da ist in der aktiven Zeit des Videosignales
alle 250 Nanosekunden ein neues Bit für einen Bildpunkt fällig.
Das TV wartet nicht.

Huh... Das ist wieder viel geworden.
Ich glaube nicht, dass du das so genau wissen wolltest,
aber ich muss diese Überlegung sowieso machen...
Da hab ich es dabei gleich mal hingeschrieben.

Also du bekommst die 19200, aber keine Garantie, :-)
dass das Terminal immer mitkommt.

Gruß Jan

Hi JanB, verwende doch die recht einfache XON/XOFF Methode wegen des Bufferüberlaufes. Wenn du es nicht eh kennst:
Ist der empfangsbuffer mehr als nn Prozent voll, wird ein XOFF (0x13) gesendet.
Unterschreitet der Buffer nun wieder (nn-x) Prozent, schickt man ein XON(0x11)
Die meisten Terminal-Emus spielen da freiwillig mit, ist aber auch leicht einzubauen.
(Geht natürlich nicht im Transparent-Mode)
mfg robert

EDIT: Will dir nicht dreinreden, du kannst aber auch IMMER, wenn du ein neues Bild refreshed und im Streß bist. XOFF schicken und erst, wenn du aus dem sichtbaren Bereich kommst und ein bißchen Zeit hast, ein XOFF, egal, wieviel grad im Buffer ist.