universelle Funktion mit 3 Variablen

Natürlich musst Du die Worte Z, Achse und freigeben auch vorher deklarieren.

Beispiel für einen IO mapped Prozessor:

1 constant Z \ Z-Achse an Bit 1 3 constant Achse \ Alle Achsen an Port 3

Folgende Umwandlung von bitnr in maske würde ich vermutlich in Assembler schreiben, also statt :-Definition als CODE-Definition. Ist wesentlich schneller, dafür vermutlich etwas länger. Aber das führt hier zu weit. Im folgenden schreibe ich nicht alle Kommentare, die man machen sollte

: n>bit ( n -- b ) 1 swap 0 DO 2* LOOP ; \ bitNr -> maske wandeln

: freigeben ( nB aP -- ) DUP P@ ( -- n aP bP ) \ aktuellen Portzustand laden ROT n>bit ( -- aP bP m ) \ bitnr in Maske wandeln OR SWAP P! ( -- ) \ setzen und ab an port ;

: sperren ( nB aP -- ) DUP P@ ROT n>bit NOT AND SWAP P! \ loeschen des Portbits ;

Die Folge DUP P@ ROT n>bit kann man ausfaktorieren und ein ein neues Wort machen: : bp>pbm DUP P@ ROT n>bit ;

dann kann man sperren... so definieren

( nB aP -- ) : freigeben bp>pbm OR SWAP P! ; \ ext. HW einschalten : sperren bp>pbm NOT AND SWAP P! ; \ ext. HW ausschalten

Ist es auch, alles völlig unkompliziert in Worten, die der Anwender versteht, weil in seiner Sprache geschrieben. FORTH ist kein abgeschlossenes System sondern jeder soll es für seine Anwendung anpassen, da dem Erfinder Chuck Moore klar wurde, dass er niemals eine abgeschlossene Sprache entwickeln kann, die alles kann. Also hat er eine Sprache entwickelt, mit der man alles verändern und erweitern kann. Und das so einfach, wie möglich. Ich gerate schon wieder ins schwärmen. Chuck ist der genialste Programmierer, den ich je kennenlernen durfte.

Man kann schlechte Programme in jeder Sprache schreiben, in FORTH ist es am einfachsten.

Oder auch: Schlechte FORTH Programmierer bringen ihr Programm zum laufen und fühlen sich gut. Schlechte C-Programmierer geben auf und fühlen sich schlecht. :-)

Ja natürlich, dass musst Du auch mit FORTH

Ich hab dann typisch Worte die mit '0' anfangen um was zu initialisieren Mit '00' für einen Kaltstart ...

Also

: 0ports 0P1 0P2 0P3 0P4 ;

: 00ports 0ports \ ggf. noch die Portimages usw loeschen... ;

: COLD disable_IR 00ports 00timer 00IRsys enable_IR ;

: main \ die komplette applikation, die ständig wierholt wird tu_dies mach_das und_mehr ; : MAIN COLD BEGIN main ABBRUCH? \ t= Ende der Applikation UNTIL disable_IR ." System angehalten! Watt nu?" ;

\ MAIN wird bei mir in allen Systemen ausgeführt, wenn die CPU samt RAM \ usw. initialisiert ist und ist die eigentliche Applikation.

Du kannst jedes Wort einzeln durch tippen des Namens aufrufen und Dir die Funktion überprüfen. Also ob der Stackeffekt stimmt, ob die HW richtig gesetzt wird... Solange bis es funzt.

Müsste eigentlich bei der

einiges zu finden sein. In der aktuellen Vierten-Dimension (VD 3/2008) habe ich ein hardwarenahes Beispiel für Reverse Engineering Preventer geschrieben :-)

Ansonsten ist Rafael Deliano auch immer eine gute Quelle für FORTH auf uC...

Ich hab gerade bei der Forth-ev gesehen, dass da jetzt auch ein Film (ca. 66min) drin ist, hab ihn noch nicht gesehen. Vielleicht ist das was zum Einstieg:

