Einsteig in Microcontroller und Programmierung

Was hat das mit Datenstrukturen zu tun? Die fehlen in Forth halt mal.

Erweiterbar sind auch andere Sprachen. Das ist bei Forth nichts besonderes.

Gibts auch für andere Sprachen.

Leicht im Sinne von Low-Level und klein.

Forth als ultimative Sprache? Meinetwegen. Wenns für Dich funktioniert bleib dabei.

Hast du vielleicht übersehen:

Ich hatte ein Rechtecksignal auf einem Port Pin generiert, was eine recht simple Operation sein sollte. Lief ursprünglich im Interpretermodus des MPE Forth Systems mit 275 kHz, die C-Version mit 2,4 MHz. Mit dem MPE Crosscompiler compiliert lief der Forth Code unverändert in meiner C-nahen Schreibweise mit 1,35 MHz, in einer optimierten Version mit 3,57 MHz (anders als bei SwiftX ist der MPE Crosscompiler nicht im Target verfügbar, da gibt es nur den Interpretermodus, der aber für viele Aufgaben auch schon schnell genug ist, wie mein erster Test gezeigt hat).

Das wird sich bis zum Ableben von ISDN eventuell auch nicht mehr gross aendern. Denn beinahe der komplette US-Markt faellt als Abnehmer aus, da so gut wie nicht vorhanden. Damit schrumpft der Gesamtumsatz pro Anlage und das ist nicht gut fuer den Preis.

Nicht ISDN-Preise fuer Telefone sehen hier so aus:

Bei unserer derzeitigen Anlage sind die Akkus mal wieder platt. Wird fast teurer als eine neue wie in dem Link oben zu kaufen. Nur weiss ich nicht ob bei 5.8GHz die Reichweite taugt. Oder sollte man lieber klassisches DECT nehmen? Die gibt es noch fuer 2.45GHz (ist hier nicht besonders dicht belegt).

Joerg ( snipped-for-privacy@removethispacbell.net):

Ja und? Wo ist das Problem? Solch eine Anlage hatte ich mal mit betreut,

73 de Tom

Am Fri, 10 Apr 2009 15:31:00 +0200 schrieb Axel Berger:

Wobei es bis 96(?) die Förderung von 800 DM gab, das machte den Einstieg doch leichter. Als die Förderung entfiel sanken dann aber auch die Preise für die Hardware um einiges.

Lutz

Hängt immer vom Projekt ab. Java finde ich recht nützlich, wenn man Webanwendung und plattformunabhängige Businessanwendungen programmiert, aber für Microcontroller ist C schon eine gute Sache, neben Forth :-)

Ja, Parallelität ist bei VHDL selbstverständlich. Habe damit im Audiobereich dutzende von 24 Bit, 192 kHz, digitale und analoge Streams per FPGA bearbeitet und geroutet. Ist als C Programmierer erstmal nicht einfach zu verstehen, da VHDL eher eine deklarative Programmierung ist (z.B. so wie SQL oder XSLT) und im Endeffekt eine Schaltung statt einen oder mehrere sequentielle Abläufe beschreibt. Gibt zwar mittlerweile auch Ansätze wie SystemC, was ich noch nicht ausprobiert habe, aber ich könnte mir vorstellen, daß das zu einigem Overhead führt, da die Architektur einfach nicht zu den Konzepten einer imperativen Sprache passt. Wäre genauso, als wollte man mit einem sequentiellen Prozessor eine Schaltung simulieren, wie es mit Ladder Logic gemacht wird, was auch mit Einschränkungen bezüglich des Timings verbunden ist, so wie SystemC wahrscheinlich mit Einschränkungen bezüglich der Programmgröße leben muß.

Xilinx und Altera bieten auch freie Software dafür an, zumindest "frei" im Sinne von Freibier :-)

Siehe paralleles Posting.

Joerg ( snipped-for-privacy@removethispacbell.net):

Das käme sicher viel besser...

Sagte ich doch, das Problem hat man, wenn die Maschine nicht autark laufen kann. Einer der Faelle: Netzwerkausfall wegen Wassereinbruch. Da nutzt auch Redundanz nichts, das lief einfach ueberall rein.

Lutz Schulze ( snipped-for-privacy@netzwerkseite.de):

Muesste hinkommen. Die Istec Anlage läuft heute noch ohne Probleme.

In article , Frank Buss writes: |> |> > Allerdings ist VHDL nix für mich. Verilog ist besser. Gibts als free |> > Software. |> |> Xilinx und Altera bieten auch freie Software dafür an, zumindest "frei" im |> Sinne von Freibier :-)

Fitter wird es immer nur vom Hersteller geben.

