PropClock: Lauftext realisieren

OP #343450
Lesenswert?

Hallo zusammen,

ich hab' nun meine PropClock schon so weit, dass ich Text anzeigen
kann. Allerdings möchte ich den auch scrollen lassen. Prinzip zur
Anzeige:
- Text liegt als einzelne Zeichen im RAM
- In einem dynamischen Timer-Interrupt wird die jeweils nächste Spalte
ausgegeben
- Beim Ende einer Umdrehung beginnt die Ausgabe wieder von vorne

Soweit so gut. Nun häng' ich aber daran, mir etwas gescheites
auszudenken, damit der Text auch scrollen kann, sollte er denn zu lang
sein. Mein Ansatz wäre, nach der kompletten Umdrehung den Text noch
eine bestimmte Anzahl Spalten weiter zu rendern und sobald das Textende
erreicht ist, zum entsprechenden Zeichen am Anfang zu springen.
Das würde wohl grundsätzlich funktionieren, allerdings muss ich dann
nach dem Erreichen des Textendes den kompletten Text nochmal
durchgehen, um das entsprechende Zeichen zu finden. Das wäre wohl kein
Problem, allerdings sind in meinem Text ebenfalls noch
Formatierungs-Bytes vorhanden. Ausserdem gibt es Zeichen in der Grösse
5x8 (normal) und 3x8, die ebenfalls berücksichtigt werden müssen.

Hätte dazu evtl. jemand eine bessere Idee?
Ich hoffe, ich habe es verständlich erklärt.

Hardware:
ATtiny26, 8MHz interner Oszi
Ich progge in Assembler.

Besten Dank im Voraus und Gruss
Philipp Burch
#343452
Lesenswert?

Wie waere es mit einem Ringbuffer?
Der Schreibpointer beschreibt das Feld ganz normal und der Lesepointer
faengt an verschiedenen Positionen an zu lesen, wird bei Ueberlauf auf
0 zurueckgesetzt und faengt wieder von vorne an bis die gewuenschte
Anzahl Zeichen rausgetaktet wurde.

gruss, bjoern.
Gast #343453
Lesenswert?

Jo, das war eigentlich meine Idee. Das Problem dabei ist aber, dass die
Laufschrift nicht Zeichenweise, sondern Spaltenweise, bzw. noch feiner
laufen soll. Ein Zeichen der Grösse 5x8 benötigt im Normalfall 10
solche Spalten und falls es fett ist 20. Daher muss ich trotzdem immer
wieder vom Anfang des Textes beginnen um alle
Formatierungsinformationen berücksichtigen zu können. Aber so wie es
jetzt aussieht müsste das eigentlich funktionieren. Naja, mal sehn.

Trotzdem danke für die Antwort!
Gast #343454
Lesenswert?

Du hast doch 2 Speicher: einen für den Text und die Formatierung und
einen für die Anzeige ("GrafikRAM").
In dein Grafik-RAM kannst/brauchst du ja nur eine gewisse Menge
schreiben (1 Umdrehung). Oder berechnest du immer erst kurz vor der
Anzeige die anzuzeigenden Daten?
Das Grafik-RAM sollte einen Buchstaben grösser sein als du brauchst
(+20).
Dann kommt der Ringspeicher zu tragen:
Du gibst immer die Daten ab einem bestimmten Punkt aus.
Der SPeicherplatz, der nicht angezeigt wird, kann mit neuen Daten
beschrieben werden.
Scrollen bedeutet dann, dass der Startindex der Anzeige wandert.
Ist der Text kurz genug, wandert der Startindex halt nicht.
#343455
Lesenswert?

Dann speicher doch die Formatierungsinformation fuer jedes Zeichen
einzeln. Also immer abwechselnd Format und Zeichen. Oder sogar in ein
seperates Feld, dann laesst sich mit Union(?) evtl noch Speicherplatz
sparen.
Ansonsten wird Dir nicht viel uebrig bleiben, als Deine eigene Loesung
schnell genug zu bekommen.