Ansonsten einfach mal rumprobiern mit einem FORTH für den PC. gforth läuft auf PC und auch unter Linux. bigforth ist wirklich big :-) MINOS (alle 3 von Bernd Paysan) sowie winFORTH sind auch toll.

Diese Systeme haben alles was das Herz begehrt und sind für uC üblicherweise zu gross, aber angenehm für 1. Gehversuche.

Saludos Wolfgang

--
Meine 7 Sinne:
Unsinn, Schwachsinn, Blödsinn, Wahnsinn, Stumpfsinn, Irrsinn, Lötzinn.
Wolfgang Allinger   Paraguay             reply Adresse gesetzt !
ca. 15h00..21h00 MEZ  SKYPE:wolfgang.allinger

"Wolfgang Allinger" schrieb:

Hallo Wolfgang,

Du bist ja ein richtiger Forth-Enthusiast! Ich muss sagen, das klingt schon interessant, was Du da schreibst, aber ich hätte noch eine grundsätzliche Frage. Für nen Feld-, Wald- und Wiesenhobbyelektroniker wie mich ist die Programmiersprache für z.B. einen AVR eigentlich nicht so wichtig. Ich möchte mir halt gerne die Zeit sparen, alles von vorn entwickeln zu müssen, drum greife ich gerne auf Libraries von anderen zurück, für z.B. Displayansteuerung und A/D-Sampling, nehme gerne Code-Beispiele für PWM, Tastenentprellung etc. Da ist das meiste eben in C geschrieben. Wichtig ist also die Verfügbarkeit von libs und Beispielcode. Portieren? Ach nee, lass man... Wie sieht's da mit Unterstützung durch Forth und die Community aus? Sowas wie amforth bringt ja, wenn ich's recht sehe, auch nur den Core mit..

Viele Grüße, Leo

Viel Lesen ist für FORTH wenig ergiebig. Angenehmer ist man spielt an laufendem System im Interpretermodus rum. Und fängt dann mit simplen Applikationen ( LEDs einschalten, Taster abfragen ) an.

Die Manuals der GP32 Implementierung sind ( im Gegensatz zur Zeitschrift ) direkt zum Download verfügbar und geben eine typische Übersicht wie sowas auf 8 Bit Controller aussieht:

Das Teil ist manchmal auf ebay verfügbar.

MfG JRD

Die Spezies findet sich in Restbeständen hier:

Es gibt dort auch eine Zeitschrift als pdf: In München gibts sogar noch eine lokale Gruppe mit monatlichem Treffen, allerdings selten mehr als

4 Teilnehmern.

Wenn der Entwickler des FORTHs das Zeug selber real für Applikationen verwendet dann erstellt er selber zwangsläufig für sich selbst Source für (HD44780-)Displays und Treiber für die PWM seines Controller-Derivats. Muß halt dann noch publiziert werden, z.B. als Zeitschrift. Knack- punkt: irgendjemand steckt richtig Arbeit rein damit was existiert, ist dann nicht kostenlos.

Natürlich tauchen in de.comp.lang.forth oder beim Münchner Stammtisch Leute auf: "Ich habe hier ein AVR-Butterfly Board und möchte damit gerne Heizungssteuerung machen. C ist mühsam, Forth ist simpel: könnte ich mal versuchen. Wo kann ich das adaptierte Forth samt Dokumentation runterladen ? Ist Hobby, sollte also kostenlos sein. Gibt es geeignete Libraries dafür ? Kann ich bestehende C-Libraries einbinden ? usw." Realistische Antworten verdauen die Leute nicht. Um die technischen Vorteile von FORTH nutzen zu können muß man auch irgendwo Beschränkungen akzeptieren.

MfG JRD

