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.

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. ;)

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-...

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

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

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:

#define SPACE_X 2+5*zoom
#define SPACE_Y 3+8*zoom

Macht besser draus:

#define SPACE_X (2+5*zoom)
#define SPACE_Y (3+8*zoom)

Das Zeug ist schon überarbeitet, aktuell

// Zeichenabstand horizontal/vertikal
#define VF_SPACE_X(ZOOM) (2+5*(ZOOM))
#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

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.

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.