mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik AVR-Mikrocomputer mit Forth als Betriebssytem


Autor: Daniel Roth (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

vielleicht ist schon jemand von euch auf die Programmiersprache Forth
gestoßen und hat sich etwas damit befasst. Die Sprache könnte man gut
auf dem AVR umsetzen und hätte dann die Möglichkeit, über ein Interface
(z.B. LCD + Tastatur oder Terminal) den AVR direkt zu programmieren
(ohne PC), wobei Kommandos direkt ausgeführt oder in den Speicher
compiliert werden. So hat man die Möglichkeit, die Ergebnisse eines
Befehls (z.B. LED anschalten) sofort zu sehen, ohne erst das Programm
übertragen zu müssen. Außerdem kann die Fehlersuche direkt im System
unter realen Bedingungen erfolgen, ohne beispielsweise auf JTAG-ICE
zurückgreifen zu müssen. Meiner Meinung nach ist Forth ideal für
Mikrocontroller, zumal der Programmumfang nicht mehr auf Flash, sondern
auf beliebige Speichermedien ausgedehnt werden kann..

Daniel

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich weiss zwar nicht, wie du dir das vorstellst, habe auch keinerlei
Ahnung von Forth.
Allerdings ist der AVR angeblich von der Struktur her auf C
zugeschnitten, und ein AVR kann prinzipiell nur Programme ausführen,
die im internen Flash stehen, da gibts kein RAM, welches Programmcode
aufnehmen könnte, weder intern noch extern. Also, um download und
Programmierung des Flash kommt man nicht drumherum. Bei den Megas ist
das immerhin über den bootlader möglich. Aber was speziell erhoffst du
dir von einem forth-System?

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Forth wird normalerweise nicht in Maschinencode kompiliert, sondern von
einem Interpreter auf dem Prozessor ausgeführt.

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
na gut, und was nutzt das? Ob ich nun ein komlett compiliertes Programm
runterlade, oder einen Pseudocode, der dann mittels Interpreter
ausgeführt wird? Ich sehe da keinen Vorteil, im Gegenteil. Ein
richtiger Betriebssystem-Kern, der dann erforderlich wird, wird einen
großen Teil des Programmspeichers auffressen, ebenso die
Gesamtleistungsfähigkeit.
Mikrocontrollerprogramme sind meiner Meinung nach immer sehr speziell,
und arbeiten auch in jeder Anwendung mit einer anderen externen
Hardware. Und was für einen PC unabdingbar ist (Standardschnittstellen,
Harware per device-driver ansprechbar) ist für MCs weder sinnvoll noch
machbar aufgrund der stets begrenzten Resourcen.

Autor: Daniel Roth (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@crazy horse:
Bei den speziellen Einsatzzwecken hast du recht. Es gibt aber auch
Anwendungen, die flexibel für Änderungen und Einstellungen sein müssen.
Beispielsweise wäre ein Roboter besser mit Forth zu steuern, um nicht
jedesmal ein geändertes Programm assemblieren zu müssen, nur um einen
neuen Kurs zu fahren. Da Forth aus den Anfängen der Computertechnik
stammt, ist es sehr sparsam mit Speicher und nach dem Minimalprinzip
aufgebaut. Der Kern ist sehr klein und würde einen AVR nicht
überfordern. Die Forth-Programme sind nur ca. 4x langsamer als
Assemblerprogramme, was man vernachlässigen kann.

Daniel

Autor: ThomasB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!
Es ist zwar interessant, was es alles gibt, aber ich finde auch, dass
das direkte Flashes besser ist. Man drück nur auf den Knopf und schon
wird das Programm erstellt, der Prozessor geslöscht und neu bespielt
und das in wenigen Sekunden.

Außerdem muss man den Prozessor sowieso flashen, da man ja die Firmware
draufspielen muss.
Auch einen Geschwindigkeitsverlust um den Faktor vier finde ich extrem
viel.
Ein weiterer Nachteil besteht darin, dass man für jedem Prozessor
anscheinend ein eigenes Board benötigt.

@Thomas:
Aber ich will dir deine Sache nicht vermießen. Jeder soll mit den
Werkzeugen arbeiten, die er selbst am besten findet und mit denen er am
besten umgehen kann.

Martin

Autor: Weinga-Unity (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Hier gehts irgendwie um Interpreter oder direkt coden.

Meine Meinung sieht so dazu aus:
Interpreter ist gut, solange nur einfach Abläufe (eben SPS Funktionen;
sprich irgend welche Abläufe) zu lösen sind.

Somit will ich auch schonwieder auf ein Projekt verweisen, welches
irgendwie voll super wäre, wo man wie bei SPS mit Kontaktplan usw...
programmiert, und wo es dann für alle Prozessoren (8051, AVR, MSP430)
einen Interpreter dafür gibt.

Will man da aber etwas mehr machen, kann man Interpreter schon
vergessen (vgl. C-Control). Die Gründe:
1. Viel zu langsam
2. Prozessoren kann man nicht richtig ausnützen (sprich alle zur
Verfügung stehenden Funktionen)

Na, ja. Meine Meinung halt.

mfg W.K.

Autor: Daniel Roth (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na hallo !!

erstmal vielen Dank für die Antworten und unterschiedlichen Meinungen.
Habe gemerkt, dass die meisten von euch mit dem AVR eine konkrete
Aufgabe lösen wollen und er in Geräten mit einer festen Funktion ans
Werk geht. Für solche Zwecke macht ein Interpreter keinen Sinn, da
stimme ich euch zu.

Mein eigentlicher Gedanke war, mit dem AVR einen Mikrorechner zu bauen,
der UNABHÄNGIG vom PC läuft, also mit LCD+Tastatur und einer
Interpreter-Sprache ausgestattet ist, die Befehle direkt ausführen kann
oder in den Speicher schreiben kann.

Damit die Nachteile einer Interpreter-Sprache nicht so ins Gewicht
fallen, habe ich daher Forth gewählt, da sie keine reine
Interpreter-Sprache ist, sondern wie eine virtuelle Maschine
funktioniert (es gibt auch echte Forth-Prozessoren). Da die
Forth-Architektur sehr verwandt mit der RISC-Architektur ist, würde sie
gut zum AVR passen.

Für alle, die Forth noch nicht kennen:
Forth interpretiert nicht im klassischen Sinne, wie in Basic, wo zu
jedem Befehl über eine Tabelle o.ä. die Adresse des zugehörigen
Maschinencode ermittelt wird, sondern Forth compiliert! in den
Speicher, so dass bei der Ausführung schon die Adressen alle
feststehen. Der IP muss nur noch mit diesen Adressen geladen werden,
was der Adressinterpreter von Forth übernimmt und seine Umsetzung
bestimmt die Geschwindigkeit des Programms. In der Regel besteht er nur
aus 5 Assembler-Befehlen.

@ThomasB:
Danke. Interessante Seite!

@Martin:
Ich finde den Geschwindigkeitsverlust nicht so hoch... :)

@Weinga:
Forth ist nicht mit Basic zu Vergleichen. Forth wurde damals vor 30
Jahren zur Steuerung von Radioteleskopen eingesetzt, wo umfangreiche
mathematische Berechnungen in Echtzeit durchgeführt werden mussten und
für Steuerungsänderungen keine Zeit war, um erst das Programm auf einem
anderen Rechner zu ändern und dann wieder in den Zielrechner übertragen
zu werden. Forth ist schnell genug !!

Bis dann
Daniel

Autor: Henk (Gast)
Datum:
Angehängte Dateien:
  • 00.zip (78,7 KB, 153 Downloads)

Bewertung
0 lesenswert
nicht lesenswert
meine versuche nach forth auf AVR 8515 bis zu heute

Autor: Daniel Roth (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Henk,

wird mich bestimmt das ganze Wochenende kosten, deinen Code
durchzuforsten :) Hab gleich mal noch ein paar Fragen an dich:

- Befindet sich das Wörterbuch im SRAM ?
- Äußerer Interpreter mit dabei ?
- Wenn ja, dann laufen Ein- und Ausgaben über RS232 ?

Habe gestern entdeckt, dass Forth,Inc. (www.forth.com) für einige viele
Dollars einen Forth-Compiler (SwiftX) für AVRs anbietet.

Bis dann
Daniel

Autor: Henk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1. am ende der flash ist mit dw das wichtigste teil das Wörterbuch ein
gebunden. das wird am anfang zum SRAM kopiert.

2. das ist der Äußerer Interpreter.

3. mittels DEFER kan man EMIT KEY und ACCEPT "umleiten", damit ich
auch in  AVR Studio debuggen kan.
Sie stehen entweder auf DROP DUP ACCEPTBOOT oder TX! RX@ ACCEPT

4. die code is noch immer in entwiklung. Sie is zusammen gebasteld nach
CAMEL SOL usw.

bitte schreibe fehler ignorieren weil ich kein deutscher bin.

Autor: Notker (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Ich hatte mich bereits vor etlichen Jahren mal mit der
Programmiersprache Forth beschäftigt, das Resultat war sehr
enttäuschend! Die Daseinsberechtigung und der Charakter dieser Sprache
schlägt sich sehr eindeutig in den zur Verfügung stehenden Ressourcen
nieder. Literatur gibt es so gut wie garkeine und die Implementationen
sind Kraut und Rüben. Es wurde zwar mal ein Versuch gestartet diese
Sprache zu standardisieren, aber kein Forth Dialekt hält sich daran. Es
wird zwar immer gesagt, Forth sei schnell aber wie Andreas richtig
bemerkt hat, ist Forth eigentlich eine Interpretersprache. Der
Sourcecode wird in eine Art Metacode umgesetzt, der dann interpretiert
wird. Es gibt zwar auch einige wenige echte Forth Compiler, aber das
sind auch nur Dinge, die irgendwo im Entwicklungsstadium
hängengeblieben sind. Das Problem bei Forth Compilern ist nämlich die
Umsetzung auf die gängigen (von Neumann'schen) Prozessorarchitekturen
und das passt hinten und vorne nicht weil dies keine stackorientierten
Maschinen sind. Es gab (oder gibt noch?) auch Prozessoren, die speziell
für Forth konzipiert wurden aber das hat sich auch alles im Sande
verlaufen.

Dazu kommt noch, dass die Programmiersprache Forth aufgrund ihrer
(anderen oder fehlenden) Struktur sehr unübersichtlich ist und sich
grössere Projekte nur mit erheblichem Aufwand realisieren lassen. Gut,
letztendlich muss jeder selbst wissen wo sein persönlicher Geschmack
liegt und was ihm am besten liegt. Es gibt ja in diesem Forum auch
einige Assembler-Hardliner, die einen C-Compiler nicht mal mit
Gummihandschuhen anfassen würden. Soll mir auch recht sein. Aber von
Forth halte ich persönlich, ehrlich gesagt, garnichts! Man könnte zwar
einen kleinen Interpreter programmieren und den Programmcode als Token
in den EEPROM laden und dort abarbeiten (so was in der Art wie hier:
http://users.cableaz.com/~cappels/dproj/ab163/at163b.htm), aber ob es
unbedingt Forth sein muss?

Notker

Autor: Daniel Roth (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
@Notker:
1. Die Daseinsberechtigung und der Charakter von Forth ist weniger von
den Resourcen, als von dem Anwendungzweck abhängig.

2. Da Forth schon in der Raumfahrt eingesetzt wurde und auch
kommerziell, können doch nicht alle Implementationen Kraut & Rüben sein
:)

3. Literatur ist tatsächlich selten, ist eben eine vergessene und
unterschätzte Sprache. Die deutschen Bücher werden meist nicht mehr
aufgelegt. Hilft nur Internet.

4. Forth ist einfach. An die RPN-Notation muss man sich allerdings
gewöhnen. Dabei steckt diese RPN (Postfix) Notation in jeden von uns,
ohne dass man es merkt :) Jeder hat doch schon einen normalen
Taschenrechner bedient: dort werden manche Operationen hinter den
Zahlen (Operanten) gedrückt (SIN, COS, ...) Andere wiederum (PLUS,
MINUS, ...) zwischen den Operanten, was dann die bekannte
Infix-Notation ist. Forth zieht durchgänging die Postfix-Notation
durch, kann man sich schnell daran gewöhnen.

5. Du hast über fehlende Forth-Compiler geklagt, die richtigen
Maschinencode erzeugen. Kein Wunder, dass du von Forth nicht viel
hältst. Du hast die Denkweise hinter Forth nicht verstanden. Solche
echten Forth-Compiler sind deshalb so selten, weil sie gegen Forth
selbst sprechen: nämlich interaktiv zu sein. Die Leistungsfähigkeit von
Forth beruht darauf, während der Laufzeit (ohne PC) einfach erweiterbar
zu sein.. und das in einem guten Verhältnis zur
Ausführungs-Geschwindigkeit.

6. Da es zur Programmierung unter Forth wenig Regeln und Standards
gibt, kann man damit auch viel Unnützes und Unübersichtliches
anstellen. Es liegt also an jedem selbst, ob der Quelltext
übersichtlich bleibt oder nicht. Auf der anderen Seite ist Forth aber
höchst strukturiert, keine Möglichkeit, Spagetti-Code zu schreiben.
Der Erfinder von Forth ist gegen Standards, da die sich auch schwer
durchsetzen lassen: beim Programmieren wird die Sprache selbst
erweitert. Einen ANSI-Standard gibt's trotzdem.

7. Eine Abarbeitung im EEProm ist zu langsam, muss schon SRAM sein.

Daniel

Autor: Notker (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
> Die Daseinsberechtigung und der Charakter von Forth ist weniger von
>  den Resourcen, als von dem Anwendungzweck abhängig.

Ich habe nicht geschrieben wovon sie abhängig ist, ich habe
geschrieben, worin sie sich eindeutig niederschlägt (s.o.).

> Da Forth schon in der Raumfahrt eingesetzt wurde und auch
> kommerziell, können doch nicht alle Implementationen Kraut & Rüben
sein
> :)

Es wurde mal von einem etwas exzentrisch denkenden Menschen entwickelt
um ein Radioteleskop zu steuern. Mit Raumfahrt hat das aber wohl nur
entfernt zu tun.

> Literatur ist tatsächlich selten, ist eben eine vergessene und
> unterschätzte Sprache. Die deutschen Bücher werden meist nicht mehr
> aufgelegt.

Also wenn das wirklich so eine tolle und unterschätzte Sache wäre, ich
denke mal, da hätte es auch bestimmt ein paar Versuche mehr gegeben,
hierüber ein wirklich gutes Buch zu schreiben. Ich habe mir gerade mal
dieses "Standardwerk" (grins) von Leo Brodie (Programmieren in
FORTH) hier aus meinem Bücherregal gezogen. Wenn man dort hineinschaut
und diese lustigen Karikaturen darin sieht, kommt einem spontan der
Gedanke, ein Kinderbuch in den Fingern zu haben. Scheint mir doch sehr
zielgruppenbezogen zu sein ;-)

> Forth ist einfach.

du nimmst mir das Wort aus dem Munde. Einfache Sprache für einfache
Gemüter.

> An die RPN-Notation muss man sich allerdings gewöhnen.

Nun ja, als leidenschaftlicher Sammler alter HP Taschenrechner habe ich
damit bestimmt keine Berührungsängste.

> Du hast die Denkweise hinter Forth nicht verstanden.

Gut, dann lasse uns Unwissende und Ungläubige doch mal etwas an deinem
unermesslichen Wissen und deiner grenzenlosen Weisheit teilhaben,
grosser Forth-Guru.

> Da es zur Programmierung unter Forth wenig Regeln und Standards
> gibt, kann man damit auch viel Unnützes und Unübersichtliches
> anstellen.

Naja, das kann man wohl mit jeder Programmiersprache. Gegenteilige
Meinungen?

> Es liegt also an jedem selbst, ob der Quelltext übersichtlich bleibt
oder nicht.

Wir lauschen gespannt den Ausführungen des Experten g

> Auf der anderen Seite ist Forth aber höchst strukturiert, keine
Möglichkeit,
> Spagetti-Code zu schreiben.

Boah, ich bin echt fasziniert! Erzähl uns mehr davon!

> Der Erfinder von Forth ist gegen Standards, da die sich auch schwer
> durchsetzen lassen.

Sowas Ähnliches habe ich mir bereits gedacht ... (LOL!)

Ok, genug gegrinst für heute, befassen wir uns wieder mit serösen
Themen ;-)

have a nice day,

Notker

Autor: Daniel Roth (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Notker,

nein nein, wollte dich nicht mit deiner Meinung angreifen. Vielleicht
liege ich ja auch halbwegs falsch, aber eine Diskussion ist es doch
schon mal wert. Die Idee hinter Forth mit dem Minimalprinzip und so ist
doch gar nicht so schlecht (solange der Nutzen auch nicht minimal ist).
Da du die HP-Taschenrechner angesprochen hast: die neuesten Modelle
können ja alternativ auch noch mit RPN-Notation umgehen, die sich für
manche Sachen gut eignet. Genauso eignet sich Forth für manche Dinge
ganz gut. Nicht für alles, das ist klar.. Jede Sprache für seinen
bestimmten Zweck.

Wenn du willst, kannst du ja deine Einstellung besser begründen,
damit auch ich die Möglichkeit habe, meine Meinung zu überdenken und
was dazuzulernen..

Daniel

Autor: Gerd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin auch eher der Meinung von Notker.
Forth ist klein, speichersparend und optimal an die Bedürfnisse von
Mikrocontrollern angepasst -sozusagen computergerecht- aber nicht an
die Bedürfnisse von Menschen.
Ich habe mich vor Jahren auch einmal mit Forth beschäftigt,
wohl auch um mich von der schnöden Masse abzusetzen und mich
selbst für einen der
'letzten einsamen noch lebenden Superprogrammierer' zu halten.
Spätesten als ich eine veschachtelte if-then-else-Kombination erstellen
wollte, habe ich den Forth-compiler mit der stärksten Packstufe von
PK-Zip komprimiert, in irgendein Verzeichnis kopiert
und vergessen.
Die aufkommenden Zweifel an meiner Genialität habe ich einfach
ignoriert und über die Jahre verdrängt. Jetzt bin ich darüber hinweg
und programmiere PC-Programme mit Delphi und Mikrocontroller in C.
In beiden Sprachen bin ich immer noch ein kleines Licht,
aber man kann sich viel im Internet zusammensuchen, und vielleicht kann
mal irgendjemand ein Codeschnipsel von mir gebrauchen.
-- Dann bin ich stolz --

Autor: Daniel Roth (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo an alle,

das es generell viele Gegner gibt, weiß ich doch schon :) Und
verschachtelte Algorithmen will ich doch auch nicht damit
programmieren..
Als Script- oder Makrosprache macht sie sich jedoch gut, was mit C
nicht oder zu aufwendig realisierbar ist. Die Grundfunktionen können
doch in einer beliebigen Sprache (C, Asm, Basic ..) verfasst werden.
Das Zusammenfassen und die Abfolge der Grundfunktionen kann zuletzt mit
Forth erfolgen, so dass man flexibel ist, wenn häufige Änderungen
erforderlich sind.. nur zu diesen Zweck ! ok ?
Für mich würde es keinen Sinn machen, jedesmal einen PC an eine
festinstallierte Steuerung anzustöpseln, nur um einen Parameter oder
eine Abfolge zu ändern.. (was die Anwender ja nicht können, sondern nur
die Programmierer der Steuerung).. Ein Menüsystem kann man nicht für
alle Dinge einsetzen..

Wie würdet ihr also dieses Problem lösen ??
bin gespannt.. :)

Daniel

Autor: Notker (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
> Für mich würde es keinen Sinn machen, jedesmal einen PC an eine
> festinstallierte Steuerung anzustöpseln, nur um einen Parameter oder
> eine Abfolge zu ändern.. (was die Anwender ja nicht können, sondern
nur
> die Programmierer der Steuerung).. Ein Menüsystem kann man nicht für
> alle Dinge einsetzen..

> Wie würdet ihr also dieses Problem lösen ??
> bin gespannt.. :)

Wenn wir schon mal bei abstrusen und total realitätsfremden
Diskussionen sind, die eine uralte und bereits so gut wie ausgestorbene
Programmiersprache mit high-tech Anforderungen des 21. Jahrhunderts
verbinden soll, wie wäre es denn mit einer Sprachsteuerung? Dann kannst
du ja deinem Compi erzählen was er machen soll und brauchst nie wieder
ein Interface anzustöpseln. Mit genug Aufwand kann man sowas bestimmt
auch irgendwie in Forth programmieren.

Also mal im Ernst mein lieber Daniel, ich kann deinen Ausführungen
nicht so ganz folgen und ich denke mal, dass ich damit in diesem Forum
bestimmt nicht der Einzige bin. Ich habe ja nichts gegen theoretische
Gedankenspiele, manchmal kommen ja wirklich gute Ideen dabei heraus.
Aber das hier ist mir ein paar Stufen zu hoch. Was soll denn das werden
wenn es fertig ist? Eine Art selbstorganisierende und morphende
Codemasse in einem Computer, die wohlmöglich irgendwann anfängt zu
denken und ohne das Zutun eines externen Interfaces ihr eigenes
Bewußtsein entwickelt? Bist wohl ein begeisterter Perry Rhodan Leser?
;-)

Wir wissen nicht, was die freundliche Hausfrau empfiehlt, aber ich
empfehle stets die Mittel der Wahl (C oder Assembler) zu verwenden.
Damit kann man eigentlich alles realisieren was einem so vorschwebt und
man kommt damit und der Hilfe der Forumskollegen eigentlich stets zum
Ziel. Oder sollte es tatsächlich etwas Exotisches sein? Kläre uns doch
mal genauer auf!

have a nice day

Notker

Autor: Notker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Da du die HP-Taschenrechner angesprochen hast: die neuesten Modelle
> können ja alternativ auch noch mit RPN-Notation umgehen, die sich
für
> manche Sachen gut eignet.

Nur als Hinweis, HP baut schon seit einiger Zeit keine Taschenrechner
mehr. Der gemeine Mensch (homo sapiens vulgaris) ist bekanntermassen
unwillig, eine gute Qualität mit der Bezahlung eines entsprechenden
Preises zu würdigen und somit hat HP beschlossen, diese Sache
einzustellen. Leider!

Autor: Daniel Roth (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Notker:

Ich hatte nach einer Lösung gefragt, nicht wie man's am besten durch
den Kakao zieht. Trotz deines langen Postings kann ich die Antwort auf
meine Frage nicht finden !?

Nochmal langsam:
- Forth erstmal kurz beiseite lassen !
- Ein Interface ist erlaubt, aber kein PC !
- Wie kann ich ein ASM/C-Programm flexibel genug gestalten, um ganze
Abläufe ändern zu können, ohne den Maschinencode neu compilieren zu
müssen, da im eingebauten Zustand oder unterwegs kein PC zur Verfügung
steht ? (Vorrausgesetzt, ein Menüinterface wäre zu aufwendig)

Eine Möglichkeit wäre es doch, ein leicht (während des Betriebes)
änderbares Ablaufscript zu interpretieren, wozu sich Forth eignet.

Daniel

p.s.: http://www.hp.com/calculators/
Es gibt sie noch, oder nicht ?

p.s.s.: um den Thread nicht unnötig in die Länge zu ziehen und vom
eigentlichen Thema abzulenken, solltest du auf Antworten mit
Unterhaltungswert verzichten.

Autor: Markus Kaufmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Daniel,

mir scheint, Du konstruierst hier einfach einen Spezialfall:
Die Änderungen sind so komplex, daß man es nicht mehr über ein Menü
machen kann, aber noch nicht so komplex, daß man größere Codeteile
ändern müßte. Gleichzeitig steht kein PC zur Programmierung zur
Verfügung.

Das ist meiner Meinung nach aber eher selten. Entweder steht der
(Gesamt-)Programmablauf relativ fest, dann reicht auch ein Menü. Oder
er steht eben nicht fest (Automatisierungstechnik, Roboter), dann haben
die Leute aber entweder spezielle Programmiergeräte (SPS, Roboter) oder
arbeiten einfach mit Notebooks.

Markus

P.S.: Ich hab' so ca. 100.000 Seiten an Perry-Rhodan-Romanen/Büchern
im Regal.

Autor: Notker (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
> Ich hatte nach einer Lösung gefragt, nicht wie man's am besten durch
> den Kakao zieht.

Sorry Daniel, aber irgendwie fühlte ich mich durch deine Ausführungen
ein wenig provoziert.

Ok, mal Spass beiseite. Es soll also ein interface erlaubt sein, aber
kein PC. Und es soll also ein Programmcode umcodiert werden können,
ohne das Ganze mit Interface-Kabel neu zu programmieren.

Nun ja, spontan fällt mir nur die Lösung in dem Link ein, den ich
weiter oben gepostet habe. Es handelt sich um einen minimalistischen
Basic-Interpreter für den AVR (läuft also im AVR!), der seinen
Programmcode als Tokens im EEPROM speichert und dort abarbeitet
(natürlich unter Zuhilfenahme des RAM). Um das Ganze zu programmieren
bzw. zu ändern ist nur ein kleines TTY-Terminal notwendig. Dieses
liesse sich auch wiederum mit einem AVR realisieren (kleine Tastatur,
LCD-Display o.ä.), so dass man hier eine sehr kompakte, programmierbare
Lösung eines Steuerungscomputers hätte. Eigentlich schon eine recht
interessante und vielfältig einsetzbare Sache. Vielleicht entspricht
dies ja deinen Vorstellungen.

Ansonsten fällt mir so spontan keine weitere passende Lösung dazu ein.

Allerdings könnte man für diesen Zweck auch einen kleinen
Palmtop-Computer mit angepflanztem I/O-Interface verwenden, z.B. so
einen Pocket-PC oder einen Palm Pilot. Die Möglichkeiten wären
vielfältig. Vielleicht kannst Du aber auch deine Wünsche noch etwas
präzisieren bzw. jemand anders in diesem Forum hat dazu noch einen
guten Einfall.

have a nice day

Notker

> p.s.: http://www.hp.com/calculators/
> Es gibt sie noch, oder nicht ?

Hmm, interessant. HP hatte dies damals selbst verkündet. Z.B. hier noch
zu lesen:

http://de.wikipedia.org/wiki/Hewlett-Packard

Scheinbar hat es sich HP doch wieder anders überlegt. Aber am
interessantesten sind sowieso nur die ganz ollen Dinger mit der roten
Anzeige g

Autor: Notker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
HP baut übrigens lebende Fossilien ;-)

schaut mal hier

http://www.hp.com/calculators/financial/12c/

und hier:

http://www.hpmuseum.org/hp12c.htm

Schon über 20 Jahre alt und immer noch voll im Trend! Das soll mal ein
anderes Unternehmen nachmachen (wenn es bis dahin nicht längst pleite
ist!).

have a nice day

Notker (der auch einen 12C sein eigen nennt)

Autor: Philipp Sªsse (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
(Habe diesen Thread vorhin als einzigen mit Suchwort "Forth" gefunden
und belebe ihn deshalb trotz seines Alters wieder)

Forth ist kein "Fossil", Forth wird benutzt. Wer einmal den
Bootloader einer Sun oder eines Mac abgebrochen hat, ist einem Forth
begegnet. Für PCs gibt es u.a. FPC, ein hardwarenahes Forth, ideal für
Erstimplementierung von Steuerungsaufgaben. Gerade im
Microcontrollerbereich ist Forth nach wie vor eine feste Größe.

Warum?

1. Forth ist klein. Ein Forthprogramm wird in der Regel kleiner sein
als ein Assemblerprogramm, weil Forth Codewiederverwertung auf die
Spitze treibt. Nur wird Forth dadurch übersichtlicher, während ein
entsprechend kompakt geschriebenes Assemblerprogramm praktisch nicht
mehr zu warten wäre.

2. Forth ist interaktiv. Das ist unschätzbar bei Diagnoseaufgaben
(daher die Verwendung in OpenFirmware usw). Hat jemand schon einmal
seinen DOS-PC mit "debug" bearbeitet? Was für ein Krampf! Ein
winziges Forth-System nimmt einem da unendlich Arbeit ab.

3. Forth ist schnell. Faktor 4? Gemeint sind eher 25 %, vermute ich.
Der eingebaute Compiler übersetzt jeden neuen Befehl in Maschinencode;
bestehende komplexere Befehle tauchen dort als Subroutine-Aufruf auf.
Durch die Arbeit mit dem Stack bedeuten Subroutinen aber
verschwindenden Performanceverlust (keine umständliche
Parameterübergabe), im Gegensatz zu C usw.

4. Forth taugt von kleinen bis zu großen Projekten. Ein alter
Forth-Programmierer hat einmal gesagt, man könnte in Forth zwar keine
großen Programme schreiben, aber man könne darin die perfekte Sprache
für ein beliebig komplexes Problem schreiben. Das ist es: man schafft
sich Ebene für Ebene immer komplexere Befehle und kann diese sogar
unterwegs testen, ganz ohne Debugcode (den man nachher vergißt).

5. Forth ist anders. Zugegeben, Forth führt ein Nischendasein. Grund
dafür ist wohl, das Forth völlig anders aufgebaut ist als andere
Sprachen. C, Assembler, Basic, Pascal, Java ... die funktionieren alle
nach irgendwo ähnlichen Prinzipien. Forth nicht. Wenn man also mit
etwas anderem angefangen hat, ist es eine gewaltige Umstellung,
ansonsten wird man mit der Sprache nicht glücklich (Beispiele im
Thread). Dabei kommt Forth eigentlich dem menschlichen Denken sehr
entgegen; nur ist dieses Denken bei Programmierern gerne schon
umgekrempelt. Der Weg zurück ist hart, aber er lohnt sich. Im
kommerziellen Umfeld ist die Entscheidung natürlich gewagt, denn einen
Forth-Programmierer kann man nicht so leicht ersetzen wie einen
C-Programmierer.


Wer einmal "forth" und "avr" bei Google eingibt, findet, daß
außerhalb dieses Forums die Kombination durchaus üblich ist und
geschätzt wird. Ich fange gerade ein Projekt an und habe mich für einen
Atmega als Basis entschieden. Eine Abschätzung des Resourcenbedarfs
ergab, daß ich mit C nicht hinkommen werde, also werde ich wohl wieder
auf Forth zurückgreifen (obwohl ich ansonsten einen Haufen C-Code von
anderen Projekten übernehmen könnte).

Ich würde mich gerne auch hier austauschen; die Erfahrungen von Henk
interessieren mich auch. Wenn Interesse besteht, kann ich dann gerne
auch eine Einführung dazu verfassen. Wenn aber nur Interesse am
üblichen Forth-Bashing besteht, nur zu. Die durchschlagende Unkenntnis
der Lästerer macht ihre Kritik nur zu einer Demonstration ihres
beschränkten Horizontes. (-:

Gruß, Philipp.

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Ich bin immer für neue Dinge offen. Kannst du uns mal das prinzipielle
Grundgerüst von Forth etwas näher bringen?
Ich habe bis jetzt nur C, Basic, Power-Builder, Cobol und Assembler
programmiert.
Deine Schilderung über die Näherbringung zum menschlichen Denken
interessiert mich sehr. Wenn man schon so lange wie ich C programmiert,
kann mann sich kaum mehr andere Konzepte vorstellen. Noch dazu dann,
wenn alle anderen Programmiersprachen so ähnlich sind.
Ich bin gespannt, was du uns über Forth erzählst.

Tschüss

Martin

Autor: olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Idee ist leider nicht so gut. Forth wird ja normalerweise auf einem
System interpretiert. Das hat so seine Vorteile, naemlich das man
direkt auf seiner Zielhardware entwickelt, aber auch den Nachteil das
ein Minimum an Nutzerinterface vorhanden sein muss.
Bei den meisten Anwendungen die man nun aber mit kleinen AVRs, MCS51
usw macht, wird man dieses Nutzerinterface aber fuer die eigentlich
arbeiten nicht mehr brauchen.
Das ganze ist daher IMHO etwas ineffizient.

Man kann aber auch richtige Forthcompiler nehmen. Wie der Zufall so
will habe ich vor Jahren soetwas mal programmiert. Sucht mal nach
st6forth. Ist aber natuerlich fuer einen ST6 und nicht AVR. Allerdings
kann man das natuerlich auch aendern, ich hab das z.B spaeter mal fuer
den MCS51 angepasst. Eine Anpassung an den AVR sollte keine grosse
Sache sein.

Das ganze hat schon eine gewisse Faszination. Insbesondere fuer sehr
kleine Prozessoren auf denen man den gewissen Luxus einer ich sag mal
hoeheren Sprache haben moechte, sich aber andererseits dicke Compiler
kaum leisten kann, ist das dann eine schoene Sache.
Ich muss aber gestehen das ich mittlerweile ueberwiegend C benutze weil
auch kleine Microcontroller mittlerweile viele Resourcen mitbringen.

Wer noch nie etwas von Forth gehoert hat fuer den wird die Sprache
zunaechst ein Schock sein. Es lohnt sich aber sich damit zu
beschaeftigen. Aehnlich wie Schach spielen oder das Kreuzwortraetzel in
der Times. :-)

Olaf

Autor: Ingo Henze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In den späten 80er Jahren hatte ich auch mal drüber nachgedacht, mich
mit FORTH zu beschäftigen.
Nach dem Anlesen des Artikels "FORTH - ein Softwarekonzept für
Mikro-und Minicomputer" von Claus Kühnel im Heft 10 der
"Kleinstrechner-Tips" war ich damals neugierig geworden.
Zumal es für den KC85/2 bzw. KC85/3 (den ich damals hatte) FORTH als
ROM-Erweiterungs-Modul M026 gab.
Aber wie das so ist, das Teil war seinerzeit nicht zu beschaffen und zu
teuer, und damit war die Sache erledigt. Schade.
Aber die knapp 20 Seiten in dem Heft werde ich jetzt mal lesen...

Gruß
Ingo

Autor: Tobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
erstmal vorneweg: ich hab keine ahnung von forth aber mir sind ein paar
fragen gekommen

"1. Forth ist klein. Ein Forthprogramm wird in der Regel kleiner sein
als ein Assemblerprogramm, weil Forth Codewiederverwertung auf die
Spitze treibt. Nur wird Forth dadurch übersichtlicher, während ein
entsprechend kompakt geschriebenes Assemblerprogramm praktisch nicht
mehr zu warten wäre."

das kann man seitdem es funktionen gibt doch bei jeder sprache machen,
von assembler angefangen. wo ist der unter von forth?


2. Forth ist interaktiv. Das ist unschätzbar bei Diagnoseaufgaben
(daher die Verwendung in OpenFirmware usw). Hat jemand schon einmal
seinen DOS-PC mit "debug" bearbeitet? Was für ein Krampf! Ein
winziges Forth-System nimmt einem da unendlich Arbeit ab.

dass hiesse, man müsste auf einem avr ein komplettes interface für ein
und ausgabe aufbauen (ausreichendes display, keyboard) oder wie willst
du sonst einen uC (ja, um die geht es hier, nicht um pc's) debuggen.
ich denk mal da sind hardwarenahe diagnosesysteme ala jtag überlegen,
die ein externes gerät als interface benutzen. oder was meintest du mit
interaktiv (z.b debuggen)


3. Forth ist schnell. Faktor 4? Gemeint sind eher 25 %, vermute ich.
Der eingebaute Compiler übersetzt jeden neuen Befehl in Maschinencode;
bestehende komplexere Befehle tauchen dort als Subroutine-Aufruf auf.
Durch die Arbeit mit dem Stack bedeuten Subroutinen aber
verschwindenden Performanceverlust (keine umständliche
Parameterübergabe), im Gegensatz zu C usw.

ist forth nun ein compiler oder interpreter. da gibt es
widersprüchliche angaben. oder gibts dafür beides wobei bei einem
compiler die interaktive entwicklung wieder ein problem wäre. so weit
ich weiss übergibt auch c parameter auf dem stack (so wie die meisten
hochsprachen) was für arbeiten mit dem stack macht denn forth, dass die
parameterübergaeb so viel schneller ist obwohl du ja schreibst,d ass
auch der stack benutzt wird? viele subroutinenaufrufe sind zwar ideal
zur codewiederverwertung aber blähen die stack unnötig auf und brauchen
auch bei entsprechender menge einiges an ausführungszeit. was ist in
zeiten von grossen speichern selbst auch kleinsten controllern der
vorteil?

so, genug gefragt. bin neugierig auf die antworten, vielleicht versteh
ich das konzept der sprache dann mal ;)

Autor: Ingo Henze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Coole Sache, so ein KC-Emulator :-)
Falls es jemanden interssiert, einen KC-Emulator nebst FORTH-Modul M026
gibt es hier:
http://kcemu.sourceforge.net

Da scheint seit einem Jahr aber die Entwicklung zu ruhen.
Zumindest konnte ich damit kurz das FORTH auf einem KC85/4 starten.
Dazu als Emulation "KC85 - 4" starten, unter "Module..." unten
links in Schacht C das Modul "M026: Forth" reintun.
Anschließend mit SWITCH 0C C1 das Modul einschalten und das Menü mit
MENU neu anzeigen. Es sollten nun oben zwei neue Menüeinträge "FORTH"
und "REFORTH" vorhanden sein.
Jetzt kann man FORTH einfach durch Eingabe von FORTH starten und zum
Spaß mal 321 + 456 ausrechnen:

321 456 + . [ENTER]

Viel Spaß :-)

Autor: Martin (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Wow!

Tolles System. Sieht aus als wäre es aus dem vorhergehendem Jahr
hunterttausend.
Also bis jetzt habe ich nicht wirklich ein Argument gehört, warum Forth
angeglich so super ist. Jedesmal wenn man genauer nachfragt kommt keine
Antwort. Mit diesen oberflächlichen Angeblich-Argumenten kann ich
nichts anfangen. Wo bleiben endlich die Beispiele, um diese Argumente
zu untermauern? Warum soll ich hier einen riesen Hardwareaufwand
begreiben nur damit man mal den Forth-Interpreter (oder was auch immer)
laufen lassen kann, wenn man mit fast null Hardware und C den Prozessor
super laufen lassen kann? Noch dazu bremst der Forth-Interpreter.

Tschüss.

Martin

Autor: Tobi (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
hab mal was gesucht und das hier gefunden:
http://claymore.engineer.gvsu.edu/~steriana/Python/pfavr/

mal ein paar features:
- PFAVR fits into less than 13Kwords of FLASH and less than 32Kbytes of
RAM
- They were designed for the ATmega128 processor with at least 32K of
external RAM with one wait-state. Other AVR's may work too if they
have at least 13Kwords of FLASH and 32Kbytes of external RAM.

kann ja sein, dass ich gerad eine schlechte implementierung gefunden
hab aber das versth ich nicht unter geringer codegrösse und
sparsamkeit.


mal einmkleiner codeschnippsel den ich gefunden habe:

LOG1W TEMPSENS
VAR N
: CELSIUS
CRC1W DROP { DROP deletes old CRC value from Stack }
TEMPSENS WR1W($BE)
RD1W ->CRC / 2 . EMIT($20)
FOR N(0,5) DO RD1W ->CRC NEXT
IF (RD1W = CRC1W) ." Grad C" ELSE ." ERROR" ENDIF
RET

sieht aus wie wenn man basiccode sinnlos probier in eine zeile zu
quetschen :)
das dingen hat nicht mehr mit dem menschlichen denken zu tun als
c-code. da liegt z.b pascal wesentlich mehr am normalen sprachgebrauch.
da bleib ich lieber bei c, sieht für mich genauso unübersichtlich aus
und man kriegt keinen krampf auf der shift taste ;)

Autor: Philipp Sªsse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Martin:
Eine Vorstellung von Forth im Rahmen eines Forenbeitrags? Oje,
hoffentlich verwirrt das nicht mehr als es klärt! Das Herz von Forth
ist ein zweiter Stack, auf den praktisch alle Operationen ausgeführt
werden. Ein '+' ersetzt z.B. die beiden obersten Werte vom Stack
durch ihre Summe. Das ersetzt fast alle (lokalen) Variablen und
Unterprogramme brauchen keine extra Parameterübergabe. Das macht der
Stack "automatisch". Dadurch kann man ohne großen Overhead auch
winzige Unterprogramme nutzen.

Dadurch ergibt sich automatisch die gefürchtete "umgekehrt polnische"
Notation, die aber letzlich unserem Denken entspricht: ich gebe Mehl und
Eier in die Schüssel, dann verrühre ich. Gebe Butter dazu und knete das
ganze usw. Erst die Zutaten, dann verarbeiten. Also "3 4 + 6 *". Das
"(3 + 4) * 6" wurde uns nur halt von Kleinauf antrainiert.

Forth hat ein Wörterbuch von Befehlen, das man selbst mit dem
eingebauten Compiler erweitert. Dabei werden frühere Befehle entweder
direkt eingefügt oder als Subroutinenaufruf. Dabei sind alle
Sprachelemente normale Befehle, auch "if", "for", "until" usw.
Auch der Compiler selbst (der Doppelpunkt) ist nur ein Befehl unter
vielen. Und das Schreiben von eigenen Compilern gehört zu einem
größeren Projekt fast immer dazu. Hier werden auch die meisten
Neugierigen abgeschreckt, denn man muß in Compilezeit und
Ausführungszeit denken.

Ein Kernwörterbuch für ein 8-bit-Forth wird unter einem kB groß sein,
der Rest ist dann in Forth geschrieben. Ein brauchbares, interakives
Forth kommt mit wenigen kB aus.


@ Tobi:
zu 1. In keiner anderen Sprache wirst du etwas wie
char Mittelwert(char a, char b) { return (a + b) >> 1); }
definieren. Das sieht zwar nachher übersichtlich aus, wird aber fett
und langsam; a und b müssen auf den Stack gelegt werden, das Ergebnis
nachher vom Stack geholt werden -- viel Overhead. In Forth macht man
alles ohnehin auf dem Stack (weil er nicht gleichzeitig Return Stack
ist) und es gibt keinen Overhead bis auf zwei Befehle zum
Unterprogrammaufruf und zum Rücksprung.

zu 2. Als Debuginterface für einen µC nimmt man z.B. eine UART, an die
man ein VT100 anschließt. Alles andere frißt natürlich zuviel
Resourcen. Aber dann kannst Du interaktiv Programmteile testen, z.B. um
einen timingkritischen Buszugriff auszufeilen. Ganz ohne
Ändern-Compilieren-Übertragen-Testen. Stell Dir vor, Du könntest eine
unwillige Zugriffsroutine einfach unabhängig vom Restprogramm von Hand
mit verschiedenen Parametern starten, um die Übertragung auf dem Oszi
zu verfolgen. In C müßte man erst wieder einen Haufen Debugcode
schreiben und hin und her.

zu 3. Forth ist Compiler und Interpreter. Was Du tippst, wird
interpretiert. Neue Befehle werden compiliert. Mit
: Mittelwert + /2 ;
läßt man den Befehl von oben dem Wörterbuch hinzufügen und kann in
Zukunft "4 6 Mittelwert" nutzen.

zu PFAVR: Das ist ein ANSI-Forth. Das wurde um allerlei mehr oder
weniger Nützliches erweitert. Wer ohne 32-Bit-Befehle und manchen
Programmierkomfort leben kann, braucht das nicht. Der Autor selbst
schreibt, daß es groß gerade ist, weil es in C geschrieben ist. Alleine
durch den Befehl "WORDS" muß jeder Befehl im Volltext im Dict stehen,
während für einen µC ein 2-Byte-Hashwert angemessen wäre.

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Forth ist grauenerregend.

Ich habe einen Jupiter ACE - erinnert sich noch wer an das Teil?

Zur gleichen Zeit habe ich auf einem Apple II mit einem Forth-Derivat
namens GraForth herumgespielt - schön, daß das so lange her ist.

Autor: Tobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@philip:
"In keiner anderen Sprache wirst du etwas wie
char Mittelwert(char a, char b) { return (a + b) >> 1); }
definieren. Das sieht zwar nachher übersichtlich aus, wird aber fett
und langsam; a und b müssen auf den Stack gelegt werden, das Ergebnis
nachher vom Stack geholt werden -- viel Overhead."

