Ich möchte das Projekt AVR BASIC zunächst als eigenen
BASIC-Interpreter mit dem Atmel Studio 7.0 kompilieren.
Es kommt jedoch zu einer Menge an Fehlermeldungen. Mir scheint es, dass
dort einige entsprechende Einstellungen im Atmel Studio vorzunehmen sind
und ich weis nicht genau wo.
Hat jemand schon dieses Projekt mit Atmel Studio 7.0 durchgeführt?
Uwe B. schrieb:> ...nur mal interessehalber --> was kommen denn so für Fehlermeldungen?
unknown type name 'PTR_TYPE' avr_basic ..tokenizer.c
recipe for target 'main.o' failed avr_basic ..avr-basic_ub\Makefile
Liegt wahrscheinlich an den oben erwähnten Einstellungen im Atmel
Studio!
Es gibt zwar im Atmel Studio 7.0 die Möglichkeit externe Makefiles
aufzurufen, aber ich kenne die Syntax vom Makefile nicht und weis nicht
genau welche Files zusammen gelinkt werden.
Beim Makefile Makefile_avr_pgm hat das zwar funktioniert, aber das
Programm scheint nicht lauffähig zu sein, da bei jedem Befehl die
Meldung "Kommando >print< unbekannt bzw. nicht vollstaendig!" kommt.
Werner M. schrieb:> unknown type name 'PTR_TYPE'
naja, ein wenig sollte man vorher schon meine Doku (und Teile des
Quelltextes) gelesen/verstanden haben...:
Mein Code ist so ausgelegt, dass die BASIC-Programme auf
unterschiedlichen Speichermedien abgelegt und von dort eingelesen werden
können. Gesteuert wird dies über einige Defines bei der Übersetzung.
PTR_TYPE ist z.B. ein solches Define, welches sich nach der Art des
jeweilige Speichermedium richtet. Heißt also, das PTR_TYPE (plus einige
andere Defines) bei SD-Card anders aussehen, als z.B. bei Files im
Dateisystem... Definiert sind diese Defines in tokenizer_access.h. Dort
sieht man aber auch, dass das jeweilige "Define-Bündel" in Abhängigkeit
eines jeweils anderen Defines bei der Übersetzung aktiviert wird. Z.B.
sind dies ACCESS_VIA_PGM, ACCESS_VIA_SDCARD, etc..
Und die Dinger werden in den jeweiligen Makefile(s) gesetzt. U.a.
deshalb gibt es mehrere davon...
Ich kenne Atmel Studio nicht, denke aber mal, dass man diese Defines
(ACCESS_VIA_PGM, ACCESS_VIA_SDCARD, etc.) dort auch irgendwo global für
die Übersetzung definieren kann...
Grüße Uwe
PS.: wofür möchtest du eigentlich den BASIC-Interpreter verwenden?
Uwe B. schrieb:> PS.: wofür möchtest du eigentlich den BASIC-Interpreter verwenden?
Ich möchte eine einfache Möglichkeit haben, um per Befehl einfach direkt
auf die Hardware zugreifen zu können. Weiterhin sollte man kleine
Programme in BASIC schreiben können und diese speichern. Als Anzeige
sollte ein LCD 128x64 dienen. Also im Prinzip einen Taschenrechner mit
Zugriff auf angeschlossene Hardware.
Im Anschluss müsste dann noch Befehlssatz erweitert werden.
Werner M. schrieb:> Ich möchte eine einfache Möglichkeit haben, um per Befehl einfach direkt> auf die Hardware zugreifen zu können. Weiterhin sollte man kleine> Programme in BASIC schreiben können und diese speichern. Als Anzeige> sollte ein LCD 128x64 dienen. Also im Prinzip einen Taschenrechner mit> Zugriff auf angeschlossene Hardware.> Im Anschluss müsste dann noch Befehlssatz erweitert werden.
Das hört sich irgendwie Alles nach FORTH an, insbesondere der letzte
Satz.
Route 6. schrieb:> Das hört sich irgendwie Alles nach FORTH an, insbesondere der letzte> Satz.
Nein ich denke eher an die gute alte Zeit der Homecomputer mit BASIC wie
z.B. C64 oder TRS-80 Model 1.
Werner M. schrieb:> Es gibt zwar im Atmel Studio 7.0 die Möglichkeit externe Makefiles> aufzurufen,
Wozu?
Wenns ein Makefile-Projekt ist dann kompiliers doch einfach so wie vom
Erfinder vorgesehen (und wie es dann wahrscheinlich auch reibungslos
funktionieren wird) mit make an der Kommandozeile. Such nach dem README
in dem drinsteht wie im Einzelnen dabei vorzugehen ist.
Oder mit anderen Worten: Warum umständlich wenns auch einfach geht?
Unter Atmel Studio 7 kann zunächst das Makefile "Makefile_avr_pgm"
ausführen lassen. Dabei werden dann alle Dateien vom Makefile
compiliert.
Wenn man aber ein eigenes Projekt aus den gegebenen Dateien machen
möchte, muss man die Einstellungen vom Makefile im Atmel Studio
einstellen. Weiterhin müssen die Dateien die sich außerhalb von
avr_basic befinden im Verzeichnis kopiert werden.
Mit beiden Varianten kommt es zu folgenden Fehlermeldungen (bedingt
durch neuere Compilerversionen):
File: ubasic_call.c Zeile 40 "const" muss vor der Variable stehen
File: ubasic_cvars.c Zeile 38 "const" muss vor der Variable stehen
File: tokenizer_data.cZeile 10 "const" muss vor der Variable stehen
Wenn diese beseitigt sind werden nach folgende Warnings ausgegeben:
Warning initialization discards 'const' qualifier from pointer target
type [-Wdiscarded-qualifiers] avr_basic ..\avr_basic\tokenizer.c 515
Warning 'new_last' may be used uninitialized in this function
[-Wmaybe-uninitialized] avr_basic ..\avr_basic\ubasic.c 1097
Warning 'val' may be used uninitialized in this function
[-Wmaybe-uninitialized] avr_basic ..\avr_basic\ubasic.c 1110
Wenn man nun das File im Controller lädt, wartet der Interpreter auf
eine Eingabe, führt aber folgendes Kommando nicht aus:
>Print "Hallo"
Kommando >Print "Hallo"< unbekannt bzw. nicht vollstaendig!
Welches Kommando erwartet der Interpreter?
Werner M. schrieb:> Welches Kommando erwartet der Interpreter?
wenn du die pgm-Variante übersetzt hast, dann lese doch einfach mal den
Anfangs-Kommentar in ubasic_avr_pgm.c. Ich glaube da steht, welche
Kommandos für die Mini-Shell implementiert sind...;-)
Grüße Uwe
Uwe B. schrieb:> Anfangs-Kommentar in ubasic_avr_pgm.c.
Danke für den Hinweis! => Folgende Kommandos:
ls --> listet alle verfuegbaren Programmnamen
<prog_name> auf
list <prog_name> --> gibt den Quelltext des Basic-Programm aus
run <prog_name> --> startet das Basic-Programm; das laufende
Programm kann man mit einem [ESC] abgebrochen
werden
mem --> Infos ueber RAM (unused, free)
time --> Laufzeit des letzten ausgefuehrten Basic-Programms
in Millisekunden
Ich bin nur erstaunt vom benutzen Code! Diese Variante benötigt 20784
Bytes.
Wenn ich alle implementierte Programme bis auf prog35 weg lasse komme
ich immer noch auf 15604 Bytes!
Wenn ich diesen BASIC-Interpreter zum 8051 AH BASIC-Interpreter
vergleiche, bin ich erstaunt das hier C noch so ressourcenhungrig ist!
Der 8051 AH BASIC-Interpreter, der wesentlich umfangreicher ist,
benötigt nur 8 kByte allerdings in Assembler!
Können bei deinem BASIC-Interpreter die Programme nur von einem
Datenspeicher geladen werden oder gibt es auch eine Variante wobei man
wie bei den alten Homecomputern das Programm in den Arbeitsspeicher
schreiben kann mit anschließender Sicherung auf ein Speichermedium?
Moin,
Werner M. schrieb:> Wenn ich diesen BASIC-Interpreter zum 8051 AH BASIC-Interpreter> vergleiche, bin ich erstaunt das hier C noch so ressourcenhungrig ist!> Der 8051 AH BASIC-Interpreter, der wesentlich umfangreicher ist,> benötigt nur 8 kByte allerdings in Assembler!
der Vergleich hinkt, eine C- bzw. Assembler-Implementierung sind jeweils
ein anderes paar Schuhe!
Und neben bei, Assembler ist immer plattformspezifisch. C kann man,
einen geeigneten Compiler jeweils vorausgesetzt, für jede Plattform
übersetzen. Es ist kein Problem meinen Interpreter für einen AVR, PIC,
ST, ..., einen Linux- oder Window-Rechner (und was weis ich sonst noch)
zu übersetzen und laufen zu lassen. OK, genug Speicher muss auf dem
Target sein, aber sooo viel braucht der Interpreter davon nun auch
nicht!
Werner M. schrieb:> Wenn ich alle implementierte Programme bis auf prog35 weg lasse komme> ich immer noch auf 15604 Bytes!
...mache es besser!
Werner M. schrieb:> Können bei deinem BASIC-Interpreter die Programme nur von einem> Datenspeicher geladen werden oder gibt es auch eine Variante wobei man> wie bei den alten Homecomputern das Programm in den Arbeitsspeicher> schreiben kann mit anschließender Sicherung auf ein Speichermedium?
...auch hier hilft Doku lesen ;-)! Mein Basic-Interpreter ist (nur) ein
Stück Software, dem man BASIC-Code vorwerfen und den man in eigene
Applikationen einbinden kann. Aber, wie der Doku und auch dem Quelltext
zu entnehmen ist, spielt das Speichermedium keine Rolle, wenn man bereit
ist, die entsprechenden (dokumentierten) Programmteile anzupassen bzw.
zu erweitern. Stichwort: tokenizer-access.c.
Und natürlich kannst du dir eine eigene "Shell" bauen, in der du zuerst
ein BASIC-Programm eingeben, abspeichern und dann starten kannst. SMED
(im Unterverzeichnis smed/) war sogar mal ein Versuch einen Editor für
den MC zuschreiben, in dem man Programme editieren und speichern kann.
Aber das führt hier alles zu weit --> bitte lese/verstehe doch erst
einmal Doku und Quelltext, um die Philosophie meines Interpreters zu
verstehen. Dann wirst du auch merken, was man alles mit dem Ding
anstellen und wie man es in seiner eigenen Anwendung einbinden könnte...
Grüße Uwe
