BASCOM Pros und Cons - aus meiner (!) Sicht

Druckbare Version

23.09.2005, 21:08
roboguy

BASCOM Pros und Cons - aus meiner (!) Sicht

Zunächst eines vorneweg:
Ich habe wirklich überlegt, ob ich dieses Posting ashängen soll oder nicht, da wir uns aber nicht am Stammtisch bei einem geistreichen Getränk darüber austauschen können, blelbt mir kein anderer Weg.

Ich habe jetzt hier ein paar Mal ein paar Fragen zu BASCOM gepostet und in der Regel schnell und freundlich hilfreiche Antworten bekommen. Allerdings scheinen sich jedesmal auch einige Gegner dieses Programms dazu berufen zu fühlen, mehr oder minder vernichtende Kommentare zu diesen Aspekten abzugeben.
Ich möchte jetzt einfach mal ein paar Punkte aufführen, die mir beim Umgang mit BASCOM aufgefallen sind:
1. Zunächst einmal halte ich dieses für ein sehr preiswertes und ziemlich komplettes Werkzeug. das es auch Anfängern in der uC-Programmierung ermöglicht recht schnell zu Erfolgen zu kommen.
2. Ich habe in der Vergangenheit ein paar Fragen gestellt oder Statements abgegeben, die bei sehr (!) sorgfältiger Suche in der BASCOM-Hilfe überflüssig gewesen wären. Ich selbst bin ein Vertreter der RTFM-Mentalität, wobei meine Kunden es noch viel doller treiben, aber ich (!) bin der Ansicht, dass die BASCOM-Hilfe nicht immer ganz konsistent ist. Ich bin es gewohnt, meine Fragen über die Suche nach entsprechenden Stichwörtern im Hilfe-Index zu lösen. Sucht man beispielsweise zum Thema logische Operatoren etwas, so ist im gesamten Index keine Referenz zu "Operators", "Logical", "AND", "OR", "NOT"....
Diese sind zwar beschrieben, aber nicht indiziert. Da gibt es meines Erachtens etwas Nachbesserungsbedarf.
3. Variablen-Initialisierung
Ich hatte vor kurzem ein Aha-Erlebnis hinschtlich der Variablen-Initialisierung:
Ich habe eine Stringvariable deklariert und dieser einen zusammengesetzten Wert zugewiesen, also z.B.
CONST Vers_Info = "0.1"
DIM Teststring AS STRING *15
Teststring = "Version " + Vers_Info
Wenn ich diesen Teststring per I2C an das RNKEYLCD-Board sende, erscheint im Display
Version 0.1 ''''''
(eigentlich waren es keine Hochkommata, sondern hochgestellte Punkte), d.h. es wurde nicht nur der Teststring ausgegeben, sondern noch ein bisschen Datenmüll.
Das einfache Einfügen von
Teststring =""
als Initialisierung vor der eigentlichen Wertezuweisung behob dieses Phänomen.
Ich habe im Übrigen zu diesem Verhalten schon in der Hilfe nachgesehen - aber nichts entdecken können.

So, das musste jetzt mal raus. Ich hoffe, dass ich jetzt keinen Flamewar angezettelt habe, aber was soll ich machen ohne Stammtisch?
24.09.2005, 08:26
PicNick

Ob das hier ein Massaker wird, wird sich herausstellen. Eigentlich würd' ich mich dir voll anschliessen.
"Help" ist offensichtlich hauptsächlich dazu da, Details zu etwas nachzusehen, nicht sosehr, es überhaupt zu finden. Persönlich helfe mir bei irgendwelchen Programmen dadurch, daß ich immer wieder zweckfrei im Help herumstöbere und dadurch einen gewissen Überblick gewinne. Aber das tue ich eigentlich auch bei jedem Wörterbuch oder Lexikon.

Dein Beispiel muß man sich genauer anschauen. Eigentlich löscht BasCom den kompletten SRAM, d.h. deine initalisierung hätte auch ohne = "" klappen sollen. Vielleicht kannst du deine Source mal attachen
Wenn's ein Bug ist, werden wir das den Leuten um die Ohren hauen, die freuen sich auf sowas. Programm wie BasCom haben immer Fehler, die halt nicht immer gleich auffallen.
Vielleicht magst du ein bißchen hier stöbern,
https://www.roboternetz.de/wiki/pmwi...in.Bascomstack
ist vieles noch Baustelle, aber irgendwo fängt man halt an
24.09.2005, 10:04
Marco78