Was Verilog als Sprache anbelangt, wird der gute Zweigeist vermutlich auf ICARUS Verilog reflektieren -- und übersieht hierbei, daß VHDL natürlich ebenfalls frei erhältlich ist und zwar als ghdl. Spielt auch wunderbar mit gtkwave zusammen, d.h. für Simulation läßt es sich prima verwenden.

Nur an die Hardware kommen natürlich beide nicht, zumindest nicht, solange sich Xilinx und Altera diesbezüglich nicht öffnen.

Rainer

ef7fdbb4cf28f52

Hatte ich gesehen. Wie bereits gesagt: Dir ist klar, daß die C-Source extrem naiv geschrieben ist und mit aggressiv handoptimiertem Forth verglichen wird?

Forth hand-optimiert ist:

: blink begin 1 dup FIO1SET3 c! FIO1CLR3 c! again ;

Vergleichbar mit C hand-optimiert:

void blink(void){ while(1){ FIO1SET3 = 1; FIO1CLR3 = 1; } }

Anscheinend wurde in der von Dir angegebenen Diskussion nur Forth optimiert aber die C Version naiv gelassen. Du hast, wenn ich das recht seh, den IAR C Compiler ausprobiert und es kam das raus:

Ist genau der Code den ich für meine optimierte C-Source erwarten würd. Der IAR Compiler inlined vermutlich aggressiv. Kannste auch mit GCC haben.

Wie schnell (in MHz) ist der IAR generierte C-Code denn nun? Davon steht nix in Deiner Diskussion.

Ich rat mal: LPC2148 ist ARM. 40MHz? Zwei Stores, ein Branch, sollten maximal 7 Clocks sein oder so. Also vermutlich mindestens 5.7 MHz.

Kommt so hin. Das sind vermutlich 9 Clocks extra für die naive C-Source. Je überflüssigem Function-Call ca. 4 Clocks.

Wär schön wenn Du die optimierte C-Source mal vermessen könntest und wenn Du uns die Daten für die verwendete CPU gibst. 40MHz CPU-Takt?

Naja, ist ja fast gleich. Beides compiliert und nicht interpretiert.

Hängt von den Umständen ab. Ändert aber nix daran, daß Interpretation langsam ist und Forth setzt traditionell auf den Interpreter. Es geht auch anders aber dann ist dieser Vorteil weg.

Hab inzwischen selber mal nach Performancedaten gesucht:

Wie von mir vermutet: Forth interpretiert ist ca. 5 bis 10 x langsamer als optimierter Objektcode (C). Forth compiliert ist ca. 2x langsamer als C, gelegentlich auch mal schneller.

Ist soweit stimmig. OK?

Ansonsten hab ich keine Lust Sprachtheologie zu betreiben. No Contest!

Irgendwer muss diese ganzen Subventionen finanziert haben. Entweder per Umlage ueber die Jahre der Kaeufer oder war es teilweise der Steuerzahler? Da die Kosten ja laut Angaben einiger Poster danach ruckartig gefallen sind, war da nicht auch ein Absahnfaktor bei?

Am Fri, 10 Apr 2009 05:40:13 +0200 schrieb Frank Buss:

Konntest Du auch in VB schon.

"option strict on"

Diese und "option explicit on" sind in meinen Augen sowieso ein Muß.

Grüße, Thorsten

Der Vorredner ist im Irgendwo vor 25 Jahren steckengeblieben. Das hat auch etwas schönes, sich zu erinnern, wie die Welt war, noch überschaubarer, damals, das stimmt. Pascal kompilierte nach P-Code, das war Spezialistenquack, und wenn Forth dasselbe machte und offen den dazugehörigen Token-Interpreter benannte, so klang das wohl auch damals schon nach Geheimnisverrat. Und bei einfachen Endlosschleifen blieb für den Laien der Rechner stehen.

Wer Buhmänner sucht, wird überall einen finden, etwa auch bei dem Umstand, dass eine Programmiersprache so unverschnörkelt direkt konzipiert sein kann, dass plötzlich zu viele Zeitgenossen ihren Arbeitseifer zur Nachahmung der abstrakten Maschinendefinition angestachelt sehen, in den meisten Fällen leider nur mit einem Billigmodell, das dann bald in der Spielzeugkiste vergessen wird, anstatt dass sie irgendwie mehr zu einem Pool beitragen, dass mit dem Werkl etwas anderes auch getan wird als mit dem Werkl Werkln zu generieren. Das ist zwar lustig und per se bestimmt nicht verwerflich, aber über die Arbeitsökonomie fehlt es hernach womöglich an den etwas besseren Werkln bzw. an den tragfähigen, weniger trivialen Anwendungen.