Stimmt schon, Du bekommst vieles als C-libs... und wirst dadurch von der Peripherie abgekoppelt. Wenn Du keine HW-Entwicklung machst, ist das ok. Speicher und sparsamer Umgang mit Resourcen ist auch nicht mehr gefragt, ich sag nur Maustreiber mit 20MB :-( Aber wehe, Du hast einen Fehler in der Lib oder in der HW, dann stehste davor, wie der Ochs vorm Berg.

WARNUNG: Wenn Du einmal kapiert hast, wie einfach es ist, interaktiv zu entwickeln, kann es passieren, dass Du davon nie mehr los kommst :-) Ich hab etwas länger gebraucht, bis ich wirklich verinnerlicht habe, bin halt durch Assembler versaut gewesen :-)

Wie gesagt, Mitch Bradley ist/war HW-Entwickler (bei SUN) und hatte vorher nie(?) programmiert. Er bekam FORTH in die Finger und lernte, wie man interaktiv einen Controller (damals noch ein Doppel-Europa TTL Grab) zum Leben bringen kann. Ich hab vergessen, auf welchem Rechner er das Forth hatte, aber er emulierte darauf die Schnittstellen der neuen Workstation und konnte seinen Controller damit entwickeln ohne den Rest der HW (die es eh noch nicht gab).

Ich hab 1980 (nach 12 Jahren Assembler, etwas Fortran und BASIC) mit Forth angefangen. Es war die berühmte BYTE vom Aug. 1980, die mich elektrisierte und hab dann nur Testprogramme für Plattencontroller etc. geschrieben, damit der Service die interaktiv warten konnte und ich die Fehler (im zugekauften Controller) umgehen konnte.

Nachem ich wusste, was da flasch lief, hab ich den Treiber im damaligen OS umgeschrieben und alles lief prima. Ich hab dann wieder in Assembler noch 6 Jahre weitergearbeitet und Forth fast vergessen.

Einer meiner MA hat dann 1982 mit Forth eine Bedieneroberfläche für ein US-Testsystem geschrieben. Der Grund war, dass nur mit der äussert Speicher effektiven Art von Forth es möglich war, den Kram im vorhandenen Speicher unterzubringen. Er hatte mit BASIC angefangen aber der Kram wurde immer größer (die Anforderungen aus dem Marketing schwollen schneller an, als man tippen konnte!) und passte nicht mehr in den Speicher.

Ich hab immer noch nicht kapiert, wozu Forth gut war. Weiter mit Assembler.

1984 bekam ich dann als Abteilungsleiter ein Projekt reingedrückt, was innerhalb von maximal 6 Monaten (Zeit bis Interkama84) als Prototyp fertig werden musste, aber hatte für geschätzte 6+ Mannjahre Arbeit nur 2 (gute) Inenieure und mich frei. Die Abteilung, die das ursprünglich machen sollte, hat alles vermurkst und das Handtuch geschmissen und die Spezialisten von der Prüfanlagenentwicklung mussten es ausbaden!

Ich erinnerte mich dran, dass die Forth Leute immer behaupteten, dass sie locker 10-15 mal produktiver seien, als in herkömmlichen Sprachen. Es war unsere einzige Chance. Wir teilten die Bereiche auf, einer für die Oberfläche, der zweite für die Ultraschallspezifischen Programme und ich sollte die HW der CPU in Ordnung bringen und mich um die IR-Service Routinen und den Rest der Abteilung kümmern.

Ich hab dann einen Forth-Guru für 2mon gemietet, den wir dann als wandelndes Lexixon gebraucht haben. Ich hatte ja etwas Erfahrung mit Forth, die anderen zwei haben es von der Pike auf gelernt und gewaltige Fortschritte gemacht.

Ich habe vorher nie gewusst, dass man auch aus Wut (auf das Damagement) zu Höchstleistungen auflaufen kann. Wir haben wie die bekloppten gewühlt und haben das Ding in weniger als 6mon zum Laufen bekommen.

Um die Sache noch abzurunden: 2mon vor der Messe stellte sich heraus, dass die CPU Platine (Z80) absolut nicht brauchbar war und ich hab dann mit einem weiteren HW-Spezi eine neue bauen lassen, auf Basis 64180... Die IR-Service Routinen und die Initialisierung geändert, die anderen 2 haben weiter in der virtuellen Forth Maschine entwickelt und praktisch nichts von der neuen CPU mitbekommen, ausser dass der Krempel besser lief!

