Einsteig in Microcontroller und Programmierung

Schade dass Du nicht erkannt hast, was man als Hardy damit machen kann. Mein Hinweis auf Mitch Bradley an anderer Stelle hier.

Such mal nach Forth Inc. Die sitzen in CA und leben nicht schlecht.

Saludos Wolfgang

Diese Erfahrungen haben diverse Leute und Firmen auch gemacht. Ich kannte einige, die die Prototypen komplett in Forth entwickelt haben und dann alles nochmal in C programmieren liessen.

Ich habe selber einen Fall gehabt, da hab ich eine Anlage, die seit 1 Jahr übern Termin raus war: "das Problem lässt sich mit heutigen Computern nicht wirtschaftlich lösen" binnen 3 Wochen in Forth komplett neu programmiert und dabei noch einige Fehler aus der HW rausgemacht.

Gut verdient dabei. Nach 1 Jahr wollten sie aber unbedingt, dass das nochmal von mir (bzw. einem MA) komplett auf TP umgeschrieben wird, da die dortigen Leute keine Lust auf Forth hatten...

Gab nochmal gute Kohle, hat ein Studie aus Aachen gemacht. Der wurde übrigens zum Forth Fan, als er gesehen hat, wie ich damals das Ding saniert habe. Merkwürdigerweise sah das Pascal Programm sehr nach Forth aus :-)

Saludos Wolfgang

Falscher Fehler, ihr hättet eine guten externen Forth Programmierer anheuern sollen, damit er als Hebamme und Kindermädchen fungiert.

Hab ich damals gemacht und bin bei Forth geblieben, als ich gesehn hab, wie und was da ging. Ich bin vorher absoluter Assembler-Hardcore Programmierer gewesen.

Nach diesen Erfahrungen hab ich mich selbständig gemacht, da der damalige AG nicht kapiert hat, wie und was da abgelaufen ist. Ich habs kapiert.

Saludos Wolfgang

Ja, Hinweis auf Forth-eV und Leihcontroller hab ich ja schon gegeben.

Egal was Zweigeist behauptet, es stimmt nicht. Forth kann man beliebig tunen, indem man nahtlos in Assembler weiterschreibt. Lohnt sich latürnich nur bei den zeitkritischen Routinen.

Forth deckt alles ab, vom Assembler über HLL bis zur Metasprache. Es ist gleichzeitig auch Betriebssystem. Ideal für begrenzte Resourcen wie embedded Controller.

Forth ist nur auf den 1. Blick langsamer, aber da die (temporären) Daten auf dem Stack verändert werden und nicht zwischen Speicherstellen von Variablen und Stack hin und her transportiert werden, so wie C es machen muss, holt Forth stark auf und es gibt genügend Beispiele, bei denen HLL Forth Routinen schneller sind als C mit seinem gewaltigen Overhead, bis die Werte auf dem Stack landen oder wieder runtergeholt werden. In Forth bleiben sie auf dem Stack und gelegentlich werden die Ergebnisse in Variablen abgelegt, falls sie noch für was interessant sind.

Saludos Wolfgang

Stimmt.

Stimmt nicht. Die Forth-eV ist aktiv.

Jein, die Forth-eV hat einiges (IIRC auch die Brodie Bücher) online.

Stimmt, aber das liegt auch an der Kompliziertheit und Fehlerträchtigkeit von C :-o

Totgesagte leben länger :-)

und für embedded controller gibt es keine bessere Umgehbung.

Chuck Moore: Keep it simple, stupid!

Saludos Wolfgang

Das hat Rafael garantiert nicht geschrieben :-)

Isset auch nicht, Forth lebt.

Probiers einfach mal. Schieb alles zur Seite, was Du bisher über Programmieren gelernt hast. Bei Forth ist praktisch alles andersrum als in allen anderen Programmiersprachen :-)

Stell Dir mal ein Programmieren ohne Klammern vor, im wahrsten Sinne des Wortes.

BTW es ist noch einfacher: Du redest mit Forth interaktiv und es interpretiert, was Du tipperst. Es schaltet automatisch in den Compilermodus um, wärend Du neue 'Worte' definierst und schaltet wieder in den Interpreter um. Wenn Du mit der Zeile/Eingabe fertig ist, ist der Code bereits compiliert.

Ist als Neuling absolut verwirrend. Ich weis bis heute nicht, ob Forth ein Interpiler oder ein Compreter ist. Lass es einfach machen, kümmer Dich nicht drum. Irgendwann klatscht Du Dir vor die Stirn und fragst Dich, warum das in allen anderen Sprachen so kompliziert ist und wie einfach, elegant und effektiv das Forth macht. Aber wie gesagt, am Anfang nicht drüber nachdenken.