Vielleicht gibt es auch speziellere Zeitgenossen, die sich vor solcher Aussicht auf Gedankenfreiheit fürchten, man könne sich dabei die Finger verbrennen oder sonstwie unter die Räder kommen, womöglich unterstellen, man wolle den in dem Betrieb rasch eingefleischten hierarchischen Strukturen die Nase zeigen, wenn es eine tragfähige Warte gibt, von der aus sich allerlei Theater im Mainstream immer wieder tatsächlich als ein ebensolches darstellt?

Parallel dazu haben dort, wo die Arbeitsökonmie härter gestrickt wird, die besseren Werkln ihre Basis von Anwendungen behauptet und sind darüber um Klassen besser geworden. Da muss man allerdings hinschauen, wenn man das sehen will, die haben noch keine Schlagwortbauchbinde aus dem Museum.

Hans-Georg Lehnardschrieb: "

Die Software-Portabilität sollte nicht das ganze Gerät incl. Hardware überdecken. Das hätte in der Tat natürlich Grenzen.

Gelegendlich sehe ich aber die Frage eines Mitlesers hier, der seinen Code präsentiert und nach Hilfe fragt. Wenn dann in der Software irgendwelche Controller-Register bearbeitet werden, kann man nur helfen, wenn man gerade auf dem gleichen Controller arbeitet. Wird dagegen der hardware-spezifische Teil von der eigendlichen Programmier-Aufgabe getrennt, dann kann im Prinzip jeder helfen, der die Programmiersprache kennt. Genau so ist das auch, wenn man sich neu in einen fremden Code einarbeiten muss.

Dirk

So eine hochgeschwurbelte Kacke schreiben nur Philosophen und Kiffer. Bei den Philosophen kann man in dem aufgeblasenen Gesülze aber wenigstens hin und wieder einen klugen Gedanken entdecken.

Also, was hast du geraucht?

Ich muß zugeben, daß in meinem persönlichen Weltbild "bezahlbar" häufig synonym ist zu "etablierter Gebrauchtmarkt vorhanden". Meine erste Anlage war neu und hat iirc gut 400 DM gekostet. Apparate stammen teilweise vom Flohmarkt, haben Wählscheiben, und kosteteten fünf Mark. Und genau da, wo ich mir schnurlose Apparate erstmals zu leisten bereit war, werde ich vom Staat enteignet -- demselben Staat der gerade meine Steuern verbrät, um das Auto, das ich mir in fünf Jahren kaufen wollte, quadern zu lassen. Angeblich ist das Verbrennen eines Fünf-Euro-Scheins strafbar. Warum sitzt Steinbrück nicht im Knast?

Ja, der sog. Inner-Interprete macht das,

Nein, ist im Prinzip nur ein Push auf den Returnstack

Nein, Unterprogramme gibt es nur (wenn überhaupt) innerhalb den primitives, falls bestimmte Code-seq. auch für anderes nützlich ist.

der Zeit mit Interpretation verbracht. Schätz ich mal.

Forth Processoren benötigen nur 1 Tcyclus pro Verschachtelung und braucht nur ein Wort mit Addressinhalt. Vergleich das mal mit einem CALL subroutine und der gesamten push und pop für die Parameterver/ent Sorgung des Stacks in C. Dann kommst Du vielleicht dahinter, warum Forth Programme garnicht soooo langsam sind, wie Du meinst.

In Instruktionen ist das schwierig auszudrücken. Das eigentliche primitive beim 8031 braucht da nur den setb/clrb und ret, also 2 Instruktionen. Wenn Du es aus dem Outer-Interpreter aufrufst, muss das Dictionary abgesucht werden um die Addresse dieser Routine zu finden, denn Du möchtest sie ja beim Namen rufen.

Wird das innerhalb einer Liste abgearbeitet, muss diese Addresse aus der Liste geholt werden und angesprungen werden. Beim 8031 vielleicht 8 Befehle, da der sehr schlecht mit Pointer arbeiten kann. Für einen PC sind das ein pop irgendwas inc IP und ein push irgendwohin. Auch nix dramatisches, vor allem wenn man das mit einem CALL vergleicht.

Wenns Dich wirklich interessiert (glaube eher nicht) dann schau wegen mir in die Quellen vom gforth, das ist recht gut auf dem PC. Es benutzt auch Optimierer... alles was Dein Herz begehrt, wenn Du sooo auf Geschwindigkeit aus bist.

Du versuchst Dich zu drehen und wenden wie ein Aal.

Egal wie, glaub weiter, dass die Erde eine C-Scheibe ist. Es macht wirklich wenig Sinn, so zu diskutieren.

Es gibt im Netz genügend benchmarks für div. Forthe sowie auch im direkten Vergleich zu C. In keinem schneidet Forth besonders ungünstig ab, häufig ist es schneller und kürzer.

EOD

Saludos Wolfgang

hihi, sag ich doch, dass Forth garnicht so langsam ist, wie Zweigeist glaubt.

Saludos Wolfgang