So wie ich es verstanden habe, laesst du den Text bei jeder Umdrehung
neu rendern? Bei meiner Propclock hab ich die Ausgabe als eine Art
Displayram im Speicher liegen und render die Zeichen nur ein einziges
mal, wenn etwas neues auf dem Display erscheinen soll. Vielleicht hab
ichs auch falsch verstanden, und du machst es genauso. Dann versteh ich
das Problem aber nicht. Bei Aenderung wird halt mal ne halt mal ne halbe
Umdrehung nichts angezeigt, wenn das Displayram updaten zu lange dauert.
Faellt aber nicht weiter auf.

gruss, bjoern.
Gast #343456
Lesenswert?

Hi Phillip,

meinst Du das 'feine' Scrollen so wie bei meiner ?

http://www.dieschwarzfamilie.de/videos/propeller2.avi

Ich habe es so gelöst, daß praktisch ein 'Anzeigefenster' über diesen
Text verschoben wird, so als ob man durch ein Guckloch schaut.

Vor und nach dem Text sind jeweils Leerzeichen und zwar soviele, wie
der untere Halbkreis Spalten hat.
Dieses 'Fenster' startet nun einfach bei 0 und wird bei jeder
Umdrehung um eine Position nach rechts verschoben. Somit gehts erst mal
bei den Leerzeichen los und langsam wird der Text sichtbar bis hinten
wieder die Leerzeichen kommen.
Somit ist die Routine schnell genug (Atmega8 mit 16Mhz) und es muß
nichts berechnet werden, außer daß die Position dieses Gucklochs um 1
inkrementiert wird und der Text einmal erstellt wird oder um
Mitternacht aktualisiert wird.
Persönliche Seite #343463
Lesenswert?

Also bei mir war das Display so aufgebaut, dass ich 32 LED Spalten hatte
und 16 LED Reihen. 16*32 macht 512. Ich hatte also 4 Bytes in jeder
Reihe.

Wenn ich den Pointer erhöht habe (also 8 Bits höher), dann bin ich doch
im nächsten Byte. Also 8 Bits weiter.


"Hi Simon, der 'Pointer' bei mir ist der Spaltenzähler.
Deinen letzten Satz verstehe ich so, als ob man bitweise
weiterschieben
würde, mache ich aber nicht."

ja, der Pointer kann ja der Spaltenzähler sein, aber woher kriegst du
denn ein Bitfeld im AVR, dass du bitweise adressieren kannst?
OP #343464
Lesenswert?

Nunja, grundsätzlich wäre es schon möglich, ein "Display-RAM" zu
erzeugen, das würde die ganze Sache natürlich einfacher gestalten. Das
Problem dabei ist aber, dass ich den ATtiny26 verwende und der hat ja
bekanntlich nur 128 (oder 256) Bytes RAM. Da ich aber eine Umdrehung
für die feine Verschiebung, sowie für den fetten Text in 256 Schritte
unterteile, könnte ich maximal eine Umdrehung speichern und dann wäre
das ganze RAM voll. Aber wahrscheinlich ist es durch die Tatsache, dass
ich da noch Formatierungsinformationen drin habe nicht möglich, eine
andere als die von mir genannte zu verwenden...
Für jedes Zeichen die Formatierungsinformationen zu speichern halte ich
auch für wenig sinnvoll, erstens wegen dem begrenzten Speicher und
zweitens, weil es wohl nicht so viel bringen würde. Ich weiss dann ja
trotzdem noch nicht, wie weit der bereits ist...

@Björn:
Also wenn du eine ganze halbe Umdrehung benötigst um den Text neu zu
erstellen, dann ist da irgendwas nicht so wirklich optimiert ;D

@Lupin:
siehe Anhang, ist alles drin (Alles Elektronische zumindest). Falls du
die Platinen von meinem Layout herstellen willst, dann würde ich dir
raten, durchkontaktierungen zu verwenden, da es teilweise sonst nicht
wirklich günstig zum Löten ist/wäre.
Angehängte Dateien:
#343465
Lesenswert?

"Also wenn du eine ganze halbe Umdrehung benötigst um den Text neu zu
erstellen, dann ist da irgendwas nicht so wirklich optimiert ;D"
Alles ne Frage der Taktrate, Aufloesung und Umdrehungsgeschwindigkeit.

