es gibt eine Menge Programmierhilfsmittel. Leider fand ich bisher nichts Geniales außer das HP-Basic, das heute scheinbar nur noch einen geringen Stellenwert besitzt. HP-Basic: + extrem stabil + rasch etwas zu schreiben + hält bei Fehlern an, beheben und weiter mit Continue + Interpreter und Compiler + sehr gute Bibliotheken - recht teuer auf PC (HT-Basic) Visual Basic: - buggy - teilweise umständlich und problembehaftet - keine rasche Portierung nach C + rasch eine schöne Oberfläche machbar + das freie Gambas verfügbar -> Linux Labview: + graphisch übersichtlich + sehr große Bibliothek - ziemlich teuer - kein einfacher Weg zu C-Code für kleine uC C-Interpreter + rasch etwas austesten + Variablen abfragen, ändern, dann weiter + rascher Weg zu C auf uC + Verwendung von Bibliotheken + preisgünstig - welche Bibliotheken für Graphikausgaben? - wer hat Erfahrung? Ich halte die Lösung mit dem C-Interpreter für interessant. Ich fand zu diesem Thema: PAWN embedded scripting language CH leicht wie Basic CINT C/C++ Interpreter CSL C Scripting language Hat jemand mit diesen Sachen bereits gearbeitet und kann etwas über seine Erfahrungen damit sagen?
Hi, hast du eventuell Links zu den letzten 4 Themnen (PAWN...CSL). Finde da nicht sehr viel nützliches im Netz. mfg W.K.
Hallo Matthias, wie wär es mit Python + für Windows und Linux verfügbar + Unmengen an Bibliotheken + C-Code Integration über Module möglich + Hochwertige Graphiktools wxpython + Open Source + Debugmöglichkeiten (man kann sich sogar einen eignen bauen) Python ist allerdings objektorientiert, dies kann je nach Anforderung etwas aufwendiger sein, aber hat enorme Vorteile. Eine andere Alternative wäre Lisp oder Perl, aber damit habe ich keine Erfahrung bzw. habe ich Lisp noch nie verstanden. Gruss Volly
"Python ist allerdings objektorientiert, dies kann je nach Anforderung etwas aufwendiger sein, aber hat enorme Vorteile." Python ist hybrid, wie C++ auch. Wer nicht OO will, muss sie auch nicht nutzen.
@volly: Python hört sich interessant an. Ich möchte trotzdem erstmal die Interpreter etwas näher ansehen. @W.K.: Es gibt eine Menge im Netz: The Small language. A little scripting language. Small is now called pawn. www.compuphase.com/small.htm http://www.compuphase.com/pawn/pawn.htm Die letzte Version ist 3.1.3526 (2006-03-04). Es tut sich da also noch was. Die Seite http://www.compuphase.com/pawn/pawnprojects.htm zeigt Projekte, die PAWN nutzen wie Apple iPod, programmable MP3 player/controller, Wagencontroller von Carl Schenck AG, CIZGI nutzt es zur Gebäudeautomation und Krankenhausklimatisierung. Fa. Artran steuerte Maschinen. Auch Spiele wurden damit programmiert oder von der Bedienerseite unterstützt. RemotelyAnywhere, ein PC-Fernsteuerprogramm benutzt Small als Scriptsprache und der Fenstermanager Enlightenment. * pawn is a simple, C-like, language. * pawn is a robust language with a compiler that performs a maximum of static checks, and an abstract machine with (static) P-code verification and dynamic checks. * For porting purposes, pawn is written in ANSI C as much as possible; Big Endian versus Little Endian is handled. * To suit internationalization and localization, pawn supports Unicode/UCS-4 and UTF-8, as well as codepages. The compiler can convert source code entered in a particular codepage to Unicode; it also supports source code files in UTF-8 format. * pawn is quick (especially with Marc Peter's assembler implementation and/or his "just-in-time" compiler) * pawn is small. It has been fitted on an Atmel ATmega128 microcontroller, a Philips LPC2138 (ARM7 core with 32 kiB RAM), as well as on a Texas Instrument's MSP430F1611 (MSP430 core with 10 kiB RAM and 48 kiB Flash ROM). * Documenting the source code can be done with "documentation comments"; the pawn compiler extracts those comments, combines them with information it deduces from the source code and writes an XML file that is immediately viewable (and printable) with a web browser. * pawn supports states and automatons in the language, including state-local variables. * pawn is free and it is published under the zLib license (this is a liberal license, and it allows using pawn in commercial applications). * More features... see the separate "feature page" Gruss Matthias
> @volly: Python hört sich interessant an. > Ich möchte trotzdem erstmal die Interpreter > etwas näher ansehen. Python ist ein Interpreter. Dann gäbe es da noch Lua und natürlich diverse Ecmascript-Varianten.
Auch wenn ich in Lisp nicht entsthaft entwickeln würde, ist es einen oder zwei Blicke wert. Ganz schön p*rn Daten wie auch Code und dessen Strukturen zur Laufzeit ohne Einschränkungen in irgendeiner Form zu verändern. Aber das war ja nicht deine Frage ;) Denn Lisp ist wirklich "gewöhnunhsbedürftig" (aber hald sehr mächtig, wie gesagt)
@Rolf: Danke für den Hinweis zu Python. @Mighty: Danke für den Tipp zu Lisp. @Alle: Leider scheint niemand hier PAWN und die anderen genannten C-Interpreter zu kennen. Schade, daß ich auf diese Weise nicht auf diesem Gebiet hinzulernen kann. Ich hoffte über ein paar Erfahrungen mit diesen Tools aus erster Hand zu hören. :-) Gruss Matthias
Äh, was suchst du eigentlich genau? Eine Sprache um Prototypen auf einem PC zu entwickeln, die du dann gegebenenfalls auf einen uC portieren willst? Wenn ja, was spricht dann gegen einen X-beliebigen C Compiler?
@Bartli: wie ich oben sagte suche ich etwas um + rasch etwas zu schreiben + was bei Fehlern anhält + die Möglichkeit gibt diese zu beheben + und dann mit "Continue" weiterzumachen + ohne neu zu kompilieren + ohne den Versuch neu zu starten und zeitaufwendig bis zu der Absturzstelle laufen zu lassen. C-Compiler sind ok, wenn es keine Fehler gibt. Keine Fehler gibt es aber nie. Und so stürzt jedes Prog. meist dann ab, wenn man es nicht brauchen kann - meist mit einem RunTimeError und ohne Hinweis, warum der jetzt nun auftrat und wo. Ein Interpreter hält im Gegensatz dazu an der Fehlerstelle an und erlaubt das Feststellen und Beheben der Fehlerursache und die Fortsetzung genau an der Stelle. So ist es aus meiner Sicht ein interessanter Weg. Der C-Compiler kann ggf. bei Geschwindigkeitsproblemen später immer noch zum Einsatz kommen. Bis dahin hat der Interpreter jedenfalls jede Menge Zeit und Nerven gespart. :-)
Naja, aber wenn du also etwas suchst, was Zeit und Nerven spart, dann such nicht nach einem Tool was Edit & Continue unterstützt, sondern such dir eine Sprache aus, für die du ein anständiges Unittest Framework zur Verfügung hast (ausser du willst selbst eins schreiben/portieren). Ich versprech dir, Unittests sparen Zeit und Nerven wie kaum etwas anderes.
Hallo Matthias, also ich denke die Arbeitsweise -- direkt Fehlererkennung & beheben & und weitermachen -- funktioniert nur bei den einfachen Fehlern. Wenn Du z.B. ein Feldüberlauf und Deklarationsfehler hast, fängst Du dort auch wieder von vorne an. Versuch es doch mal mit dem Ansatz von Bartli, die Testunits kosten zwar in der Anfangsphase viel Zeit, aber die Zeit bekommst Du später ohne Probleme wieder raus. Andererseits gibt es bei den Programmiersprachen try-catch-Befehle, mit denen Du auch nicht erwartende Fehler abfangen kannst, ohne daß das Programm abstürzt. Im würde die Zeit eher in ein sauberes Konzept, vielleicht mit UML, und Testunits stecken, als mich der Hoffnung eines Interpreters hingeben. Ich denke Du wirst später enttäuscht sein. Gruss Volly
> die Testunits kosten zwar in der Anfangsphase viel Zeit Ja, das ist ganz wichtig. Nur weil die ersten Versuche mit Unittesting sinnlos erscheinen (du hast das Gefühl, nicht voranzukommen, weisst nicht, wann was wie testen), nicht gleich aufgeben. Es ist gewöhnungsbedürftig. Empfehlen kann ich dieses Buch: http://www.amazon.de/exec/obidos/ASIN/0974514012/ref=pd_bxgy_text_1/303-8676151-8546658 Es beschreibt zwar JUnit, es ist aber eigentlich egal, was für eine Sprache/Testframework Kombination man benutzt. Das Prinzip ist immer dasselbe.
@Bartli, Volly: Danke für Eure Sichtweise, auch wenn Sie erst mal völlig neu und ungewohnt für mich ist und ich mir so noch wenig darunter vorstellen kann. Es gibt offenbar sehr viele verschiedene Möglichkeiten. Wenn Ihr den Interpreter nicht für so toll haltet bin ich fast geneigt eher so ein System mit dem alten HPBASIC wieder irgendwo auszugraben, mit dem ich vor 20 Jahren so rasch so gute Erfolge hatte. Da lief der Laden - viel rascher und problemloser als heute mit Labview. Das ist sicher subjektiv. Damals war ich mit der Lösung sehr zufrieden. Liebe Grüße Matthias
Meine Mess-, Steuer- und Regelaufgaben erledige ich mit Testpoint. http://www.cec488.com/index.html Lad dir das Programm runter, ist bis auf die Speicherfunktion voll funktionfähig. Zu kaufen bei KEITHLEY-Deutschland. Kostet ca.1600,-EUR. Kostenloser Support. Beliebig viele kostenlose Runtime-Versionen. Ist Objektorinetiert. Du kannst im Programm Fehlerbehandlungsobjekte einfügen. Nachteil, falls es ein Nachteil ist: Das Design ist unverkennbar Windows 3.1. Hier mal ein Anwendungsbeispiel: www.lieven-instruments.com
> Da lief der Laden - viel rascher und problemloser > als heute mit Labview. Das ist sicher subjektiv. > Damals war ich mit der Lösung sehr zufrieden. So, nun paßt garnichts mehr zusammen, was willst Du eigentlich machen. Woran willst Du Labview koppeln, wo liegen die Probleme? Gruss Volly
@Yussarian: Danke für den Tipp zu Testpoint. Es ist halt leider keine freie Software. @Volly: Zu Deiner Frage: Ich will mich nicht mit Tools herumärgern, sondern meine Anwendung rasch zum Laufen bringen und Tests machen können, wobei ich nicht viel Zeit zur Programmierung aufwenden möchte, da das Ergebnis zählt. Später kann es sein, daß mal ein C-Programm aus dem einen oder anderen Teil werden soll. Daher die Idee mit dem C-Interpreter. Zum MSP430 und Atmel AVR gibt es ja den GNU. Und die Toolkette mit dem C-Interpreter läuft wohl auf beiden Familien. Labview ist eigentlich viel zu groß und unhandlich für das, was ich da vor habe. Der Pluspunkt ist, daß es wohl eine Light- Variante geben soll und eine Linux-Variante gibt. In Richtung C auf uC ist es aber wohl eher ungeeignet.
hi, ich mache solche tests immer auf 'nem normalen pc mit dem ollen visual studio 6. der c-compiler (im gegensatz zum c++ compiler) ist sehr gut. es kompiliert/linkt rasend schnell und man kann prima debuggen (source-level). vorteil: bis auf hardware-spezifische sachen kann man den c-code fast 1:1 übernehmen und man hat keine downloads zum target. z.b. habe ich auf diese weise einen prism2-kompatiblen wlan-treiber geschrieben, der jetzt in einer embedded umgebung eingesetzt wird. zugriffe auf die hardware mache ich über makros. die werden je nach umgebung zu den richtigen api-aufrufen bzw i/o port zugriffen.
Und eines sollte man auch mal sagen: Mit einem guten Debugger kannst Du fast dieselben Dinge machen, die Du auch mit einem Interpreter machen kannst. Zumindest die Dinge, die in einem Program noch relativ gefahrlos geändert werden können, während das Program läuft. Variablen anschauen, überwachen, neue Werte zuweisen. Point of Execution umsetzen, Return Stack anschauen (Wichtig für die Frage: Woher ist die Funktion eigentlich aufgerufen worden), im Stackframe in der Aufrufhierarchie zurückgehen und dort Variablen anschauen (ist besonders interessant bei Rekursionen, etc.). Programmcode ändern während das Pgm läuft ist sowieso immer eine haarige Sache, geht aber auch zb. mit Visual C/C++ ab 6.0 Da hat dann ein Interpreter keine wirklichen Vorteile mehr. Zumal auf heutigen Desktop-Systemen alles was weniger als 10000 Zeilen hat sowieso so schnell kompliliet wird, dass man sich noch nicht mal eine Zigarette anzünden kann.
Ein guter Interpreter hat schon Vorteile. Wenn in einem Ruby-Programm an einer bestimmten Stelle unerklärliches Verhalten auftritt setze ich einen Breakpoint, bekomme eine Interpretershell und kann an dieser Stelle mit dem Zustand des Programmes beliebig experimentieren, Programmschnipsel ausführen, Funktionen umdefinieren, Variablen ändern - all das direkt in der Sprache, ohne irgend ein zusätzliches Werkzeug.
Wenn es nicht umbedingt C sein muss, dann schau Dir mal FORTH (wikipedia)an. Ist Interpreter, Compiler, Debugger, OS in einem. Die Arithmetik ist allerdings sehr sehr sehr gewöhnungsbedürftig!
Wer programmierbare Taschenrechner von HP mag (wie den HP48), der wird mit Forth glücklich. Für anders ausgerichtete Menschen ist Forth ziemlich grässlich. (Ich weiß, wovon ich rede, mein erster "Homecomputer" war ein Forth-Rechner. Mich schaudert's noch heute)
@Rufus Kann ich gut nachvollziehen, geht mir genauso. Was aber interessant ist, ist die Realisierung bzw. die Philosophie, die dahinter steckt. Hatte damals ein echt gutes Buch über FORTH, nicht ein reines Syntaxbuch sondern wie es impementiert ist. War mal kurz davor für die C-Control 2 (C164) eine Entwicklungsumgebung unter C nach den Grundlagen (Funktionsprinzip von FORTH) zu entwickeln, d.h. Interpreter, Debugger, OS. Naturlich OHNE "umgekehrte polnische Notation" (ist nicht rassistisch, heist wirklich so). Im Prinzip sind Befehle wie "printf" nichts anderes als Forth-Wörter. Da FORTH eine stackorientierte Sprache ist, läst sie sich leicht portieren. Im Prinzip war FORTH das erste Java (virtuelle Machine).
Das ekligste an Forth ist eben die UPN gewesen. Naja, und der Joghurtbecher mit sagenhaften 956 Bytes, die für Programme und Daten zur Verfügung standen, der war halt auch nicht gerade das gelbe vom Ei als Entwicklungssystem. Kurrzeitig hatte ich mir damals ein Forth-System namens GraForth angesehen, das auf einem Apple II lief ... die UPN hat mich dann aber erfolgreich davon abgehalten. Mehr Informationen zum Jupiter Ace (auch Schaltpläne und ein kommentiertes ROM-Listing!) gibt es übrigens hier: http://www.jupiter-ace.co.uk/
> Das ekligste an Forth ist eben die UPN gewesen. Hmm, UPN ist doch schön. Das schätze ich am meisten am HP48. > Naja, und der Joghurtbecher mit sagenhaften 956 Bytes, die für > Programme und Daten zur Verfügung standen, der war halt auch nicht > gerade das gelbe vom Ei als Entwicklungssystem. Da hab ich ja auf dem kleinsten AVR mehr ;-) PS: Schon mal in PostScript programmiert?
Da war ein Hinweis in http://groups.google.de/group/de.sci.electronics zum Thema FORTH. Wen's interessiert: http://www.forth-ev.de/wiki/doku.php/projects:r8c:r8c_forth und http://www.forth-ev.de/filemgmt/viewcat.php?op=&cid=2 MfG
Hallo Matthias, nachdem hier alle möglichen Programmiersprachen durch sind, ist Deine Ursprungsfrage eigentlich noch nicht richtig beantwortet. Wenn Du mit keiner der Programmiersprachen so richtig glücklich bist bzw. der Protierungsaufwand Dir zu gross ist, dann "baue" Dir doch eine eigene Sprache. Sprachaufbau definieren (Grammatik) und dann mit lex/yacc o.a. Parser + Sprachinterpreter einen eigenen Compiler oder Interpreter bauen. Damit bist Du flexibel und wenn Du es in ANSI C realisierst, dann ist auch eine Anpassung an unterschiedliche Platformen kein Problem. Ich habe für verschiedene Projekte, nicht nur mit Mikros, solche Steuersprachen erstellt. Ich gebe zu, dass die Einarbeitung erstmal ein bisschen Zeit erfordert, aber dann gehts leicht von der Hand und es macht auch noch Spaß :-) Gruß Volkmar
> Wenn Du mit keiner der Programmiersprachen so richtig glücklich bist
[...] dann "baue" Dir doch eine eigene Sprache.
Ist so oder ähnlich nicht auch FORTH entstanden ?
:D
@Volkmar: Danke für den Beitrag. Im Prinzip halte ich den Vorschlag für sehr gut. Nur leider habe ich die Zeit für so etwas im Moment nicht. Es sind zuviele andere Dinge neben dem Beruf zu tun. Daher hoffte ich auf die Nutzung von etwas bereits Vorhandenem. Es gibt ja eine Menge im Netz. Und ich habe sicher nicht den Überblick über die große Menge an Lösungen. Mir ist ein OpenSource-Produkt lieb, das auf Resonanz stößt, weil es da dann auch eine Zukunft geben wird. Keep it small und simple sind wichtige Ansatzpunkte. Schade finde ich, daß sich bisher niemand gemeldet hat mit konkreten Erfahrung zu meinen oben genannten Interpretern. Ch scheint nicht so übel zu sein. Und Small/Pawn wohl auch nicht. Da gibt es eine ganze Entwicklungsumgebung dazu, die nicht erst noch erstellt werden muss. Conrad vermarktet die C-Control - mit Basic. Es gab aber auch mal C für die C-Control auf dem 80C167. Ein Interpreter eben. So etwas müsste doch interessant für den einen oder anderen sein. Es sieht aber so aus, als ob eindeutig Basic die Nase vorn hat. Vielleicht ist dann Gambas für Oberflächen ein gar nicht so dummes Tool. Ich dachte an etwas wie Gambas in C. Dann kann man die Oberfläche in C machen und den Code für den uC auch. Eine Sprache für alles. Der Overhead schreckt manche wohl ab bei den objektorientierten C-Tools. Daher dann teure Ansätze wie Labview, Testpoint etc.
>> Wenn Du mit keiner der Programmiersprachen so richtig glücklich >> bist [...] dann "baue" Dir doch eine eigene Sprache. > > Ist so oder ähnlich nicht auch FORTH entstanden ? Ist so oder ähnlich nicht jede Programmiersprache entstanden?
Naja, C# z.B. wohl eher nicht. Aber sicher viele, z.B. Perl und Ruby.
Hallo Matthias, um noch mal auf Deine Eingangsfrage zu kommen. Ich habe mir die von Dir beschriebenen Sprachen angesehen. Sie sind alle ganz interessant, aber was möchtest Du konkret damit programmieren? Einen PC, eine Steuerung, einen Mikrocontroller? Ich prgrammiere gerade eine virtuelle Maschine für ein von mir entwickeltes Steuerungssystem. Die VM läuft sowohl auf einem MEGA64/128 als auch auf dem IPC von Beck, ist multitaskingfähig und ist z.Z. in Assembler programmierbar. Für die direkte Programmierung übers Netz bzw. Terminal baue ich gerade einen simplen Basic-Interpreter, könnte aber genausogut ein C-Interpreter sein, aber in Zukunft ist eher eine Anpassung an GCC geplant. Aber bis dahin gibts noch viel zu tun. Die entscheidende Frage dabei ist das Zielsystem. Nicht jede der o.a. Interpreter lassen sich einfach in einen Mikrocontroller packen, weil die Ressourcen dafür nicht ausreichen. Also, für welches Zielsystem suchst Du? Gruß Volkmar
@Volkmar: danke, daß Du auf die Frage zurückkommst. Ich habe 2 Zielsysteme im Auge. Auf der einen Seite den PC, der etwas messen und steuern soll. Und auf der anderen Seite den uC, der das Frontend darstellt, worauf der PC zugreift. Die Idee ist eine Controllerplatine zu nehmen mit AVR oder MSP430 mit ADC und DAC und diese über USB abzufragen oder Daten auf den DAC oder einen Speicher auszugeben, woraus der DAC dann per DMA arbeitet. Es gibt ja auch diese Minilabs. Die sind gut, haben aber meist nur 10bit. Mit dem MSP430 hätte ich mehr bit und mehr Flexibilität. Ich möchte durchgängig bei einer Sprache bleiben für Oberfläche auf dem PC und die Treibersoftware auf dem uC. Soweit die Idee. Vielleicht hat ja jemand Lust da mitzumachen. Bei mir wird es aber langsam gehen, weil ich noch einen Beruf habe und eine Homepage. Gruss Matthias
Hallo! Ich hab auch schon lange soetwas im Hinterkopf. Einen Teil hab ich bereits: Eine Platine mit AT89C2051 der I2C, 1wire, RTC und einige GPIO's hat. Über RS232 wird mittels einem eigenen Protokoll dann vom PC aus (Master) alles gehandhabt. Für den PC habe ich eine Klasse geschrieben (Delphi-Pascal), wo ich nur mehr sage Dev.I2CStart oder Dev.owWriteByte(x). Das Board is der Wahnsinn und hat schon viele Tests und Versuche enorm erleichtert. Geplant wäre eben noch eine kleine VM am µC gewesen, mit der man das Ding auch als kleine SPS laufen lassen kann. Was fehlt ist ist eben die ADC und DAC Komponente (habs zwar über I2C auch schon laufen, aber nicht sehr schnell). Nun zu deiner Idee: MSP430 find ich gut. USB find ich auch gut nur würde ich keine FTDI-Geschichte verwenden sondern entweder einen USB tauglichen µC oder einen USB-IC mit SPI oder so. Hab erst vor kurzen eine Post von Maxim bekommen, die da was interessantes hatte. Mit USB hab ich bereits was gemacht http://www.ime.jku.at/tusb und würde die Variante über libusb empfehlen. Das mit der Sprache wird so ne Sache sein. Kann mir nicht ganz vorstellen dass sie gleich ist für PC und µC. Was ich mir vorstellen kann ist ein kleiner universeller Befehlssatz der am µC interpretiert wird auf einer VM. Die VM kommuniziert dann über einen virtuellen Adressbus und Datenbus (im endeffekt 2 Register) mit der realen Maschine. Problem dafür ist halt ein C-Compiler. Vielleicht kenn jemand so nen universellen Befehlssatz mit VM (nicht Java oder so). Man könnte ja auch z.B. einen 8051 abbilden. Über USB wird das Programm in die VM downgeloaded. PC-Seitig einfach ne ordentliche DLL. Habs bei meinem USB-Projekt gesehen. Ne ordentliche DLL und man kann die in jeder Umgebung verwenden. Ich hab dabei versucht, nur Integer als Parameter zu verwenden wodurch es keine Typkonflikte gibt. Hoffe einige Ideen in den Raum gestellt zu haben und warte gespannt auf die Fortsetzung dieses Threads. mfg W.K.
Nachtrag: Wenn z.B. den 8051 in MSP430 virtuell nachbildet, kann man das ja auch problemlos am PC machen und die ganze Hardware mit Scroller und Leds visualisieren. Somit hat man auch die Möglichkeit das ordnetlich zu testen ohne die Hardware zu verwenden.
@Weinga-Unity: Das hört sich interessant an, was Du da machst. Der C2051 wäre nicht mein Ding und von Delphi habe ich keine Ahnung. Ich würde eben einen MSP430 favorisieren auf so einem Olimex-Board. Da ist ADC und DAC drauf. Und es gibt den GNU. SMALL/PAWN müsste da ggf. zum Laufen zu bringen sein. Die Software auf dem PC sollte auf den MSP zugreifen können. Von TI gibt es jetzt übrigens einen winzigen USB-Emulator mit vorne dran einem MSP430F2013. Das Teil kostet 20$, braucht nur 1uA im Standby und hat einen 16bit ADC an Bord. Das ist für mich so ein Beispiel für eine einfache, aber geniale Messtechnik. Es sollte möglich sein später auch von Linux aus auf das Teil zugreifen zu können. Offene SW ist schon sinnvoll.
Hallo! MSP430 kenn ich und hab auch schon viel gemacht (MSP430F149 und noch nen kleineren). Ich würde für nen externen USB Transiver tendieren mit SPI oder I2C, da man das dann auch für andere µC's verwenden kann (selbst den Code). Ich weiß net, ob SMALL/PAWN (is ja ein C-Interpreter) so ideal ist für nen Betrieb auf nen µC (so nach Gefühl). Wie schon gesagt würde ich es klasse finden, einen µC (z.B. 8051 oder auch nen abstrakten, vielleicht kennt einer einen) im MSP430 nachzubilden (sollte nicht so schwer sein). C-Kompiler gibts ja dafür und man kann prompt das Ding per Laufzeit mit nem C-Programm füttern. Debuggen auf ASM-Level sollte dann auch kein Problem sein. Ich finde auch, dass diese Lösung nicht sehr viele Resourcen vergeuden würde. Vielleicht hat SMALL/PAWN aber auch seine Vorzüge.. USB mäßig wie gesagt LIBUSB (is net Lib, dies für mehrere Betriebssysteme gibt). Meine Frage is nun, wass du eigentlich mit dem SMALL/PAWN am µC machen willst? Vielleicht mach ich über die Sommerferien ein Projektseminar an der UNI (USB-Oszi mit DSP). Da könnte ich ja einiges einfießen lassen. Aber mal sehen. mfg W.K.
@Weinga-Unity: Prima, daß Du die MSP zu gut kennst. Ich habe nichts gegen den USB per SPI. Geht vermutlich schneller. :-) Was meinst Du mit LIBUSB? Ich kann nicht viel Zeit reinstecken und mag die 8051-Struktur nicht wirklich. Daher verspüre ich im Moment nicht den dringenden Zwang zur Emulation eines 8051 unter MSP, so interessant das später zur Kostenoptimierung auch sein mag. Per Laufzeit mit einem C-Programm füttern klingt sehr interessant. So etwas würde ich wollen. Mir hat damals die Idee von Conrad mit dem C-Interpreter auf dem 167 gut gefallen. Es müsste doch möglich sein so etwas Ähnliches auch auf dem MSP hinzubekommen. Zu PAWN habe ich noch keine Erfahrung. Ich habe es mir mal heruntergeladen. Quincy heißt die IDE dazu, die beiliegt. Die Idee war einen C-Interpreter auf dem PC einzusetzen um damit rasch voranzukommen. C statt Gambas heißt das Motto. Obwohl ich gegen Gambas nichts habe. Aber Basic ist eben nicht zu C durchgängig. Wenn das Prog. auf dem PC läuft in Kombination mit dem uC können C-Teile davon schrittweise in den uC einfließen. Ob PAWN hier eine Hilfe sein kann vermag ich noch nicht zu sagen. Es gibt ja heute auch Debugger auf JTAG-Basis. Es war nur so eine Idee, daß PAWN eine interessante Lösung sein könnte, vielleicht besser noch auf dem PC. Ist Dir damit klar genug, was ich vor habe? Gruss Matthias
Hallo! LIBUSB is ne LIBRARY, mit der man USB ansteuern kann genau so, wie USB aufgebaut ist. Descriptoren lesen, EP schreiben, lesen... und nicht das Windows-Konzept, wo alles hinter einen Treiber versteckt wird und nur über CreateFile usw. kommuniziert wird. In Wirklichkeit ist LIBUSB ein Universaltreiber, den man für alle USB-Geräte verwenden kann, der aber die Schnittstelle soweit aufbereitet, dass man das USB-Konzept Programmseitig zur Verfügung hat. Intern (was mir ja egal ist) wird er auch wieder mit CreateFile usw. arbeiten. Vielleicht ist das Konzept mit dem 8051 noch nicht ganz klar geworden (kann auch AVR oder was anders sein). Man bildet den entsprechenden µC am MSP430 nach und kann mit den bereits existierenden C-Compiler für 8051 oder AVR C-Programme schreiben, kompilieren und dann in die VM im MSP430 reinspielen. Somit is es egal, ob man 8051 oder Interpreter. C ist C und die Interaktion zw. Hardware und C is meineserachtens bei der 8051 Variante gar kein Problem. Debuggen is ja dann auch easy, da man einfach die VM anzapfen kann und per USB die VM analysieren kann. Wenns mit PAWN auch schön geht, is es auch gut. mfg W.K.
@Weinga-Unity: Danke für die Info. Das klingt ja sehr interessant. Gerne würde ich da mitmachen. Wäre schön, wenn Du mich ein wenig auf dem Laufenden halten kannst :-) Gruss Matthias
Hallo! Nur um flasche Hoffnungen zu vermeiden, die Thematik beschäftigt mich schon länger, nur ob ich das je mal konkret so umsetzen werde ist die Frage da ich es bis jetzt noch nicht wirklich brauche. Schönes Wochenende noch... der Griller ruft! mfg W.K.
Hallo, na dann grill mal schön :-) Du weißt ja, wie Du mich erreichen kannst. Gruss Matthias
Hallo! Tschuldigung, dass ich wieder nen alten Thread hervorkrame, aber hab was gefunden was hier irgendwie hinpasst (im entferntesten Sinne). http://atmel.com/dyn/resources/prod_documents/DOC0592.PDF mfg Weinga-Unity
Leider kann ich dir nix zu den Interpretern sagen, nach denen du suchst. Meine Meinung zum ganzen, wenn du in C nichts wichtiges bisher geschrieben hast, dann wäre die Zeit am besten investiert erstmal solide C Kenntise aufzubauen. Es gibt ohne Zweifel bessere Sprachen als C, insbesondere auf PC (Python, Ruby, auch C++), auf uC als Platform bezweifele ich stark dass man dort ernsthafte Alternative hat. Vielleicht könntest Ada einsetzen, schützt dich aber nicht vor (deinen) logischen Fehler im Program. Und um diese geht's ja meistens(so meine Erfahrung). Gruss, Daniel
@Weinga, Daniel: Danke für Eure Beiträge. Ich habe früher einiges in C programmiert. Bin aber da kein Profi. Eine große Menge an positiven Erfahrungen hatte ich mit HPBASIC. Das war wirklich eine geniale Sprache. Schade, daß es sowas für den PC nicht als Freeware gibt. Mit dem HTBasic kann ich mich nicht so richtig anfreunden.
Was mich ja etwas wundert, ist dass bisher noch keiner c# erwähnt hat. Wenn ich auf dem PC was programmiere, dann nach möglichkeit nur noch damit. *Wird Interpretiert! *Man kann ändern und weitermachen bei Fehlern. *Mächtiges Expetionmanagement! *Direct Command Window nach break. *C ähnlich *ok sehr objektorientiert * GUIs sher einfach *mit nunit steht ein mächtiges Testingframework identisch JUnit zur Verfügung Gruß Tom
@Ziff: welche Geräte meinst Du damit? Kannst Du ein Beispiel geben? Mir geht es um einen Controller, der in der Lage ist energiesparend Sensoren abzufragen dies ggf. in einem FRAM abzulegen, einfache Berechungen durchzuführen und Ergebnisse auszugeben auf einen integrierten DAC. Natürlich gibt es vom großen "C" diese C-Control-Teile. Die wollte ich jedoch nicht unbedingt nehmen, obwohl der CC vielleicht gar nicht so übel ist. Vielleicht könnte ich den auch auf so einen MSP430 laden. Picolisp ist halt wieder eine andere Sprache. Ich bin da offen. Wenn es super geht, einfach zu verstehen, einfach zu implementieren, performanter als ein Basic-Interpreter, so soll mir alles recht sein. Ob ein Webinterface da groß weiterbringt vermag ich nicht zu sagen. Da müsste ich ja Strippen für das Netzwerk ziehen. Der niedrige Energiebedarf ist dann wohl hin. Matthias
Thomas Burkhart schrieb:
> Was mich ja etwas wundert, ist dass bisher noch keiner c# erwähnt hat.
Danke Tom. Das hört sich doch alles gut an.
Nutzt Du das selbst für Dich?
Da "Ch" schien mir auch nicht übel.
Nur ist das halt Kaufware. Wenn es
bezahlbar ist kann es besser sein zu
kaufen als ewig rumzufrickeln, wenn gratis
Sachen nicht so toll erklärt sind.
Ändern und weitermachen bei Fehlern finde
ich genial, wenn man Dinge ausprobieren
möchte. Das war ja das Schöne an HPBasic
und später Turbo C - daß man da rasch mal
was zum Laufen brachte. Wobei es bei HPBasic
eben keine run time errors gab, deren Ursache
man oft nur erraten konnte.
Matthias
Ich verwende C# schon ne ganze Weile. Hat übrigens noch so nette Features wie Runtime Type Information, d.h. Du kannst vom Programm aus informationen über den Typ Deiner Objecte erfahren. Wenn Du nur C# verwenden willst, gibt es eine abgespeckte Version von Visual Studio, die nicht viel kostet. Meiner Meinung nach ist C# derzeit die effizienteste Art Software für den PC zu entwicklen und ich hab daor 10 Jahre MFC unter C++ gemacht. gruß Tom
Thomas Burkhart schrieb: > Meiner Meinung nach ist C# derzeit die effizienteste Art Software für > den PC zu entwicklen das hört sich für mich sehr gut an. Aus der freeware Ecke wirds da nichts vergleichbar brauchbares geben nehme ich mal an. Dieses C# wird wohl nicht auf einem Controller wie dem MSP430 laufen, so nehme ich an. Für den PC ist es dann eine schöne Lösung. Dafür kann ich es ins Auge fassen. Matthias
Respekt im übrigen einen fast 4(!) Jahre alten Thread wieder zubeleben. Moment mal, Zu C#: > *Wird Interpretiert! Das stimmt so nicht. C# (wie alle Sprachen die das .net Framework verwenden, also Visual Basic.net, Managed C++, F#,...) sind, ähnlich wie Java, eine Art Mittelding zwischen Interpreter und Compiliezter Sprache. .net Programme werden in einen optimierten Zwischencode übersetzt, der dann der zur Laufzeit von der .net in Maschinencode übersetzte werden. > Wenn Du nur C# verwenden willst, gibt es eine abgespeckte Version von > Visual Studio, die nicht viel kostet. Die Express Versionen gibt es sogar komplett kostenlos: http://www.microsoft.com/germany/Express/ Und z.Z. gibt's den Release Candidate für VS 2010 ebenfalls zum kostenlosen Download: http://www.microsoft.com/germany/visualstudio/products/visual-studio/2010/
Matthias W. schrieb: > Dieses C# wird wohl nicht auf einem > Controller wie dem MSP430 laufen, so nehme > ich an. Nein, das wird es nie. Übrigens wird es nicht interpretiert, sondern in eine Zwischenbinärsprache (CLI) übersetzt, und das ganze setzt auf dem .Net-Moloch auf.
Auf einem MSP430 läuft das .net Framework soweit ich weiß nicht, aber auf einem ARM, genauer auf einem AT91SAM9261: http://www.aug-electronics.com/ami/Pictures/tabid/159/Default.aspx
Andreas Kanzler schrieb: > C# (wie alle Sprachen die das .net Framework verwenden, also Visual > Basic.net, Managed C++, F#,...) sind, ähnlich wie Java, eine Art > Mittelding zwischen Interpreter und Compiliezter Sprache. .net Programme > werden in einen optimierten Zwischencode übersetzt, der dann der zur > Laufzeit von der .net in Maschinencode übersetzte werden. Jain... natürlich erzeugt der Complier erst mal Bytecode. Dieser wird aber zur Laufzeit mehr oder weniger interpretiert. Tom
Ganz wie in alten Tagen, hieß damals "Tokenizing" am C64 ... Ja, echter Fortschritt findet sich nur bei M$ :-)
Hof fähig hat das allerdings nicht MS, sondern Sun mit dem Javabytecode. Ja, MS hat bei .net ganz kräftig bei Java abgeschaut. Aber Hauptsache auf MS schimpfen.
Und MS hat vor allem auch aus den Fehlern on Java gelernt und einiges besser gemacht. Gruß Tom
Rufus t. Firefly schrieb:
> und das ganze setzt auf dem .Net-Moloch auf.
Auf so einen Moloch aufsetzen mag ich
natürlich nicht so gerne. Viel lieber sind
mir kleine überschaubare Sachen . . .
Das CC scheint ja nicht so monsterhaft . . .
Das HPBasic passte damals auch noch auf
sehr kleine Festplatten.
Matthias
"Tokenizing" machen sehr viele BASICs. Aber was eine verkürzte schreibweise der Schlüsselworte mit Zwischensprachen zu tun haben soll? Dan schohn eher p-Code vom UCSD-Pascal http://de.wikipedia.org/wiki/P-Code ist noch älter als C64.
Thomas Burkhart schrieb: > Und MS hat vor allem auch aus den Fehlern on Java gelernt und einiges > besser gemacht. Lernen aus Fehlern ist ja von Vorteil. Wenn was Gutes am Ende dabei rauskommt . . . Ich programmiere momentan eher selten. Daher sind intuitive Ansätze natürlich zu bevorzugen. Matthias
Andreas Kanzler schrieb:
> Respekt im übrigen einen fast 4(!) Jahre alten Thread wieder zubeleben.
manchmal ist es gut ein paar Jahre auf neue
Entwicklungen zu warten. Manches wird ja besser.
Wenn es dieses HP Basic für den MSP gäbe
würde ich es sofort einsetzen wollen.
Natürlich hat der MSP nicht so viel Ram
wie damals diese HP-Workstation HP9816S,
die ja auf einem 68000 aufbaute. Statisches
RAM war damals sauteuer.
Matthias
Ein Geraet kann ein Webinterface haben und ein serielles Interface benutzen.
Dann möchte ich doch nochmal FORTH in's Spiel bringen. Es ist, nach reinem Assembler das schnellste, der Code ist sehr kompakt und die umgekehrte polnische Notation ist für den intellektuell normal Bemittelten einfach zu verstehen. (Wenn es auch, wie ich einräumen will, Gewöhnung erfordert). Es gibt auch Assembler und ein Scheduling dafür und Fliesskommarechnungen gibt es auch. Auch Tracer/Debugger sind vorhanden. Gerade wenn ein intuitiver Zugang erforderlich ist, ist FORTH ein ernstzunehmender Kandidat. Man baut auf den primitiven Worten seine eigene problemorientierte Sprache auf. Es gibt recht gute online-Texte dazu. Z.B. "Thinking FORTH" von Leo Brodie das auch Anfängern der Sprache aber auch des Programmierens insgesamt gerecht wird. Ich habe selbst FORTHs für AVR u.a. implementiert und bin davon überzeugt, das es für schnelle effiziente Problemlösungen gut geeignet ist.
Ziff schrieb:
> kann ein Webinterface haben und ein serielles Interface
kannst Du das ein wenig näher beleuchten
wo Du da meinst, daß das zum Thema
C-Interpreter zur Steuerung brauchbar wäre?
Matthias
@Grrrr (Gast) > Ich habe selbst FORTHs für AVR u.a. implementiert Bist Du bereit Deine Forth Implementierung zu veröffentlichen ? Ich würde sehr gerne mal Forth auf dem AVR ausprobieren. ( Hatte es früher auf nem 8085 und nem Z80 implementiert ) Merci Frank
Grrrr schrieb:
> Dann möchte ich doch nochmal FORTH in's Spiel bringen.
Gibt denn da Beispiele für gelungene Implementierungen
wo man sehen kann wie das zum Thema
Interpreter zur Steuerung brauchbar wäre?
Matthias
mich wundert so ein bißchen, daß auf dem Controller eigentlich immer wieder so vieles neu gemacht wird. - Gedanken um ein Minibetriebssystem oder eine Ablaufsteuerung - ADC-Routinen - DAC-Routinen - Abfrage/Entprellung Taster - Registerprogrammierung All das hält ziemlich auf. Bei den Infineon- controllern gibt es ja DAVE, der ein wenig hilft da Struktur ins Programm zu bekommen. Wer eine Messaufgabe hat möchte sich doch auf diese Aufgabe konzentrieren und nicht jedesmal das Rad neu erfinden. Wenn es da ein Basissystem gäbe auf dem ein kleiner schlanker Interpreter sitzt, so ähnlich wie die Debug-Funktionen früher bei den Motorola 68332. Bei den Oberflächen hat man ja heute Eclipse, das mehr und mehr zu einem Standard zu werden scheint. Auf dem Controller selbst jedoch vermisse ich da was . . . Matthias
Frank W. schrieb: > @Grrrr (Gast) > > Ich habe selbst FORTHs für AVR u.a. implementiert > > Bist Du bereit Deine Forth Implementierung zu veröffentlichen ? Nein. Ich verkaufe meine Implementierung im Rahmen von Aufträgen. Sie läuft auch auf ATMegas mit mehr als 64kB Flash. Es ist zwar auch geplant, das FORTH für Hobbyisten und im Quellcode für Gewerbliche anzubieten, aber ich darf hier keine Werbung machen. Aber es gibt auch quelloffene Implementierungen für den AVR. Hier http://www.mikrocontroller.net/articles/Forth sind einige genannt. Matthias W. schrieb: > Gibt denn da Beispiele für gelungene Implementierungen > wo man sehen kann wie das zum Thema > Interpreter zur Steuerung brauchbar wäre? FORTH ist in gewissem Sinne Compiler, Interpreter und OS in einem. Es verwendet Threaded-Code (siehe Wikipedia oder eben das Buch). Wenn Du Dich mit der Sprache ein wenig beschäftigst wirst Du merken, wie einfach und intuitiv solch eine Steuerung zu implementieren ist. Eine an SPS angelehnte "Sprache" lässt sich in den Grundzügen sicherlich innerhalb einer Woche implementieren. Da es so einfach ist solche Sprachen zu entwickeln sind sie aber fast immer recht spezialisiert und werden auch nicht veröffentlicht, da sie Teil des Lieferumfangs an den Kunden und damit sein Eigentum sind.
Um sich echte Codes anzuschauen ist http://www.forth.org/fd/contents.html ganz gut geeignet. Auf Deutsch gibt es auch http://www.forth-ev.de/filemgmt/viewcat.php?cid=2
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.