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?
:
Verschoben durch User
Werner M. schrieb: > Es kommt jedoch zu einer Menge an Fehlermeldungen. ...nur mal interessehalber --> was kommen denn so für Fehlermeldungen? Uwe
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?
:
Bearbeitet durch User
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?
:
Bearbeitet durch User
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
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte 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.