Zu 1.: Da stimme ich zu. Ich habe noch kein Tool vermisst. Es ist alles dabei was man braucht. Sogar ein Simulator.

Zu 2.: Die Hilfe finde ich auch brauchbar. Schön ist es, das man auf einen Befehl gehen kann und nur F1 drücken muss um die Hilfe direkt zum Befehl zu bekommen.
Spätestens mit der Indexsuche habe ich immer alle sgefunden was ich gesucht habe.
Ob der Inhalt der Hilfe brauchbar ist, liegt immer an jedem selbst. Ich finde nicht alle Erklärungen sinnvoll. Andere sind da sicherlich anderer Meinung. Das ist halt einer der Punkte, die uns Menschen unterscheiden.

Zu deinem Problem:
Als was hast du denn Vers_Info dimensioniert?
Die Variablen sind von Start an alle gelöscht. Nur mit einem extra Befehl, wird das nicht gemacht. Dann sind die Werte zufällig.

Verbessern kann man immer was. Aber das ist überall so. Fängt bei Bascom an, geht über Windows und endet in der Natur.
24.09.2005, 16:35
albundy

Im allgemeinen kann ich dem zustimmen.
Aber es gibt auch Schwachstellen, die sehr stiefmütterlich behandelt werden. Beispielsweise das Kapitel Grafik LCD. Ich habe z.B. keinerlei Angaben darüber gefunden, welcher SED Controller unterstützt wird und welcher nicht. Der SED1565 wird es jedenfalls nicht. Weshalb ich gezwungen bin mir eine eigene Library dafür zu schreiben.
Wobei wir beim nächsten Punkt sind. Wer schon einmal versucht hat eine eigene Lib zu schreiben, wird schnell an seine Grenzen stoßen. Nicht zuletzt deshalb, weil die Bascom Help in diesem Fall mehr als mangelhaft ist.
In diesem Zusammenhang habe ich herausgefunden, daß es für die Lib's interne Variablen (als Gateway zwischen Bascom und ASM) gibt, die man benutzen könnte, sofern diese irgendwo erwähnt würden.
Aber man will ja an den Lib's extra verdienen, deshalb wird es auch kaum Informationen über die Interna geben.
Schade eigendlich ...
24.09.2005, 16:59
Goldenflash

Naja ich geb auch mal meinen Senf dazu... :cheesy:

ZU1: Wie könnte es anders sein, ich stimme dir voll und ganz zu, ich habe ebenfals noch nichts vermisst.

ZU2; Tja, hier muss ich leider sagen, dass ich so den Eindruck habe, dass die Programmierer keine Ahnung hatten was sie in die Hilfe-Datei schreiben sollen. Eine komplette "MSDN" war ihnen zuviel, also gabs nur kurze Erleuterungen.
Schade eigentlich, sonst ist das Programm wirklich TOP. Vor allem für Anfänger die schnell Ergebnisse sehen können. :-s

Gruß Florian
24.09.2005, 22:02
pebisoft

was ist in bascom der unterschied zwischen einer lib und einer
asm-routine als sub, wenn das programm im avr fertig abgelegt ist und
der avr nun selbständig am arbeiten ist. ich sehe keinen unterschied.
beim pc ja, das programm wird bei bedarf dazu geladen. beim avr kann ich während des betriebes kein programm mehr mit den ips-programmer laden.
mfg pebisoft
24.09.2005, 22:58
hrei

Zitat:

Zitat von pebisoft

was ist in bascom der unterschied zwischen einer lib und einer
asm-routine als sub, wenn das programm im avr fertig abgelegt ist und
der avr nun selbständig am arbeiten ist. ich sehe keinen unterschied.

Einer der Unterschiede ist, daß eine Library dazu gebracht werden kann, selbständig zu erkennen, ob sie benötigt wird oder nicht (beispielsweise durch die bloße Nutzung eine Befehls, der die Lib benötigt).
Bei einer Sub muss diese explizit per Include eingebunden werden. Das passiert bei den meisten von Bascom genutzten Libraries. Auch existiert eine relativ elegante Möglichkeit der Lib Parameter via Config zu übergeben, die dann während der Preprozessorphase entsprechend behandelt werden können.

Zitat:

beim pc ja, das programm wird bei bedarf dazu geladen. beim avr kann ich während des betriebes kein programm mehr mit den ips-programmer laden.

Bei PC-Programmen passiert in Bezug auf die Compilierung absolut nichts anderes als beim µC . Bei beidem gibt es natürlich viele verschiedene Spielarten.

Henrik
25.09.2005, 09:04
Frank

Zitat:

Zitat von pebisoft

was ist in bascom der unterschied zwischen einer lib und einer
asm-routine als sub, wenn das programm im avr fertig abgelegt ist und
der avr nun selbständig am arbeiten ist. ich sehe keinen unterschied.
beim pc ja, das programm wird bei bedarf dazu geladen. beim avr kann ich während des betriebes kein programm mehr mit den ips-programmer laden.

@Pepbisoft: Hrei hats ja schon angesprochen. Genauer gesagt verwechselts du eine statische Libary mit einer dynamischen Libary (DLL), das ist ganz was anderes. Auch auf dem PC werden Funktionen von statischen Libarys fest in das Programm integriert, da wird nix mehr nachgeladen.
Dynamische Libarys gibt es eigentlich vorwiegend erst ab späteren Windows Versionen. Diese erfordern zum einen einen Massenspeicher und zum andern eine aufwendige Speicherverwaltung . Sowas ist bei kleinen Controllern fast unmöglich zumindest nicht paktikabel, die Programme würden schon durch die Speicherverwaltung aufgebläht. Du darfst nicht ein Windows-Betriebsystem das GIGABYTES zur Verfügung hat mit einem kleinen Controller verwechseln.

Was die Hilfe betrifft stimme ich dem gesagten zu. Die ist eigentlich schon recht gut und ausführlich, dennoch ist es manchmal etwas schwierig alles zu einem Thema zu finden. Soweit ich vom Autor gehört habe wird die Hilfe von Bascom derzeit überarbeitet, vielleicht wird auch das dann noch besser.
25.09.2005, 11:06
PicNick

Vergleiche mit dem rezenten Windows enden stets mit der weisen Festellung, daß es eben einfach ganz anders ist.
Allein dadurch, daß das Programm in einem Flash gespeichert ist, entfällt alles, was bei Prozessore in Richtung "dynamisch" ablaufen kann, bzw. wird nicht praktikabel.
Beim BasCom ist der Unterschied "Inline" und "library" klein, aber fein.
"Inline" ist IMHO ganz gut mit MACROS vergleichbar, die zur Compile-time parametrisiert generiert werden.
"Library" sind fest programmierte Routinen, die letzlich unique an einem festen Platz im Speicher stehen, und die zur run-time aus den Call Argumenten variiert werden (können).
Dabei macht das BasCom trickreicherweise noch so, daß er auch die eigentlich bereits kompilierten LBX-en nochmal übersetzt, damit er Variablen/Konstanten (z.B. $Crystal) einarbeiten kann.
Es wird in der LBX ja nur das kompiliert, was sich nicht mehr ändern kann (taucht in der lbx als ".OBJ xxx" auf). Mit den gewohnten Object libraries haben die nix am Hut.
Dadurch erspart sich BasCom immerhin einen "linker"
Schwierigkeit, die daraus folgt: Es gibt kaum allgemeine anwendbare Regeln, wie man zwischen "include sourcefile", Inline assembler und Libraries auswählen soll. Kommt immer ganz drauf an.
25.09.2005, 12:55
pebisoft