Bei US kannste nicht viel türken, die Anwender verschieben den Prüfkopf und wehe das Display zeigt was flasches. Da iss nix mit Simulation!

Mit den Erfahrungen und auch der Antwort des Damagements: Na also, ging doch, man muss halt die Entwickler ordentlich in den Arsch treten, dann kommen die schon aus den Hufen. Die Damager haben nicht begriffen, was da abgelaufen ist, Dank gabs latürnich sowieso nicht! Da ich das nicht nochmal erleben wollte, habe ich dann die Fa. (mit den anderen 2 und einem weiteren Ing.) verlassen und wir haben eine eigene Fa. gegründet.

Ich hab dann 1992 diese Firma verlassen (gibts immer noch) und ein Ing.- Büro gegründet.

Für mich stellt Forth eine ungeheure Befreiung aus den Zwängen der Compiler und Assembler dar. Es hat mir meine Scheuklappen und Ketten abgenommen. Ich möchte nie mehr der Slave eines Compilers sein!

Ich ändere mal das Subject, sonst findet man das nicht wieder. Sorry an die anderen Forther hier :-)

Saludos Wolfgang

--
Meine 7 Sinne:
Unsinn, Schwachsinn, Blödsinn, Wahnsinn, Stumpfsinn, Irrsinn, Lötzinn.
Wolfgang Allinger   Paraguay             reply Adresse gesetzt !
ca. 15h00..21h00 MEZ  SKYPE:wolfgang.allinger

Rafael Deliano schrieb:

Meinst du mit GP32 das da:

?

--
  Klaus Rotter * klaus at rotters dot de * www.rotters.de

Ich hab mir gerade mal Samuel's video ots-1.mpeg geladen und angesehen.

Gefällt mir gut und ich hab viel neues gelernt, wie man Forth Programme auch schreiben kann. Meine sehen etwas anders aus. Aber durch abgucken wird man nicht dümmer :-)

Ich bin normalerweise immer interaktiv im Forth und tippe die Kommandos direkt ein, bis es funzt und kopiere es dann in den Sourcefile. Samuel macht wenig interaktiv. Aber jeder Jeck ist anders, sagt man im Rheinland. Kann daran liegen, dass er wenig Frickeleien an der HW macht. Sein Stil ist eher der klassische Programmierer Stil, Source schreiben und ausprobieren. Ich probiere erst und dann gibbet die Source.

Er fängt dafür von oben nach unten an zu schreiben, ich machs üblicherweise genau umgekehrt, so wie man ein Haus bauen sollte :-)

Mit meiner Richtung fange ich an den üblen Stellen tief im Eingemachten an und die Bedienung kommt als letztes. Ist für mich (bei HW) der bessere Weg, dann weiss ich, dass die HW ok ist, Bedieneroberfläche ist dann nur noch Schweiss... Wenn mans so wie Samuel macht, merkste erst u.U. kurz vor Fertigstellung, dass gaaaaaanz unten ein übles Problem ist. Aber wie gesagt: Jeder Jeck...

Und ich stehe auf Kommentare :-o Je gehässiger, umso besser :-) Aber lest selber.

Und Stack Kommentare ( ... -- ... ) liebe ich auch.

Das -- symbolisiert das Wort, links davon steht, was es auf dem Stack in welcher Reihenfolge erwartet, rechts vom -- steht, was es hinterlässt. Der jeweils rechteste Eintrag symbolisiert TOS (Top Of Stack) links daneben falls vorhanden NOS (Next Of Stack) ...

z.B.

DUP ( n1 -- n1 n1 ) \ verdoppelt den Stack entry SWAP ( n1 n2 -- n2 n1) \ vertauscht den Stack TOS mit NOS

1 2 3 SWAP ( -- 1 3 2 ) \ also TOS = 2, darunter die 3 darunter die 1.

Soweit zur Einführung, weiter im Text.

Hier mal (m)ein (extremes) Beispiel für einen Feueralarm:

======================X8========================================

\ FEUER Demo FEUERMELDER Anwendung ALL 11:26 14MAY93 \ Last changed screen # 000 ALL 11:26 14MAY93

\ (C) 1993 by Dipl.-Ing. Wolfgang Allinger 'ALL0593' \ c/o Ingenieurbuero Allinger \ Jamaica /e Peru \ Barrio Gloria Maria \ Villa Elisa, Paraguay \ mailto: all2001 (at) gmx (dot) de \ noncommercial use granted !!!

\ Diese lauffähige Demo zeigt, wie eine anwenderfreundliche, \ selbstdokumentierende Sprache am Beispiel eines FEUERMELDER \ aussieht. Hinweis: alles in "( )" und nach "\" ist Kommentar. \ ":" ... ";" sind neue Definitionen. \ "Feueralarm?" und "Feueralarm_bearbeiten" sind 2!! Programme. \ Diese Demo belegt weniger als 700 byte Programmspeicher und \ läuft praktisch auf beliebigen Rechnern ohne Änderung.

\ HISTORY MASTER LOAD SCREEN ALL 11:19 14MAY93

DECIMAL \ default base

001 CONSTANT $VFEUER \ Versions Kontrolle

: -FEUER FORGET $VFEUER ; \ entfernt dieses Programm wieder

\ 2 ?SCREENS THRU \ 1 LOAD lädt dann die Anwendungsblöcke \ bei SEQ file system auskommentieren !

\ ALL20081130 v0.01 address corrected for /de/sci/electronic \ ALL0593 v0.00 first release

\ .VFEUER ... constants ... USER Interface ALL 10:16 14MAY93

: .VFEUER $VFEUER CR . ; \ zeige Versionsnr.

-1 CONSTANT ja

\ Bereich Meldung .. alle für die jeweilige Umgebung anpassen

VARIABLE Meldung \ bits gesetzt wenns qualmt, n. Zeile setzt 5 Meldung ! \ zB: bit0 = Melder1, bit2 = Melder3 : Melder@ ( a -- u ) @ ; \ liefert Datum aus Adresse Meldung CONSTANT Melder0 \ liefert Adresse der 1. Meldung : Rauch ; \ evtl eine Maske.. für geräuchertes 16 CONSTANT bits/Meldung \ zB 16bit oder was auch immer 16 CONSTANT alle \ Anzahl Melder

\ Rauchmelder anwählen abfragen entdeckt? ALL 11:15 14MAY93

VARIABLE Rauchmelder \ 1 ... n

: anwählen ( d a -- ) NIP ( n 0 a -- n a ) ! ;

: abfragen ( a -- uMASKE uDATA )

@ 1- bits/Meldung /MOD ( -- rem qot ) Melder0 + Melder@ ( -- rem uDATA ) 1 ROT ( -- uDATA 1 rem ) SHIFT ( -- uDATA uMASKE ) \ rem -> MASKE SWAP ; ( -- uMASKE uDATA )

: entdeckt? ( uMASKE uDATA -- t=RAUCH) AND 0> ;

\ Feueralarm melden nächsten abgefragt? ALL 11:15 14MAY93

: Feueralarm ( -- ^string nMelder )

" Rauch an Melder Nr.: " ( -- ^string ) Rauchmelder @ ;

: melden ( ^string n -- ) CR SWAP COUNT TYPE . 7 EMIT ;

: nächsten ( -- d ) Rauchmelder @ 1+ 0 ;

: abgefragt? ( n a -- ? ) @ 1-

