Meine Grafiklibary für den Attiny85/SSD1306 und ein kleines Betriebssystem

So und jetzt mit Account hier noch eine kurze Beschreibung der Demos 
(steht aber auch im Youtube video und drunter):

#1 Diagram
In dieser Demostration zeichnen wir 2 Ebenen eine Ebene wird berechnet, 
das Diagram, eine weitere Ebene wird drüber geblendet, diese Ebenen 
haben jeweils Helligkeitswerte von 0 bis 63 werden zusammen addiert und 
dann mit Fehlerstreuung auf schwarz weis konvertiert

#2 Alien
Dieses Beispiel zeigt subtraktives Blending, und Textdarstellung, es 
werden 3 Ebenen gezeichnet, eine Textebene, über ihr eine berechnete 
ebene mit einem Grafikeffekt, und eine Bildebene, die Bildebene wird von 
der darunter liegenden Ebene subtrahiert.

#3 Flexgrid
Im Flexgrid Beispiel werden benutzerdefinerte Fonts gezeigt, der 
Systemschrift werden 6 Zeichen hinzugefügt und mit ihrer Hilfe wird eine 
Animation auf der Konsolenebene gezeichnet, darüber liegt ein 
Grafiklayer

#4 Will it Bend
Das "Will it Bend" beispiel zeigt einen klassischen Grafikeffekt, ein 
sich verbiegender Quader wird allein über die Berechnungsebene 
gezeichnet.


#5 Oszilloskop
Das "Oszilloskop"-Beispiel zeigt die Erstellung von Benutzeroberflächen. 
Ein simuliertes Oszilloskop mit einem Mauszeiger wird dargestellt. 
Darunter wird eine Textebene ausgegeben.


#6 Alleycat
"Alleycat" demonstriert die Nutzung von Konsolen und Animationen durch 
Umschalten von Layern. Es ist praktisch ein "Hello World"-Beispiel.

#7 Plasmastern
"Plasmastern" zeigt Fading-Effekte und einen berechneten 
Plasma-Grafik-Effekt.


#8 Spaceship
"Spaceship" demonstriert additives Blending und Rauschen durch 
Zufallszahlen.

#9 Wobble
"Wobble" zeigt die Manipulation von Layern on-the-fly. Während der 
Dekodierung des Layers wird eine Sinuswelle über dessen y-Position 
gelegt.

#10 Origin
"Origin" ist ein klassischer Copper-Effekt. Eine Grafik wird ausgegeben 
und jeweils spaltenweise manipuliert. Dadurch ergibt sich eine 
Fullscreen Animation. Zusätzlich wird eine Textebene angezeigt.

#11 Face Value
"Face Value" zeigt einen zeilenweisen Grafikeffekt.

#12 Boing Ball
"Boing Ball" demonstriert die Verschiebung von Layern und die Nutzung 
von Color-Keying.

#13 3D Engine
Die "3D Engine" stellt einen rotierenden Würfel dar. Primär wird das 
Zeichnen von Linien demonstriert.

#14 Crossfade
"Crossfade" liest direkt Daten aus zwei Ebenen, um damit eine 
Überblendung zwischen zwei Grafiken zu realisieren.

#15 Raycaster
"Raycaster" ist der Port einer simplen Raycasting-Engine für den PC. 
Eine Engine dieser Art wurde auch in original "Wolfenstein 3D" genutzt. 
Quelle der Engine, siehe Sourcecode.

über Geschmack kann man ja bekanntlich streiten, den Ton bei Youtube 
abschalten ist aber relativ einfach!

ein wesentlich flexibleres Rendering ist möglich, beispielsweise kann 
man eben Grafiken und Linien über den Text zeichnen... siehe auch

der Ram verbrauch ist sehr gering, je nach aktiviertem Featuresatz, der 
Raycaster braucht beispielsweise 56 Byte statische Variablen, und ca 90 
Byte Stack.

siehe auch:

Beitrag "Re: SSD1306 Library zum Darstellen von Text auf OLED Displays"

OMG schrieb:
> Und warum muss man sich dazu so eine hektische und nervige
> Musik anhören?

Könnte man mit Jerry Lee Lewis übertönen.

mfg

PittyJ schrieb:
> Sowas gab es 1985 auch für den C64. Das sind jetzt 37 Jahre her.
> Wo ist die Innovation?