da die lib nicht dynamisch sind ,ist es doch für einen avr unerheblich im welchen speicherberich die lib liegt. mit den avr mache ich doch keine dynamischen experiemente wie in windows oder linux. wenn ich für den wenigen speicherplatz des avr programme schreibe achte ich doch eh darauf nur das zu proggen was gebraucht wird und habe das unter kontrolle. bei der lib weiss ich nicht so genau was sie jetzt gerade einlädt oder nicht. zb schreibe ich selber kleine routinen mit mein fastavr-basic im asm-source und binde die dann von oben nach unten in den avr-flash ein, die springe ich dann ganz einfach an , wenn ich sie brauche. sozusagen habe ich die sub ausserhalb des basicprogrammes abgelegt. es ist ein ganz tolles experiement und es funktioniert. es gibt hierbei aber feste regeln.
bevor ein anfänger in bascom die lib erstellen kann, ist er herausgewachsen und wechselt schon nach winavr-c um.
da mit den lib-dateien noch geld verdient wird, wird man den wahren inhalt nie richtig kennenlernen, schade eigentlich.
mfg pebisoft
25.09.2005, 13:18
PicNick

Alles, was seinen Zweck erfüllt und funktioniert, ist schon mal gut.

Geld verdienen: ATMEL verdient, MIcrochip verdient, Sharp verdient,.... Wenn mit den Zeugs, was wir so brauchen, nix zu verdienen wäre, gäb' es das alles auch nicht und wir würden durch die Finger schauen. Und mit der Software is es halt auch so. Die ganzen "Open-Source" Vereinigungen sind meist auch nur im Anfangsstadium wirklich "free".
Wenn erst mal einer richtig Arbeit reinsteckt, will er auch Kohle haben, ist ja verständlich.
25.09.2005, 14:59
roboguy

Na, da hat sich ja doch einiges getan. Diese Threads entwickeln eine gehörige Eigendynamik.
@MArco78:
Um noch einmal auf den einen Punkt zurückzukommen, den ich in meinem Ursprungsposting aufgeführt hatte ("Variableninitialisierung"):
Ich hatte wirklich diesen Code verwendet
CONST Vers_Info = "0.1"
DIM Teststring AS STRING *15
Teststring = "Version " + Vers_Info
Also Vers_Info als Konstante deklariert und den Teststring damit und dem Wert "Version " gefüllt. Wenn ich dann diesen Teststring per I2C ausgebe erscheint ein bisschen Datenmüll. Ein vorangestelltes Teststring="" unterbindet das. Schon komisch, oder?
25.09.2005, 16:37
PicNick

Ich hab' mir das mal angesehen, und aus der assemblerliste ist eigentlich kein Fehler erkennbar (auch kein unterschied durch = "")
(print statt LCD, das ist aber wurst)

Müßte man wirklich mit dem AVR-Studio debuggen.

Oder natürlich, es ist in der Gesamtsource irgendwas (aber was ?) ganz Schräges drinnen.

Wenn wer gucken will:

Code:

Const Vers_info = "0.1" Dim Teststring As String * 15 ;------------------------------------------------ ; teststring = "" ;------------------------------------------------ LDI XL,0x60 LDI XH,0x00 CLR r24 ST X,r24 ; einfach eine NULL setzen ;------------------------------------------------ : Teststring = "Version " + Vers_info ;------------------------------------------------ LDI XL,0x60 ; teststring lo LDI XH,0x00 ; hi LDI ZL,0x04 ; "Version" lo LDI ZH,0x01 ; hi CALL L_0x00F0 ; from flash to SRAM (X) ;------------------------------------------------ LDI XL,0x60 ; teststring lo LDI XH,0x00 ; teststring hi CALL L_0x00B2 ; set X to stringtop ;------------------------------------------------ LDI ZL,0x0E ; "0.1" lo LDI ZH,0x01 ; hi CALL L_0x00F0 ; from flash to SRAM (X) ;------------------------------------------------ LDI XL,0x60 ; teststring lo LDI XH,0x00 CALL L_0x00C4 ; print string CALL L_0x00D0 ; print crlf CLI ;------------------------------------------------ ;---- END ;------------------------------------------------ L_0x00B0: RJMP L_0x00B0 L_0x00FC: LPM ADIW ZL,0x0001 AND r0,r0 RET ;------------------------ literal L_0x0104: .DB 0x56, 0x65, 0x72, 0x73, 0x69, 0x6F, 0x6E, 0x20 ;Version .DB 0x00, 0x00, 0x30, 0x2E, 0x31, 0x00 ;..0.1.