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
Also ich versuch's jetzt mal mit meiner Methode. Mal sehn, ob das dann nicht zu lange dauert (Bei 3000rpm darf das maximal etwa 600 Zyklen benötigen). Müsste aber eigentlich so überschlagsmässig hinhauen. Bin aber trotzdem noch offen für weitere/bessere Vorschläge.
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.
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!
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.
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.
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.
@Peter: Ich stand auch mal vor dem Problem. Womit ich gerade nicht so klarkomme ist dass ihr sagt: "Der Pointer um 1 inkrementiert" usw.. Die Pointer im AVR arbeiten Doch Byteweise. Das heißt, wenn man den Pointer erhöht, ist man nicht eine, sondern 8 Spalten 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.
Der Pointer zeigt auf den Displayram und nicht auf den Zeichenspeicher...
Philipp, kannst du vielleicht einen schaltplan online stellen wie du die stromübertragung realisiert hast? einfach 2 spulen, FET, gleichrichter und einen spannungsregler mit elkos dahinter?
Viel zu lesen, aber hier werden alle moeglichen Varianten diskutiert: http://www.mikrocontroller.net/forum/read-1-245003.html gruss, bjoern.
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?
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.
"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
Ich seh grad, das ist auch nicht die aktuellste Version des Quelltexts, zumindest hab ich 2 Fehler gefunden...
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.
@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.
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.
Habt ihr eine Idee, wie man waagerechten Text realisieren könnte? evtl. entlang eine Kreissehne?
Wird nichts aussehen, aber hier ist der Ansatz: http://de.wikipedia.org/wiki/Polarkoordinaten und btw: http://www.luberth.com/analog.htm vor allem: http://www.luberth.com/pimpstar.html
@Reinhold: Dann brauchst du aber wohl mindestens etwa 32 oder noch mehr Zeilen. Das wird dann auch Hardwaremässig schon schön aufwändig. Oder du machst den Durchmesser der PropClock unendlich gross, dann hast du da geraden Text :D
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.