Ob ich ne "ganze halbe" Umdrehung brauche, weiss ich nicht, aber ich
empfange die Daten auch nebenbei noch ueber den Trafo. Mit Displayram
komplett loeschen, empfangen und wieder voll schreiben koennts in der
Tat so "lange" dauern. Aber da mans sowieso nicht bemerkt, es sei
denn, man konzentriert sich drauf, hab ich das ganze nicht weiter
optimiert. Dafuer hab ich alles selbst geschrieben, ohne mir auch nur
eine Zeile fremden Quelltext anzuschauen. War auch nurn Quicky in 2
Nachmittagen:
http://www.lania.de/salival/bilder/propclock
Angehängte Dateien:
Gast #343467
Lesenswert?

Ich würde das auf jeden Fall ohne Display-Ram machen, und zwar so:
Du hast einen spaltenorientierten CharGen, bei dem ist ein Kennzeichen
drin (entweder ein Bit oder ein bestimmtes Bitmuster), wenn eine Spalte
wg. Proportionalschrift nicht gebraucht wird, also übersprungen werden
soll.

Dann hast Du den Dot-Counter, der aber nicht linear zählt, sondern
immer sofort incrementiert wird, solange diese Kennzeichen erkannt
wird. Nehmen wir an, dass ein Buchstabe maximal 16 Spalten breit ist,
werden diese aus den unteren 4 Bits erzeugt, das ergibt dann die
Spaltenadresse im CharGen.
Die restlichen höheren Bits geben die Buchstabennummer (Index des
Strings) an.

Was bewirken Deine Formatierungsinformationen?
Blinken / Breitschrift etc?
Dann musst Du am Anfang den ganzen Text von Anfang bis zur Startstelle
durchsuchen. Oder Du merkst Dir den Status an der Startstelle und
aktualisiert ihn, sobald eine neue Formatierung kommt.
OP #343468
Lesenswert?

@Björn:
Also ich empfange da nebenbei auch noch mein Zeugs über den Trafo (Die
Auswertung der empfangenen Bytes ist aber noch nicht implementiert),
der Rotor dreht mit ca. 3000rpm und der Controller ist mit 8MHz
getaktet. Da bleibt schon nicht mehr sooo viel Zeit für Anderes... Aber
egal, lassen wir das.

@Profi:
Die Erkennung der schmalen Zeichen ist kein Problem, ich überprüfe
einfach, ob die ersten beiden Spalten nur 0 enthalten.
Bei Rest deiner Idee blicke ich irgendwie nicht ganz durch.
Mit meinen Formatierungsinformationen hab' ich folgende Optionen:
- Fett (Spalten doppelt so breit)
- Invertiert
- Unterstrichen
- Keine Zwischenräume zwischen den Zeichen
- Lauftext (Für kurze Texte)

Für die Anzahl der Spalten ist aber natürlich nur das Fett-Attribut von
Belang. Blinkenden Text könnte ich dann aber bei Gelegenheit auch noch
einbauen, gute Idee.
#343469
Lesenswert?

Wird auch an meiner Interruptroutine liegen. Wenn das nicht mein Code,
sondern der eines Anderen waere, haette ich schon laengst gemeckert,
dass man im Interrupt nur Flags setzt und keine FSM laufen laesst.

Will mich nicht rausreden, aber ich hatte mir ausgerechnet, dass ich
mehr als genug Zyklen Zeit hab, im Interrupt rumzuhaengen. Ausserdem
hat das Empfangen hoechste Prioritaet und alles andere ist eher
unkritisch. Naja, es laeuft. Wie Du schon sagst: Lassen wir das.

War halt nen ProofOfConcept. In meiner nicht geplanten richtigen
Version wuerde der Code leicht anders aussehen. Allerdings nicht viel,
da ich die Intelligenz auf den Rechner auslagern wuerde. Da liefe dann
ein Perl/TK Programm, dass den Displayram quasi RAW beschreibt. Damit
wuerde dann nicht nur Text, sondern auch Bildchen und Animationen
moeglich sein.

gruss, bjoern.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren