Library für Bascom erstellen

Hallo,
hat hier irgendwer schonmal eine eigene Lib für Bascom erstellt? Ich finde, was die externe Libs angeht, ist die Bascom-Hilfe weniger ausführlich.
Ich weiß, daß die Library nur unter Asm unterstützt wird. Kann Basom aus einem Basiccode so ein ASM- File erstellen?
Wie gebe ich die Variablen an die Library weiter, welche verwendet werden?
Kann ich Routinen von einer Lib direkt als Befehl aufrufen?
Sind Routinen von Librarys mit Macros vergleichbar?

Ich Frage, da ich ein Bascomcode habe, den ich gerne in eine Lib verwandeln will. Soll zum Schluß ungefähr so funktionieren, wie die I2C- Library. Aber ich weiß nicht, was ich hierfür beachten muß.

Die beste Erläuterung, (die ich bis jetzt gefunden habe) steht in der Library Mylib.lib selbst. Du kannst das Zeugs mit dem Notepad aufmachen.
BasCom macht afaik keine .asm dateien aus seinen Sourcen.

Hm, bissl unlogisch finde ich, daß die Libs ur ASM sein dürfen, obwohl Bascom mit einer Art von Basic interpretiert. Irgendwiehabe ih das Gefühl, daß die Funktion mit Libs nur für Erweiterungen von MCS selbst (die natürlich auch etwas Kosten) gedacht ist.

Wenn ich ein Source von Bascom einfügen will, muß ich es dann wohl erst compilieren und danach disassemblieren und Anpassen. Sehr Bedienerfreundlich.....weil: Könnte ich ASM so gut, bräuchte ich wohl weniger den Bascom-Compiler, und somit auch die Umgebung von Bascom nicht.

@PicNick: Hast du schon mal ne eigene Lib geschrieben und verwendet?

Hallo Rag_Empire,

In der Hilfe ist unter "Mixing ASM and BASIC" einiges zu finden.

Es ist ( derzeit ) mit BASCOM-AVR nicht möglich, BASIC-Code in entsprechenden ASM-Code zu übersetzen. Daher ist also selber in ASM programmieren nötig.

Für die Variablenbehandlung gibt es mehrere Möglichkeiten:

Eine Variable kann mit z.B.

lds r24, {Variablenname}

in ein Register geladen werden. Analog dazu natürlich abspeichern mit

sts {Variablenname}, r24.

Hier kann auch mit Offset gearbeitet werden z.B.: {Variablenname+1}

Während dieses Verfahren für Byte-Variablen gut geeignet ist, ist für Variablen mit mehreren Bytes (Word, Integer, Long, String) die Verwendung eines Variablenpointers besser geeignet.

Loadadr X, Variablenname

Loadadr ist eine Hilfs-Befehl, welcher es ermöglicht mit Variablenpointer in BASCOM-AVR zu arbeiten.
Ist die Variable z.B. auf der Adresse &H123 wird dieser Befehl beim Kompilieren in

ldi xl, &H23
ldi xh, &H01

übersetzt.

Hat man die Adresse einer Variablen in einem der X oder Z Pointer-Register, kann dann mit folgender Sequenz eine Long-Variable in die Register r20-r23 geladen werden:

ld r20, X+
ld r21, X+
ld r22, X+
ld r23, X+

Abspeichern geht analog dazu.

Damit selbst erstellte Lib-Routinen aus dem BASIC aufgerufen werden können, müssen diese wie SUB oder FUNCTION in BASIC deklariert werden und die Library mit $LIB "MyLib.lib" gelinkt werden. "MyLib" steht für den Namen der selbst erstellten LIB.

Die Adressen der übergebenen Parameter, sowie die Adresse eines Rückgabewertes bei einer FUNCTION werden auf dem Y-Pointer (Soft-Stack) gespeichert.

Makros sind nicht mit LIBs vergleichbar. Lib-Routinen sind mit eingebundene Routinen, welche bei Bedarf angesprungen/aufgerufen werden, während Makros direkt beim Makro-Aufruf in den Code eingefügt werden. Eine LIB-Routine wird nur einmal eingebunden, während ein Makro bei jedem Aufruf in den Code eingefügt wird.

Man könnte z.B. die Hilfsfunktion Loadadr als ein Makro bezeichnen.

Grundsätzlich wäre aber zu überlegen, ob ein Portieren eines BASCOM-AVR Programmteiles in eine Library notwendig ist. Es lassen sich mit Librarys Code-Größe als auch Ausführungsgeschwindigkeit optimieren. Falls weder Code-Größe noch die Geschwindigkeit ein Problem sind, können diese Funktionalitäten in BASIC-Code in SUB od FUNCTION verpackt werden und dann von jedem Programmpunkt aufgerufen und verwendet werden. Siehe dazu DECLARE SUB und DECLARE FUNCTION in der Hilfe

Es ist irgendwo eine Philosophiefrage. BasCom läßt ja zu, daß du an einer beliebigen Stelle "include" sagst und deine Routinen (in Sourceform) einbindest. Außer, daß du sie dadurch natürlich auch jedesmal frisch übersetzt, ist das ja soweit ok und hilft, Programm-Monster-Megalithen zu vermeiden und sich auf diese Weise "Libraries" zu machen.
Wenn du dir die compilierten "*.LIBS" ansiehst, wirst du sehen, daß die Schweinebacke in Wirklichkeit ja nur den Code übersetzt, der keine Absoluten Sprung- oder Datenadressen verwendet. Den rest läßt er ja wie er ist und übersetzt ihn dann mit seiner normalen "inline-assembler" Methode.
So richtige Object-files, wie man sie sonst (vom PC) kennt, sind das ja nicht. Das wär nämlich auch komplizierter, BasCom würde dann auch einen "Linker" brauchen, den er sich so erspart.
Ich selbst:
Da ich die Problemstellung ja auch kenne, bin ich am Überlegen, ein entsprechendes Tool (PC) zu schreiben, daß zum Bascom-Library Erstellen geeignet ist. Da ich doch schon seit einigen Wochen in dem Beruf arbeitet, trau' ich mir das auch zu, wenn es nur nicht so ein grausliches Gefummel wäre. Angeblich will ja jeder Programmierer einmal in seinem Leben eine Betriebs-System und einmal einen Compiler schreiben. Ich weiß nicht, ich hab das Gefühl überhaupt nicht.

@oe9vfj:
Danke für die ausführliche Antwort. Das mit der Variablenbehandlung habe ich jetzt verstanden. Ja, es geht bei mir um die Größe und um das Handling, deswegen will ich die Lib schreiben.

Was meinst du aber mit

Zitat:

---

Es ist ( derzeit ) mit BASCOM-AVR nicht möglich, BASIC-Code in entsprechenden ASM-Code zu übersetzen

---

wird es irgendwann möglich sein? Wäre für mich dann einiges leichter. Weil sonst muß ich mir echt die Mühe machen, Compilieren und Disassemblieren, Anpassen.......
Viel Arbeit und Nerven kostet das dann wieder!

@PicNick:
Ja, richtiger Begriff: Gefummel!!!! Aber so ein Tool, wie du Angesprochen hast, wäre viel ersparniss an Nerven und Zeit........ würde ich sogar kaufen, wenn es dies gäbe!

Jetzt, wo gerade keiner zuhört, kann ich es ja sagen:
Mein Traum wäre eine Methode, wo man Bascom-, GCC und Assembler- Module untereinander kreuz und quer linken könnte, damit man je nach Problem die Vorteile der einzelnen Sprachen nutzen kann. Aber wie schon gesagt: das stinkt ganz furchtbar nach Arbeit.

Falls es wen interessiert oder hilft:
Ich hab' in unserere Wiki ein paar BasCom - Interna dargestellt
https://www.roboternetz.de/wiki/pmwi...ain.Bascomcall

Du meinst so ne Art Allround- Oberfläche? Das wäre echt der Hammer! Aber das gibt es nicht und somit haben wir halt gräusliches Gefummel, was uns alle Nerven und Zeit kostet. Tja, die Welt wäre so einfach, wenn die Welt so einfach wäre.

Und ich finde es immernoch unlogisch von MCS, daß die Libs nur ASM sein dürfen, obwohl Bascom selbst mit einer Abart von Basic interpretiert.

PS: Aber erst als dus erwähnt hast ist mir aufgefallen, das Bascom gar kein Linker benutzt, was mich hätte von Anfang an wundern müssen.

