(→Ersetzen von Bascom-Library-Functions) |
|||
| Zeile 58: | Zeile 58: | ||
===Tips=== | ===Tips=== | ||
| + | '''Vorgangsweise''' | ||
Wenn man eine Library-Funktion entwickeln will, ist es günstig, sie erstmal als normale Sub-Routine mit inline-Assembler zu schreiben, und erst, wenn das halbwegs klappt, sie in eine Library zu übertragen. Die Syntax ist zwar etwas verschieden, aber das kriegt man hin. Der Vorteil ist aber, daß man seinen Assemblercode im Simulator normal debuggen kann, und das ist was wert. | Wenn man eine Library-Funktion entwickeln will, ist es günstig, sie erstmal als normale Sub-Routine mit inline-Assembler zu schreiben, und erst, wenn das halbwegs klappt, sie in eine Library zu übertragen. Die Syntax ist zwar etwas verschieden, aber das kriegt man hin. Der Vorteil ist aber, daß man seinen Assemblercode im Simulator normal debuggen kann, und das ist was wert. | ||
| + | |||
| + | '''Argumente''' | ||
Wenn man der Funktion Argumente oder eine Result-Adresse übergeben will, muß man natürlich den | Wenn man der Funktion Argumente oder eine Result-Adresse übergeben will, muß man natürlich den | ||
[[Bascom_Inside#Call_Sub_.26_Function|Bascom Call-Standard]] beachten. Der ist aber recht aufwendig. Alle (globalen) Variablen, die man mit DIM angelegt hat, kann man auch mit "LOADADR" adressieren, das spart Einiges. | [[Bascom_Inside#Call_Sub_.26_Function|Bascom Call-Standard]] beachten. Der ist aber recht aufwendig. Alle (globalen) Variablen, die man mit DIM angelegt hat, kann man auch mit "LOADADR" adressieren, das spart Einiges. | ||
| − | Zwischen "$ASM" und "$END ASM" ist man Herrscher über den kompletten Controller. Man kann alle Register hemmungslos einsetzen. Es ist also nicht so wie in einer ISR | + | '''Sichern''' |
| + | |||
| + | Zwischen "$ASM" und "$END ASM" ist man Herrscher über den kompletten Controller. Man kann alle Register hemmungslos einsetzen. Es ist also nicht so wie in einer ISR, daß man alles sichern und wieder herstellen muß | ||
Nur die Register | Nur die Register | ||
| Zeile 71: | Zeile 76: | ||
R6 | R6 | ||
sollte man sichern und am Ende wieder herstellen, wenn man sie verändern will. | sollte man sichern und am Ende wieder herstellen, wenn man sie verändern will. | ||
| + | |||
==Autor== | ==Autor== | ||
Version vom 3. Juni 2006, 13:35 Uhr
Inhaltsverzeichnis
Bascom Libraries
Im Installationsbereich von Bascom befinden sich eine Reihe Libraries mit den Endungen ".LBX" und ".LIB". Erstere sind gleichnamige, aber vorkompilierte Versionen von den ".LIB" Files. Dieses Vorkompilieren geschieht im LIB-Manager (Menu->Tools).
Aber auch die ".LBX" Files sind keine Object-Libraries, wie man sie von anderen Sprachen her kennt und die durch einen "Linker" zusammengefügt werden. Beides sind normale Textfiles, die erst beim Kompilieren des Basic-Hauptprogrammes tatächlich in Maschinencode übersetzt werden.
Deshalb ist es Bascom auch ziemlich egal, ob man bei der $lib Anweisung "lib.lib" oder "lib.lbx" angibt, es ist im Grunde die selbe Arbeit
Warum nun überhaupt ".LBX" ?
Durch das Vorkompilieren werden die Libraries doch einigermassen unleserlich, und wenn von einer Library die ".LIB" Version nicht da ist, will man den Code wohl nicht preisgeben.
Beide Versionen sind Sammlungen von "Bausteinen", die Bascom nur in das Benutzer-Programm einbindet, wenn sie tatsächlich gebraucht werden. Diese Bausteine sehen folgendermassen aus:
[Baustein_Name] Baustein_Name: .... Assembler-Answeisungen... RET [end]
Beispiel
Man erzeugt mit Notepad oder einem anderen Editor eine Datei "Testlib.LIB" im Library-Verzeichnis von Bascom (muß man im Installationsverzeichnis nachsehen, wo das ist)
[Meine_Funktion] Meine_Funktion: RET [end]
(und speichern, natürlich)
Im Hauptprogramm (in BasCom) schreibt man nun
$regfile = "m32def.dat" $crystal = ..... $lib "testlib.lib" $external Meine_Funktion Declare Sub Meine_Funktion() '.... irgendwo... CALL Meine_Funktion
Dadurch wird die Funktion an die nächste freie Stelle in den Maschinen-Code eingefügt und bei "Call" aufgerufen.
Man braucht jetzt nur noch irgendetwas Sinnvolles in die Funktion reinzuschreiben.
Ersetzen von Bascom-Library-Functions
Es ist sehr einfach, Funktionen, die sich in irgendeiner mitgelieferten Bascom-Library befinden, durch eigenen Code zu ersetzen. Bascom geht nämlich beim Suchen nach einer gerade benötigten Funktion im in der Reihenfolge der "$LIB" Anweisung vor. Die Standardlibrary "MCS.LBX" wird immer erst als Letztes durchsucht. Schreibt man also
$LIB "testlib.lib"
sucht er erst in dieser Library, und erst wenn da nix drinsteht, nimmt er das, was sich in MCS.LIB befindet.
Leider sind nicht alle Bascom-Funktionen in Libraries vorhanden, vieles ist im BasCom-Programm fest eingebaut. Und manches findet man erst nach ein wenig Detektivarbeit ("PULSEIN" heißt zum Beispiel "_PULSE_IN").
Tips
Vorgangsweise
Wenn man eine Library-Funktion entwickeln will, ist es günstig, sie erstmal als normale Sub-Routine mit inline-Assembler zu schreiben, und erst, wenn das halbwegs klappt, sie in eine Library zu übertragen. Die Syntax ist zwar etwas verschieden, aber das kriegt man hin. Der Vorteil ist aber, daß man seinen Assemblercode im Simulator normal debuggen kann, und das ist was wert.
Argumente
Wenn man der Funktion Argumente oder eine Result-Adresse übergeben will, muß man natürlich den Bascom Call-Standard beachten. Der ist aber recht aufwendig. Alle (globalen) Variablen, die man mit DIM angelegt hat, kann man auch mit "LOADADR" adressieren, das spart Einiges.
Sichern
Zwischen "$ASM" und "$END ASM" ist man Herrscher über den kompletten Controller. Man kann alle Register hemmungslos einsetzen. Es ist also nicht so wie in einer ISR, daß man alles sichern und wieder herstellen muß
Nur die Register
YL:YH R4:R5 R6
sollte man sichern und am Ende wieder herstellen, wenn man sie verändern will.
Autor
Siehe auch