Ich finde das wahnsinnig, das das auf einem IC mit 8 Pins läuft. Mich 
beeindruckt das!

das Library ist übrigens auf Github "umgezogen", wurde geputzt, 
unterstützt jetzt mehrere Konsolen mit Scrolling und Zoom, und als 
zusätzliche Platform den Arduino.

https://github.com/GoergPflug/AttinyStreamGfxApi

Gibts ne reale Anwendung dafür?

Zoom hab ich auf solchen Mini-Displays irgenwie nie vermisst, und ich 
kann mir gerade auch keine Anwendung vorstellen, wo ich sowas brauchen 
könnte....

Wozu soll das gut sein?

Übrigens hat die Chip-Größe nix mit der Gehäuse-Größe zu tun.

Ein ATMega328 dürfte sich da nur unwesentlich von einem ATTiny85 
unterscheiden.

Wenn du auf "klein" stehst, beschäftige dich lieber mit SMD!

Wenn Du das wirklich für andere Leute benutzbar machen möchtest, musst 
Du jede Funktion mit Parametern, Rückgaben und guter Beschreibung (sowie 
ggfs. Beispiel) dokumentieren.

Die Musik ist Geschmackssache, wenigstens mal nicht so langweilig, 
dürfte von mir aus auch Hardtechno sein ;-)

Oh Mann, hört ihr euch eigentlich selbst zu? Wo ist die 37 Jahre alte 
Lib, in C geschrieben, die sich auf verschiedenen Plattformen nutzen 
lässt?

@Görg: Auch wenn ich gerade keine Anwendung für Grafikdisplays habe, 
finde ich es gut, dass du dein Beispiel teilst. Das Video ist dabei sehr 
nützlich und sagt mehr als 1000 Worte. Danke!

ikannix schrieb:
> Zeno schrieb:
> Du bist ganz schön anmaßend! Es muss wohl noch gestattet werden, Dinge
> zu hinterfragen, zu mal wir uns hier in einem technisch orientierten
> Forum befinden.

nein, ikannix, du bist anmaßend. hast du schon was sinnvolles 
beigetragen? in diesem Thread bestimmt nicht. Und auch eine Spielerei 
ist sinnvoll, weil man damit Programmieren lernen kann. Manche können 
halt nur meckern, wenn andere was machen.

> Zeno schrieb:
> Ich frag mich ob es für dich nicht besser wäre Kochkurse auf YT
> anzuschauen.

Ich frage mich, ob es für dich nicht besser wäre, die Tastatur 
wegzuwerfen...

Mal abgesehen von der fragwürdigen Musikhinterlegung (Die vermutlich dem 
Alter und gewünschter Hintergrunduntermalung beim proggen/coden für den 
Flux oder so geschuldet ist??). Sind Überblendeffektr nicht so der 
Renner. Ein simuliertes UI mit zeigen einzelner Menüelemente wäre 
deutlich interessanter. Und wie man es dann programmtechnisch verwaltet, 
welche Resourcen es auf dem Controller benötigt... Der Würfel geht in 
diese Richtung.

Beachtliche Arbeit!! Hab sowas mal auf einem 8051 machen müssen.

ikannix schrieb:
> Zuerst schmeißt du aber dein Lötkolben weg - dann reden wir weiter.
>
> Wenn ich mir deine "Museums" Beiträge auf deiner HP anschaue - dann ist
> es bei dir mit der Innovation nicht weit her. Schon klar dass dich so
> ein Beitrag gleich vom Hocker haut :-))

Ja, ich habe hunderte von Beiträgen aus allen möglichen Gebieten der 
Elektronik auf meinen Webseiten aufbereitet, das ist mit der 
Retroelektronik ein schöner Ausgleich zu meiner Arbeit als 
Elektronikentwickler, da hab ich nämlich genug moderne Technik jeden 
Tag. Außerdem versuche ich in diesem Forum ab und an Leuten zu helfen, 
die technische Fragen haben. Und ich finde es toll, wenn sich jemand die 
Mühe macht, technische Dinge aktiv zu durchdenken, das muss ja nicht 
immer gleich sinnvoll sein...

Und was machst du so, außer anderer Leute Arbeit zu diskreditieren?

