>Und deine Frage ist jetzt?
Es scheint so zu sein, dass es keinen Standard für ein objekorientiertes
Forth gibt. Der Syntax im geposteten Artikel-Link oben und im Link zur
Uni-Wien ist unterschiedlich.
Ich will ein einfache Möglichkeit, Objekte schnell zu definieren und
darzustellen, wie z.B.
Diese Stack-Orientierung mit UPN muß man aber wirklich mögen und
wollen...
Ich hielt Forth immer für ein Relikt aus den Anfängen der Computerei,
aus der Not der Ressourcenknappheit auf den damaligen Systemen heraus
geboren.
Hätte nicht gedacht, daß sich heute noch Jemand damit beschäftigt.
Das war damals (1983) schon sehr progressiv, denk auch an Smalltalk (die
beruehmte Implementierung Smalltalk-80) oder auch Lisp (Emacs, auch ca.
1980). Die RPN (reverse polish notation) fand ich schon damals
antiquiert, aber viele Ingenieure schworen darauf (der Uebergang vom
Rechenschieber zum Taschenrechner war wohl traumatisch fuer sie).
Heute ist es natuerlich schoen, dass Du fuer sehr wenig Geld (und
elektrische Leistung) Rechenleistung und Speicherplatz bekommst von
denen man damals noch nicht einmal Traeumen konnte.
Weisst Du ob es ein Entwicklungssystem fuer Forth gibt?
Thomas W. schrieb:> Das war damals (1983) schon sehr progressiv,
Müsste schon irgendwann in den Siebzigern gewesen sein. Ich habe hier
noch ein deutsches Forth Handbuch von 1982 liegen (E.Floegel).
Auch damals lagen wir schon ein Jahrzehnt mit solchen Dingen zurück.
Im Übrigen würde ich sagen, Forth ist das Entwicklungssystem.
Und so kann man's bekommen:
Christoph M. schrieb:>>Und deine Frage ist jetzt?> Es scheint so zu sein, dass es keinen Standard für ein objekorientiertes> Forth gibt. Der Syntax im geposteten Artikel-Link oben und im Link zur> Uni-Wien ist unterschiedlich.
Es gibt kein Forth Standard. Es gibt ein paar Standard-Token, aber schon
die Ausgabe ist implementierungsabhaengig. Und dann kannst Du eigene
Dictionaries definieren. It's the beauty of it.
Christoph M. schrieb:> Wahrscheinlich ist FORTH ein ziemlich exotisches Thema hier, aber ich> probiere es trotzdem mal:
Mein erster Computer* wurde in Forth programmiert. Ein
graphikorientiertes Forth hab' ich dann auch noch auf einem anderen
Computer ausprobiert ... und das hat mir als Begegnung mit dieser
Write-Only-Sprache völlig gereicht.
Wenn man mit einem HP-Taschenrechner sozialisiert wird, also die
Gehirnwindungen früh genug entsprechend verbogen werden, kommt man mit
stackorientierten Programmiersprachen sicherlich bestens zurecht und
kann beispielsweise auch in PostScript tolle Dinge anstellen.
Wenn aber nicht ...
<Pedanterie> Syntax ist weiblich. </Pedanterie>
*) Jupiter ACE. Z80, 3 kB RAM, davon grob 900 Byte für Programme und
Daten nutzbar. Forth-Interpreter in 8 kB ROM, der Quelltext gleich in
Tokens übersetzte (und damit mit 900 Byte doch etwas mehr möglich machte
als ein simples "hello world").
Christoph M. schrieb:> Wobei mir die Zeile1 50 circle heap-new constant my-circle>> nicht ganz klar ist und umständlich erscheint (was soll die 50 auf> "heap-new constant" würde ich auch gerne verzichten.
Ich habe ja nun wirklich keine Ahnung von Forth, aber das, was die da
schreiben, klingt ziemlich sinnvoll:
1
Now we can create a circle on the heap (i.e., allocated memory) with:
2
3
50 circle heap-new constant my-circle
4
heap-new invokes construct, thus initializing the field circle-radius with 50. We can draw this new circle at (100,100) with:
> Für graphische Anwendungen wäre ein objektorientiertes Forth nicht> schlecht.
Darueber kann man natuerlich geteilter Meinung sein, aber ich meine doch
das HP das vor 30Jahren fuer den HP48SX erfunden hat.
Vanye
Oliver S. (oliverso)
30.10.2025 09:45
>Ich habe ja nun wirklich keine Ahnung von Forth, aber das, was die da>schreiben, klingt ziemlich sinnvoll:> Now we can create a circle on the heap (i.e., allocated memory) with:
Ah, jetzt ist es klarer.
Ich hätte gerne so einen Syntax:
1
20 10 "mytext" textoutput
2
"hallo" mytext
3
10 delay
4
"nix" mytext
Das soll ein Text-Output Object an der Position 20,10 kreieren und dann
erst "hallo" und danach "nix" dahin schreiben. Was haltet ihr von diesem
Syntax?
Thomas W. schrieb:> Ich meinte etwas Neues, z.B. VSCode- oder Eclipse-basiert?
Ich weiß auch nicht wie's passieren konnte,
aber gerade fiel mir sofort Ardu-Forth ein,
unmittelbar gefolgt von Forthuino.
Christoph M. schrieb:> Was haltet ihr von diesem> Syntax?
Deine Entscheidung. Wenn die Forth Syntax und Semantik deines Forth es
her geben bau es dir genau so. Du bist dein eigener König in deinem
eigenen Forth-Königreich.
Das war in Forth schon immer so. Zuerst baut man sich eine DSL, mit der
DSL löst man sein Problem.
Hannes J. schrieb:> Das war in Forth schon immer so. Zuerst baut man sich eine DSL, mit der> DSL löst man sein Problem.
Das ist für viele, die in Forth reinschnuppern anfangs recht verstörend,
ebenso wie die UPN.
Einer meiner Ausbilder sagte mal recht salopp:
In anderen Sprachen (er meinte in Hauptsache C und Pascal) muss man das
"Problem" solange modifizieren und beschneiden, bis man es in der
Sprache abfassen kann.
In Forth verändert man die Sprache solange, bis sie die Problemstellung
vollständig widerspiegelt.
In anderen Sprachen fügt man einfach eine neue Funktion hinzu, zum
Beispiel zum Zeichen eines Kreises. Wenn das in Forth bereits als
Spracherweiterung gilt, dann sieht man daran die "Höhe" dieser
Hochsprache.
Hannes J. (pnuebergang)
30.10.2025 10:12
>Deine Entscheidung. Wenn die Forth Syntax und Semantik deines Forth es>her geben bau es dir genau so. Du bist dein eigener König in deinem>eigenen Forth-Königreich.
Ich denke, du liegst falsch. Schau dir den Syntax meines Beispiels noch
mal genau an.
Christoph M. schrieb:> Hannes J. (pnuebergang)> 30.10.2025 10:12>>Deine Entscheidung. Wenn die Forth Syntax und Semantik deines Forth es>>her geben bau es dir genau so. Du bist dein eigener König in deinem>>eigenen Forth-Königreich.>> Ich denke, du liegst falsch. Schau dir den Syntax meines Beispiels noch> mal genau an.
Wie? Ich liege falsch dass das deine Entscheidung ist? Na dann, wessen
Entscheidung soll es denn sein? Ach egal, wenn du nicht machen willst
was du selber willst dann lass es halt.
Johann L. schrieb:> In anderen Sprachen fügt man einfach eine neue Funktion hinzu, zum> Beispiel zum Zeichen eines Kreises.
In den anderen Sprachen ist exakt definiert, wie eine Funktion aufgebaut
wird, wie Anweisungen auszusehen haben.
C hat irgendwas um Hundert Schlüsselworte.
Rigide Syntaxregeln.
Forth hat nichts davon.
Forth kennt nur Worte.
Diese Worte werden (meist) durch Whitespaces voneinander getrennt.
Das war es schon an Syntaxregeln.
Jedes Wort ist jederzeit redefinierbar, also auch mitten im laufendem
Betrieb.
Also, ja, es wird die Sprache selber verändert. Das ist das normale
Vorgehen wenn man mit einem Forth System arbeitet. z.B. das hinzufügen
von spezialisierten Compilern und Interpretern.
Der Streit ob Forth nun eine Hochsprache ist, wird seit Jahrzehnten
geführt.
Ich sage:
Der Punkt ist falsch, die Frage ist falsch, der Gedanke ist falsch, die
Annahme ist falsch.
Forth ist eher eine Philosophie, als eine Sprache.
Forth ist eher ein System, als eine Sprache.
Arduino F. schrieb:> Forth ist eher eine Philosophie, als eine Sprache.
Ja, ich habe den Link auf das Forth-Manifesto im Transputer Thread
gesehen.
300+ Seiten, die man sich erst mal reinziehen muss, um die Hirnwindungen
forthkompatibel zu bekommen.
Johann L. schrieb:> um die Hirnwindungen> forthkompatibel zu bekommen
Ja!
Das ist ein Projekt.
Glaube auch nicht, dass das es jeder bis in die Komfortzone schafft.
Vorbildung in anderen Sprachen dürfte da eher hinderlich, als hilfreich,
sein
Arduino F. schrieb:> Glaube auch nicht, dass das es jeder bis in die Komfortzone schafft.
Nachdem die Sprache im Pleistozän der Programmiersprachen ersonnen
wurde, und seit dem ein scheintotes Dasein fristet, wirds wohl überhaupt
niemand überhaupt versuchen.
Oliver
Christoph M. schrieb:>>Ich?>>Auf µC: C++>>Vom AVR 8Bit Tiny bis 64Bit K210>> Du solltest die Frage schon lesen, da stand "das obige Pico2_LCD_096> Board".
Die da?
Christoph M. schrieb:> Welche Programmiersprache nutzt ihr?
Manchen fällt es wohl wirklich scwher, Zusammenhänge in einem Satz zu
nennen.
Oder zwei Sätze sinnvoll zu verbinden.
Christoph M. schrieb:> Hat jemand von euch das obige Pico2_LCD_096 Board schon mal ausprobiert?> Wenn ja, welche Programmiersprache nutzt ihr?
Dürfte verständlicher sein, oder?
Christoph M. schrieb:> Du solltest die Frage schon lesen,
Da standen 2 Fragen!
Auf eine kann ich eine positive Antwort liefern.
Übrigens:
Meine Antwort schließt auch das Pico2_LCD_096 ein, wenn es mal in meine
Hände kommt.
Aber das hast du ja nicht gefragt und offensichtlich nicht verstanden
Um noch einmal zum Thread-Thema zurück zu kommen, ich halte eine
Objekt-orientierte Erweiterung dieser Sprache im besten Falle für einen
akademischen Brainfart.
Forth ist niemals für so etwas konzipiert worden. Manchmal sollte man
die Dinge einfach so belassen (und benutzen) wie sie erdacht worden sind
und sie nicht in maximal unpassende Gewänder zwängen.
Mir jedenfalls graust es bei dem Gedanken, ein ++ an den Namen gehängt
zu sehen. Welch hässlichen Dinge so etwas nach sich zieht, kann man ja
seit vielen Jahren sehen.
Norbert (der_norbert)
30.10.2025 17:14
>Um noch einmal zum Thread-Thema zurück zu kommen, ich halte eine>Objekt-orientierte Erweiterung dieser Sprache im besten Falle für einen>akademischen Brainfart.
Gut, aber immerhin beschäftigt sich ja die Uni Wien damit, wenn du das
mit "Brainfart" meinst:
https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Basic-Objects-Usage.html#Basic-Objects-Usage
Mir geht es nur indirekt um FORTH. Ich hätte nur gerne die
Bequemlichkeit von FORTH schnell eigene Definitionen zu erzeugen, wie
oben schon beschrieben:
1
20 10 "mytext" textoutput
2
"hallo" mytext
3
10 delay
4
"nix" mytext
Ich überlege gerade, einen kleinen Interpreter in Micropython (bzw.
Circuitpython, das gibt es für das Board
https://circuitpython.org/board/waveshare_rp2350_lcd_0_96/
der das Script oben versteht )
Vielleicht sollte man einen Micropython/Circuitpython Thread für das
Board aufmachen.
Christoph M. schrieb:> Norbert (der_norbert)> 30.10.2025 17:14>>Um noch einmal zum Thread-Thema zurück zu kommen, ich halte eine>>Objekt-orientierte Erweiterung dieser Sprache im besten Falle für einen>>akademischen Brainfart.>> Gut, aber immerhin beschäftigt sich ja die Uni Wien damit, wenn du das> mit "Brainfart" meinst:> https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Basic-Objects-Usage.html#Basic-Objects-Usage
Der Zweck, womit sich manche Forschenden beschäftigen, ist auch manchmal
etwas zweifelhaft.
Ein Prof von mir (über 20 Jahre her) hat auch noch in einer Sprache
programmiert, die damals schon nicht mehr geschult wurde.
> Ich überlege gerade, einen kleinen Interpreter in Micropython (bzw.> Circuitpython, das gibt es für das Board> https://circuitpython.org/board/waveshare_rp2350_lcd_0_96/> der das Script oben versteht )
Du willst FORTH mit python auswerten?
Der "Hersteller" hat sogar ein Tutorium dazu:
https://www.waveshare.com/wiki/Pico-LCD-0.96#Python> Vielleicht sollte man einen Micropython/Circuitpython Thread für das> Board aufmachen.
Welcher "man"? Du vielleicht?
Christoph M. schrieb:> Gut, aber immerhin beschäftigt sich ja die Uni Wien damit, wenn du das> mit "Brainfart" meinst:
Dann passt ja akademisch. ;-)
Nur weil ein paar Leute gerade nichts anderes zu tun haben, …
Christoph M. schrieb:> Ich überlege gerade, einen kleinen Interpreter in Micropython (bzw.> Circuitpython, das gibt es für das Board
Das iss 'n normaler 2350, das gibt's schon fertig. Ein kleines module
für das screen device dazufrieren und den Karton zumachen. Fertig!
Norbert (der_norbert)
30.10.2025 18:08
>Das iss 'n normaler 2350, das gibt's schon fertig. Ein kleines module>für das screen device dazufrieren und den Karton zumachen. Fertig!
Tja, irgendwo hängt es immer:
Beitrag "Circuitpython und Waveshare PiPico2 LCD0 nch96"
Christoph M. schrieb:> Mir geht es nur indirekt um FORTH. Ich hätte nur gerne die> Bequemlichkeit von FORTH schnell eigene Definitionen zu erzeugen, wie> oben schon beschrieben:>
1
20 10 "mytext" textoutput
2
> "hallo" mytext
3
> 10 delay
4
> "nix" mytext
Du möchtest Postscript.
Gibt's das eigentlich für irgendeinen uC?
Christoph M. schrieb:> Norbert (der_norbert)> 30.10.2025 18:08>>>Das iss 'n normaler 2350, das gibt's schon fertig. Ein kleines module>>für das screen device dazufrieren und den Karton zumachen. Fertig!>> Tja, irgendwo hängt es immer:> Beitrag "Circuitpython und Waveshare PiPico2 LCD0 nch96"
Ich habe präzise einmal Zirkuspython ausprobiert und es für noch nicht
einmal halbwegs sinnvoll einsetzbar befunden. Selbst das Attribut
Kinderspielzeug wäre noch ein Euphemismus.
Manchmal ist es in der Tat besser, wenn man nicht versuchte tausend
Dinge besonders schlecht zu machen, sondern lieber nur hundert Dinge,
dafür gut.
Normales MicroPython und ein Hand-gedengeltes module wäre meine Wahl.
Hab' vor Jahren mal eines für ein ST7735 1,8" TFT geschrieben. Hat einen
Tag gedauert. Inklusive Optimierung.
Norbert schrieb:
>Normales MicroPython und ein Hand-gedengeltes module wäre meine Wahl.>Hab' vor Jahren mal eines für ein ST7735 1,8" TFT geschrieben. Hat einen>Tag gedauert. Inklusive Optimierung.
Ich wollte jetzt eigentlich kein Forschungsprojekt zu diesem
Display-Board starten. Das ist eine kleine Nebenspielerei und der Plan
war, einen Text in unterschiedlichen Größen an unterschiedliche
Positionen anhand eines Beispiels zu schreiben.
Christoph M. schrieb:> Norbert schrieb:>>Normales MicroPython und ein Hand-gedengeltes module wäre meine Wahl.>>Hab' vor Jahren mal eines für ein ST7735 1,8" TFT geschrieben. Hat einen>>Tag gedauert. Inklusive Optimierung.>> Ich wollte jetzt eigentlich kein Forschungsprojekt zu diesem> Display-Board starten. Das ist eine kleine Nebenspielerei und der Plan> war, einen Text in unterschiedlichen Größen an unterschiedliche> Positionen anhand eines Beispiels zu schreiben.
Abhängig vom verwendeten Controller hat ja vielleicht schon jemand einen
zumindest rudimentären Treiber gedengelt.
Schau mal bei:https://awesome-micropython.com/
Christoph M. schrieb:> Welche Programmiersprache nutzt ihr?
Die Liste würde sehr lang werden!
Hauptsächlich programmiere ich in Assembler verschiedene Architekturen.
Vom Z80, Z8 über 8086 und 8051 sowie PIC, AVR.
Hochsprachen - je nach Anwendung vom BASIC in verschiedenen Ausführungen
über TurboPascal, DBase, Foxbase-Foxpro-Visual Foxpro, C, und natürlich
Forth mit Z8, Z80, 8051, PC.
Ich habe bestimmt noch Etliches vergessen?
P.S. Focal
Ich frage mich was immer neue Sprachen bringen sollen. Lernen muss man
doch jede neu und egal wie einfach sie zu sein scheint. Assembler ist
sicher nicht das, was ich heute empfehlen würde, aber C ganz sicher.
Und mit C++ ist man auch gut dabei.
Ich mache das Wenige mit Arduino, weil ich auch bei diesen Controllern
bleibe. Und wenn, dann mache ich auch nichts Bewegendes mehr.
Soll ja jeder gerne alles lernen, aber ich persönlich würde dann z.B.
lieber so gut wie nur irgendwie möglich C lernen. Das ist die
Hochsprache, die auf so ziemlich jeden Mikrocontroller funktionieren
wird.
Frank O. schrieb:> Ich frage mich was immer neue Sprachen bringen sollen.
Forth ist ja nun nicht besonders neu.
Bei C muss man sich um viele Dinge selber kümmern, und es hat teilweise
gewöhnungsbedürftige Syntax (Pointer- und Stringoperationen).
python erzeiht wenigstens dazu, Quellcode strukturiert zu formatieren.
Welchen Vorteil Ajax gegenüber JS bietet, weiß ich auch noch nicht.
> Assembler ist> sicher nicht das, was ich heute empfehlen würde, aber C ganz sicher.> Und mit C++ ist man auch gut dabei.
Assembler funktioniert nicht plattformübergreifend. Hochsprachen schon
eher.
> Ich mache das Wenige mit Arduino, weil ich auch bei diesen Controllern> bleibe. Und wenn, dann mache ich auch nichts Bewegendes mehr.
Arduino ist nur eine Entwicklungsumgebung mit der Zielsetzung eine
Programmiersprache für viele Controller zu haben.
Man kann mit dem Code für einen 8-Bit AVR genauso programmieren, wie
einen ESP32. (unter Beachtung gewisser Abweichungen). Z.B. wird mit
"Serial.begin()" bei beiden die Standard-UART-Schnittstelle
initialisiert).
> Soll ja jeder gerne alles lernen, aber ich persönlich würde dann z.B.> lieber so gut wie nur irgendwie möglich C lernen. Das ist die> Hochsprache, die auf so ziemlich jeden Mikrocontroller funktionieren> wird.
Solange es dafür einen Compiler und Linker gibt.
Hallo,
Rahul D. schrieb:> Solange es dafür einen Compiler und Linker gibt.
Mir ist kein halbwegs verbreiteter Prozessor bekennt, für den es keinen
C-Compiler gibt.
rhf
Roland F. schrieb:> Mir ist kein halbwegs verbreiteter Prozessor bekannt, für den es keinen> C-Compiler gibt.
Das ist ja schön.
Mir fällt auch keiner ein. Das liegt aber wohl eher daran, dass mein
Controller-Spektrum relativ begrenzt ist.
Wenn ich in der Vergangenheit wühle, konnte vor 30 Jahren gewisse
(verbreitete) PICs nur in Assembler programmieren.
Johann L. schrieb:> Wenn das in Forth bereits als> Spracherweiterung gilt, dann sieht man daran die "Höhe" dieser> Hochsprache.
Und wenn man Forth kennt, dann weiss man nach dieser Aussage, dass Du es
nicht kennst.
Christoph M. schrieb:> Was haltet ihr von diesem Syntax?
Wäre es nicht sinnvoller zuerst ein TextOutput Object zu erzeugen (wenn
man es objectorientiert machen will).
Dann das Objekt zu positionieren,ggf. sichtbar zumachen, und erst zum
Schluß Text anzuzeigen?
Wenn Du nämlich viele TextOutput Objekte anlegen musst, dann haben die
ja u.U. noch gar keine festgelegte Position.
/regards
Andreas H. (ahz)
>Wäre es nicht sinnvoller zuerst ein TextOutput Object zu erzeugen (wenn>man es objectorientiert machen will).
Vielleicht ist der Code doch etwas missverständlich, den ich
hingeschrieben habe.
Ich versuche es mal genauer am "use case" zu erklären: Oft hat man auf
dem Bildschirm analoge Werte, die man anzeigen will. Am besten schreibt
man einen Namen davor, dass man weiß, was der Wert bedeutet und im
besten Fall noch eine Einheit dahinter. Man muss eigentlich am Anfang
nur das Objekt mit Namen, Position und eventuell Einheit auf dem
Bildschirm erzeugen. Später braucht man an das Objekt eigentlich nur
noch periodisch den neuen analogen Wert zu schicken.
So ähnlich wie in dem Bild:
https://www.mikrocontroller.net/attachment/681824/PiPicoLcd96_Voltmeter.png
Christoph M. schrieb:> Wahrscheinlich ist FORTH ein ziemlich exotisches Thema hier
Nicht nur hier, sondern vor allem: heute.
> Für graphische Anwendungen wäre ein objektorientiertes Forth nicht> schlecht.
Forth und "objektorientiert" ist schon vom Grundkonzept her ziemlich
unverträglich.
> Einen Grundlagenartikel zu einer Form der Objektorientierung gibt es> hier:> https://vfxforth.com/flag/jfar/vol3/no3/article3.pdf
Nunja, man kann sicher auch eine Klobürste zum Zähneputzen verwenden.
Aber die Handhabung ist doch etwas haklig und der Erfolg bezüglich der
Aufgabe doch eher suboptimal.
Christoph M. schrieb:> Für graphische Anwendungen wäre ein objektorientiertes Forth nicht> schlecht.
Mit welcher Begründung? Welche Kompetenz hast du, dass du das beurteilen
kannst?
Man könnte auch Postscript nehmen, dann hat man ne
forth-ähnliche Sprache zur Grafikprogrammierung zur
Verfügung.
Gibt es da ein Interpreter oder Compiler im
Mikrocontroller-Bereich?
mfg
Lotta . schrieb:> Gibt es da ein Interpreter oder Compiler im> Mikrocontroller-Bereich?
Du könntest versuchen, Ghostscript zu portieren. Das stammt aus Zeiten,
zu denen PCs so viel Rechenleistung hatten wie ein mittlerer ARM-Cortex;
außerdem steckt ein Postscript-Interpreter seit Jahrzehnten in jedem
etwas besseren Drucker drin - und auch da ist da, was da als Prozessor
werkelt, nicht irrwitzig leistungsfähig.
Ein 8-Bit-AVR oder ähnliches dürfte allerdings unter der Latte
durchgesprungen sein, ein paar hundert kByte RAM dürften schon nötig
sein.
Ghostscript gab es auch für DOS, d.h. ein 16-Bit-System mit -genau- ein
paar hundert kByte RAM.
Du könntest Dir aber auch ein CYD besorgen und darauf z.B. "Display
PostScript" portieren.
Das ist sicherlich mühsam, aber ... wer Forth(ähnlich) programmieren
will, der scheut keine Mühen, oder?
https://en.wikipedia.org/wiki/Ghostscripthttps://github.com/witnessmenow/ESP32-Cheap-Yellow-Displayhttps://en.wikipedia.org/wiki/Display_PostScript
Harald K. schrieb:> Lotta . schrieb:>> Gibt es da ein Interpreter oder Compiler im>> Mikrocontroller-Bereich?>> Du könntest versuchen, Ghostscript zu portieren. Das stammt aus Zeiten,> zu denen PCs so viel Rechenleistung hatten wie ein mittlerer ARM-Cortex;> außerdem steckt ein Postscript-Interpreter seit Jahrzehnten in jedem> etwas besseren Drucker drin - und auch da ist da, was da als Prozessor> werkelt, nicht irrwitzig leistungsfähig.
Jep. Man sehe sich z.B. das anhängende Postscript "Programm" an. Das
erzeugt ein IFS-Fraktal[1], den Barnsley Farn. So genannt weil es von
Michael F. Barnsley als Beispiel für ein natürliches Objekt mit
näherungsweise fraktaler Struktur benannt wurde.
Auf einem PC mit Ghostscript rendert das in Sekunden, während ein
Drucker mit eingebautem Postscript-Interpreter für ein paar Minuten in
Tiefschlaf versinkt.
[1] https://de.wikipedia.org/wiki/Iteriertes_Funktionensystem
Axel S. schrieb:> Auf einem PC mit Ghostscript rendert das in Sekunden, während ein> Drucker mit eingebautem Postscript-Interpreter für ein paar Minuten in> Tiefschlaf versinkt.
Naja, kommt a) auf den Drucker und b) dessen Auflösung an - ein
typischer 600-DPI-Drucker hat eine ganz erheblich größere zu
bearbeitende "Bildschirmfläche" als die, mit der GS für den PC-Monitor
rendert.
Eine A4-Seite (abgerundet auf 8x11") mit 600 Dpi hat eine Auflösung von
4800 x 6600 Pixeln ... da ist natürlich ein Drucker 'ne Weile lang mit
beschäftigt.
Wenn man aber die Ausgabeauflösung z.B. auf die des CYD beschränkt
(320x200 oder so), dann dürfte die Wartezeit nicht mehr ganz so
elendiglich lange sein.
Wow, ich bin erstaunt, dass es jetzt doch eine ganze Reihe nützlicher,
kompetenter Beiträge gab. Ich wollte den Thread ja schon aufgeben.
Danke :-)
Lotta schrieb
>Man könnte auch Postscript nehmen,
Axel S. (a-za-z0-9)
>farn.ps (1,22 KB)
Das Postscript Forth-artig ist, wusste ich nicht, ist aber sehr
interessant. Es scheint also so zu sein, dass der ursprünglicher
Gedanke, FORTH für graphische Elemente zu verwenden, schon sehr lange
gemacht wurde.
1
Design:
2
The original PostScript was written for printing, with the model being that only one document could be printed at one time, and that the document was broken into logical sections approximating a page. For this reason, the underlying model of PS was based on a stack machine similar to the Forth programming language, which reduced the complexity of the code on the printer and the amount of memory needed to store individual graphics.
( https://en.wikipedia.org/wiki/Display_PostScript )
Ich meine gehört zu haben, dass die Nextion-Display auch mit einem
speziellen Forth-Prozessor ( J1 ) laufen.
Es ist interessant, was Perplexity zur Objektorientierung von Postscript
meint
1
PostScript is not natively an object-oriented programming language, but it is a stack-based, interpreted language with many high-level features. It supports procedures and modular programming but does not inherently provide built-in object-oriented constructs like classes and inheritance. However, PostScript’s flexible dictionary structures and procedures allow programmers to simulate object-oriented principles, such as encapsulation and dynamic dispatch, through custom coding techniques. Notably, extensions and environments like Sun's NeWS demonstrated how PostScript dictionaries could be used to create a dynamically-bound object-oriented runtime environment inspired by Smalltalk concepts.
Das hört sich für mich so ähnlich an, wie Strukturen in C die man dort
manchmal auch für Objekte verwendet.
Geht es dir bei der Kombination von Forth mit Objektorientierung nur um
den Erkenntnisgewinn, oder versprichst du dir konkrete Vorteile davon?
Falls letzteres:
Für den RP2{04,35}0 ist ja eine ganze Reihe von Programmiersprachen
verfügbar:
1
The microcontroller can be programmed in assembly, C, C++, Forth, Swift,
2
Free Pascal, Rust, Go, MicroPython, CircuitPython, Ada, TypeScript and
3
Zig.
(https://en.wikipedia.org/wiki/RP2040)
Wieso ausgerechnet Forth? Wo siehst du die Vorteile bspw. gegenüber C
oder C++?
- Kürzere Entwicklungszeiten?
- Übersichtlicheren Quellcode?
- Bessere Wartbarkeit?
- Schnellere Ausführung des Codes?
- Geringerer Speicherplatzbedarf (Flash und/oder RAM)?
- Bessere Standardisierung?
- Bessere Dokumentation (Sprachreferenz, Tutorials usw.)?
- Bessere Unterstützung durch die Community?
- Mehr persönliche Programmiererfahrung vorhanden?
- ...?
Und warum muss es unbedingt objektorientiert sein?
Die meisten gängigen Grafikbibliotheken (nicht zu verwechseln mit
GUI-Framwworks) sind es höchstens ansatzweise. Oft sind zwar das
Drawable und der Graphics-Context Objekte im Sinne der OOP, nicht aber
die Grafikprimitive (Linie, Polygon, Kreis usw.).
Zum Thema PostScript:
Während das klassische PostScript für Drucker nach wie vor eine gewisse
Bedeutung als herstellerübergreifende Grafiksprache für Drucker hat, ist
Display PostScript längst gestorben. Die meisten der Gründe, warum es
damals eingeführt wurde, sind heute nicht mehr relevant, dafür treten
seine Nachteile (vor allem die geringe Ausführungsgeschwindigkeit wegen
des Interpreters) mehr und mehr in den Vordergrund.
Yalu X. (yalu) (Moderator)
>Geht es dir bei der Kombination von Forth mit Objektorientierung nur um>den Erkenntnisgewinn, oder versprichst du dir konkrete Vorteile davon?
Sagen wir mal, es ist reines spielerisches Interesse.
>Für den RP2{04,35}0 ist ja eine ganze Reihe von Programmiersprachen>verfügbar:
Für den PiPico2 (also RP2350), der auf diesem Display-Board verbaut ist,
habe ich kein uf2-File gefunden.
Der nächste Aufwand wäre dann, einen Display-Treiber für das Board zu
schreiben. Da bin ich mir nicht sicher, ob sicher der Aufwand lohnt.
RBX schrieb:
>YT:>"Concatenative programming and stack-based languages" by Douglas Creager>https://www.youtube.com/watch?v=umSuLpjFUf8
Harte Kost, aber sehr interessant. Das Konzept der Befehle auf dem Stack
hat mich an Python erinnert. Und tatsächlich: Python wird auf einer
Byte-Code Stackmaschine ausgeführt. Die scheint ihre Ursprünge in Forth
zu haben, allerdings mit der starken Erweiterung das die Daten Objekte
sind.
Was die OOP betrifft, ist das m.E. ja nur eine andere Schreibweise für
den Quellcode. Ist halt dafür gedacht, zusammengehörige Dinge zu
kapseln,
um die Lesbarkeit und Wartbarkeit zu erhöhen. Anders, wie bei Strukturen
können da dann auch Prozeduren/Funktionen (Methoden) zu den Variablen
(Eigenschaften) dazu geschrieben werden. Also :
--------------------------------------------
Klassen - Objekte - Eigenschaften - Methoden
--------------------------------------------
Das Salz in der Suppe sind dann :
---------------------------------------------------------
Kapselung - Vererbung - Polymorphie
Überschreiben - Überladen - Konstruktoren - Destruktoren
---------------------------------------------------------
Damit macht es dann erst richtig Sinn.
Was da zum Schluß als eine vom Compiler erzeugte Binary rauskommt,
egal ob bei prozeduraler oder OOP - Programmierung, dürfte es da
kaum Unterschiede geben. Der Compiler muß das ja auch wieder in Adressen
und Sprünge zurück verwurschteln. Ein Prozessor, egal ob Mikro oder
normaler PC, kennt kein OOP. Da wird es wohl eher kein Geschwindigkeits-
gewinn geben, eher das Gegenteil. Kommt dann darauf an, wie gut der
Compiler das zurück übersetzt.
Also, bei großen Projekten, wo Teams zusammenarbeiten und auf gemeinsame
Klassen zugreifen müssen, ist es halt interessant. Bei kleineren Sachen
sehe ich da kein großer Vorteil.
So mal meine Ansicht darüber.
Moin,
Lotta . schrieb:> Gibt es da ein Interpreter oder Compiler im> Mikrocontroller-Bereich?
Nimm halt irgendein (ur)aelteres ghostscript (als src) und einen
c-compiler fuer den Mikrocontroller und bau's dir selber...
Vor 1000 Jahren habbich das mal mittels turbo-c fuer einen sehr
speziellen Siemens-PC mit 80186 Prozessor gemacht.
Gruss
WK
Yalu X. schrieb:> Geht es dir bei der Kombination von Forth mit Objektorientierung nur um> den Erkenntnisgewinn, oder versprichst du dir konkrete Vorteile davon?
Er will gar nichts machen außer hier rum jammern. In der Woche in der er
hier rum jammert hätte er mehrere existierende OO-Erweiterungen
ausprobieren und sogar anfangen können seine angeblich gesuchte sehr
spezielle OO-Erweiterung selber zu implementieren. Wie man das in Forth
halt so macht.
Aber er ist schon patzig geworden als ihm gesagt wurde das es seine
Entscheidung ist was er wie macht. Das hat er so gar nicht verarbeiten
können. Er? Was machen? Um Himmelswillen.
Christoph M. schrieb:> RBX schrieb:>>"Concatenative programming and stack-based languages" by Douglas Creager>>https://www.youtube.com/watch?v=umSuLpjFUf8>> Harte Kost, aber sehr interessant. Das Konzept der Befehle auf dem Stack> hat mich an Python erinnert. Und tatsächlich: Python wird auf einer> Byte-Code Stackmaschine ausgeführt. Die scheint ihre Ursprünge in Forth> zu haben, allerdings mit der starken Erweiterung das die Daten Objekte> sind.
Falsche Baustelle. Die OO macht der Compiler und nicht die Bytecode
Ausführungsebene. Ein Prozessor ist ja am Ende auch nichts anderes. Nur
daß man den "Bytecode" dann eben "Maschinensprache" nennt. Trotzdem kann
er Programme ausführen, die in einer OO-Sprache geschrieben sind. Der
Prozessor muß dazu nichts von Kapselung und Methoden wissen. Eine
Methode ist am Ende des Tages auch nur eine Subroutine.
>>Das Konzept der Befehle auf dem Stack>> hat mich an Python erinnert
Axel S. (a-za-z0-9)
>Falsche Baustelle.
Nein, das ist schon die richtige Baustelle. Es ging mir darum
aufzuzeigen, dass auf der unteren Ebene der modernen Programmiersprache
Python ein VM arbeitet, welche die Konzepte von Forth übernommen und
stark erweitert hat.
Wer mal wissen will, wie so etwas in der Implementierung aussieht, kann
sich die VM von Micropython anschauen:
https://github.com/micropython/micropython/blob/master/py/vm.c
Christoph M. schrieb:> Nein, das ist schon die richtige Baustelle. Es ging mir darum> aufzuzeigen, dass auf der unteren Ebene der modernen Programmiersprache> Python ein VM arbeitet, welche die Konzepte von Forth übernommen und> stark erweitert hat.
Es gibt auch hier im Hause ein Custom-Design, was Python-Bytecode direkt
in Maschinensprache eine harten Stack-Maschine umsetzt - mit
Einschraenkungen bei den Datentypen. Ist alles nicht sooo neu, das
einzig 'heisse' daran ist, dass es auf dem FPGA wahlweise auf einer CPU
oder als eigenstaendiger Hardware-Sequenzer ablaeuft und die Grenzen
zwischen HW und SW komplett verschwimmen. Da liegt wohl die Zukunft.
Wenn es um akademischen Spass geht, wuerde ich vernuenftige OO nicht auf
dem Level von Forth miteinander kombinieren wollen. Aber eine
super-kompakte Implementierung von Display-Postscript in Forth-Bytecode
haette durchaus Nerd-Faktor.
Christoph M. schrieb:> Für graphische Anwendungen wäre ein objektorientiertes Forth nicht> schlecht.
Ich wette in der Hölle programmiert man grafische Anwendungen mit
objektorientiertem Forth.
Cyblord -. schrieb:> Christoph M. schrieb:>> Für graphische Anwendungen wäre ein objektorientiertes Forth nicht>> schlecht.>> Ich wette in der Hölle programmiert man grafische Anwendungen mit> objektorientiertem Forth.
Dazu haben die gar keine Zeit.
Die werden dort festgebunden und mit hochgeklebten Augenliedern dazu
gezwungen, in einer Endlosschleife deine Posts zu lesen.
Norbert schrieb:> Dazu haben die gar keine Zeit.> Die werden dort festgebunden und mit hochgeklebten Augenliedern dazu> gezwungen, in einer Endlosschleife deine Posts zu lesen.
Ich komme mit Komplimenten ja sowieso schon schlecht klar aber DAS ist
wirklich das netteste was mir seit langem gesagt wurde. Mir wird ganz
anders...
Cyblord -. schrieb:> Ich wette in der Hölle programmiert man grafische Anwendungen mit> objektorientiertem Forth.
Ich erkläre es dir mal, wie man es einem kleinen Kind erklären müsste:
1. Menschen haben Gehirn.
2. Manche Hirne können die Forth Denke.
3. Manche können die OO Denke.
Soweit alles gut und schön!
Jetzt zur "Hölle":
Es gibt Leute, welche zwar, dank hinreichend Hirn, programmieren können,
aber nicht mit 2 und 3 klar kommen (wollen?).
Für diese, muss OO-Forth die Hölle sein.
Andere, die 2 und 3 haben, können damit durchaus glücklich werden.
Auch wenn dir das nicht schmeckt.
von Axel S. (a-za-z0-9)
04.11.2025 09:55
>Falsche Baustelle. Die OO macht der Compiler und nicht die Bytecode>Ausführungsebene.
Bei genauerer Betrachtung ist das für die Python-Bytecodemaschine
falsch: Dort sind alle Daten Objekte und die Operatoren sind polymorph,
wie man mit Hilfe des Python-Byte-Code-Disassemblers sehen kann.
Arduino F. schrieb:> Du weist schon, dass die genannte Hölle nur eine Projektion ist, oder?
Was wäre bei "oder" der Fall?
Ich sage auch, dass es am Karma eines Fußballfans liegt, wenn er im
Stadion war und seine Mannschaft mal wieder verloren hat - wenn er mal
nicht da war, hat sie gewonnen.
Das ist aber einfach nur ein blöder Spruch (eine meiner besonders
ausgeprägten Fähigkeiten).
Christoph M. schrieb:> Bei genauerer Betrachtung ist das für die Python-Bytecodemaschine> falsch: Dort sind alle Daten Objekte und die Operatoren sind polymorph,> wie man mit Hilfe des Python-Byte-Code-Disassemblers sehen kann.
Super, dann hast du jetzt ja dein Ziel erreicht:
- Python-Bytecode erlaubt OOP.
- Python-Bytecode erzeugt Forth-Feeling.
- Das Ganze läuft auf dem von dir anvisierten Waveshare-RP2350-Board.
Alle deine Wünsche sind damit erfüllt, aber damit nicht genug:
- Das GUI-Framework LVGL inkl. dem Treiber für das 0,96"-Display ist
ready-to-use verfügbar.
- Du hast Zugriff auf eine Vielzahl weiterer Python-Module.
Du musst nur noch beachten, das der MicroPython-Bytecode etwas anders
aussieht als der gewöhnliche Python-Bytecode.
Bis heute Abend zeigst du uns sicher ein in MicroPython-Bytecode
programmiertes "Hello World" auf dem Display.
Nächste Woche kommt dann die Killer-Applikation, die selbst den letzten
Zweifler davon überzeugt, dass stackorientierte Programmierung in
Verbindung mit OOP alles in den Schatten stellt, was es bisher an
Programmiertechniken gab.
Ich bin gespannt:)
Yalu X. (yalu) (Moderator)
08.11.2025 12:49
>Bis heute Abend zeigst du uns sicher ein in MicroPython-Bytecode>programmiertes "Hello World" auf dem Display.
Das strapaziert aber meine Lernkurve und ich bin mir nicht sicher, ob
dich das glücklicher macht.
Bytecode
Cyblord -. schrieb:> Ich wette in der Hölle programmiert man grafische Anwendungen mit> objektorientiertem Forth.
Kommt ein Programmierer in die Hölle, dort gibt es Sektempfang und jede
Menge Partys. Fragt er erstaunt ist das wirklich die Hölle ? Aber klar
doch und alles kostenlos. Nach ein paar Tagen bemerkt er das einige
manchmal durch ein Loch am Ende der Hölle starren. Durch das Loch sieht
er schreiende brennende Menschen die dort auf glühenden Kohlen
herumspringen. Fragt er wieder jemand was dort los ist. Antwort: Das
sind die Forth Programmierer, die brauchen das ;-)
Christoph M. schrieb:> Bytecode>> 0000000 064d 1f00 0220 6818 6c65 6f6c 6159 756c> ...
Wow, das ging ja schnell.
Du hast dich also innerhalb weniger Stunden in den MicroPython-Bytecode
eingearbeitet und darin ein Programm geschrieben, das einen Text auf dem
LCD ausgibt?
Nein, natürlich nicht.
Du hast basierend auf den Modulen LCD_0inch96, framebuf, writer,
freesans20 usw. ein Python-Programm namens helloYalu.py geschrieben,
dieses dieses durch den Compiler geschickt und von dessen Output einen
Hexdump erstellt.
Die von dir propagierte Forth- bzw. Forth-ähnliche Programmierung, die
ja prinzipiell mit MicroPython-Bytecode möglich ist, scheint wohl doch
nicht so der große Bringer zu sein. Stattdessen lässt du dir den
stackorientierten Code lieber automatisch generieren, nämlich vom
Python-Compiler.
Das haben viele Leute vor dir auch schon erkannt, deswegen verwenden sie
gleich Python und freuen sich, nicht mit der UPN-Programmierung auf
Bytecode-Ebene in Berührung zu kommen :)
Yalu X.
>Du hast basierend auf den Modulen LCD_0inch96, framebuf, writer,>freesans20 usw. ein Python-Programm namens helloYalu.py geschrieben,>dieses dieses durch den Compiler geschickt und von dessen Output einen>Hexdump erstellt.
Gratulation ;-)
Bleibt die spannende Frage, wie habe ich es erzeugt und kann man es
de-compilieren und den Quellcode wieder herstellen.
Andreas H. (ahz)
09.11.2025 02:23
>Diesen "speziellen" Prozessor kannst Du auch selber probieren:>https://github.com/jamesbowman/swapforth/tree/master/j1a
Danke für den Link.
In den Anfängen der J1 gab es ein Paper und ein Forth-System dazu. Weil
das Konzept aus einem minimalen Befehlssatz mit minimalen
Hardwareresourcen ein ganzes System aufzubauen so elegant ist, hatte ich
mir dieses als Vorlage für eine eigen VM genommen und den passenden
Forth Compiler dazu gebaut, um ein wenig mit optimierten Befehlssätzen
zu spielen.
Es gab damals den Hinweis, dass die J1 im Nextion-Display eingebaut ist,
aber so richtig glauben konnte ich das nicht, da ja Forth doch eine
bestimmte spezialisierte Expertise erfordert.
Mit dem Hinweis von Lotta zu Postscript wird der Zusammenhang aber
klarer: Traditionell war Forth über Postscript wohl immer schon mit
graphischen Anwendungen verknüpft. Da lag der Gedanke bei Nextion wohl
nahe, eine Forth-CPU für ihre Displays zu verwenden.
Die Entwicklung eines eigenen Silizium im Consumer-Markt lohnt sich
eigentlich nur, wenn man Absatzzahlen im Millionenstückbereich erwartet.
Die J1 bietet hier minimale Chipfläche und maximale Codedichte und keine
Lizenzkosten. Heutzutage würde man vielleicht Richtung RISC-V tendieren,
allerdings dürfte es schwierig werden, mit einem vom C-Compiler
erzeugten RISC-V Code die selbe Dichte zu erreichen.
Christoph M. schrieb:> Die Entwicklung eines eigenen Silizium im Consumer-Markt lohnt sich> eigentlich nur, wenn man Absatzzahlen im Millionenstückbereich erwartet.> Die J1 bietet hier minimale Chipfläche und maximale Codedichte und keine> Lizenzkosten. Heutzutage würde man vielleicht Richtung RISC-V tendieren,> allerdings dürfte es schwierig werden, mit einem vom C-Compiler> erzeugten RISC-V Code die selbe Dichte zu erreichen.
Man muss das Silizium ja nicht direkt entwickeln. Auch in Handies fanden
sich schon FPGAs... (Stichwort Consumer).
Die Code-Dichte von RISC-V 32c ist eigentlich nicht so uebel, aber
grundsaetzlich krankt die Architektur daran, dass man nicht so richtig
von der MIPS-Schule weggekommen ist.
Bei der Siliziumdichte sieht's dann verglichen mit Stackmaschinen mies
aus.
Der Punkt ist halt schlussendlich in der klassischen embedded
Entwicklung der: GCC oder nicht GCC (oder dito LLVM). GCC ist aber klar
auf Registermaschinen ausgelegt und 'kennt' die Forth-Denke nicht. Also
bleibt praktisch gesehen Forth nur noch allenfalls fuer paralleles
Multiprozessing in einer gewissen Nische uebrig, wo man mit C sowieso
nicht weiterkommt, resp. sich der Standard (Safety) nach minimierter
Logik richtet.
Da man aus Python aber so ziemlich alles zwischen Hardware bis
Stack-Maschinencode generieren kann, und die OO da eigentlich ziemlich
vorbildlich funktioniert, stellt sich schon die Frage fuers Engineering:
Warum Forth, wenn es einen gut lesbaren de-fakto Standard gibt.
Martin S.
>Da man aus Python aber so ziemlich alles zwischen Hardware bis>Stack-Maschinencode generieren kann,
Apropos: Gibt es eine für Python optimierte FPGA-CPU?
Kennt sich jemand mit Postscript aus?
Bei Linux kann man einfach das *.ps File anklicken und es wird
automatisch dargestellt. Wenn man es editiert, wird das geöffnete Bild
auch jeweils sofort aktualisiert.
Da das Display aber nur 160x80 Zeichen hat und die Seite aber eher so
was wie ein DIN-A4 Format hat, wird das Bild nur im unteren linken Eck
dargestellt ( siehe Anhang ). Besser wäre es, wenn die Postscriptseite
das gleiche Format wie das Display hätte. Kann man das einstellen?
1
%!PS
2
3
000setrgbcolor% Set color to black
4
0016080rectfill% Draw a filled rectangle covering the page
5
6
111setrgbcolor
7
newpath% Start a new path
8
00moveto% Move to the start point (x=100, y=100)
9
10080lineto% Draw a line to the end point (x=200, y=200)
Christoph M. schrieb:> Die Entwicklung eines eigenen Silizium im Consumer-Markt lohnt sich> eigentlich nur, wenn man Absatzzahlen im Millionenstückbereich erwartet.
Wie immer im ASIC Markt. Unter 1 Mio Stück/Jahr redet da kein
ernstzunehmender Fabber mit Dir.
> Die J1 bietet hier minimale Chipfläche und maximale Codedichte und keine> Lizenzkosten.
Und zusammen mit der Möglichkeit zur interaktiven Entwicklung macht es
das insbesondere für FPGAs interessant.
Martin S. schrieb:> Die Code-Dichte von RISC-V 32c ist eigentlich nicht so uebel, aber> grundsaetzlich krankt die Architektur daran, dass man nicht so richtig> von der MIPS-Schule weggekommen ist.
Was wirklich überraschend ist. Man könnte ja fast vermuten, dass sich
David Patterson (RISC-V) und John Hennessy (MIPS) da mal unterhalten
haben. Vielleicht als sie das "Quasistandardwerk" über
Computer-Architecure
(https://www.amazon.de/-/en/Computer-Architecture-Quantitative-Approach-Kaufmann-dp-0443154066/dp/0443154066)
geschrieben hatten?
> Da man aus Python aber so ziemlich alles zwischen Hardware bis> Stack-Maschinencode generieren kann, und die OO da eigentlich ziemlich> vorbildlich funktioniert, stellt sich schon die Frage fuers Engineering:> Warum Forth, wenn es einen gut lesbaren de-fakto Standard gibt.
"Da man aus Scala(*) aber so ziemlich alles zwischen Hardware bis
Stack-Maschinencode generieren kann, und die OO da eigentlich ziemlich
vorbildlich funktioniert, stellt sich schon die Frage fuers Engineering:
Warum Python, wenn es einen gut lesbaren de-fakto Standard gibt."
Oder mit anderen Worten: Man kann sowas mit praktisch jeder aktuellen
Sprache bauen. Aber immer mit den jeweiligen Vor- und Nachteilen. Es ist
also eine überflüssige Trivialdiskussion, oder?
/regards
(*) Siehe z.B. Chisel & Spinal-HDL als Scala DSLs für HW Entwicklung.
Christoph M. schrieb:> Kennt sich jemand mit Postscript aus?
Als ich damit mal rumgespielt hatte war ich noch "jung und knusprig".
Heute leider nur noch "und" :/
Iirc müsstest Du die Transformationsmatrix für das Outputmedium
entsprechend anpassen. Aber ehrlich: Das war noch in einem früheren
Leben ;)
Vielleicht hilft Dir das weiter:
https://www.adobe.com/jp/print/postscript/pdfs/PLRM.pdf
Apropos: Ist das ein Longan Nano Board? neidisch guck
/regards
Christoph M. schrieb:> Kennt sich jemand mit Postscript aus?
Ist schon ein paar Jährchen her, aber ...
Unter Linux nutzt man ja üblicherweise ghostscript, und da kann man für
den X11-Treiber problemlos Auflösung (PS rechnet per default mit 72dpi)
und Größe des Ausgabegeräts (das X11 window) einstellen:
gs -q -g160x80 -r72 whatever.ps
Danke für eure Antworten. Da muss ich mich erst mal ein wenig damit
beschäftigen.
Andreas H. (ahz)
10.11.2025 15:42
>Apropos: Ist das ein Longan Nano Board? neidisch guck
Es ist nur ein PiPico2 Board. Aber ziemlich flott: im wesentlichen ein
Dual Core ARM-Cortex33.
Aber ich finde es trotzdem recht nett. Mein ursprüngliche Idee war ein
kleines Platinenoszi und Voltmeter damit zu machen, welches ich an die
Experimentierplatinen klemmen kann.
Das Board kriegst du unter anderem bei berry-base:
https://www.berrybase.de/waveshare-rp2350-lcd-0.96-mikrocontroller-0.96-lcd-arm-risc-v-26-gpio-4mb-flash-mit-header
Yalu X. (yalu) (Moderator)
10.11.2025 15:56
>Mit><</PageSize [160 80] >> setpagedevice>kannst du die Seitengröße einstellen.
Ich habe es oben im Script eingetragen, aber es bleibt gleich groß.
Liegt es eventuell am im Ubuntu eingebauten Postscript?
Christoph M. schrieb:> Ich habe es oben im Script eingetragen, aber es bleibt gleich groß.> Liegt es eventuell am im Ubuntu eingebauten Postscript?
Evince scheint
1
<</PageSize [160 80] >> setpagedevice
zu ignorieren. Wenn man die Datei vorher mit ps2pdf in PDF konvertiert,
wird die PageSize aber richtig übernommen.
1
$ ps2pdf line.ps
2
$ evince line.pdf
Man kann auch versuchen, die Größe mit einem DSC-Kommentar festzulegen:
1
%%BoundingBox: 0 0 160 80
Das funktioniert mit Evince, wird aber von ps2pdf ignoriert.
Natürlich kannst du auch beide Möglichkeiten kombinieren:
Andreas H. schrieb:> Oder mit anderen Worten: Man kann sowas mit praktisch jeder aktuellen> Sprache bauen. Aber immer mit den jeweiligen Vor- und Nachteilen. Es ist> also eine überflüssige Trivialdiskussion, oder?
Nicht ganz, wenn man sich mit der Semantik und Transpilationsdetails
naeher beschaeftigt. Da gibt es ein paar Aspekte, die bisher nur mit
Python sauber/effizient funktionieren, insbesondere wenn es in die
Co-Verifikation (gegen bestehende Algorithmen) geht.
Aber das ist eine andere Geschichte.
Christoph M. schrieb:> Apropos: Gibt es eine für Python optimierte FPGA-CPU?
Ja. Aber liegt hier eher als Proof of Concept. Im Endeffekt wird die
zugrundeliegende Stackmaschine dann doch in C programmiert, oder gleich
ein Hardware-Sequencer in HDL generiert.
Andreas H. (ahz)
10.11.2025 20:30
>>https://www.berrybase.de/waveshare-rp2350-lcd-0.96-mikrocontroller-0.96->>lcd-arm-risc-v-26-gpio-4mb-flash-mit-header>Danke für den Link. Ist schon bestellt :)
Es ist auf jeden Fall ein nettes Display und da ja bald Weihnachten ist,
hast du wahrscheinlich Glück und es kommt noch vor dem
Post-Geschenke-Stau durch.
In welcher Programmiersprache willst du es programmieren? Micropython
scheint mir mittlerweile ziemlich geeignet.
Wenn sich mehr Leute dafür interessieren, könnte man einen Micropython
Thread speziell für dieses Display aufmachen.
Christoph M. schrieb:> In welcher Programmiersprache willst du es programmieren? Micropython> scheint mir mittlerweile ziemlich geeignet.
Kommt auf die Anwendung an. Ich bin da nicht so sehr auf irgendwas
festgenagelt. Aber Python steht da eher nicht im Vordergrund.
/regards
Hier noch ein wichtiger Hinweis zum LCD, falls man einen anderen Treiber
suchen muss oder einen selber schreiben will:
*The built-in controller used in this LCD is ST7735S, which is an LCD
controller with 162 × RGB × 132 pixels, while the pixels of this LCD are
160(H) RGB × 80(V).
https://www.waveshare.com/wiki/Pico-LCD-0.96
Christoph M. schrieb:> https://www.waveshare.com/wiki/Pico-LCD-0.96
Wenn Du Dir da an den LVGL Demos gefallen findest (nice Toolkit btw.)
dann wundere Dich nicht wenn Du da Probleme beim experimentieren
kriegst.
Aktuell hat das LVGL Image bereits die Version 9.4 eingebaut. Der Link
zur Doku ist aber immer noch für Version 8. Und von 8 --> 9 hat sich
einiges geämdert. Insbesondere sind einige Set-fct jetzt nicht mehr für
die einzelnen Widgets direkt verfügbar, sondern werden über Styles
gesetzt.
Aktuelle Doku findest Du auf
https://docs.lvgl.io/9.2/integration/bindings/micropython.html in
LVGL_Library.pdf.
/Regards
P.S: Ach ja: Du merkst: Mein Board ist angekommen ;)
Thread beobachten
Seitenaufteilung abschalten