Sicherlich amüsantes Spielzeug: / * Abmessungen: 147mm × 88mm × 34mm / * Gewicht: 163 g / * Display: 31/2 Zoll TFT-Bildschirm (65536 verschiedene Farben) / * Auflösung: 320 × 240 Pixel / * CPU: 32-bit RISC CPU (ARM-Architektur), getaktet mit 133 Mhz / * Arbeitsspeicher: 8 MB SDRAM / * ROM: 512K (Flash-Speicher, d.h. eigene Software kann eingespielt werden) / * Klang: 44,1 kHz 16-Bit-Stereo-Klang, Kopfhöreranschluss, Stereolautsprecher eingebaut / * Speichermedium: Smart-Media-Card (SMC) bis 128 MB / * PC-Verbindung: USB-Kabel / * Stromversorgung: 2 AA-Batterien oder 3V-DC-Adapter / * Steuerung: 4-Wege-Digitalpad (Joystick) und 6 Knöpfe

Ich meine aber das da:

Mein "GP32" ist eine alte "General Purpose" Variante des Freescale MC68HC908 die mit 3-5V läuft und noch in DIL40 fädeldrahtfreundlich verfügbar ist:

MfG JRD

Hatte ich mir vor ein paar Wochen mal angesehen, verstehe aber nicht ganz, was es für einen Sinn macht, etwas in einer Stunde in Forth zu schreiben, was man mit Perl, AWK o.ä. in 5 Minuten programmiert hat. Für Low-Level Hardwarewareprogrammierung mag Forth manchmal recht praktisch sein, aber auf dem PC gibt es besseres.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Rafael Deliano schrieb:

Hat jemand eigentlich Erfahrung bei einem konkreten Projekt mit Forth in dieser Größenordnung, also 32 Bit und ein paar MB RAM? Meine erster Kontakt mit Forth war wohl Mitte der 80er Jahre auf einem 6502. Da war Forth schön, denn es war relativ schnell, kompakt und überschaubar, ohne Assembler bemühen zu müssen. Gute Compiler gabs keine, so dass Forth da wirklich eine Art Offenbarung war. Der wirklich brauchbare gcc für AVRs hat mich schon lange kein Forth mehr anschauen lassen (obwohl ich ColorForth mal ausprobiert habe). Ähnlich ist es (bei mir) mit ARM7.

-Klaus

--
  Klaus Rotter * klaus at rotters dot de * www.rotters.de

Läuft ColorForth nicht nur auf x86'er Systemen und ist eher ein abschreckendes Beispiel einer Forth-Umgebung? Es sei denn, man hat keine Probleme damit, Huffmann-gepackte Strings im Kopf auszurechnen :-)

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Trifft für jedes aktuelle Forth auf PC zu. Z.B. Gforth

Davon gibt es formal auch eine Variante "Gforth EC" ( =Embededded Controller ). Wurde auch versuchsweise schon auf 8 Bit Renesas R8C portiert, Hardware war das Board von Elektor. Da erhebt aber wohl niemand den Anspruch daß es eine fertige Entwicklungsumgebung zur Erstellung von Applikationen ist. Wie das bei kostenlos, open source usw. eben so ist. An FORTH für ARM10 werkelt gerade jemand der das dann aber hauptsächlich wieder intern hier zur Anwendung bringen wird. Bestenfalls gibts davon aber eine Vorführung auf der Forth-Tagung oder am Münchner Stammtisch. D.h. viele Anwender in der Industrie ( d.h. keine Anfänger ) portieren halt selbst.

Das hängt halt davon ab was man sich vom FORTH erwartet: ich will etwas das nicht auf PC sondern im Target interaktiv läuft und compiliert um Entwicklungs- und Testzeit zu sparen. Wenn der produzierte Code etwas mehr Speicher benötigt und etwas langsamer ist als der den ein Crosscompiler vom PC erzeugen könnte toleriere ich das. Zumal ich ja Assembler sehr leicht einbinden kann.

MfG JRD

Neue Aktivitäten gibts laufend. Jetzt frisch gegründet am 27.11.08 auch noch ne newsgroup für FORTH in Yahoo:

Peter Jakacki: / This group was started because I have not found one Forth group that / addresses the real strength of Forth and that is in embedded systems, / particularly microcontrollers. Most groups are bogged down in the / language per se, or are PC centric.

Die zentralen Problem für FORTH sind tatsächlich die "Enthusiasten" und das Rumspielen am PC.