ikannix schrieb:
> genervter schrieb:
>> wird zeit das die überheblichen besserwisserischen alten?
>> säcke endlich mal bei seite gehen.......
>
> Hm ? Ich tippe mal auf Zeno (der Anmaßende), Wolfgang (der
> Museumsdirektor) , Abdul (der 8051 Versteher), .....

ikannix, der Schwätzer mit fehlender Sozialkompetenz...

das mit dem SP ist eine Nachlässigkeit, dort habe ich wohl vergessen 
etwas zu löschen was früher mal drinn war. Das 
Multitaskingbetriebssystem ist an sich eher ein "Nebenprodukt", ich habe 
es nicht ohne Grund aus der akuten Version auf Github komplett entfernt, 
schlicht weil es eher ein Experiment ist und es wohl dafür keine 
sinnvoll Verwendung geben dürfte, man ist auf kleinen Kontrollern 
schlicht mit anderen Konstruktionen besser dran wie mit preemtivem 
Multitasking und Swappping. Sinnvoll nutzbar dürften primär die 
Grafikfunktionalität sein, weil sie einige Probleme umschifft die andere 
Grafikbibliotheken auf dem Attiny haben, insbesondere das es eben mit 
nur 512 Byte Ram unmöglich ist den Bildschirminhalt zu puffern, eine 
regelmäßig auftretende Anforderung die schwer umzusetzen ist ist die 
Darstellung von Diagramen die von Text überlappt werden. Das geht mit 
den anderen verfügbaren Bibliotheken nur sehr schwer, man kann den 
Bildschirmspeicher nicht per I2C zurück lesen, das ist eine 
Einschränkung des SSD1306, und für einen Framebuffer fehlt das Ram.

Ich würde also auf die Version auf Github verweisen, in der alles 
entfernt wurde was nicht wirklich sinnvoll nutzbar ist.

"lieber" OMG, Header only Libraries sind durchaus verbreitet, und es 
macht in diesem Fall Sinn, durch diese Konstruktion optimiert GCC weit 
besser wie wenn man den Code in andere Dateien auslagert, der Effekt ist 
sehr real.

Ich kann die ganzen negativen Vibes hier auch nicht nachvollziehen, da 
wird auf dem Autor wegen der Musik (!!!) die er zu seinem Video gewählt 
hat rumgehackt und "mangelnde Innovation" beklagt.

Hackt ihr auf jedem auch so rum der ein Board-Layout "zum review" hier 
irgendwo postet? Da ist auch "keine Innovation" vorhanden wenn zum 
100sten mal ein Steuerungsboard designed oder "irgendwas mit LEDs" 
gemacht wurde.

Es mag nicht besonders innovativ sein, aber sowas kann durchaus als 
Programmierübung gut sein und als Basis für eigene Projekte. Wenn es 
dann irgendjemand anderes danach wiederverwerten kann, weil er genau 
sowas sucht, ist es doch völlig i.O.

All diese ach so "innovativen" Leute, die aus fertigen Codeschnipseln 
anderer Leute was zusammenbasteln sollten sich mal überlegen, wo sie 
denn ohne diese wären.

Das swappen ins Flash ist auch schwer zu debuggen, der AVR-Simulator 
scheint Bugs zu haben, ich hatte davor eine Routine die probiert hat 
Umschaltungen der Bits von 1 auf 0 zu minimieren, und die den 
Schreibbereich verschiebt wenn Speicherzellen ausfallen, auf dem 
Controller funktioniert sie wunderbar (zumindest hoffe ich es, Ausfälle 
konnte ich aber auf dem Controller noch nicht beobachten, das Flash 
scheint erstaunlich robust zu sein), auf dem Simulator wird nach jedem 
zweiten "flashen" Müll ins Flash geschrieben, sogar wenn man von Hand im 
Memory Viewer Daten ins Flash schreibt um den Ausfall durch Abnutzung zu 
simulieren.

ikannix schrieb:
> Hm ? Ich tippe mal auf Zeno (der Anmaßende), Wolfgang (der
> Museumsdirektor) , Abdul (der 8051 Versteher), .....

Du bist auch ganz schnell ganz alt mein Lieber!