Es gibt übrigens zwei ständige Interpreter in Forth, den sog. Outer- Interpreter und den Inner-Interpreter. Der Compiler ist ebenfalls integraler Bestandteil, optional Assembler, Multitasker, Dateisystem und was das Herz sonst noch begehrt. Debugger gibst auch, die meisten Forthler benötigen den aber erst garnicht, da das debuggen interaktiv eh schneller geht.

Saludos Wolfgang

Hast Du jemals irgendein Projekt über Gulp bekommen? Eventuell sogar was vernünftiges?

Ich hab immer nur Zeit mit Gulp verplempert und kenne selber auch niemanden, der mal was vernünftiges von denen bekommen hätte.

Saludos Wolfgang

"need-to-know Prinzip" sagt man scheinbar auch hier:

Ist generell sinnvoll, und für Hardwareentwicklung muß man ja auch nicht die Software im Detail kennen (umgekehrt könnte es schon eher sinnvoll sein). Wobei allerdings in großen Firmen das auch dazu führen kann, das mangels Gesamtüberblick nur suboptimale Lösungen z.B. für eine Software erstellt werden.

VB ist gar nicht so schlecht, zumindest ab VB.NET, womit man auch typsicher programmieren kann, wodurch aber die Syntax ein wenig umständlicher wird. Ab so 16 MB RAM läuft es auch auf WindowsCE Embedded Systemen sehr gut. Ist sogar so, daß ich ein C-Programm als Watchdog für das VB-Programm geschrieben hatte und dieses Programm wegen einem Fehler in der Win32-API (CloseHandle funktioniert bei CreateToolhelp32Snapshot nicht) ein Speicherloch hatte, sodaß das Gerät nach ein paar Stunden mangels Speicher merkwürdige Fehler produzierte. Solange man aber in VB.NET bleibt und keine wirklich dummen Sachen macht, wie Referenzen in Hashtables vergisst, scheint der Garbage Collector recht gut zu funktionieren und die Software läuft mittlerweile im Dauerbetrieb ohne Probleme.

Habe gerade nochmal nachgelesen: das Produkt für Microcontroller heisst SwiftX. Bei der Pro-Version ist auch ein Compiler im Target enthalten (sofern der da reinpasst). Hier ein paar Beispiele, wie gut der Code optimiert wird:

Ein C Compiler würde es wohl nicht viel besser machen.

Wichtig war mir hierbei der Systemzustand. Z.B. wenn man ein komplexes System mit Menüsteuerung hat und man führt eine Menge Aktionen durch, aber irgendwann sieht man einen Fehler. Dann könnte man in Forth z.B. Funktionen interaktiv aufrufen, um die Register eines angeschlossenen Chips per I2C abzufragen. Wenn du das in C nicht von vorneherein vorgesehen hast, dann musst du das erstmal einbauen, das Programm neu starten und hoffen, daß du den fraglichen Systemzustand wieder reproduzieren kannst.

Oder der Fehler tritt bei einem Kunden auf. Man könnte sich dann ein System vorstellen, bei dem man sich per Internet auf dem Target einloggt und im laufenden Programm den Zustand analysieren kann. Debugger sind da meist zu unflexibel.

Dann solltest du mal Forth ausprobieren, ist besser als jeder Debugger :-)

Das kann man sich leicht selbst programmieren, je nach Anwendungsfall optimiert für die Anwendung. Aber generell stimme ich dir hier zu, denn Forth lässt einem sehr viele Freiheiten, die aber auch dazu führen können, daß man mehr Fehler machen kann, die der Compiler nicht erkennt und die dann erst zur Laufzeit in Erscheinung treten. Und es macht IDE-Herstellern die Arbeit schwerer. In Java kann man z.B. wegen der sehr beschränkten Sprache viele Refaktoring-Tools bauen, die zuverlässig funktionieren, wie Umbenennen von Methodennamen. Das geht in Forth nicht so einfach, da eine IDE nicht sicher feststellen könnte, wann ein Wort eine Wortdefinition ist und wann es z.B. nur von einem anderen Wort interpretiert wird.

Die optimale Sprache gibt es sowieso nicht, hängt immer von der Anwendung und den Kundenwünschen ab.