Mark Alberts (der Autor vom BASCOM-AVR) hat wenn ich mich recht erinnere in einer seiner Antworten in der Mailingliste www.grote.net/bascom dies als ein mögliches zukünftiges Feature bezeichnet.
Um in ASM wirklich effektiv arbeiten zu können, sind meines Erachtens schon fundierte AVR-ASM Kenntnisse notwendig.
Da der von BASCOM-AVR erstellte Code schon sehr kompakt ist, lässt sich nur in einem Punkt noch merkbar etwas optimieren:
BASCOM-AVR holt für jeden Befehl die benötigten Parameter/Variablen aus dem SRAM und speichert zum Abschluss des Befehles die Ergebnisse wieder ins SRAM zurück. So ist jeder BASCOM-AVR Befehl quasi unabhängig vom vorhergehenden bzw. nachfolgendem. Sofern aber in einer Befehlssequenz die gleichen Variablen immer wieder verwendet werden, könnten diese in einem gewissen Code-Bereich in den CPU-Registern gehalten werden, wodurch man sich das Abspeichern und neu Laden ersparen würde. Dazu muss aber unter Umständen einiges an ASM-Code umgeschrieben werden, da nicht unbedingt eine Routine mit einer Variablen in den gleichen Registern beginnt, wie eine andere Routine mit der Variablen endet. Weiters muss überlegt werden, welche CPU-Register werden für die Ausführung einer bestimmten Aufgabe benötigt, welche können für die Zwischenspeicherung von Variablen freigehalten werden.
Ein ASM-Listing wäre hier natürlich schon eine gewisse Hilfestellung, aber ist auch einiges an weiterer Arbeit im ASM-Coding notwendig, um wirklich gegenüber dem BASIC-Code noch weiter zu optimieren.


Wenn Du vielleicht etwas konkreter ausführen könntest, was Du vorhast, wäre vielleicht eine zielführendere Hilfe möglich.

Sind ja zwei Aspekte da, die nicht direkt zusammenhängen:
1 Modularisierung: Irgendwann hat man das x-te mal irgendeine Logik ausprogrammiert, dann will man das Zeugs eigentlich nicht mehr sehen und einfach nur als Baustein in der Lade haben.
2 Improvement: Beschleunigung des Codes oder sonstige Verbesserungen (?). Da hat der Pepi schon dargestellt, dem möcht' ich mich anschließen, ernsthaft verbessern kann man nur, indem man irgendwelche Tricks anwendet, die der brave Kompiler state-of-art so einfach nicht machen kann.

Den ersten Aspekt würd ich voll unterstützen.
Beim zweiten kommt's immer drauf an, da mag man diskutieren.

Bei mir handelt es sich um den 1. Aspekt:

Es geht um das Busprotokoll Snap. Ich habe ein Bascom Source geschrieben, welcher Mit diesem Busprotokoll empfangen und senden kann (klingt im Moment noch einfach). Jedoch kann dieser Source auch beschränkt headers erstellen und die Schnittstelle vor dem Senden Prüfen, ob diese gerade frei ist. Auch die Berechnung der Checksummen ist hier vorhanden. Da das Busprotokoll so flexibel ist, daß je nach Anwendung das Eine oder Andere von den grobe detailierten Aufgaben verwendet wird und der Rest unbenzuztz belibt, ist es Platzverschwendung jedesmal alles zu integreieren. Somit wäre eine Lib flexiebler und einfacher. Der Source ist in Bascom jedenfalls (Compiliert) fast 2kb groß, was den Platz von einem Tiny schon alleine vollstopft. Die Programmabschnitte voneinander trennen und einzeln per Include aufrufen funktioniert nicht, da sie sich je nach konfiguration gegenseitig brauchen.

Vieleicht hat jemand schon solch eine Lib geschrieben?

Will aber hier auch nicht zu sehr auf den Bus-Source eingehen, da mich das mit den Libs im Allgemeinen intressiet. Die Idee von MCS mit den Libs ist gut, nur für die eigene Awendung finde ich es sehr unhandlich.

Zitat:

---

Zitat von Rage_Empire

..handelt es sich um den 1. Aspekt

---

Ich hab's auch so verstanden.
Damit das (unabhängig von Asm oder sonstwas) den gewünschten Effekt hat, müßt das ganze schön in unabhängige Module zerlegt sein (oder werden), daß erst durch die Haupt-Applikation das aktuelle Set zusammengestellt wird.
Wegen des Asm-Codes kann ich schon helfen, du müßtest mir deinen Bascomcode (.BAS) oder das (INTEL)-HEX schicken, dann kann ich dir das dann als ASM zurückschicken, damit's nicht gar so eine Arbeit ist.
Aber hilft dir das ?