das sehe ich genau anders herum. bei vielen systemarchitekturen ist der
stack im hauptspeicher abgelegt und der zugriff darauf ist systembedingt
um einiges langsamer als der auf interne register. durch die vielen
zugriffe auf diesen 'rechen'-stack entstehen dann doch nicht gerade
wenige waitstates die die programmausführung ausbremsen. bei dem
prinzip, dass andere sprachen (ala c) benutzen werden die rechnungen
mit den internen registern durchgeführt die keine längere zugriffszeit
haben. bei deinem minimalbeispiel oben könnte man noch von einer
minimalen zeitersparniss ausgehen, aber bei auch nur wenig komplexeren
operationen dürfte der overhead durch den speicherzugriff grösser sein,
als der durch das einmal in register kopieren und zurück


gegen meine behauptung der unübersichtlichkeit in meinem letzten post
darf jeder forth verfechter auch gerne noch was sagen :)

Autor: Stefan Kleinwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei dem Beispiel:
char Mittelwert(char a, char b) { return (a + b) >> 1); }

wird gcc z.B. den Funktionsaufruf -je nach gewählter
Optimierungsoption- komplett weglassen und durch wenige
Assemblerbefehle ersetzen.

Stefan

Autor: Philipp Sªsse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man wird i.d.R. als TopOfStack ein Register benutzen, ein weiteres als
Stack-pointer. Eine Addition würde also eine indirekt adressierte
Speicherzelle zum ToS-Register addieren und den Stack-Pointer
decrementieren. Nenne mir mal einen Controller, der dafür länger
braucht als für die zwei Push, zwei Pull, Registeraddition, noch ein
Push, noch ein Pull.

