mikrocontroller.net

Forum: Projekte & Code Vektor-Font in C


Autor: Johann L. (gjlayde) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;)

Autor: Johann L. (gjlayde) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Johann L. (gjlayde) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: 900ss D. (900ss)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. :-)

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: 900ss D. (900ss)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: tuho (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.