Wenn ich es in unabhängige Module zerlege, wird der Source noch größer.
Wie ist es eigentlich mit dem Konfigurieren? Bei der I2C-Lib geht das über Config...blabla....
Aber geht das so allgemein, oder wird das von Bascom aus so unterstützt?
Weil da sehe ich auch noch ein Problem darin.

Hier könnte vielleicht die bedingte Kompilierung etwas helfen. Wenn Du im Programm eine Konstante setzt, welche eine Aussage über die genutzten Programmteile macht, kannst Du mit

#IF SNAP_Prot = 1 then

#ELSE

#ENDIF

Ist nicht unbedingt, was man sich unter einer eleganten Programmierung vorstellt, aber für den Moment möglicherweise eine brauchbare Lösung.

Mark Alberts arbeitet derzeit an einen Re-Design des Compilers, welcher dann auch BASIC-Code in Librarys möglich macht. Dann ist das gezielten Linken von benötigtem BASIC-Code möglich.
Ein Fertigstellungszeitpunkt ist mir nicht bekannt und nehme an, es wird noch etwas dauern,

Habe ich schon Versucht, aber wenn keine Konstannte gegeben ist (falls eine Funktion nicht gebraucht wird) funktioniert es schon nichtmehr.

Wünschen wir Mark Alberts viel Erfolg!

Diese (bedingten) Präprozessor-Anweisungen sind schon ok. Ich verwend' das oft, wenn ich z.B. die gleiche physische Source für verschiedene Plattformen verwenden will (um redundanzen zu vermeiden)

Rage-empire hat ja auch nur dann was davon, Realtime-dynamik würde ja nix nutzen.

Es kann durchaus sinnvoll/effektiv sein, für die verschiedenen SNAP Applikationen mit Cut & Paste angepaßte Sourcen / Module zu erzeugen.
Besonders, wenn eh nicht mehr dran gebastelt wird.

Es soll nicht verschwiegen werden, daß es ganzschön anspruchsvoll sein kann, ein Programm gut und zweckmäßig zu strukturieren.
Denk mal dran, du müßtest z.B. ja den "$Crystal" Parameter in diverse Timing-Routinen berücksichtigen können.

man kann auch Asm in Bascom direkt einbinden, benötige dafür keine Libs. Es geht um die allgemeine Library- Funktion und diese ist unstreitbar beschränkt auf ASM, was ich für den user des Bascom- Intrepreter an sich zum Nachteil empfinde. Sicherlich ist es von Vorteil, das Bascom auch ASM unterstützt, gar keine Frage. Aber die Lib- Funktion ist darauf beschränkt und hat somit gar nichts mit der Bascom Interpretierung zu tun....? ->Unlogisch

War da eben nicht noch ein Posting?

Was mir an deinem Programm noch nicht klar ist?:

Hast Du alle Funktionen in SUBs zw. FUNCTIONs welche aus dem Programm aufgerufen werden. Gibt es für verschiedene Optionen verschiedene SUBs/FUNCTIONs oder wird innerhalb eines Programmteile (SUB/FUNCTION) je nach Option ein Teil nach Bedarf verwendet. Wieviele Verwendung-Optionen gibt es für diese Programmpaket

@Rage-empire
Da hast du schon recht, Bascom sollte seine Libraries auch selbst erzeugen können. Bei GCC geht das ja auch und in jeder (?), sagen wir den meisten anderen Sprachen.
Was ich fürchte, daß das Haupt-Klientel von BasCom junge Einsteiger sind, die, wenn sie sich als Fortgeschrittene dann ernsthaft solche Libraries wünschen, eh schon auf C oder sonstwas umgestiegen sind.
Und mit ein paar zerquetschten Power-Usern macht man nicht viel Geschäft.
(Ist aber vielleicht ungerecht)

Nein, momentan ist der Source noch so gecschriebn, das die Routinen via Gosub abgefragt werden. Mcht das überhaupt einen Unterschied, ob mit Gosub oder Declare?

Weil Gosub -> Go Sub ??