Natürlich ist es weniger effektiv als eine Forth-Maschine, wo die CPU
den zweiten Stack verwaltet, aber immer noch effektiv genug.

Je nach Controller mag es sich lohnen, auch die Nummer 2 des Stack
(NOS) als Register zu führen, das führt aber automatisch zu mehr
Swapperei zwischen ToS und NoS (beide Register addieren, NoS nachladen
und Register decrementieren). Hängt von den Taktzyklen für die
entsprechenden Befehle ab, ob das besser ist.

Übersichtlichkeit? Du bist nicht der erste, der Forth als
"Write-Only-Language" belästert. Die Versuchung ist tatsächlich groß.
Der Autor Deines Codeschnipsels verschärft das Problem nicht nur durch
gruselige Namen (es besteht die Ahnung, daß ein DS1820 ausgelesen
werden soll), sondern auch durch offenbar willkürlich umdefinierte
Sprachelemente. Ein FOR mit dieser Klammernotation ist ebenso
"unforthisch" wie das kaputte IF. Ja, man kann sich in Forth schnell
ein wirres Basic schreiben. Aber nützlich ist das wohl weniger.

In einem Forth-Tuturial findest Du glücklichere Beispiele. Wenn man zu
Beginn eines Programmierprojektes in Stichworten die Programmfunktion
aufschreibt, gibt das meist schon einen guten Programmcode für die
oberste Ebene ab. (-:

Autor: Nesselhauff (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Es ist übrigens völlig egal, wie alt ein Thread ist - es ist überhaupt 
kein Problem, ein Diskussion über Jahre zu führen, mit großen Zeitlücken 
dazwischen. Der Zeitfaktor schmälert doch nicht den Inhalt.

Die ursprüngliche Frage lautet, ob Forth ein sinnvolles Betriebssystem 
für den AVR-Mikrocomputer ist, um im Bedarfsfall mit minimaler 
Interface-Hardware (UART + VT100-Terminal) in den laufenden Betrieb mit 
Änderungen eingreifen zu können.

Und ich kann bestätigen: Forth ist von Natur aus Betriebssystem, 
Interpreter und Compiler in einem. Dabei liegt der Speicherverbrauch 
samt Programm vielleicht bei 4 kB, und die Geschwindigkeit nah am 
Maschinencode. Forth besteht im Kern aus wenigen Bytes Maschinencode, 
der Rest besteht aus Forth selbst.

Forth ist nicht vergleichbar mit anderen Konzepten. Es ist eleganter, 
denn es besteht nicht aus einem großen Programmieraufwand, sondern aus 
einer selbsterzeugenden, intelligenten Codeidee.

Trotz seiner atemberaubenden Geschwindigkeit und seiner unglaublichen 
Winzigkeit ist Forth dennoch interaktiv - außerdem steht der Lösung von 
Aufgaben beliebiger Komplexität schlichtweg gar nichts im Wege.

Forth ist nur deshalb bei der Masse der Programmierer in Vergessenheit 
geraten, weil es zum einen der heute rasend schnellen Prozessoren wegen 
nicht mehr auf Geschwindigkeit ankommt, weil es zum weiteren bei den 
heute riesigen Arbeitsspeichern nicht mehr auf sparsame Kleinheit 
ankommt, und weil zum anderen Programmierer in den meisten Fällen 
sozialisiert wurden durch Basic, C, Pascal oder PHP.

Forth ist ein mühsames Geschäft, wenn man es gewohnt ist, in anderen 
Hochsprachen beliebig komplexe Anweisungen mit einer Zeile Code 
abzuhaken. Das geht in Forth zunächst eben nicht. Die erwähnte komplexe 
Anweisung muss man sich erst mal bauen - dann geht es genauso, wie in 
... sagen wir C. Für den heutigen Programmierer gilt es aber als 
unzumutbarer Aufwand, sich seine Sprache jedesmal neu zu schreiben - 
durchaus verständlich.

Im Grunde ist Forth damit ein Kit, um sich für seine ganz speziellen 
Zwecke eine eigene Sprache zu bauen - die dann allerding unvergleichlich 
mächtig ist. Dieser Mühe setzt sich heute keiner mehr aus - darum kann 
Forth niemals populär werden.

Für Mikrocomputer jedoch gibt es nichts besseres! Die Interaktivität ist 
ein Feature, das man mit dem geringstem Hardwareaufwand realisiert 
werden kann - aber wen interessiert das, wo alles vorgefertigt mit 
Notebooks oder Handhelds möglich wird. Programmierer verstehen heute 
weniger denn je, was sie da benutzen - Hard- und Software sind zu 
komplex, zu riesig dafür. Aber bequem.

Meine Antwort: Ja - für den AVR-Mikrocomputer unbedingt Forth nehmen. 
Wenn man es nicht hasst, weil man nichts versteht oder weil man bequem 
ist.

Autor: Detlev T. (detlevt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Forth ist sicher für Microcontroller nicht grundsätzlich falsch, weil es 
ja eigentlich genau für diesen Zweck entwickelt wurde: Die 
Programmierung von Steuerungen. Den Nachteil sehe ich darin, dass man 
nach meinem Verständnis immer Bottom-Up programmieren muss. Man fängt 
also mit kleinen Bausteinen an, setzt sie zu größeren zusammen, dann zu 
noch größeren und am Ende steht die Applikation.

Das setzt aber voraus, dass man sein Projekt von Anfang an komplett 
durchschaut, man also schon am Anfang weiß, welche kleinen Bausteine man 
braucht. Viele werden hier eher Top-Down programmieren. Also erst einmal 
eine Art Template erstellen, bei dem der Compiler nicht mehr meckert, 
und das dann mit Funktion füllen. Da passt Forth halt nicht ins Konzept.

Autor: stru_aus (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
huhu,
ich wecke auch mal diesen alten thread auf :)

ich hatte mir vor ein paar tagen amForth angeschaut.
meine fortherfahrungen davor: einmal wikipedia seite dazu durchgelesen, 
mehr nicht.

amForth ausprobieren ging viel einfacher als ich erwartet hatte, denn es 
sind gleich hexfiles für arduino dabei, und zufälligerweise lag hier 
einer rum.

flashen und voila! man hat über minicom eine art shell und kann den 
atmega rechnen lassen.
"1 2 + ." liefert tatsächlich "3 ok"

ein paar helferfunktionen um mittels forth direkt auf alle 
atmega-funktionalitäten sind dabei, nur fehlte dann noch passende doku - 
ich schaffte es nicht die led auf dem arduino-board zum blinken zu 
kriegen, statt dessen hab ich irgendwie das forth system geschossen: 
erst nach neueinspielen des eeprom hexfiles gingen einfache funktionen 
wieder.

mein urteil: amforth ist ein funktionierendes, ausbaubares system, aber 
derzeit noch recht frickelig, speziell und unzureichend dokumentiert.
danke an den entwickler :D

Autor: Balduin T. (balduin)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das war mal ca 1980 aktuell ;)

Ich kann mich noch daran erinnern dass das mal bei einem Kunden in einem 
kleineren Projekt eingesetzt wurde und hinterher das komplette 
Entwicklerteam überzeugt war "Nie wieder !"

Autor: matze (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
https://sites.google.com/site/libby8dev/fignition

Hier ist ein AVR Forth computer.. hab den thread leider etwas spät 
entdeckt :O sonst hät ich nicht extra einen geöffnet.

Gruss Matze

Autor: R. Freitag (rfr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mathias Trute hat ein AVR-Forth geschrieben, es ist auch irgendwo 
verfügbar.

Forth hat einen grossen nachteil: Das System braucht enorm viel 
Speicher.Daher taugt das alles nur zum Systemtest. Anwendungen erstellt 
man damit besser nicht.

Gruss

Robert

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Das System braucht enorm viel Speicher.

"brauchen" ist so nicht richtig. Forth Systeme "brauchen" sogar 
erstaunlich wenig Speicher. Bei Forth Systemen kann man aber durchaus 
sagen: Je mehr Bytes, desto mehr Forth-Wörter hat man im System 
integriert. Man kann aber letztendes alle Forth Worte, die nicht 
gebraucht werden, auch aus dem System entfernen und so das System wieder 
abspecken.

Forth ist halt gewöhnungsbedürftig. Das ist der größte Nachteil.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich möchte kurz anmerken, dass ich dieses Argument "RPN machen wir doch 
jeden Tag" zum kotzen finde ;-) Ich sterbe bei RPN Taschenrechnern und 
brauche welche mit Infix Notation. Ist einfach eine Geschmacksfrage. 
Frage mich auch was das in einer Programmiersprache zu suchen hat. Aber 
da bin ich möglicherweise zu konservativ.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simon K. schrieb:
> Ich möchte kurz anmerken, dass ich dieses Argument "RPN machen wir doch
> jeden Tag" zum kotzen finde ;-) Ich sterbe bei RPN Taschenrechnern und
> brauche welche mit Infix Notation.

:-)
Ist alles eine Frage der Gewohnheit. Den Bogen hatte ich bei meinem 
HP-Taschenrechner aber schnell raus. RPN ist einfach nur konsequent: 
Zuerst die Operatoren und dann die Operation. Bei den älteren 
Taschenrechnern war das ja auch nicht ander: erst tippte man den Winkel 
ein und dann drückte man die Taste für Sinus. Nur bei + * - / war alles 
ganz anders.

> Frage mich auch was das in einer Programmiersprache zu suchen hat.

Das ist einfach das Forth Konzept. RPN und die dafür aber konsequent 
durchgezogen. Das macht den "Compiler" einfach und schlank.

LISP ist genau anders rum: Zuerst die Operation und dann die Operanden.

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Wir standen vor wenigen Jahren, d.h. 2009, vor der Entscheidung, ein 
skriptfähige Ausführungsumgebung für einen STM32 zu finden. Nach 
wirklich umfangreichen Voruntersuchungen sind wir immer wieder bei Forth 
gelandet und haben uns für pForth entschieden.

Die Gründe hierfür waren die folgenden:
1. kompakte Laufzeitumgebung
2. deterministisches Ablaufverhalten ohne Garbage Collector o.ä.
3. Forth-Codegenerator sehr einfach als PC-Anwendung implementierbar
4. Laufzeitumgebung nicht mit GPL/LGPL, sondern BSD-artig

Bei dem Projekt ist jedoch nicht die komplette Firmware bzw. der 
Anwendungsteil in Forth geschrieben, sondern nur die eigentlichen 
Berechnungsfunktionen. Das Produkt, das dabei herausgekommen ist, ist 
unsere Funkfernsteuerung iVol blu bzw. iVol 2G16:

http://www.baltic-seagull.de/

Autor: sven98de (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein minimalistisches Forth, daß wenige Ressourcen des Controllers belegt 
u. trotzdem erweiterbar ist :
http://www.wulfden.org/downloads/Forth_Resources/3...

Autor: radiostar (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
> Ein minimalistisches Forth, daß wenige Ressourcen des Controllers belegt
u. trotzdem erweiterbar ist :

Ist zwar schon ein paar Jahre her (18, um genau zu sein), aber damals 
hatte ich ein genau auf den Zweck angepasstes Minimalforth auf einem 
68HC11 programmiert, mit dem ich eine drehbare Antenne gesteuert (und 
geregelt) habe. Dabei war das Betriebssystem in C geschrieben und der 
Interpreter arbeitete nach Forth-Manier. Wenn man einen simplen aber 
flexiblen Interpreter braucht, dann ist die gute alte Forth-Methode IMHO 
ideal.

Autor: Gerhard H. (Firma: Rentner) (spectro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
matze schrieb:
> https://sites.google.com/site/libby8dev/fignition
>
> Hier ist ein AVR Forth computer.. hab den thread leider etwas spät
> entdeckt :O sonst hät ich nicht extra einen geöffnet.
>
> Gruss Matze

Hi!

Finde den Link Spitze! Musste mir den "FIGnition" sofort ordern ! ;-)

Gerhard

Autor: Firth of Forth (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Forth love if honk then :-)

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel Roth schrieb:

> vielleicht ist schon jemand von euch auf die Programmiersprache Forth
> gestoßen und hat sich etwas damit befasst. Die Sprache könnte man gut
> auf dem AVR umsetzen

Nein, der AVR ist sogar denkbar ungeeignet für Forth. Seine 
Harvard-Architektur ist gerade nicht dafür gedacht, "interaktiv" zu 
sein, sondern sieht statischen Code vor. Dementsprechend ist der 
Programmspeicher für eben diesen statischen Code immer "groß", 
jedenfalls groß im Verhältnis zum verfügbaren RAM, auf den Forth 
einerseits wegen seines dynamisch generierten Codes und andererseits 
wegen seiner stackorientierten Arbeitsweise angewiesen ist.

Also ich kann ja vielleicht noch akzeptieren, daß jemand Spaß an Forth 
als Sprache hat. Auch wenn ich das nicht wirklich nachvollziehen kann, 
ich fand die Sprache schon beschissen, als ich das erste Mal 1986 auf 
einem Atari 800XL damit rumgespielt habe. Und der war von der 
Architektur her immerhin weitaus besser für Forth geeignet als ein AVR.

Forth auf einem AVR ist ungefähr so sinnvoll wie ein Ferrari F40 als 
Vorspannfahrzeug für eine Betonfräse oder ein Montainbike als Startstufe 
für einen bemannten Marsflug. Das paßt einfach nicht zusammen.

Wenn du unbedingt mit Forth auf einem µC rumspielen willst, dann nimm 
einen mit VonNeumann-Architektur. Auch noch nicht ideal für Forth, aber 
immerhin schon wesentlich geeigneter als Harvard.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Vielleicht sollte man mal einige alte Fragen aus dem Thread beantworten:
1. Standardprozessoren, die sich für Forth eignen:
z.B. der 68K hat quasi 8 Stacks
2. Weltraum bzw. hohe Zuverlässigkeit:
IPS ist eigentlich fast vollständig standard Forth. Hat seine extrem 
hohe Zuverlässigkeit in Amateurfunk-Satelliten bewiesen.


Ich sehe eher in der heutigen Zeit das Problem, daß mitgelieferte Libs 
immer für C sind. Ein Forth-Programmierer müßte die alle nachschreiben 
oder irgendwie in einem Mischcode aus C und Forth integrieren, damit er 
die Prozessor-Libs dann in Forth benutzen kann.

Aus meiner Sicht sind DLLs und Forth halbwegs vergleichbar. Man kann ein 
laufendes System durch Austausch von Modulen umprogrammieren.

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.