Einem Original 8051 Grafik beizubringen, die auch nur halbwegs so 
schnell ist, daß man nicht beim Zeichnen zusehen kann, ist echt ne 
Aufgabe. Noch dazu wenn der LCD-Controller ein T6963C ist. Und das es 
ein 8051 war, lag schlicht am Arbeitgeber. Zu der Zeit war ich Z80 und 
68K Fan.
Ein anderes Projekt für den 8051 wurde dann für den 80C166 neu übersetzt 
und lief sofort mit Faktor 8000 schneller. Da staunte ich auch.


Über die Arbeit habe ich doch gar nicht gemeckert, sondern nur über die 
Darstellung dieser.

Wegen dem Betriebssystem, ich werde es getrennt nochmals 
veröffentlichen, sobald meine IR-Dioden und TSOP angekommen sind, ich 
habe leider nur einen TSOP und keine IR-Diode, deswegen kann ich den 
Netzwerkcode nur testen indem ich eine weisse Diode "voll draufscheinen" 
lasse, dann funktioniert es. Deswegen ist auch nur der Sendecode 
enthalten, der Empfängercode für die Netzpakete läuft akut noch auf 
einem Arduino.

Ich will die IR-Netzwerkfunktion aber richtig implementieren, leider 
scheinen die Dioden sich in China im Lockdown zu befinden. Deswegen wird 
sich das verzögern und ich stelle erstmal die Grafikfunktionalität 
fertig.

Schlachte doch ne alte TV-Fernbedienung.

Nein, ich arbeite komplett bzw fast komplett ohne Puffer im Ram, die 
einzigen vorhandenen Puffer sind folgende:

Speicher für die Konsole(n) bei 16x8 wären das 128 Byte, wenn die 
Konsole/n abgeschaltet sind auch diese Puffer nicht vorhanden.

ein optionaler 64 Byte Puffer für das Halftoning, ohne diesen Puffer ist 
die Qualität des Halftonings schlechter.

die Displayroutine "synthetisiert" das komplette Bild on the Fly, sie 
weis wann sich jeweils die angezeigten Objekte (Sprites/Layer)  ändern 
werden, zusätzlich ruft die Displayroutine einen Callback auf, mit dem 
man für jede X/Y Koordinate einen Helligkeitswert zurückgeben kann.

Die Bibliothek arbeitet "intern" immer auf 6 Bit Helligkeitswerten.

Diese Strategie reduziert den Speicherverbrauch auf das absolute 
Minimum.

Das Video ist übrigens bei Hackaday angekommen.

PittyJ schrieb:
> Sorry, wenn ich Demos sehe, die 1985 schon auf einem C64 mit <1MHz
> liefen, dann frage ich mich, wo der Fortschritt 37 Jahre später ist.
> Ein ATTiny gibt es mit 20 MHz, also 20 mal mehr Power. Und der C64 hat
> die Musik noch selber gemacht.

[ ] Du hast Ahnung vom C64.

Der hatte mit VID und SID zwei überaus clevere ASICs, die sich um SEHR 
Viel Arbeit beim Thema Video und Sound gekümmert haben. Ohne die wäre 
der C64 nciht mal ansatweise so leistungsfähig. Wo sie diese ASICs im 
AVR?

Könnte der Bresenham und Sprite-Kollisionserkennung in Hardware?

Abdul K. schrieb:
> Könnte der Bresenham und Sprite-Kollisionserkennung in Hardware?

Ob es der C64 konnte weiß ich nicht, der Amiga aber sicher. Ich vermute 
mal, daß der VIC keinen Bresenham konnte, ggf. aber Sprite-Kollision.

Stefan ⛄ F. schrieb:
> Ja, Sprite Kollisionen konnte der C64 in Hardware erkennen. Ich meine
> mich zu erinnern, dass er auch Kollisionen mit einer auswählbaren Farbe
> im Hintergrund-Bild erkennen konnte.

Absolut, das konnte bzw. kann er :-) Und der Hintergrund konnten wimre 
sowohl Zeichen als auch Pixel einer Bitmap sein.

Alleine das in Hardware zu realisieren stelle ich mir schon relativ 
komplex vor (inklusive überlappende Sprites etc.) und in Software würde 
das auch einige Taktzyklen kosten. Und das bei jedem Bildrefresh.

Es gibt ein Update...
ich bin jetzt übrigens auf version 0.9

unterstütze zusätzlich alle AVR-Arduinos, gefüllte Vektorgrafik, 
Zeichnen von Kreisen, und Videocompression

