Der Attiny85 stellt ja nur 5710 Bytes zur Verfügung und auch bei Arduino
Mini oder ESP8266 wünsch ich mir schon seit Jahren skalierbare Fonts.
Also ich könnte wohl unter einer Woche eine Micro-SSD1306-lib schreiben
die voll skalierbare 16-Segment Fonts (vielleicht auch 24-Segment) ohne
RAM direkt zum OLED schickt. Wäre nur so 5x langsamer.
Und da ich dafür eine Subroutine für schräge Linien bräuchte, kämen
Grafikbefehle quasi kostenlos.
Und damit das Freude macht eine 100€ Kickstarter Kampagne damit ich die
lib open source stelle.
Aber da werdet Ihr jetzt bestimmt sagen, dass es so eine Mikro-Lib schon
längst gibt.
Also bitte jetzt den Link dorthin.
das Roland
und Dankeschön :-)
P.S. kann man beim SSD1306 eigentlich OR oder XOR zum OLED schicken ?
Also Grafik-Linien übereinander malen..
So etwas in ein paar 100 Bytes quetschen ist ja eine interessante
Herausforderung. Aber warum sollte ich jemanden dafür bezahlen.
Platinchen mir 32Bit MCs kosten das selbe. In die aufgeblähte
Entwicklungsumgebung einarbeiten ist auch nicht soooo wild. Dann brauche
ich mir um Speicher und Geschwindigkeit der grafischen Ausgabe keine
Gedanken mehr machen.
Wenn ich einfach nur umfangreichere Programme mit grafischer Oberfläche
realisieren will – warum sollte ich mich dann an deiner Kickstarter
Kampagne beteiligen?
Hab jetzt mal in die
https://cdn-shop.adafruit.com/datasheets/SSD1306.pdf geschaut.
In y-Richtung kann man wohl nur in 8 pixel "page" Schritten adressieren.
Dann würde ich mich wohl doch auf 8px, 16px, 32px, 40px, 48px, 56px und
64px hohe fonts beschränken. 8, 16, 32, 64 würde auch reichen.
Wobei ich natürlich besser den Attiny85 in die Mülltonne stopfen sollte.
Hab für meine Mini-Lötstation aber inzwischen mit den 6 IO pins einmal
20xGain-ADC + drei DigitalIn + ein DigitalOut + I2C hinbeommen.
Könnte also neben dem OLED auch noch einen INA226 an den 1€ Attiny85
anschließen.
Das geht aber nur mit Vektor-Fonts.
Also Ihr Besserwisser, gibt es schon so eine Lib oder nicht ?
Für einen HP-GL Emulator habe ich das vor Jahrzehnten mal gemacht. Das
war eine Punkt-Verbindungsroutine als Ausgabe und jeder Buchstabe war
als Koordinatenfeld angelegt. Wenns dafür 100k Euro gibt - feine Sache,
her damit.
Die Punktverbindungsroutine war ein aus Sinclair Basic nach Z80
Assembler portierter Simpelalgorithmus.
Leider nicht Krösus schrieb:> Platinchen mir 32Bit MCs kosten das selbe. In die aufgeblähte> Entwicklungsumgebung einarbeiten ist auch nicht soooo wild.
Ja die Blue Pill hab ich mir schon längst mal geordert. Aber genau auf
diese aufgeblähte Keil IDE hab ich keinen Bock. Wollte auch schon länger
den nrf51.. programmieren. Aber wenn ich google was da die armen
Anfänger für Schwierigkeiten und fast gar keine Hilfe haben.. seufz da
bleib ich lieber bei der Arduino IDE
Matthias S. schrieb:> Für einen HP-GL Emulator habe ich das vor Jahrzehnten mal gemacht.
Ich bin ja noch die C64 Generation. Sonst würde mich so eine lib auch
nicht reizen.
Mit 16 Segmenten ähnlich https://de.ffonts.net/LED-16-Segment.font
gäbe es 6 "Bereiche" mit horizontalem Rechteck, 6 Bereiche mit
vertikalem Rechteck und 4 Bereiche mit diagonaler Linie.
Da ich immer gleich mit einem byte eine "page"-höhe (64px display höhe =
8 "pages", besser 8 "Zeilen") von 8 pixeln schreiben muss, überlappen
sich bis zu 3 Bereiche.
Daraus könnte ich eine Abfolge generieren bei der ich mit &-Operation
mit den 16bit des Buchstabens erkenne wie die Teilbereiche gefüllt
werden.
Also wenn ich ein "E" mit 3px dicken Linien schreiben möchte, dann wäre
das erste (vertikale) Byte nicht 0b11100000 sondern eben 0b11100000 |
0b11111111
Das nächste Byte in X-Richtung wäre wieder 0xff und nochmal 0xff aber
dann wäre der Bereich der Überschneidung verlassen und es ginge mit
0b1110000 weiter.
Bei dem "S" aus
https://d144mzi0q5mijx.cloudfront.net/img/L/E/LED-16-SegmentA.png
hingegen würde es nach 3x 0b11100000 mit der Überlagerung von 0b11100000
und dem Anfang der Diagonale weiter gehen.
Einfach wird das sicher nicht !
>Ja die Blue Pill hab ich mir schon längst mal geordert. Aber genau auf>diese aufgeblähte Keil IDE hab ich keinen Bock.
Wieso Keil? Dafür gibt es mindestens 3 Arduino Frameworks.
Und für die ILI-Arduino-TFT's gibt's so weit ich weiß auch schon
Vectorfonts:
https://www.instructables.com/id/Arduino-TFT-display-and-font-library/
Das R. schrieb:> Ja die Blue Pill hab ich mir schon längst mal geordert. Aber genau auf> diese aufgeblähte Keil IDE hab ich keinen Bock...> da bleib ich lieber bei der Arduino IDE
Keil kenne ich nicht, ich kann Dir allerdings die auf Eclipse basierte
IDE "SystemWorkbench for STM32" empfehlen.
Wer Eclipse immer noch zu "aufgebläht" findet, benutzt den GCC im
Konsole Fenster und als Editor Notepad++.
> Aber wenn ich google was da die armen Anfänger> für Schwierigkeiten und fast gar keine Hilfe haben
Gerade für dieses Board gibt es jede Menge Hilfe. Ich glaube, wer damit
nicht klar kommt, der sollte wirklich besser bei Arduino mit AVR
blieben.
Hier findest du Anfängerfreundliche Einstiegshilfe:
http://stefanfrings.de/mikrocontroller_buch2/index.htmlhttp://stefanfrings.de/stm32/index.html
Dieser STM32F103 hat ein paar Eigenschaften, die für Anfänger sogar
hilfreich sind:
- Der STM32 keinen speziellen Programmieradapter. Damit fangen bei AVR
ja schon oft die Probleme an. Zu viel Auswahlmöglichkeit und die
billigen taugen nicht für alle Fälle.
- Der Adapter zum Debuggen kostet original ab 12€, aus Asien ab 2,50€
(bei AVR jedoch ab 50€)
- Der STM32 hat keine Fuses, mit welchen man den Chip versehentlich
unbrauchbar macht.
- Integer Variablen sind Atomar (gilt bei AVR nur für short integer,
8bit). Das vereinfacht die Programmierung von Zählern in
Interruptroutinen - besonders für Anfänger.
Die gleichen Vorteile bieten auch alle anderen Mikrocontroller mit "ARM
Cortex M" Kern.
Das R. schrieb:> ich könnte wohl unter einer Woche eine Micro-SSD1306-lib schreiben> die voll skalierbare 16-Segment Fonts (vielleicht auch 24-Segment) ohne> RAM direkt zum OLED schickt.
Machen. Zeigen. Oder Klappe halten.
> Aber da werdet Ihr jetzt bestimmt sagen, dass es so eine Mikro-Lib> schon längst gibt.
Gibt es nicht. Weil sowas keiner braucht. 16-Segment Fonts sehen einfach
nur ScheiXe aus. Sowas benutzt man nur dann, wenn man kein richtiges
Display hat, sondern auf die festverdrahteten 16 Segmente angewiesen
ist.
Für Punktmatrix Displays gibt es deutlich schönere Fonts, die auch bei
vergleichsweise geringer Auflösung gut lesbar sind. Einen 7-Segment Font
kann man zwar in einer 7x5 Matrix unterbringen, aber im Vergleich zu
einem normalen 7x5 Font sieht der einfach nur grausam aus. 16 Segmente
sind unter 16 Pixel Breite gar nicht vernünftig zu rendern. Wenn man
Details wie die leicht geneigten Ziffern und die angespitzten Enden der
Segmente nachbilden will, reicht das noch nicht mal.
Wenn man für ein Projekt den Retro-Charme der 80er haben will, kann man
auch gleich den ganzen Schritt gehen und 16-Segment Hardware verbauen.
Und was skalierbare Fonts generell angeht: es ist an sich schon schwer,
so einen Font schön zu rendern. Frag mal Microsoft, die haben Jahre
gebraucht, bis sie mit Truetype wenigstens annähernd den Anschluß an
vorgerenderte Bitmap-Fonts (wie unter X11 üblich) gefunden haben. Für
kleine Auflösungen und schwarz-weiß sind handgemalte Fonts nach wie vor
das Nonplusultra. Mit Graustufen wird es etwas einfacher, mit RGB Pixeln
dann aber gleich wieder aufwendiger. Das packt man nicht in einen µC.
Schon gar nicht, wenn es darum geht, den Flash-Verbrauch von
Bitmap-Fonts zu kompensieren.
Das R. schrieb:> Daraus könnte ich eine Abfolge generieren bei der ich mit &-Operation> mit den 16bit des Buchstabens erkenne wie die Teilbereiche gefüllt> werden.
Ich habe damals ein Byte als Koordinaten in einem 16*16 Feld benutzt,
HighNibble war Y und LowNibble war X. Die Hardware (Mupid Z80) war
damals so angelegt, das Y=0 oben war und Y=0 links. Dann wurde ein Z
'z.B.' mit 4 Bytes definiert. Da es einem Bildschirm nichts ausmacht,
wenn eine Linie doppelt gefahren wurde, musste z.B. beim Querstrich fürs
'A' auch nicht abgesetzt werden. 'Z' hatte also 4 Bytes plus Endmarker
und das 'A' 5 Bytes.
Wie gesagt, das war ein Spässchen lange vor Truetype und PS.
Matthias S. schrieb:> Ich habe damals ein Byte als Koordinaten in einem 16*16 Feld benutzt,
Danke dass wenigstens einer mit denkt!
"nur alleine.. verliert man.. immer." (Robo Durden)
Da der Attiny85 nur 512 Bytes RAM hat kann ich so ein vierpunkt "Z"
nicht erst in einen Buffer schreiben.
Ich werde jetzt auch nicht mehr 16-Segment Font sagen weil ich natürlich
immer 16bit Font gemeint habe. Also ein Font aus 16 sklaierbaren
Vektoren.
Wobei ich gerade mal 24 Vektoren gezeichnet habe. Siehe Anhang.
Solche 24 Vektoren kann ich beim Schreiben der 8bit hohen Zeilen
("pages") leicht per &-Operator testen und in die 8bit aufnehmen.
Als Bonus würde ich die ascii-Kleinbuchstaben um 50% nach unten
versetzen.
Außerdem könnte ich leicht die linken 9 Vektoren mit 0b11111111 und
0b10000000 testen und falls im Buchstaben nicht vorhanden den Buchstaben
nur mit "halber" Breite schreiben.
Dazu noch testen ob gar nur die rechten 5 Vektoren aktiv sind, dann kann
ich Satzzeichen wie "." und ":" und "!" noch schmäler ausgeben.
Seit über 15 Jahren brauchen die Maker eine 8px-64px Font-Lib unter 1
kB.
Und mit dem Attiny85 + SSD1306 ist der Bedarf nach wie vor da.
Irgendwie unfassbar dass es da anscheinend immer noch nichts gibt.
Naja, nicht wenn man wie immer hier die Antworten sieht.
Das R. schrieb:> Irgendwie unfassbar dass es da anscheinend immer noch nichts gibt.
Wenn es etwas noch nicht gibt, dann in der Regel deswegen, dass es
entweder schlecht ist oder niemand braucht.
Du löst da ein Problem, das niemand hat. Wir längst Mikrocontroller mit
reichlich Speicher, die sogar weniger kosten, als deine Zielplattform.
Dazu kommt, dass Vektor Fonts auf so wenigen s/w Pixeln einfach schlecht
aussehen. Wobei deine x-Segment Variante noch schlechter ist, weil sie
auf allen Displays schlecht aussieht.
Als Machbarkeitsstudie ist dein Projekt durchaus interessant. Ich gehe
davon aus, das alle Interessenten sehen wollen, was dabei heraus kommt,
aber wirklich benutzen wird es kaum keiner.
Naja, wenn du dich unbedingt auf die 16 Segmente beschränken willst,
kannst du weiter komprimieren, indem du den 9 möglichen Zielpunkten eine
Nummer gibst, die deine Plotroutine vorher weiss. Ein Buchstabe besteht
dann nur noch aus den Nummern für die 9 Ziele, die per Linienzeichnen
verbunden werden.
Mir war das damals zu unflexibel, weswegen ich die Koordinaten in das
16x16 Feld eingetragen hatte.
M.E. besteht die 'Library' dann aus 3 Hauptroutinen:
Nummer 1: Plotte einen Pixel bei Y,X (Attribut AND = Löschen, XOR =
Invertieren, OR = rübermalen)
Nummer 2: Ziehe mit Routine Nummer 1 eine Linie von Y1,X1 nach Y2,X2
(Attribute siehe Nummer 1)
Nummer 3: Zeichne Buchstabe 'X' mit Skalierung an Punkt Y,X (Wieder mit
den Attributen) unter Verwendung von Routine Nummer 2.
Damit wäre nur Nummer 1 anzupassen auf die Eigenarten des Displays.
Das war damals beim Mupid simpel, denn das war ein straighter
Framebuffer - in Z80 Assembler ein reiner Glücksfall und überhaupt der
Grund, warum ich diesen Unsinn gemacht habe.
Da brauchts keine Machbarkeitsstudie, schon alles von vielen Leuten
schon zig mal probiert -> immer gescheitert.
Displays mit geringer Auflösung brauchen einen handoptimierten
Bitmapfont (für jede Fontgrösse) wenns brauchbar aussehen soll.
BTW: Wenns nur um den Speicher geht könnte man sich eine Kompression für
die Bitmapfonts ausdenken. Ich könnte mir vorstellen das sich
Experimente in dieser Richtung eher lohnen.
Matthias S. schrieb:> ...Ein Buchstabe besteht> dann nur noch aus den Nummern für die 9 Ziele, die per Linienzeichnen> verbunden werden.> Nummer 2: Ziehe mit Routine Nummer 1 eine Linie von Y1,X1 nach Y2,X2> (Attribute siehe Nummer 1)
Ich kann nicht einzelne Pixel der Reihe nach zum Display schicken, dass
dauert zu lange. Und für das Zeichnen im temporären Buffer fehlt das
RAM.
Außerdem bräuchte ich für die 9 Ziele auch 4bit. Das "Z" mit seinen 4
Punkten ergäbe dann zwar nur 16bit aber das "W" wären 20bit. Dazu immer
ein paar Bit um die Länge der variablen Buchstaben zu kodieren :-(
Da ist es geschickter ich belege für jeden Buchstaben 3 Byte und kann
dann leicht mit & testen welche der 24 Vektoren in dem 8px hohen
Streifen gemalt werden.
Ich sehe durchaus ein dass der STM32 die bessere Wahl ist wenn man eh
zwei oder mehr I2C module anschließen will.
Das R. schrieb:> Und für das Zeichnen im temporären Buffer fehlt das> RAM.
Ja, das war natürlich damals bei mir kein Problem, da der Framebuffer
selber gross genug war und einfach im Speicherbereich des Z80 abgelegt
war. Um den Bildaufbau hat sich die Hardware alleine gekümmert (das war
so ein BTX-Display-Chip).
Ist ja auch nur als Diskussionsbeitrag gedacht.
Thread beobachten
Seitenaufteilung abschalten