[forth Tagung 2008] Basel-Projekt Vorschlag
Erich Wälde
Auf der Tagung hatte ich zum Thema "Projekte" was
vorgeschlagen: So 'ne Art Baukasten mit Mikrokontroller,
etwas Peripherie, Assembler und Forth und was man halt so
braucht. Zusammen mit ordentlicher Doku und ausgearbeiteten
Beispielen geeignet für Schüler AG oder Volkshochschulkurs.
Das ganze soll dazu dienen, Jungvolk mit dieser Welt des
Bastelns vertraut zu machen, und auf längere Sicht daraus
auch Nachwuchs für die Forth Gesellschaft zu ziehen.
Die daran anschließende, längliche Diskussion will ich hier
nicht wiedergeben, sondern lediglich meine Gedanken mal so
auftüpfeln, daß sie als Diskussionsgrundlage ergeben.
Jetzt, nachdem ich's aufgeschrieben habe, bin ich mir gar
nicht mehr so sicher, ob ich das wirklich lostreten will :-)
Michael Kalus: kannst Du das bitte in's Wiki aufnehmen? Danke.
Schöne Pfingsten!
Erich
-----------------------------------------------------------
Motivation
~~~~~~~~~~
1.
Meiner (manchmal nicht so) bescheidenen Meinung nach wird
der Verein nur auf Dauer überleben, wenn wir es schaffen,
neue Leute anzuwerben, v.a. Jungvolk. Das betrifft auch die
Beiträge zur Vierten Dimension.
2.
Elektor. Ich hatte mal mit dem Herrn Krempelsauer eine
Diskussion. Da hatte ich mich beschwert, daß man bei Elektor
zu wenig auf das Baukastenprinzip achtet. Da macht einer was
mit einem AVR und einem Sensor X. Ein anderer macht was mit
einem PIC und einem Sensor Y. Es ist völlig unmöglich, aus
den Artikeln zu lernen, wie man Sensor Y an den AVR
anschließt. Software immer zum Runterladen, nie (selten?)
ein Flußdiagramm und eine Beschreibung, aus der man das
nachbauen könnte. Ein Graus.
Ähnliches Problem ist die Windowslastigkeit. Mir tät ja ein
kleiner Kasten reichen, in dem kurz beschrieben wird, ob das
Projekt auch unter Linux geht, und wenn ja, wo man nachlesen
kann. Das wär ja schon mal was.
Gebracht hat die Diskussion m.E. nichts. Aber ich verstehe
inzwischen besser, wie die ihr Heft machen, und daß sie m.E.
gar nicht in der Lage sind, das Baukastensystem
einzufordern, oder zu leiten, oder herzustellen.
Ziele
~~~~~
Wenn man nun mit Hilfe der Forth Gesellschaft ein Projekt in
die Wege leiten würde, was wollte man damit erreichen?
1. Die Schar der Bastler erreichen und vergrößern, klarer
Fokus auf Jugendliche (oder Kontroller-Unbedarfte)
2. Dadurch Nachwuchs (nicht nur) für Forth (Gesellschaft)
ziehen
3. Einen Einstieg in diese Bastelwelt anbieten, mit einer
gewissen Anleitung
4. Was immer es ist, es muß unter Windows und Linux und
MacOS funktionieren.
5. Material erarbeiten, welches für einen Volkhochschulkurs
oder eine Schüler AG geeignet ist:
+ nachbausicher --- bedrahtete Bauteile!
+ billig ---
+ modifizierbar --- Platz mit Lötaugen etc.
+ quelloffen --- Schaltung und Layouts frei verfügbar
Hier fehlen bestimmt noch Dinge, zumal ich mir diese Frage
nie so richtig gestellt hatte.
Zutaten / Produkte
~~~~~~~~~~~~~~~~~~
Wenn mann's erst mal aufschreibt, dann kommt heraus, daß man
da 'ne ganze Menge Sachen braucht, bis alles zusammen ist
Hardware
--------
1. Board mit Mikrokontroller und etwas Peripherie (i2c, spi,
serial, LCD) wenn ich das JETZT zu entscheiden hätte,
dann würde ich was atmega-mäßiges nehmen. Etwas fertig
erhältliches gibt's bestimmt auch; z.B. roboternetz.de,
das RN-CONTROL Board
http://www.roboternetz.de/phpBB2/viewtopic.php?t=1877&sid=9c465dabaea45a437fab7b22c370e762
Der Kontroller darf ruhig üppig ausgestattet sein. Denn
gleich schon wieder sparen ist doof. Das kann man später
auch noch, wenn man mal kapiert hat, wie's funktioniert.
2. (separate) Bausteine wie
. i2c -- 8xIO
. 8x LED
. 8x dipswitch
. i2c ADC
. i2c Uhr
. i2c Thermometer
. einen Piepser
. 1-wire Bausteine?
. spi Bausteine?
so ähnlich wie die E-Blocks, aber billiger und zum
Selberlöten.
3. Steckverbindung mit fertig konfektionierten Kabeln oder
Pins mit immer der gleichen Anordnung zum Zusammenstecken
4. Programmierdongle --- der kann als erstes Übungslötobjekt
herhalten Da gibt's dann noch den usbprog
(www.embedded-projects.de), aber der ist nicht so billig
und SMD bestückt. Also schlecht für Lötanfänger. Und
außerdem gibt's noch 'ne richtig lange Latte an diversen
Programmierern für annähernd jeden Kontroller.
Software Host (Linux /Windows /MacOS)
-------------
1. assembler (avra /? /?)
2. burner (avrdude sp12 /? /?)
3. serielles terminal (minicom /hyperterminal /?)
optional: die Entwicklersuiten, die für den Kontroller vom
Hersteller bereitgestellt werden
Da kann ich nur für mich reden. Ich komme mit avra avrdude
minicom gut hin. amforth gefällt mir auch gut. Das gforth
auf dem r8c hat mir auch gut gefallen, aber der r8c aus dem
Elektorprojekt ist mir zu klein.
Software Target
---------------
1. assembler, kommt quasi mit. Das muss auch m.E. als erstes
vorgestellt werden, damit man sich in den Datenblättern
zurechtfindet, und damit man Schritt 2 verstehen und
gehen kann.
2. Forth (amforth /? /?)
amforth konfigurieren (z.B. Frequenz), übersetzen, äh
assemblieren und auf den Kontroller bringen. Dann fängt
der Forth Teil an.
3. C (gcc-avr /? /?)
4. Basic???
5. Java???
6. Other???
Meiner Meinung nach ist es sehr lehrreich, das gleiche
Problem in verschiedenen Sprachen zu lösen, um die
Vor-/Nachteile der Sprachen kennenzulernen, um zu lernen,
daß viele Wege zum Ziel führen. Und ich finde es auch nicht
schlimm, wenn sich jemand danach für C oder etwas anderes
entscheidet. Ich wünsche mir da auch geeignete Beispiele,
die klein genug sind, aber über das Hello-World LED Blinken
hinaus gehen.
Dokumentation
-------------
1. Ordentliches Handbuch
. wie installiert und testet man die erforderliche sw
. wie nimmt man das board in Betrieb (Assembler Beispiel)
. wie konfiguriert man ein amforth und bringt es auf den
Kontroller
. Verweis auf Datenblätter
. wo/wie bekommt man Hilfe, weitere Anleitungen
. Projektegalerie?
2. eine längere Reihe von ausgearbeiteten Anwendungsbausteinen
. Zeit messen, Uhr, Kalender
. Sensoren für alle Lebenslagen aus den Bereichen
. . Wetter: Temperatur, Luftdruck, rel. Luftfeuchte,
Windgeschwindigkeit, -richtung, etc.
. . Robotik: Abstands-/Berührungssensoren, Licht,
Motordrehzahl, etc.
. . ...
. Datenübertragung: Wie redet man mit anderen Bausteinen
(i2c, spi, seriell, infrared, bluetooth, LAN, DCF
Zeitzeichenempfänger ...)
. Anzeige: LED, LCD
. Aktoren: Schaltrelais, Servo-/Schritt-/DC-Motoren ...
. Steuerung: z.B.: wenn's regnet soll's Dachfenster
zugefahren werden.
. Regelung: Wie funktioniert eine Regelung? Wie
programmiert man so etwas?
Das ist ein sehr großes Feld, und es wäre wahrscheinlich
schlau, etwas auszusieben, was die Zielgruppe besser
anspricht, zumindest am Anfang.
3. Übersetzungen von Datenblättern??? Oder könnte man dem
Jungvolk an dieser Stelle auch das Englisch lernen
schmackhaft machen???
Mögliche Rolle der Forth Gesellschaft e.V.
Was haben wir damit zu tun?
1. Den Baukasten zusammenstellen
2. Die erforderliche Dokumentation inclusive der
Anwendungsbeispiele erstellen
3. Platinen/Bausätze zusammenstellen und ggf. vertreiben
4. selber Kurse geben, sowohl an Jugendliche, als auch an
Lehrer, oder solche die es werden wollen
5. dann braucht's da ganz schnell 'ne online Präsenz und
Forum
Fragen zur Diskussion:
~~~~~~~~~~~~~~~~~~~~~~
1. Sind die o.g. Ziele plausibel? Fehlt was?
2. Ist so ein Projekt überhaupt geeignet, die o.g. Ziele
prinzipiell zu erreichen?
3. Gibt es längst geeignete Projekte, die wir "nur" mit
Forth "infizieren" bräuchten, um eine größere Gruppe
Leute zu erreichen? z.B. Arduino board, Make controller,
Asuro ...
4. ist "nachbausicher, billig, modifizierbar, quelloffen"
erstrebenswert? Gibt es Alternativen?
5. Welche anderen hw / sw Komponenten kämen evtl. noch in
Frage? Welches wäre Dein Lieblingskontroller für so ein
Projekt?
6. Was kann jeder einzelne realistisch beitragen?
7. Welche Gelegenheiten zur "Vermarktung" der Idee gibt es?
Marcel Hendrix
> Fragen zur Diskussion:
> ~~~~~~~~~~~~~~~~~~~~~~
> 1. Sind die o.g. Ziele plausibel? Fehlt was?
Vielleicht koennte man 8052-ANS-Forth oder BYTE-FORTH
( http://www.forth.hccnet.nl/apps/bbs/ ) dafuer benutzen.
-marcel
Frank Buss
> 1. Board mit Mikrokontroller und etwas Peripherie (i2c, spi,
> serial, LCD) wenn ich das JETZT zu entscheiden hätte,
> dann würde ich was atmega-mäßiges nehmen.
Ich finde die at91sam7-Serie von Atmel recht interessant: Hat viele IOs und
Schnittstellen wie I2C, SPI, AD-Wandler usw., viel Speicher, ist schnell
und kann in-system per USB oder seriellem Port programmiert werden, da
schon ein Bootloader integriert ist, oder auch per JTAG und man kann
darüber auch debuggen. Gibt da auch schon fertige kleine Boards, z.B. hier:
http://www.olimex.com/dev/sam7-h256.html
Bei Sparkfun kostet das allerdings $45.95, was für die angedachte
Zielgruppe, Schüler und Bastler-Neulinge, vielleicht schon ein wenig zu
teuer ist. Eine fertige Lösung statt selberlöten ist aber schon sinnvoll,
damit die Neulinge nicht gleich die Lust verlieren, wenn der Controller
nach dem zusammenlöten nicht läuft. Und man kann dann auch moderne
SMD-Bausteine nehmen.
Meine Idee wäre ein minimales Breakout-Board mit einem at91sam7 und einem
Mini-USB-Stecker. Da kann man dann alles dran anschließen, was man möchte
und könnte nach dem Baukastenprinzip LEDs, Taster usw. anschließen. Der
Atmel sollte vorgeflasht sein und sich als USB HID Gerät ausgeben, denn
dann braucht man unter Windows, Linux und Mac keinen eigenen Treiber
schreiben und kann relativ leicht darauf zugreifen. Ein Programm mit
wxWidgets bietet dann betriebssystemunabhängig einen Editor und Upload-Tool
an, mit dem man Forth- oder BASIC-Programme (für Neulinge vielleicht
einfacher) auf das System schieben kann, mit integriertem Terminal, was
über die USB-HID Schnittstelle geleitet wird und Funktionen auf dem Board,
um Zeichen zu empfangen und zu senden. Implementiert wird die Kommunikation
von einer DLL (bzw. Shared Library), womit der forgeschrittene Anwender
dann per ActiveX z.B. von Visual Basic aus sehr leicht eine Steuer- und
Regelschaltung programmieren könnte (und der sehr fortgeschrittene Anwender
per wxWidgets plattformunabhängig, z.B. mit integriertem Ficl Forth :-)
Ich bin mir aber nicht sicher, wie das Verbindungsprinzip aussehen sollte.
Eine Idee wäre wie das Olimex-Board eine zweireihige Steckerleiste. Vorteil
wäre, daß man eine externe Platine, die mit einer Buchsenleiste
ausgestattet ist, einfach aufstecken kann. Nachteil ist, daß man nicht so
leicht mehrere Erweiterungsplatinen gleichzeitig anschließen könnte.
Eine andere Idee wäre, eine zweireihige Lötstiftleiste im DIL-Format
anzubringen und dann einfach auf ein Breadboard aufstecken (
http://www.conrad.de/goto.php?artikel=527819 ), wo man auch die restlichen
bedrahteten Bauteile einfach einstecken kann und andere Zusatzplatinen mit
DIL-Steckern. Da müsste man dann gar nicht löten, könnte aber dennoch
leicht einen Einstieg in die Welt der Microcontroller finden.
Schließlich wäre noch eine Idee, eine oder mehrere Klemmleisten
anzubringen, also sowas wie das hier:
http://de.farnell.com/3704671/steckverbinder/product.us0?sku=phoenix-contact-1727117
Das wäre für Experimentierzwecke wohl am universellsten und einfachsten
einsetzbar. Notfalls kann man da für eine Hello-World-Blink-LED auch direkt
LEDs und Widerstände einschrauben, oder auch Platinen mit einer gewinkelten
Lötstiftleiste anschrauben. Oder auf den Zusatzplatinen auch so eine
Klemmleiste anbringen und die Verdrahtung geht dann über Kabel, ggf. auch
mit zusätzlichen Breadboards.
--
Frank Buss, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Rafael Deliano
C anfangen und dabei zur Einsicht gelangen daß ihnen eine kryptische
lowlevel HLL genügt. Es mag auch sein daß die Leute in diesem Alter
noch an Enthusiasmus leiden und Artikel über das was sie so treiben
für VD schreiben würden.
Aber mangelnde technische Erfahrung schränkt solche Artikel
inhaltlich etwas ein. Leser erwartet entweder etwas das
unterhaltsam ist oder sein Wissen mehrt. Wenn Anfänger für Anfänger
schreiben kann wohl kaum Wissen weitergereicht werden.
Und mangelnde Schreiberling-Routine schränkt die Lesbarkeit ein.
> Elektor. ... mit dem Herrn Krempelsauer eine
> Diskussion. ... hatte ich mich beschwert,
Der ist genausowenig zu beneiden wie der Editor der VD und zwar
aus identischen Gründen.
Überigens soll die Welt mit einer weiteren Zeitschrift gesegnet
werden:
http://www.mikrocontroller.net/topic/96064
> nie (selten?) ein Flußdiagramm
Auch in der VD nicht. Hätte halt der Autor liefern müssen,
Illustrationen müssen ja in die Prosa eingearbeitet sein.
Letztlich sind eben die Leser die Autoren. Wenn ein Elektor/VD-Leser
das Problem seiner Zeitschrift sehen will muß er nur in den Spiegel
schauen.
Aus Sicht von nanoFORTH:
> es muß unter Windows und Linux und MacOS funktionieren.
Wenn sich das Forth im Zielsystem befindert und im Host nur ein
Terminalprogramm benötigt wird hat man das.
Jedoch: anno 2008 erwarten viele Anwender grafische Benutzer-
oberfläche in 4096 Farben. Eigentlichen wollen sie auch
nicht programmieren sondern nur was zusammenklicken.
> bedrahtete Bauteile
Der GP32 ist in DIL40. Aber der ist angejahrt.
Grosses DIL wird bei Freescale nichtmehr angeboten und
auch SDIP42 ist kaum beschaffbar.
> quelloffen
Ich bezweifle daß Anwender die Source eines Compilers/Systems
benötigt. Eher braucht man Handbücher und Beschreibungen konkreter
Anwendungen.
> Hier fehlen bestimmt noch Dinge,
Z.B.: 5V Betriebsspannung
Die erleichtert viele Schaltungen, aber kollidiert eben mit
aktuelleren Controllern mit viel Speicher.
> Board
Dann ist das System eben typisch nichtmehr billig. Deshalb gabs den
GP32 ja roh als IC. Da zeigte sich aber daß viele Leute nichtmal
DIL40 fädeln können/wollen.
> atmega
Wenn das FORTH im Zielsystem laufen sollte macht Harvard ( also auch
8051 ) bei der Programmierung des FLASH traditionell Probleme.
> 1. assembler (avra /? /?)
Den kann man im FORTH integriert haben.
> /hyperterminal /?)
Es gibt problemlosere Terminalprogramme. Ich habe ganze Liste
im nanoFORTH-Handbuch.
> eine längere Reihe von ausgearbeiteten Anwendungsbausteinen
Forth wird für potentiellen Anwender interessant wenn
es sich um eine Applikation handelt die nichttrivial ist.
Die Applikation färbt dann in den Augen des Interessenten
auf das Werkzeug ab. Etwas auffälliges wäre:
http://www.austrobots.com
Sowas ist natürlich von Anfänger nicht nachbaubar.
> Welche Gelegenheiten zur "Vermarktung" der Idee gibt es?
Eine qualitativ gute Projekt/Artikelserie die in der VD gelaufen
ist wäre vermutlich auch für Elektor von Interesse ( vorausgesetzt
die VD ist nicht online allgemein verfügbar ).
MfG JRD
Michael Kalus
Wie ich sehe hat dir die Forthtagung sehr gut getan, du bist noch voll
im Schwung. :-)
On 10 Mai, 12:50, Erich Wälde <ew.ng116...@online.de> wrote:
...
> Jetzt, nachdem ich's aufgeschrieben habe, bin ich mir gar
> nicht mehr so sicher, ob ich das wirklich lostreten will :-)
Stimmt alles was du so dachtest. Vom Umfang der Aufgabe her hast du
durchaus Recht wenn du das dem Bildungsminister vorschlägst. Es wäre
prima solche gut ausgearbeiteten Materialien für den Unterricht an
Schulen samt zugehörigem Curiculum zu haben. Im Verein bewältigen wir
das aber nicht, da fehlt uns jeder Einfluss, und die nötige manpower
sowie das Geld dazu. Eine Platine ist schnell gemacht, der Rest aber
nicht.
Ich bin daher der Meinung nur da was beizutragen, wo ich es persönlich
auch sofort umsetzen kann. Das ist derzeit mal ein Beitrag für die VD,
dann was für das forth-ev wiki. Oder mal Butterflys besorgen für
jemanden der sich gerade dran macht Forth darauf zu studieren. Sowas
direkt praktische halt.
...
> Michael Kalus: kannst Du das bitte in's Wiki aufnehmen? Danke.
Hm, ich verstehe das wiki als Sammlung von Ergebnissen. Damit man
darin nachsehen kann, was jemand schon gemacht hat. Also Quellen.
Ich finde deine Vorschläge sind hier im Forum gut platziert. Hier
bekommst du Antworten, formt sich aus deinen Überlegungen vielleicht
ein Projekt, findest du hoffentlich auch andere Begeisterte und ihr
könnt loslegen.
Viele Grüße, Michael
Michael Kalus
On 10 Mai, 19:59, Rafael Deliano <Rafael_DelianoENTFER...@t-online.de>
wrote:
...
> Aus Sicht von nanoFORTH:
...
> > bedrahtete Bauteile
Hm, da fällt mir ein: Gibts da eigentlich von Dir ein Board das die FG
ankaufen und in ihren Mikrocontroller-Verleih nehmen könnte?
Viele Grüße, Michael
Rafael Deliano
Adapterboards:
http://www.embeddedforth.de/GP32/GP32boards.html
Dienen zur schnelleren Realisierung gefädelter Breadboards:
http://www.embeddedforth.de/temp/breadboard.pdf
Ist eine Anschaltung für ein HP Barcode-IC.
Links ist vertikal ein handgeätztes Stromversorgungsboard.
D.h. ein System für Leute die sehr viel Breadboards bauen. Nicht
speziell auf das ominöse Jungvolk zugeschnitten.
> Mikrocontroller-Verleih
Ohje, der Forth-Friedhof.
Dessen Popularität leidet darunter, daß rohe Einplatinencomputer
ohne irgendwelche Anwendungsschaltungen nichts tun. Man kann
natürlich irgendeine Demoapplikation dazubauen, aber viel bessert
sich damit nicht.
Letztlich sah das Konzept ehedem erfolgversprechend aus weil es das
Testen von kommerziellen, relativ teueren Produkten ermöglichte
bevor man sie kaufte. Bei den heutigen billigen Systemen ist das
nichtmehr nötig.
MfG JRD
Rafael Deliano
> Schulen samt zugehörigem Curiculum zu haben.
ausbildung in der Industrie ) durchaus Budgets. Aber da ist die
Anforderung daß das Zeug mainstream ist. Vgl. Asuro:
Controller AVR weil populär, Programmiersprache C weil populär
( wenns Fortan IV auf Controllern gäbe würden Hochschulen das nehmen ).
Das gilt auch für Anfänger der eigenes Geld auf den Tisch legt: es
soll risikoarm sein also das was alle anderen auch machen.
FORTH also Nischensprache wäre eher in Nischenapplikationen
etablierbar, z.B. nur Roboter.
MfG JRD
Frank Buss
> Das gilt auch für Anfänger der eigenes Geld auf den Tisch legt: es
> soll risikoarm sein also das was alle anderen auch machen.
Das wird ein Grund sein. Aber Forth ist auch schwieriger zu lernen, als
z.B. Basic. Von der Syntax her wird es wohl derselbe Aufwand sein, wenn man
unvorbelastet daran geht, also Funktionen/Wörter definieren, Postfix/Prefix
usw., aber Forth verlangt eine hardwarenahere Programmierung, da man
verstehen muß, was HERE, @, ! usw. bedeutet. Basic ist dagegen
eingeschränkter, aber programmiererfreundlicher für Einsteiger.
Aber welche Sprache man auf so einem Board implementiert ist erstmal
unabhängig von der Konstruktion. Man kann ja später mehrere anbieten: Forth
für den hardwarenahen Programmierer und Basic für den Einsteiger, der die
LED blinken lassen will, ohne sich viel mit der Hardware auseinandersetzen
zu wollen, um erstmal einen Einstieg zu haben und nicht alles auf einmal
lernen zu müssen.
Rafael Deliano
Allerdings fangen Leute heutzutage mit Pentium statt KIM1 oder AIM65
als erstem Spielzeug an, lernen also keinen Assembler.
Insbesondere auf 8/16 Bit Controller muß man aber den Assembler können,
da FORTH selbst nicht rasend schnell ist und kritische Teile deshalb
in Assembler eingebunden werden.
> Aber welche Sprache man auf so einem Board implementiert ist erstmal
> unabhängig von der Konstruktion.
Wenn a la Crosscompiler die Interaktivität von FORTH verlorengeht
bestehen kaum noch Vorteile gegenüber C.
Es ist auf kleiner CPU wie schon im thread gesagt so, daß man mit
Harvard typisch Probleme hat ein System zu realisieren das
ASCII-Source direkt ins Flash compilieren kann. Man kann natürlich
auf einer Harvard-CPU ein Bytecode-System realisieren. Aber dann
scheitert Anwender eben an der Rechenleistung wenn er echte
Applikation realisiert.
MfG JRD
Frank Buss
> Insbesondere auf 8/16 Bit Controller muß man aber den Assembler können,
> da FORTH selbst nicht rasend schnell ist und kritische Teile deshalb
> in Assembler eingebunden werden.
Es gibt auch optimierende Forth Compiler, da sollte es dann nicht langsamer
sein, als direkt in Assembler programmiert.
Ein guter Ansatz für Programmierneulinge, aber auch für Hardware-Leute, die
sich nicht lange mit Software herumschlagen können oder wollen, könnte ein
Basic sein, was sehr direkt in Assembler umgesetzt werden kann und viele
fertig verwendbare Funktionen zur Verfügung zu stellen, z.B. wie hier zu
sehen:
Das geht natürlich auch mit Forth, aber wie du schon geschrieben hast, die
meisten Leute haben heute keine Assembler-Erfahrung und da lernt man
leichter Basic.
> Wenn a la Crosscompiler die Interaktivität von FORTH verlorengeht
> bestehen kaum noch Vorteile gegenüber C.
Der Verlust der Interaktivität folgt nicht zwangsläufig aus der Verwendung
eines Crosscompilers, was die Forth-Systeme von MPE und SwiftX beweisen.
Wird natürlich ein wenig komplexer das ganze.
> Es ist auf kleiner CPU wie schon im thread gesagt so, daß man mit
> Harvard typisch Probleme hat ein System zu realisieren das
> ASCII-Source direkt ins Flash compilieren kann.
Da würde ich CPUs nehmen, die auch direkt aus dem RAM Code ausführen
können, wie bei Atmel-Prozessoren möglich. Im Prinzip sehe ich aber auch
keine Probleme, direkt ins Flash zu compilieren. Viele PICs der 18'er Serie
oder 8051 Derivate können z.B. das Flash per Programm zur Laufzeit ändern
und überleben Millionen von Schreibzyklen.
Rafael Deliano
> langsamer sein, als direkt in Assembler programmiert.
ist Optimierung oft technisch nicht möglich bzw. würde die
Compilierzeit ungünstig beeinflussen. Letztere bestimmt in so einem
System die Akzeptanz durch den Benutzer deutlicher als 20% schnellere
Geschwindgkeit der Applikation.
Man sollte auch berücksichtigen, daß C den erzeugten Code
optimieren kann, weil man ihm dafür eine Menge Informationen für die
Datentypen eintippt. Aus dem Grunde gibts aber eben auch kein echtes
interaktives C.
> ein Basic sein, was sehr direkt in Assembler umgesetzt werden kann
das man nicht selber für die Entwicklung von Applikationen einsetzt
und dadurch verifiziert daß es als produktives Werkzeug brauchbar ist.
> Wird natürlich ein wenig komplexer das ganze.
Das ist eben der Knackpunkt: der Markt für FORTH-Compiler ist nicht
sehr üppig entwickelt. Also darf ich als Anwender den Compiler selber
entwickeln und pflegen und auf neue Controller portieren. Da tue ich
gut daran ihn klein zu halten, d.h. unbenötigte Features zu vermeiden.
> Da würde ich CPUs nehmen, die auch direkt aus dem RAM Code ausführen
> können, wie bei Atmel-Prozessoren möglich.
Das ist bei Harvard ( 8051, AVR ) aber typisch nicht der Fall.
> überleben Millionen von Schreibzyklen.
Behauptet das Freescale-Datenblatt auch bis mans ausprobiert und
das Kleingedruckte liest. Praktisch muß der GP32 nach ca. 100
Compilierzyklen per Mass-Erase komplett gelöscht und neu
programmiert werden weil das FLASH muckt. FLASH ist kein EEPROM.
MfG JRD
Frank Buss
>> ein Basic sein, was sehr direkt in Assembler umgesetzt werden kann
> Ich bin immer skeptisch ob man Leuten etwas verkaufen kann bzw. soll
> das man nicht selber für die Entwicklung von Applikationen einsetzt
> und dadurch verifiziert daß es als produktives Werkzeug brauchbar ist.
Würde ich für mich nicht ausschließen :-) Ich mag zwar die Syntax von Basic
nicht, muß aber zugeben, daß man damit bedeutend schneller als in Assembler
was programmieren kann. Mit Forth habe ich noch zu wenig Erfahrung, um das
einschätzen zu können, aber die von dir angesprochende Typisierung von
Variablen, Funktionsargumenten und Rückgabewerten ist schonmal eine
Erleichterung für den Programmierer gegenüber Forth, da das zur
Compilierzeit Fehler frühzeitig entdecken kann.
Das Problem mit dem Flashen könnte man umgehen, indem man die CPU auf dem
PC simuliert. Wäre auch für Modul- und Regressionstest sinnvoll. Die
Simulation eigener Hardware könnte in derselben Programmiersprache erstellt
werden, in der man auch das Programm schreibt. Das wäre allerdings ein
etwas größeres Projekt und mit schöner IDE usw. würde das wohl Jahre
dauern, wenn man das in der Freizeit programmiert.
Matthias Trute
> Überigens soll die Welt mit einer weiteren Zeitschrift gesegnet
> werden:
> http://www.mikrocontroller.net/topic/96064
Warum wohl? Weil es schon zuviele davon gibt?
>> es muß unter Windows und Linux und MacOS funktionieren.
> Wenn sich das Forth im Zielsystem befindert und im Host nur ein
> Terminalprogramm benötigt wird hat man das.
> Jedoch: anno 2008 erwarten viele Anwender grafische Benutzer-
> oberfläche in 4096 Farben. Eigentlichen wollen sie auch
> nicht programmieren sondern nur was zusammenklicken.
Die Anwenderschar von amforth ist sicher überschaubar, aber
der Wunsch nach einer Klicki-Bunti-Oberfläche kam noch nicht
bei mir an.
>> quelloffen
> Ich bezweifle daß Anwender die Source eines Compilers/Systems
> benötigt. Eher braucht man Handbücher und Beschreibungen konkreter
> Anwendungen.
Quelloffen ersetzt nicht Handbücher. Anderslautende Meinungen habe ich
aber schon gehört ;=)
>> Hier fehlen bestimmt noch Dinge,
> Z.B.: 5V Betriebsspannung
3.3V wären besser, da z.B. SD-Cards keine 5V vertragen. Zudem
wäre es schön, den Controller zu sockeln, dann ist er schnell
mal ausgetauscht.
>> atmega
> Wenn das FORTH im Zielsystem laufen sollte macht Harvard ( also auch
> 8051 ) bei der Programmierung des FLASH traditionell Probleme.
Die muss nur *einer* lösen, der Entwickler des Kernsystems. Dem Rest
kann das herzlich egal sein; da gibt es eher schon mal Herausforderungen
aus dem Umstand, das das Dictionary eben nicht im RAM liegt, wie
vom ANS94 implizit gewünscht...
Gruß
Matthias
Rafael Deliano
des Initiators ( selbst die VD hatte schon eifrige Redakteure z.B.
Vogt ) sondern setzen auch ein schlüssiges Konzept voraus.
Das Blatt hat etablierte Kunkurrenz a la Kennzifferzeitschriften
und Elektor.
Papierversion muß finanziert werden, benötigt Leser,
stetigen Strom von Artikeln. Dafür hat man sich zwar statt
Autorenhonorar die originelle/kostensparendere Variante "Preis
für Artikel" ausgedacht. Aber letztlich gibts weniger Schreiberlinge
als zu füllendes Papier.
> 3.3V wären besser, da z.B. SD-Cards keine 5V vertragen.
Compact Flash läuft mit 5V.
> Zudem wäre es schön, den Controller zu sockeln, dann ist er schnell
> mal ausgetauscht.
Geht nur bei DIL/SDIP gut und dann ist es typisch ein 5V-Oldtimer.
> ANS94
Mit applikationsfernem Ballast geht man unter.
MfG JRD
Rafael Deliano
> was programmieren kann.
HLL erfunden worden.
> Das Problem mit dem Flashen könnte man umgehen, indem man die CPU
> auf dem PC simuliert.
Testen will man bei Controllern in Originalhardware und Echtzeit
d.h. so realitätsnah wie möglich.
Außerdem ist Simulation von kleinen aktuellen CPUs wie
dem 68HC08 mit allen Opcodes nur für Hersteller von Interesse der
das anhand von Orginalsoftware die für Entwurf verwendet wurde
einfach und präzise machen kann.
MfG JRD
Frank Buss
>> ANS94
> Mit applikationsfernem Ballast geht man unter.
Ist das nicht der aktuellste Forth Standard? Man kann natürlich noch ein
paar andere Dinge brauchen, wie Interrupt-Handling, Multithreading usw.,
aber als Basis scheint mir das gut geeignet. Ich verwende biespielsweise
Ficl aktuell für ein Kundenauftrag für ein Embedded System unter WindowsCE
und macht zumindest viel mehr Spaß damit zu entwickeln und interaktiv zu
testen, als mit C oder Visual Basic und dabei brauche ich nur die ANS94
Wörter (plus Hardwareanbindung und ein eigenes IO-Konzept in C), nicht die
objektorientierte Erweiterung oder andere Spielereien.
Frank Buss
> Testen will man bei Controllern in Originalhardware und Echtzeit
> d.h. so realitätsnah wie möglich.
Das muß natürlich auch sein, aber ich habe z.B. für ein Gerät, was ich noch
in C programmiert habe, die Hardwareschicht komplett abstrahiert und konnte
es dann relativ leicht mit einem GUI, was das LCD-Display simulierte, in
Windows ablaufen lassen und damit viel leichter die Steuerung
implementieren, mit dem Kunden besprechen usw.
Bei einigen Dingen lohnen sich auch automatisierte Tests im Stil von JUnit,
z.B. wenn man einen Algorithmus implementiert hat und den mit vielen
unterschiedlichen Testparametern oder aufgenommenen Messreihen durchlaufen
läßt und "Offline" schnell anpassen kann. Dazu braucht man allerdings keine
vollständige CPU-Simulation, aber ein Standard wie ANS94 hilft schon. So
kann ich z.B. einzelne Wörter unter Win32Forth testen und dasselbe läuft
dann (meistens) auch mit Ficl auf der Embedded Plattform.
Rafael Deliano
>> Mit applikationsfernem Ballast geht man unter.
> Ist das nicht der aktuellste Forth Standard?
Auch Forth83 war das nicht, war aber zumindest kompakter.
> unter WindowsCE
Das läuft wohl nicht auf 8 Bit CPU. Also kann man beliebig Ballast
mitschleppen.
MfG JRD
Bernd Paysan
>>>> ANS94
>>> Mit applikationsfernem Ballast geht man unter.
>> Ist das nicht der aktuellste Forth Standard?
> Ist nicht für kleine embedded Controller gedacht gewesen.
> Auch Forth83 war das nicht, war aber zumindest kompakter.
Der Standard verpflichtet ja nur, die Core-Wörter zu implementieren, und das
ist ziemlich kompakt - klar geht's noch kompakter, Vorschläge, welche
Core-Wörter man weglassen kann?. Gforth EC passt jedenfalls in
8-Bitter 'rein. Abgesehen davon sind 8-Bitter auch schon auf dem Rückzug,
denn mit heutigen Prozessen passt ein 16-Bitter wie der MSP430 oder der R8C
locker auf einen pad-limitierten Chip, und wer nicht wirklich die
Stückzahlen braucht, kann auch einen ARM nehmen.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Michael Kalus
On 11 Mai, 10:17, Rafael Deliano <Rafael_DelianoENTFER...@t-online.de>
wrote:
> Es gibt einlagig, handgeätzt ( und deshalb quasikostenlose )
> Adapterboards:http://www.embeddedforth.de/GP32/GP32boards.html
> Dienen zur schnelleren Realisierung gefädelter Breadboards:
Überschaubar einseitig, einfach anzuschließen, handlich; dass heißt
nicht zu klein. Da kann man auch selbst dran herum löten. Gefällt mir
gut.
http://www.embeddedforth.de/temp/breadboard.pdf
> Ist eine Anschaltung für ein HP Barcode-IC.
> Links ist vertikal ein handgeätztes Stromversorgungsboard.
> D.h. ein System für Leute die sehr viel Breadboards bauen. Nicht
> speziell auf das ominöse Jungvolk zugeschnitten.
Aha, ok. Wie verbindest du deine CPU-Karte mit dem Breadboard? (In dem
Bild scheint die nur aufgelegt, demo-halber nehme ich mal an)
Pinleiste an den herausgeführten Leitungen in Sockel darunter nehme
ich mal an, oder?
Und was ist das für ein Chip in der Mitte des gefädelten Boards?
Oder verstehe ich da was falsch?
> > Mikrocontroller-Verleih
> Ohje, der Forth-Friedhof.
Ich weiß gar nicht wie der so frequentiert wird inzwischen.
Michael
Michael Kalus
On 11 Mai, 10:17, Rafael Deliano <Rafael_DelianoENTFER...@t-online.de>
wrote:
> Adapterboards:http://www.embeddedforth.de/GP32/GP32boards.html
Deiner hompage ist gut zu entnehmen wie du die einsetzt. Programmiert
wird der Controller einmalig per Programmiergerät mit dem nannoFORTH,
und ab da kann dann via Terminal die Applikation im Controller selbst
angelegt werden?
Das Programmiergerät scheint auch nicht sehr aufwändig zu sein und
wird über eine serielle Schnittstelle bedient?
Grüße, Michael
Rafael Deliano
Fläche geht kaum in Kosten ein also klebt man nicht an SMD und
Briefmarkengrösse.
> Wie verbindest du deine CPU-Karte mit dem Breadboard?
Hier sieht mans etwas besser:
http://www.embeddedforth.de/temp/digbb.pdf
Auf der Lötseite werden die teueren Buchsenleisten
Conrad 735000-62 verwendet, sodaß man auf dem Lochrasterboard
billige Stiftleisten verbauen kann.
> Und was ist das für ein Chip in der Mitte des gefädelten Boards?
HP hat ehedem 8051 mit Masken-ROM als Decoder für Barcodelesestifte
angeboten:
http://www.embeddedforth.de/temp/hp.pdf
MfG JRD
Rafael Deliano
> Controller selbst angelegt werden?
inzwischen auch mit den unbestückten Boards, habe ich genug rumliegen.
Bedienung erfolgt vom PC aus mittels Terminalprogramm. Source
wird im Klartext hochgeladen, sofort compiliert und ins FLASH
gespeichert.
> Das Programmiergerät scheint auch nicht sehr aufwändig zu sein und
> wird über eine serielle Schnittstelle bedient?
Ja. Die Software kann man sich nach Registrierung
kostenlos von P&E runterladen. Quasi die von Freescale
ehedem offizielle kostenlose Lösung für 68HC08.
Das Programmiergerät wird erst benötigt wenn nach vielen
Programmierzyklen oder bestimmten Bedienungsfehlern das FLASH
nichtmehr mag. Dann wird es komplett gelöscht und das System neu
einprogrammiert. Keine bleibenden Schäden.
Das Problem mit der V24 ist, daß sie langsam ist. Die nächste
IC-Generation von Freescale hat deshalb ein BDM-Inteface. Das ist
Schachtel $30 (?) die typisch an USB hängt. Es gibt zwar hochoffizielle
billige BDM-Lösungen von Freescale a la Spyder wie er mal in Elektor
angeboten wurde. Das ist aber eher verkrüppelter Müll. Letztlich
fliegen die Bastler bei Freescale raus.
Ich kann mir die BDM mit einem GP32 an V24 machen.
MfG JRD
Michael Kalus
wrote:
> > dass heißt nicht zu klein. Da kann man auch selbst dran herum löten.
>
> Das ist der Vorteil von selber geätzt statt Board gekauft:
> Fläche geht kaum in Kosten ein also klebt man nicht an SMD und
> Briefmarkengrösse.
Vor allem wenn die Augen langsam nachlassen so wie bei mir
inzwischen! ;-))
Danke für die Ausführungen. Michael
Frank Buss
> Hier sieht mans etwas besser:
> http://www.embeddedforth.de/temp/digbb.pdf
> Auf der Lötseite werden die teueren Buchsenleisten
> Conrad 735000-62 verwendet, sodaß man auf dem Lochrasterboard
> billige Stiftleisten verbauen kann.
Die Buchsenleisten sehen so aus wie die, die ich mal von Reichelt gekauft
habe:
http://www.reichelt.de/?;ACTION=3;LA=2;GROUPID=3221;ARTICLE=73677
Die Abbildung stimmt nicht, so sehen die in Natura aus:
http://www.frank-buss.de/tmp/buchsenleiste.jpg
Oder das Datenblatt ansehen. Den einzigen Unterschied sehe ich im Preis:
Bei Conrad kosten die, auf die Pinanzahl raufgerechnet, mehr als dreimal
soviel.
Rafael Deliano
> Reichelt
Sind technisch unterschiedlich.
Die von Conrad ( Hersteller ist http://www.fischerelektronik.de )
haben Kelchkontakte wie für ICs aber eben passend für übliche Stift-
leisten. Damit mehr Steckzyklen, wenig Kontaktprobleme, auch
problemlos trennbar.
Die von Reichelt sind ein gestanztes Blech. Entsprechend
Kontaktprobleme wenn man sie mal verkantet gesteckt hat.
Deshalb verwende ich die für ein Breadboard-Controllermodul lieber
nicht. Ich verbaue sie aber in anderen Anwendungen wo wenig
Steckzyklen zu erwarten sind.
MfG JRD
Rafael Deliano
Nachdem wohl Ende Diskussion ist kann man ja zusammenfassen:
* Nochmalerfindung von C-Control u.ä. "aber mit Forth" ist wenig
praktikabel weil teuer.
* Ein ideologisch motiviertes System das auf keinen realen Markt
zielt ist nicht erfolgversprechend. Das ist so ein Produkt wie
die VD.
* C-Control kann einen allgemeinen Markt erreichen, weil der
Anbieter das Vertriebssystem hat.
* Spezielle Systeme a la RN-CONTROL für Roboter können mit einiger
Mühe auf Vertriebsseite zumindest diesen Nischenmarkt erreichen.
Ob der groß genug ist wird sich zeigen.
Eine semiindustrielle Nische die bei kleinen Stückzahlen
höhere Kosten trägt kann auch interessant sein.
* man könnte sich wie gesagt eine Nische in der Nische suchen.
Müsste aber eben "spektakulär genug sein" ( vgl den Vorschlag
zu Biped ) um zumindest Interesse zu wecken. Stückzahlen bewußt
im Bereich 1-5 Stück. Letztlich Demosystem.
* Bestehende HW auf FORTH umzustricken ist oft/meist nicht
praktikabel
* wenn FORTH komplett im Zielsystem laufen soll gibt es
Mindestanforderungen an verfügbares FLASH, RAM,
ob das FLASH einfach aus Applikation änderbar ist usw.
* Es gibt nicht für jede CPU ein FORTH. Und eine ordentliche
Portierung ( incl. Handbuch, Assembler ) auf neue CPU lohnt
sich nur sporadisch.
* Soweit es überhaupt Leute gibt die mit Forth noch aktiv sind hat
offensichtlich jeder eigenes Forth-System, eigene CPU, eigene
Vorstellung von Hardware.
Sollte es jemals irgendwas kooperatives geben, dann wohl nur
als Multiprozessorsystem wo unterschiedliche Baugruppen z.B.
über SPI-Bus zusammenhängen.
Das kann z.B. irgendein Roboter-Monster sein der ausser Motoren
diverse Sensoren, Spracheingabe/ausgabe u.ä. Funktionen hat.
Das kann eh nur ein Demosystem sein, da man bei den
Randbedingungen keine technisch/ökonomische optimierte Lösung
erhält.
MfG JRD