Für mein Scope-Uhr Projekt habe ich einen Vektor-Font in C geschrieben. Für die Strahlsteuerung muss eine Font-Implementierung nicht-blockierend sein und darf immer nur einen Pixel ausgeben. Der Font kann in ganzzahligen Schritten vergrößert werden und er kann als Proportional-Schrift angezeigt werden, was Platz auf der Anzeige spart und ein harmonischeres Erscheinungsbild gibt. In der einfachsten Version (nur Ziffern und Großbuchstaben) brauchten Zeichensatz und Font-Software auf einem ATmega8 rund 860 Bytes an Programmspeicher. Für den ganzen Zeichensatz (Groß- und Kleinbuchstaben, Umlaute, ...) braucht's insgesamt knapp 2kByte.
Angehängte Dateien:
-
font_1-3.png
24 KB
Hier noch Font-Ansichten in den ersten drei Zoom-Stufen von 1 bis 3 und so skaliert, daß die Zeichen etwa gleichgroß erscheinen. Links als Pixel und rechts wie es mit einem Filzstift aussehen würde.
Hey, nicht schlecht. Das nenne ich mal programmieren auf professioneller Ebene. Du machst das wahrscheinlich beruflich, bzw. oft ;) Gefällt mir sehr gut. Sowohl die Idee als auch die Umsetzung. Guten Code erkennt man auch daran, dass man ihn schnell versteht und nachvollziehen kann. ;)
Angehängte Dateien:
-
font-on-scope.jpg
51 KB
Nochn Bild, ist leider net so leicht zu fotografieren, aber die kleinste Zoome-Stufe des Fonts ist auf der Röhre sehr gut lesbar :-) "Franz jagt im komplett verwahrlosten Taxi quer durch Bayern" ist übrigens die deutsche Übersetzung von "The quick brown dog jumps over the lazy fox". Simon K. wrote: > Hey, > nicht schlecht. Das nenne ich mal programmieren auf professioneller > Ebene. Du machst das wahrscheinlich beruflich, bzw. oft ;) > > Gefällt mir sehr gut. Sowohl die Idee als auch die Umsetzung. > > Guten Code erkennt man auch daran, dass man ihn schnell versteht und > nachvollziehen kann. ;) räusper So ein Kommentar hätte ich jetzt net erwartet, oder war das ironisch? Die Quelle ist gespickt mit #ifdefs und enthält das Killer-Kommando, das Unaussprechliche (fängt mit "go" an und hört mit "to" auf). Johann
Johann L. wrote: > Nochn Bild, ist Könntest du etwas zur Ansteuerung der Bildröhre sagen? Besonders würde mich interessieren, ob es ein Blanking gibt und falls ja, wie dieses realisiert wurde. > Die Quelle ist gespickt mit #ifdefs und enthält das Killer-Kommando, das > Unaussprechliche (fängt mit "go" an und hört mit "to" auf). Was ist daran schlimm? Wenn man diesen Befehl verantwortungsvoll einsetzt, kann dieser durchaus positiv sein.
Benedikt K. wrote: > > Könntest du etwas zur Ansteuerung der Bildröhre sagen? Besonders würde > mich interessieren, ob es ein Blanking gibt und falls ja, wie dieses > realisiert wurde. Wasn das? Strahlaustastung? Ja, die gibt es. Die Ansteuerung der Röhre hab ich übernommen von http://www.jogis-roehrenbude.de/Leserbriefe/Scope-Clock/Scope-Clock.htm wobei ich die BY505 ersetzt habe durch eine MUR1100. Per Transistor und Koppel-Kondensator wird am Potetial des Wehnelt-Zylinders gezupft. Ansonsten mach ich die Hochspannungen über selbstgestrickte SNT und selbstgeklöppelte Drosseln. Brain ist ein AVR ATmega168 mit einer ISR-Rate von 32kHz, d.h. alle ca. 32µs wird ein neuer x/y-Pixel gesetzt: ...-P1-P2-P3-... wenn es einen Sprung gibt, dann sieht die Sequenz so aus: ...-P1-P2-OFF-P3-ON-P4-... Wobei jeder - wieder 1/32000 Sekunde ist. Wenn der Strahl nen längeren Weg zurücklegt, dann muss die Off-Phase verlängert werden nach dem gleichen Schema ...-P1-P2-OFF-P3----ON-P4-... Das funktioniert bei kurzen Off-Zeiten für Strahl-Umpositionierung. Zwischen benachbarten Pixel wird nicht ausgetastet. Damit die Helligkeit unabhängig wird von der Anzahl gezeichneter Pixel, stelle ich den Strahl ins Aus, wenn ein Frame weniger als 1000 dieser Ticks dauert. Dazu fahre ich den Strahl ausserhalb des Bildschirms und taste ...-0-OFF------ON-OFF------ON-OFF-... Ich hoffe mal das schadet der Röhre (auch eine D7-16) nicht?
Johann L. wrote: > Brain ist ein AVR ATmega168 mit einer ISR-Rate von 32kHz, d.h. alle ca. > 32µs wird ein neuer x/y-Pixel gesetzt: Synchronisierst du die Ausgabe mit der Netzfrequenz um flimmern zu verhindern oder läßt du alles so frei laufen? Und wenn es frei läuft, hast du kein flimmern wenn du im Zimmer kein Tageslicht hast? > Wobei jeder - wieder 1/32000 Sekunde ist. Wenn der Strahl nen längeren > Weg zurücklegt, dann muss die Off-Phase verlängert werden nach dem > gleichen Schema > > ...-P1-P2-OFF-P3----ON-P4-... Warum muß die Off-Phase verlängert werden? Ist der DAC nicht schnell genug? > Damit die Helligkeit unabhängig wird von der Anzahl gezeichneter Pixel, > stelle ich den Strahl ins Aus, wenn ein Frame weniger als 1000 dieser > Ticks dauert. Dazu fahre ich den Strahl ausserhalb des Bildschirms und > taste > > ...-0-OFF------ON-OFF------ON-OFF-... > > Ich hoffe mal das schadet der Röhre (auch eine D7-16) nicht? Ich denke nicht dass es schadet, aber warum schaltest du den Strahl nicht ab und stopst die Pixelausgabe solange? Mit einem festen Raster an Ausgabesequenzen dürfte das dann doch auch funktionieren. Oder übersehe ich etwas? Zu deinem SnakeOnScope schreibst du, dass der AVR mit 24MHz läuft. Ist das Übertakten auch für die Scopeuhr notwendig damit die Ausgabe schnell genug ist? Auf deiner Website hast du eine Platine für die Röhre (Röhrensockel) und eine PWM-Heizungssteuerung. Es gibt auch die Pläne, Layouts u.s.w. für Eagle dazu. Hast du evtl. noch Platinen über? Extra eine ätzen lassen ist etwas teuer. Vielleicht kannst du mir eine oder zwei verkaufen? Ich habe auch vor, mir eine Scopeuhr zu bauen. Wollte es auch mit Vektorfonts machen, weil ich es elegant finde. Nun hast Du schon alle Vorlagen dafür. Chic :-) Obwohl ich es eigentlich selber machen wollte. Wirst du die Pläne und Layouts fürdie Scopeuhr auch veröffentlichen? Ich werde zwar eh etwas anders aufbauen, aber der uC-Part mit den DACs wird so werden wie bei dir. Danke. 900ss
Angehängte Dateien:
-
scope-testbilder.jpg
29 KB
900ss D. schrob: > Johann L. schrieb: >> Brain ist ein AVR ATmega168 mit einer ISR-Rate von 32kHz, d.h. alle ca. >> 32µs wird ein neuer x/y-Pixel gesetzt: > > Synchronisierst du die Ausgabe mit der Netzfrequenz um flimmern zu > verhindern ... Ich versteh die Frage net. Was ist Netzfrequenz ? > hast du kein flimmern wenn du im Zimmer kein Tageslicht hast? Nö. Nur wenn die Software nicht nachkommt, also wenn es weniger als ca. 30 Frames/s (fps) sind. Das entspricht auch der Geschwindigkeit eines GJ-Schirms. Die D7-16 gibt es auch mit anderen, schnelleren oder langsameren Schirmen. >> Wobei jeder - wieder 1/32000 Sekunde ist. Wenn der Strahl nen längeren >> Weg zurücklegt, dann muss die Off-Phase verlängert werden nach dem >> gleichen Schema >> >> ...-P1-P2-OFF-P3----ON-P4-... > > Warum muß die Off-Phase verlängert werden? Ist der DAC nicht schnell > genug? Der schon, aber es gibt parasitäre L und C von Schaltung, Zuleitung, Platten, ... Der Strahl ist träge, er braucht Zeit von A nach B. Je weiter A von B weg ist, gesto länger dauert es, bis er angekommen ist. Das Geschwindigkeitsprofil durfte gut auf einer abklingenden e-Kurve liegen. Die 3 Fotos zeigen den Effekt. Angesteuert werden Eckpunkte eines 720-Ecks. Links Jede 360-te Ecke, in der Mitte jede 361-te Ecke und rechts jede 7/16*720-te Ecke, also jede 315-te. Im Optimalfall wären die Verbindungen zwischen den Punkten Strecken, und das Gesamtbild links eine Strecke, in der Mitte ein Kreis mit Punkt im Zentrum und rechts ein Kreis, der ein hell umrandetes Loch inder Mitte hat. Auuserdem sieht man, daß der Strahl zuerst in X- und erst dann in Y-Richtung geht. Die DAC-Werte können nicht gleichzeitig gesetzt werden. >> Damit die Helligkeit unabhängig wird von der Anzahl gezeichneter Pixel, >> stelle ich den Strahl ins Aus, wenn ein Frame weniger als 1000 dieser >> Ticks dauert. Dazu fahre ich den Strahl ausserhalb des Bildschirms und >> taste >> >> ...-0-OFF------ON-OFF------ON-OFF-... > ... aber warum schaltest du den Strahl > nicht ab und stopst die Pixelausgabe solange? Mit einem festen Raster an > Ausgabesequenzen dürfte das dann doch auch funktionieren. Oder übersehe > ich etwas? Es gibt 2 Ausgabeparameter: fps, ppf und pps fps: Frames / Sekunde pps: Pixel / Sekunde ppf: Pixel / Frame die zusammenhängen über pps = ppf * fps. Natürlich werden in den Dunkelzeiten keine Pixel ausgegeben, aber den Strahl kann man nicht anschalten, nur austasten. Wenn er zu lange aus bleibt, dann lädt sich der Austast-C wieder auf. Austasten geht über Zupfen am Wehnelt-Zylinder, dessen Potential über den AUstast-C eins auf die Mütze bekommt. Aber das Potential führt unbeeinflusst die e-Kurve einer R-C-Kombo nach. > Zu deinem SnakeOnScope schreibst du, dass der AVR mit 24MHz läuft. Ist > das Übertakten auch für die Scopeuhr notwendig damit die Ausgabe schnell > genug ist? 24MHz bei 5V und 25°C sind kein Problem. UART, PWM, I/O-Ports, alles geht einwandfrei. Ich hab keinen langsameren Quarz angedacht, die 24MHz sind schon immer an der Schaltung dran. Natürlich will man ne möglichst hohe Speed. Ein Teil macht ein fixer Quarz, ein anderer machen Software+Compiler und noch einer ein µC mit nem hohen Datendurchsatz. > Auf deiner Website hast du eine Platine für die Röhre (Röhrensockel) und > eine PWM-Heizungssteuerung. Es gibt auch die Pläne, Layouts u.s.w. für > Eagle dazu. Hast du evtl. noch Platinen über? Extra eine ätzen lassen > ist etwas teuer. Vielleicht kannst du mir eine oder zwei verkaufen? Ja, ich hab noch eine. > Ich habe auch vor, mir eine Scopeuhr zu bauen. Wollte es auch mit > Vektorfonts machen, weil ich es elegant finde. Nun hast Du schon alle > Vorlagen dafür. Chic :-) Obwohl ich es eigentlich selber machen wollte. > Wirst du die Pläne und Layouts fürdie Scopeuhr auch veröffentlichen? Hatte ich vor, ja. Momentan ist es aber Baustelle und es kann sein daß alles mal für 1/2 Jahr in der Mottenkiste landet :-) bis ich's wieder vorkrame. Johann
Oh mann, danke für die ausführliche Erklärung. Mit Netz frequnez meine ich, ob du es mit den 50Hz aus dem Stromnetz synchronisierst. Aber scheinbar nicht. Damit kann man gut Störungen von 50Hz/100Hz aus dem Stromnetz unterdrücken (Einstreuungen von außen). Es wird halt alle 20ms ein Frame gezeichnet. Hab Interesse an der Platine. Ich hab dir auch noch 'ne Mail geschrieben. Ich hoffe du hast mich in die whitelist eingetragen :-) 900ss
Angehängte Dateien:
-
Scopesimu.png
6,3 KB
Wollte nur ein "Danke schön" und ein Lob für dieses Stück Software loswerden. Habe mir einen Simulator für meine Scopeclock mit wxWidgets gebaut um die Algorithmen zu testen. Und den Vektorfont-Generator habe ich ins Projekt übernommen (aus deinem letzten Scopeclock-Snapshot deiner Homepage) und er lief sofort problemlos. Es waren keine Änderungen notwendig außer der Anpassung der Defines für die Vektorfontoptionen und der Pixelausgaberoutinen. Angehänger Screenshot zeigt es. Danke Dir. Gruß 900ss
Hey, cool Freut mich zu lesen. Ich hatte auch erst aufm PC anzeigen lassen, allerdings etwas mühsamer mit einzelnen PPM-Grafiken. Wundert mich ehrlich gesagt daß es zu reibungslog geht. Verwendest du die Inline-Versionen der Callbacks? Ist etwas tricky, ohne Quelländerung und externe Includes Inline-Funktionen einzubauen. Weiteren Speedup bringt die Lookup-Tabelle. Wenn ich's recht mitbekommen hat soll das ganze aufn Cortex M3? Für den Vektor-Font wollte ich mal nen Wiki-Artikel machen, aber es gibt irgendwie nichtmal ne passende Kategorie dafür... Ist ja nicht µC-spezifisch. Johann Edith: Die ISR-Rate ist jetzt bei 48kHz, d.h. es werden bis zu 48000 Pixel/Sekunde berechnet (Wichtig bei Asteroids :-)
Johann L. schrieb: > Wundert mich ehrlich gesagt daß es zu reibungslog geht. Verwendest du > die Inline-Versionen der Callbacks? Ist etwas tricky, ohne Quelländerung > und externe Includes Inline-Funktionen einzubauen. Ich habe die defines 'VECFONT_BEAM_XY' bzw. 'VECFONT_BEAM_SKIP' verwendet. > Weiteren Speedup bringt die Lookup-Tabelle. ??? Häh? Wo meinst du jetzt? > Wenn ich's recht mitbekommen hat soll das ganze aufn Cortex M3? Ja. Ich hatte dir ja schon ein paar Dinge per Mail geschrieben. Aber irgendwie warst du tot ;-) > Edith: Die ISR-Rate ist jetzt bei 48kHz, d.h. es werden bis zu 48000 > Pixel/Sekunde berechnet (Wichtig bei Asteroids :-) Ja, ich weiß dass du diese Pixelrate auf deinem AVR hinbekommst. Nicht schlecht. Nur zum Vergleich: Ich habe auf dem CM3 das uc/OS2 laufen und lasse einen Sinus auf beiden DACs ausgeben. Bei einer Pixelrate von 120kHz ist die CPU laut Kernel-Statistic mit ca. 20% ausgelastet :-) Ich verwende allerdings auch die DMA Kanäle, was die IRQ-Last erheblich verringert. Nur das Ansteuern der Z-Achse (Strahlaustastung) ist wegen der DMA zum DAC etwas tricky. Ich muß ja auch die Strahlaustastung dann per DMA synchron zu den x/y-Achsen zu einem IO-Port schicken. Aber es wird gehen, so wie ich es im Moment sehe. 900ss
900ss D. schrieb: > Johann L. schrieb: >> Wundert mich ehrlich gesagt daß es zu reibungslos geht. Verwendest du >> die Inline-Versionen der Callbacks? Ist etwas tricky, ohne Quelländerung >> und externe Includes Inline-Funktionen einzubauen. > > Ich habe die defines 'VECFONT_BEAM_XY' bzw. 'VECFONT_BEAM_SKIP' > verwendet. Jo, das geht. Allerdings kannst du aufm CM3 ganz großzügig und sauber über die Callbacks gehen, also über vecfont.beamxy() und vecfont.skip(). >> Weiteren Speedup bringt die Lookup-Tabelle. > > ??? Häh? Wo meinst du jetzt? Ist im Header erklärt und geht über die Defines VF_LOOKUP_START und VF_LOOKUP_END. In der Tabelle sind nicht alle Zeichencodierungen gleich lange. Ein ? ist aufwändiger als ein -. Daher kann nicht in die Tabelle indiziert werden, sondern es muss gesucht werden. >> Edith: Die ISR-Rate ist jetzt bei 48kHz, d.h. es werden bis zu 48000 >> Pixel/Sekunde berechnet (Wichtig bei Asteroids :-) > > Ja, ich weiß dass du diese Pixelrate auf deinem AVR hinbekommst. Nicht > schlecht. Nur zum Vergleich: Ich habe auf dem CM3 das uc/OS2 laufen und > lasse einen Sinus auf beiden DACs ausgeben. Bei einer Pixelrate von > 120kHz ist die CPU laut Kernel-Statistic mit ca. 20% ausgelastet :-) Ich Da spiels du natürlich in einer ganz anderen Liga und musst dir wegen der Speed echt keine Gedanken machen. Und du brauchst die Strick-Info nicht in ein einzuges Byte zu quetschen (Länge, dx, dy, Start/Ende zeichnen?, Skip?, Zeichenbreite reduzieren?, ...) Johann
Johann L. schrieb: > Jo, das geht. Allerdings kannst du aufm CM3 ganz großzügig und sauber > über die Callbacks gehen, also über vecfont.beamxy() und vecfont.skip(). Es funktioniert so gut und damit bin ich zufrieden. :-) > Ist im Header erklärt und geht über die Defines VF_LOOKUP_START und > VF_LOOKUP_END. In der Tabelle sind nicht alle Zeichencodierungen gleich > lange. Ein ? ist aufwändiger als ein -. Daher kann nicht in die Tabelle > indiziert werden, sondern es muss gesucht werden. Ah OK, das werde ich noch probieren. Auch wenn ich "Zeit genug habe". Verschwenden möchte ich sie denn doch nicht. Danke für den Tip. > der Speed echt keine Gedanken machen. Und du brauchst die Strick-Info > nicht in ein einzuges Byte zu quetschen (Länge, dx, dy, Start/Ende > zeichnen?, Skip?, Zeichenbreite reduzieren?, ...) Warum soll ich das nicht tun. Geht ja gut so. Allerdings wäre der Code wahrscheinlich schneller, wenn man für jedes Feature ein eigenes Byte nehmen würde, Man muß dann nicht mehr maskieren. Ich bin noch weit weg von meinem Ziel :-) Muß erstmal meine Ablenkverstärker (mit Röhren) ausprobieren. Einen hatte ich schon mal aufgebaut. Brauche aber ja zwei, damit ich dann sehe, ob ich statt eines Kreises ein Ei bekomme, falls er nicht linear genug ist. Außerdem ist bei Pixelrate der Frequenzgang nicht so unproblematisch. Nun, diese Wochenende ist das Wetter wohl zu gut zum basteln. :-) 900ss PS. Was macht dein Asteroids? Ich find das scharf auf so einem kleinen Wicht. Schön wäre es, wenn man deinen Code vom Snake und Asteroids genauso einfach übernehmen könnte, wie den des Vektorfonts. :-)
900ss D. schrieb: > Johann L. schrieb: >> der Speed echt keine Gedanken machen. Und du brauchst die Strich-Info >> nicht in ein einziges Byte zu quetschen (Länge, dx, dy, Start/Ende >> zeichnen?, Skip?, Zeichenbreite reduzieren?, ...) Auf nem 32-Bit µC am besten in uint32, vor alles das auseinanderklabüstern von dx und dy ist aufwändig. Wichtig ist wie immer eher die WCET als die Speed. http://de.wikipedia.org/wiki/WCET > nicht linear genug ist. Außerdem ist bei Pixelrate der Frequenzgang > nicht so unproblematisch. Zu hohe Pixelraten sind nicht sinnvoll. Bei zu vielen Pixeln wird die Anzeige zu duster. Mit 1500 Pixeln kannst man schon einiges an Action darstellen :-) Dafür reichen wohl 50-60kHz. > PS. Was macht dein Asteroids? Ich find das scharf auf so einem kleinen > Wicht. Schön wäre es, wenn man deinen Code vom Snake und Asteroids > genauso einfach übernehmen könnte, wie den des Vektorfonts. :-) Snake hatte ich parametrisiert für PC: Beitrag "AVR: Snake! ------------O" allerdings nach Funktionieren auf AVR nicht weitergeführt, bzw nur die AVR-Teile. Sooo schwert portierbar ist mein Code ja nicht, siehe zB #include "compat/interrupt.h" #include "compat/pgmspace.h" zur Parametrisierung AVR <-> PC. Vecfont-mässig brauchst du dann aber saturierte Versionen von Addition und Subtraktion wegen der Scroll-Schrift (Umbruch oben/unten, damit's da nicht den Strahl schleift und er sauber ausgetastet wird) AVR Arithmetik/Saturierung Johann
Johann L. schrieb: > Auf nem 32-Bit µC am besten in uint32, vor alles das Ja das ist mir klar, möchte aber deinen Code nicht völlig auseinanderreißen. Es läuft ja gut. > auseinanderklabüstern von dx und dy ist aufwändig. Wichtig ist wie immer > eher die WCET als die Speed. Ja das stimmt. Aber ich glaube erstmal nicht, dass es mit der Speed zu eng wird. > Zu hohe Pixelraten sind nicht sinnvoll. Bei zu vielen Pixeln wird die > Anzeige zu duster. Mit 1500 Pixeln kannst man schon einiges an Action > darstellen :-) Dafür reichen wohl 50-60kHz. Ich möchte auch das Uhrenziffernblatt mit einem Kreis versehen (so wie auf dem Screenshot oben). Und da hat man schon ein paar Punkte mehr. Außerdem habe ich 12bit DACs, dass gibt auch mehr Punkte, da ja die Auflösung höher ist. Nur wird das nicht zu einem dunkleren Schirm führen. Aber ich muss das ausprobieren. So ist das alles Theorie. > Snake hatte ich parametrisiert für PC: > Beitrag "AVR: Snake! ------------O" Ja das werde ich mir dann mal anschauen. > > allerdings nach Funktionieren auf AVR nicht weitergeführt, bzw nur die > AVR-Teile. Sooo schwert portierbar ist mein Code ja nicht, siehe zB Einige Dinge sind aber schwer zu verstehen, da auch dann die Kommentare fehlen ;-) Andere wiederum sind sehr gut kommentiert. So, nu ist erstmal gutes Wetter angesagt. Werde meine Speed Triple aus der Garage holen und etwas Kurven kratzen (soweit das in Norddeutschland geht ;-)). Obwohl ich echt mal wieder Lust hätte, an der Uhr weiterzumachen. Aber bei dem Wetter...
900ss D. schrieb: > Johann L. schrieb: >> Auf nem 32-Bit µC am besten in uint32, vor alles das > > Ja das ist mir klar, möchte aber deinen Code nicht völlig > auseinanderreißen. Es läuft ja gut. Auf 12 Bit musst du dann eh was anpassen, zB VF_INT_BITS auf 16 oder 32. >> Zu hohe Pixelraten sind nicht sinnvoll. Bei zu vielen Pixeln wird die >> Anzeige zu duster. Mit 1500 Pixeln kannst man schon einiges an Action >> darstellen :-) Dafür reichen wohl 50-60kHz. > > Ich möchte auch das Uhrenziffernblatt mit einem Kreis versehen (so wie > auf dem Screenshot oben). Und da hat man schon ein paar Punkte mehr. > Außerdem habe ich 12bit DACs, dass gibt auch mehr Punkte, da ja die Bei echten 12-Bit DACs entsprechen die 48kPixel vom AVR dann knappen 800kPixel. Da wird's dann schon ordentlich zugig :-) > Einige Dinge sind aber schwer zu verstehen, da auch dann die Kommentare > fehlen ;-) Andere wiederum sind sehr gut kommentiert. Baustelle eben... > So, nu ist erstmal gutes Wetter angesagt. Werde meine Speed Triple aus > der Garage holen und etwas Kurven kratzen (soweit das in Norddeutschland > geht ;-)). Schöne Maschine das. Ich hab nach den zweiten unverschuldeten Unfall (Totalschaden) aufgehört :-(. Würde gern wieder rumzischen, aber die ANzahl der Knochen und Organe ist eben begrenzt (die der Idioten auf der Straße leider nicht). Viel Spaß, Johann
Ich hab nicht alle Beiträge gelesen, aber im Quelltext von vektor-zeichen.c sollte man folgendes noch überarbeiten:
1 | #define SPACE_X 2+5*zoom
|
2 | #define SPACE_Y 3+8*zoom
|
Macht besser draus:
1 | #define SPACE_X (2+5*zoom)
|
2 | #define SPACE_Y (3+8*zoom)
|
Das Zeug ist schon überarbeitet, aktuell
1 | // Zeichenabstand horizontal/vertikal
|
2 | #define VF_SPACE_X(ZOOM) (2+5*(ZOOM))
|
3 | #define VF_SPACE_Y(ZOOM) (3+8*(ZOOM))
|
kann's leider nicht ins Wiki hochladen.
Im Wiki gibt's jetzt nen Artikel mit aktuellen Quellen und 3 Beispiel-Programmen dazu: Vektor-Font in C Der Zeichensatz ist sogar um eigene Zeichen erweiterbar :-)
Fein, danke! Werde ich mal schauen, ob sich was verändert hat zu der Version die ich habe. Mit der Uhr wird es sich noch hinziehen. Ich doktere noch an den Ablenkverstärkern mit den Röhren rum. Wer schön sein will muß leiden ;-) Gruß 900ss
Angehängte Dateien:
-
Ziffernblatt_Text.jpg
150 KB
Hallo, nachdem ich vor einer Weile den Vektorfont Generator auf meinem Simulator benutzt habe: Beitrag "Re: Vektor-Font in C" jetzt endlich das Resultat auf der echten Scopeclock. Ist der erste Versuch, es gibt noch einiges zu verbessern. Aber es funktioniert schon mal. Der Vektorfontgenerator tat es mal wieder ohne irgendeine Änderung im Code, nur die der Pointer der Pixelausgaberoutine bzw. BeamOff mußte geändert werden. Georg, das hast du echt super gemacht, danke nochmal. Gruß Joachim
Hab eben nochmal den Artikel überflogen und mir das letzte Bildchen was
näher angeschaut...
> jetzt endlich das Resultat auf der echten Scopeclock.
Sieht aus, als würd was mit der Strahlaustastung nicht 100% stimmen,
weil den Zeichen jeweils der letzten Pixel fehlt, z.B.
v: der rechte Arm ist zu kurz
n: dito
1: die untere Serife ist zu kurz
8: ist nicht ganz geschlossen
S: ist asymmetrisch
Johann L. schrieb: > Sieht aus, als würd was mit der Strahlaustastung nicht 100% stimmen, Hast du richtig erkannt. Hab den Fehler schonmal versucht zu finden, ist mir aber nicht gelungen. Bin seit der ersten Inbetriebnahme (daher stammt das Foto) selten an der Uhr gewesen. Im Moment kümmere ich mich gerade um ein Schaltnetzteil zur Stromversorgung der Uhr wie du weisst ;-) Ich will mal testen, wie es damit läuft. Danach werde ich entscheiden, wie ich die Uhr versorge. Und dann kommt wieder die Software.
Hallo, mit der Vekfont habe ich genau das gesucht was ich gefunden habe. Ich hab das Ding grad zum Laufen gebracht und steuere damit ein 480x320 Zeichen Display an. Gibt es die Möglichkeit die Pixeldicke zu verändern - also eine FETT Schrift einzustellen? Auf Grund der hohen Auflösung sehen die größeren Zeichen (ab Zoom=3) doch recht filigran aus und sind nicht besonders schön abzulesen. Ich bin noch nicht besonders weit durch den Code gestiegen - vielleicht hat ja jemand von Euch eine Idee wo ich da ansetzen müsste. Beste Grüsse, Holger
tuho schrieb: > Hallo, > > mit der Vekfont habe ich genau das gesucht was ich gefunden habe. > Ich hab das Ding grad zum Laufen gebracht und steuere damit ein > 480x320 Zeichen Display an. > > Gibt es die Möglichkeit die Pixeldicke zu verändern - also eine FETT > Schrift einzustellen? Nicht direkt. Aber der Zeichensatz ist ja Hardware- und Display-unabhängig geschrieben. Zum Zeichnen eines Pixels wird der Callback .beam_xy mit der x- und y-Koordinate des zu zeichnenden Pixels aufgerufen. Die Routine weiss ja nicht, wie eine solche Ausgabe konkret auszusehen hat und überlässt die Implementierung der Anwendung. Anstatt nur einen Pixel zu zeichnen. kannst du also einfach einen kleinen Block zeichnen lassen, zB 3×2 Pixel. Dadurch werden zwar Pixel mehrfach gezeichnet, was auf einer nicht-flüchtigen Anzeige nicht weiter stören sollte. Der Callback muss vor dem Zeichnen des ersten Pixels initialisiert worden sein. Da das Programm offenbar korrekt funktioniert, hast du die Initialisierung korrekt durchgeführt und brauchst nur ein paar Zeilen in deiner Implementierung hinzuzufügen. Der eigentliche Vekfont-Code braucht weder angefasst noch verstanden zu werden :-) > Auf Grund der hohen Auflösung sehen die größeren Zeichen (ab Zoom=3) > doch recht filigran aus und sind nicht besonders schön abzulesen. > > Ich bin noch nicht besonders weit durch den Code gestiegen - vielleicht > hat ja jemand von Euch eine Idee wo ich da ansetzen müsste.
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.