https://www.youtube.com/watch?v=pep0TOAl7SM

sowie einen "Interleavemodus" für das I2C, ich mische die I2C-Ausgabe 
unter die Berechnungen, dadurch sind sie praktisch umsonst, weil eben 
nicht mehr gewartet werden muss auf den I2C.
3D Grafik ist 500% schneller, normale ca 30%.

https://github.com/GoergPflug/AttinyStreamGfxApi

Grüße :-)

es gibt eine weitere Iteration des ganzen, diesesmal mit der Unterstützung von hardwarebeschleunigtem 3D auf dem SSD1306 für AVR Arduino, allerdings noch etwas alpha, und eben unbekannt wie weit die Features wirklich von allen Displays unterstützt werden, es ist noch etwas Forschung nötig.

https://www.youtube.com/watch?v=IJkiNY2OHoY

Grüße :)

Görg P. schrieb:

es gibt eine weitere Iteration des ganzen, diesesmal mit der Unterstützung von hardwarebeschleunigtem 3D auf dem SSD1306 für AVR Arduino, allerdings noch etwas alpha, und eben unbekannt wie weit die Features wirklich von allen Displays unterstützt werden, es ist noch etwas Forschung nötig.

https://www.youtube.com/watch?v=IJkiNY2OHoY

Grüße :)

Wenn das immer noch auf einem AtMega läuft, bin ich offiziell beeindruckt!

es ist ein Mega2560, aber es würde auch auf dem Attiny85 laufen vermutlich etwas schlechter, die Codegröße ist ziemlich klein für das 3d, aber die fehlenden Multiplikationen machen natürlich die Mathematik teurer.

Ich hab mich vor ein paar Jahren auch mal an Animationen auf dem Display versucht, das dann aber nicht mehr weiter verfolgt. https://www.youtube.com/watch?v=RE9Cm6moHj4

Görg P. schrieb:

es gibt eine weitere Iteration des ganzen, diesesmal mit der Unterstützung von hardwarebeschleunigtem 3D auf dem SSD1306 für AVR Arduino, allerdings noch etwas alpha,

Nette Spielerei, wenn man die Grafik nur um der Grafik Willen betreibt.

Ich habe 2020 einen Aufbau mit einem A*Nano und SSD1306 gemacht, der per ADS1115 Spannungen messen soll und diese zyklisch auf eine SD-Karte schreibt. Werte und Status sollen am OLED angezeigt werden.

Das war eine Bruchlandung, weil die OLED-Libraries (Adafruit oder u8g8) dermaßen viel RAM fressen, dass es für die Hauptaufgaben nicht mehr ausreicht.

Ich habe später eine Lib gefunden, die nur Text kann und ansonsten eher dusselig ist, aber wenig Ressourcen braucht und das Gerät damit endlich zum Leben bekommen.

Mein Standpunkt ist klar: Man braucht etwas, was sparsam mit dem Speicher umgeht! Grafikspielchen mögen nett sein, aber dafür ist Arduino nicht die passende Basis.

Manfred P. schrieb:

Mein Standpunkt ist klar: Man braucht etwas, was sparsam mit dem Speicher umgeht! Grafikspielchen mögen nett sein, aber dafür ist Arduino nicht die passende Basis.

Das basiert zwar auf Arduino-Hardware aber sicher nicht auf Arduino-Software.

Wenn man sowas machen will schreibt man das selber, und dann kann das sehr wohl sparsam wie auch performant zugleich sein.

Diese ganzen Arduino-Librarys können zwar scheinbar alles, nur leider nix davon richtig....aber das ist ja nichts Neues.

Was kann Arduino dafür dass AVRs nutzlos wenig RAM haben um Spaß zu haben.

Görg P. schrieb:

es gibt eine weitere Iteration des ganzen, diesesmal mit der Unterstützung von hardwarebeschleunigtem 3D auf dem SSD1306 für AVR Arduino, allerdings noch etwas alpha, und eben unbekannt wie weit die Features wirklich von allen Displays unterstützt werden, es ist noch etwas Forschung nötig.

https://www.youtube.com/watch?v=IJkiNY2OHoY

Grüße :)

Top. Find ich geil und mir gefällt die Musikauswahl. Da kickt direkt die Demonostalgie rein!