Ist soweit ich mich erinnere nicht gerade auf embedded Controller ausgerichtet. Viele Leute träumen bequem von etwas das völlig konform und gleichzeitig besser ist. Das ist technisch nicht möglich. FORTH ist nicht mainstream. War es nie, wird es nie sein.

MfG JRD

Dann kanntest du aber andere Hersteller als ich, vor dem www war es doch immer eine Quälerei an Datenblätter zu kommen. Dass es sowas wie AppNotes gibt habe ich damals nie erfahren. Wenn man keine Firmenadresse oder Visitenkarte hatte wars doch i.a. Essig mit Datenbüchern. Ich kann mich noch daran erinnern als ich ein Buch mit Anschlussbelegungen von ICs gekauft habe. Dann hatte man zumindest mal das Pinout und konnte Vermutungen anstellen zuwas das IC gut ist. Ein Datenblatt war das natürlich noch lange nicht.

Thomas

Am Thu, 09 Apr 2009 23:18:49 +0200 schrieb Falk Willberg:

Dieser Vorteil spart sehr viel Zeit, nahezu unbezahlbar.

Ich pflege auch immer den Ruf, zwar was mit EDV zu machen von PCs aber nicht so die Ahnung zu haben.

Sonst kommt man zu gar nichts mehr.

Lutz

Forth hatte seine grosse Zeit, und IMHO zu recht, als wir alle noch mit EPROMS gearbeitet haben. Heutzutage sehe ich die speziellen Vorteile nicht mehr. Es ist lediglich eine Sprache die genauso gut oder schlecht ist wie C. Aber C ist nunmal der verbreitete Standard und deshalb nehme ich es. Ich haette es auch besser gefunden wenn sich Pearl durchgesetzt haette, aber das ist nunmal nicht passiert.

Ich benutze uebrigens eine forthaehnliche Sprache auf meinem Taschenrechner (HP48SX) dessen Namen mir leider entfallen ist. Und fuer diese Anwendung ist es genial. Weil man halt unterwegs auf dem kleinen Display mit der geringen Rechenleistung gut arbeiten kann, die Sprache aber andererseits viel schneller ist als eine interpretierte Sprache.

Ach, du musst nicht immer so auf die Geschwindigkeit rumhacken. Ich komme eigentlich nur selten mal ans Grenzen was das angeht. Heutzutage sind Controller doch immer schnell genug. Was den Punkt angeht sollten die Leute lieber von den alten 8Bit Controllern weggehen und mal was mit 16Bit oder mehr nehmen.

Olaf

Ich benutze einen debbuger recht haeufig. (gdb an 68332 ueber BDM) Aber irgendwie kann ich deine Probleme nicht recht nachvollziehen. Es ist mir noch nie in den Sinn gekommen eine Funktion einfach mal so zum Spass aufzurufen, einfach weil die Funktionen immer im Zusammenhang mit anderen Dingen stehe. Wenn ich also bestimmte Teilaspekte meines Programms testen will dann benoetige ich dafuer eine mehrzahl an Funktionen. Die gibt es auch in Form eines eigenen Debug-Menues in meinem Programm.

Olaf

Also ich hatte anno knips bei Motorola kein Problem an Daten zu kommen. Okay, wär' ich als Steppke in ner Niederlassung aufgekreuzt, hätten die wohl erstmal misstrauisch gefragt, was ich damit anstellen will, aber so war das unkompliziert: Fax hin mit ner freundlichen Frage nach Datenblättern und family guides, ne Woche später ächzte der Postbote in den ersten Stock und warf mir ein Päckchen vor die Füße. Drin waren die gewünschten Unterlagen, ein Begleitschreiben und ein Überweisungsträger, mit dem ich mich *freiwillig* an den Versandkosten beteiligen konnte.

Gruß, Florian

War etwas undeutlich, das gilt nur fuer Festplatten direkt am SATA-HA. Du verwendest aber bestimmt auch DVDs (die Laufwerke sind auch in der SATA-Inkarnation ATAPI), USB-Sticks oder externe Festplatten an USB oder FW ... und damit auch SCSI.

Micha

Vielen Dank für diese sehr plastische Darstellung der Software- Entwicklung bei "einem grossen Fahrzeug Hersteller" (Deppen- Leerzeichen absichtlich drin gelassen).

Bei derart geballter "Kompetenz" wundert es einen dann auch nicht mehr, daß gerade Fahrzeuge von großen Herstellern immer häufiger wegen unerklärlicher Elektronikfehler streiken.

XL

Ich habe einige Tage einem Postscriptdrucker Testbilder entlockt. Das hat mir gereicht.