@PicNick: Ja, glaube da hast du recht. Ich selbst komme aus der 8051er ecke und habe erst mit AVRs (habe mich erst mit Pic versucht, aber von 8051er auf Pic...ohgottohgott!!!) angefangen. ASM mit 51er ist nicht mit AVR-ASM vergleichbar, deswegen benuzte ich Bascom. Bis jetzt fahre ich damit auch ganz gut, bis auf solche Grenzen eben.......leider.

Der Unterschied GOSUB und Call sub ist der, daß "gosub" ein einfacher assembler-call auf den Label ist, während bei deklarierten Funktions oder Sub's der ganze Software-Call-Mechanismus losgetreten wird.
(Nicht verwechseln mit GOTO, sowas ist bähh)

Kurzum: wenn eine Routine keine call-Argumente braucht und auch keine lokalen daten, isses besser (kürzer), du macht gosub draus

Nachteil bei all dem: auch wenn du garnicht hinspringst, jeder call oder gosub erzeugt eine Referenz auf die Routine, und dann ist sie auch schon dabei im Endprodukt


PIC's hab ich zwar, mach' aber nix mehr. das BANK-Gewurstel und der Brenner-x Kult haben mir den Nerv gezogen.
BasCom verwend' ich, weil er sehr angenehm für's prototyping ist, man schreibt einfach in den Schirm hinein, was einem grade einfällt und drückt ab.
Wegen diesen Features, die ich schätze, möcht ich ja auch ein bißchen Tools dafür machen, um eben das Zeugs ein bißchen aufzupeppen für größere Geschichten.

PIC! ja, das Bankgewurstel... zu wenig ASM- Befehle (Da mußt ja alles selber schreiben)...... Nee, nichts für mich. Ja, das mit Bascom bin ich Deiner Meinung

Solange Du nicht Werte (Parameter) zur Verarbeitung übergeben willst ist da im eigentlich kein Unterschied.

Die zu wählende Variante hängt davon ab, ob in dem Unterprogramm Variablen (Informationen) aus dem Hauptgramm zu verarbeiten sind und ob es ein (oder mehrere) Rückgabewerte an das Hauptprogramm gibt.

Ein einfaches Beispiel:

Long1 = Val(String2)

Die Funktion Val konvertiert eine Nummer in einem Text in eine Nummerische Variable (z.B. Long). Mit dieser nummerischen Variable kann dann gerechnet werden. Wäre dieser Programmteil Val über ein GOSUB anzusprechen, dann müsste vorher der umzustellende String in eine Stringvariable kopiert werden, welche im Val Programmteil verwendet wird, da der Programmteil ja nur eine fixe globale Variable behandeln kann. Diese macht dann die Umwandlung dann in eine andere fixierte globale nummerische Variable (z.B. LONG). Nach Beendigung des Val Unterprogrammteiles müsste dann das Hauptprogramm den Wert wieder aus der num. Variablen herauskopieren, falls er noch länger gebraucht wird. Für jede Funktionaltät müsste SRAM reserviert werden.
Diese Variablen, mit welchen der Programmteil Val arbeitet, wären nur von diesem verwendbar und die String-Variable müsste dann auch auf den grössten vorkommenden String ausgelegt sein.

Wird aber eine FUNCTION oder SUB (wenn es keinen Rückgabewert gibt) verwendet, werden nur Zeiger auf die Variablen übergeben (bei byVal wird der Wert in einen temporären Speicherbereich Frame kopiert). Diese Zeiger verweisen auf die eigentlichen Variablen.
Der Code ist dann flexibler zu verwenden und braucht im allgemeinen weniger SRAM.

Ich hoffe, ich konnte Dir den Unterschied an diesem zugegebenermaßen etwas drastisch dargestellten Beispiel (worst case) klar machen.
Es hängt also immer davon ab, welche Informationen hat das Unterprogramm zu verarbeiten und was liefert es an das Hauptprogramm zurück.

Hm, also mit denen Vielen Variablen ist es glaub ich einfacher Gosub zu benutzen.

Apropo Libs...
....paßt nicht ganz hier her, aber will kein neuen Thread desswegen aufmachen.....

gibt es eine Liste mit den Libs (die bei Bascom dabei sind) und für was sie gut sind? Der Lib- Manager sagt über die funktionen und anwendung ja wenig aus.

Mir ist keine solche Liste bekannt. Der erste Anhaltspunkt ist der Name der Lib selbst. Im Header der LIB ist bzw. sollte etwas über den Zweck der LIB beschrieben sein. Du wird also nicht umhin kommen, die LIB einzeln durchzusehen.