MfG JRD

:-))

Danke für den Link, kann man die NG auch im usenet sehen?

Saludos Wolfgang

--
Meine 7 Sinne:
Unsinn, Schwachsinn, Blödsinn, Wahnsinn, Stumpfsinn, Irrsinn, Lötzinn.
Wolfgang Allinger   Paraguay             reply Adresse gesetzt !
ca. 15h00..21h00 MEZ  SKYPE:wolfgang.allinger

Es war abschreckend... :-( Es scheint sich auch nicht mehr viel zu tun. Kaum jemand steuert da Code bei, zumindest nach der ColorForth Homepage zu urteilen.

-Klaus

--
  Klaus Rotter * klaus at rotters dot de * www.rotters.de

Rafael Deliano schrieb:

Hm... habe ich hier auch noch rumliegen, aber bis jetzt eher nichts gemacht. Der 8Rc hat doch eine Von-Neumann-Architektur, oder? Der Reiz von Forth ist für mich der, wirklich das ganze System zu verstehen und zur Not auch ändern zu können. Geh' doch mal selbst beim gcc auf Bug-Suche, viel Spass! Und von anderen Systemen fehlt dann komplett der Quelltext...

Wie komplex werden denn dann die Applikationen - geht das manchmal wesentlich über das klassische MSR Gebiet hinaus? Sprich, kommen da auch mal TCP/IP und/oder grafische Benutzeroberflächen ins Spiel? Und das alles in Forth?

Ich bin ja eigentlich auch ein Verfechter des KISS (keep it stupid simple) Prinzips. Hunderte von MB große Entwicklungsumgebungen gehören da eher nicht dazu, aber der gcc ist ja inzwischen auch alles andere als klein. Allerdings kenn' ich mich beim gcc ein (bisschen) aus, ich habe eine Entwicklungsumgebung für AVR auf einem USB-Stick. In einen Computer schieben (Win32) und ein batch Datei starten - nun kann man entwickeln - mit der kommandozeile, jfe und make. Schuster, bleib bei deinen Leisten...

Da AVR ja eine Harvard Architektur ist, muss man ein paar Klimmzüge machen, damit da Forth gut läuft.

-Klaus

--
  Klaus Rotter * klaus at rotters dot de * www.rotters.de

Weiss ich nicht. Das Forth selber kann man wohl problemlos reinladen. Es war aber eher für Anfänger die Forth mal testen wollten a la Elektor gedacht.

Bezogen auf Gforth: Source offen, aber zu umfangreich. Bezogen auf nanoFORTH: System kompakt, aber Source nicht offen. Ausserdem ist auch dort das Listing viel zu umfangreich als dass es wirklich für Anwender relevant sein könnte.

Hauptsächlich Signalanalyse mit FFTs u. ä. . Anbindung an PCs dann über Ethernet.

Oder man ignoriert eben den AVR.

MfG JRD

:-))

Danke für den Link, kann man die NG auch im usenet sehen?

Saludos Wolfgang

--
Meine 7 Sinne:
Unsinn, Schwachsinn, Blödsinn, Wahnsinn, Stumpfsinn, Irrsinn, Lötzinn.
Wolfgang Allinger   Paraguay             reply Adresse gesetzt !
ca. 15h00..21h00 MEZ  SKYPE:wolfgang.allinger

Es ist eine newsgroup in Yahoo. Mit allen Vor- und Nachteilen. Einschlägige Diskussion dazu gibts gerade in comp.arch.embedded und comp.lang.forth

/ CBFalconer wrote: // IMO Yahoo groups don't have the wide access and usability of a news // group. I see you have found comp.lang.forth. How about // alt.comp.lang.forth? Both should have world-wide access.

alt.comp.lang.forth z.B. hat t-online nicht.

Wie auch Sennewald für LTSpice

schon angemerkt hat: Einbinden von Files ist besser. Einrichten von newsgroups ist einfacher, insbesondere wenn diese enge technische Themen ansprechen wollen.

MfG JRD