Ich bin vor einiger Zeit mit dem Versuch gestrandet von Bascom auf
mikroBasic umzusteigen. Ich war so naiv zu glauben ich könnte die aus
meiner Sicht gravierenden Mängel von Bascom hinter mich lassen als da
wären
- beschränkte und umständliche ausführung von mathematischen Ausdrücken
- instabile Kompilate, insbesondere bei Projekten die mal übers Geblinke
oder von "Hallo" auf einem LCD hinaus gehen.
- ineffiziente Codeerzeugung, je größer und komplexer - um so riesiger
und langsamer das Kompilat
- unübersichtlicher Code
- veraltete IDE
ich veruchte mich dann mit mirkoBasic von mikroe und war zuerst
natürlich angetan von den Möglichkeiten, jedoch musste ich schnell
feststellen, dass mikroBasic für die AVR's wohl doch recht
stiefmütterlich behandelt wird. Die Stabilität lässt doch zu wünschen
übrig (unmengen Bugs aus meiner Sicht) und die Bibliotheken sind closed
source. Irgendwie bin ich etwas enttäuscht und denke nun:
rausgeschmissenes Geld.
Welche Erfahrungen habt ihr hier? Genauer: wie umgeht ihr die Probleme
bei den betreffenden beiden Compilern?
Torsten schrieb:> Oh, nach spätestens 3 Antworten geht wieder das große Bascom> bashing> los. Ich nutze auch Bascom, aber in diesem Forum darf man das nicht> erwähnen...
hmm also mir gehts eher um eine sachliche Betrachtung, dass es hier im
Forum glaubensgemeinschaften zu geben scheint (auch was Bascom betrifft)
ist mir durchaus bekannt. Ich würde mich aber freuen doch dann auf
sachlicher ebene zu bleiben um die Probleme zu beleuchten und
entsprechende Lösungsansätze zu lesen die der Einzelne für sich als
hilfreich herausgefunden hat.
Ohne jetzt eine Diskussion über die relativen Qualitäten von BASIC und C
vom Zaun brechen zu wollen (und wissend, dass die eh noch kommen wird):
Der GCC scheint mir deutlich ausgereifter und besser supported als jeder
dieser beiden BASIC-Compiler, sowohl was den plattformunabhängigen als
auch was den AVR-spezifischen Teil angeht.
Michael Graf schrieb:> Ohne jetzt eine Diskussion über die relativen Qualitäten von BASIC> und C> vom Zaun brechen zu wollen (und wissend, dass die eh noch kommen wird):> Der GCC scheint mir deutlich ausgereifter und besser supported als jeder> dieser beiden BASIC-Compiler, sowohl was den plattformunabhängigen als> auch was den AVR-spezifischen Teil angeht.
gar keine Frage! Ich bin Hobbyist und ich möchte aber kein C-Profi
werden was das betrifft. Es liegt mir einfach nicht, so wirds Vielen
gehen denen "ausgeschriebene" Strukturbefehle lieber sind. Lassen wir
das also bitte außen vor.
newcat schrieb:> Die Stabilität lässt doch zu wünschen> übrig (unmengen Bugs aus meiner Sicht) und die Bibliotheken sind closed> source. Irgendwie bin ich etwas enttäuscht und denke nun:> rausgeschmissenes Geld.
Da würde ich zustimmen, aber ich kenne Bascom nicht. Wenn es nicht den
Vorstellungen entspricht, dann sollte man auf was anderes wechseln.
Ich sehe das wie Michael.
Auf einem C optimierten Mikrocontroller sollte man C programmieren. Mehr
kann man dazu nicht sagen. Für Spielereien mag Bascom und mikroBasic
ganz nett sein.
Viele Grüße
newcat schrieb:> gar keine Frage! Ich bin Hobbyist und ich möchte aber kein C-Profi> werden was das betrifft. Es liegt mir einfach nicht, so wirds Vielen> gehen denen "ausgeschriebene" Strukturbefehle lieber sind. Lassen wir> das also bitte außen vor.
Ich finde es immer etwas unelegant, die Probleme eines schlechten
Werkzeugs zu umgehen, wenn es ein besseres gibt. Ich habe selbst mal mit
BASIC angefangen (vor 27 Jahren auf einem C-64...) und bin immer mal
wieder darauf zurückgekommen, z.B. für Excel-Makros. So unterschiedlich
sind BASIC und C auch wieder nicht -- beides sind prozedurale Sprachen;
die Notation kann man lernen.
Vielleicht wäre es eine Überlegung wert, doch einmal eine neue
Programmiersprache zu lernen, statt sich zu überlegen, wie sich die
Probleme proprietärer Compiler umschiffen lassen?
newcat schrieb:> gar keine Frage! Ich bin Hobbyist und ich möchte aber kein C-Profi> werden was das betrifft.
Musst du auch gar nicht.
Ob du
1
ifVariable=5then
2
...
3
endif
schreibst, oder
1
if(Variable==5)
2
{
3
...
4
}
ist doch völlig wurscht. Und sobald dir das händische Aufdröseln von
arithmetischen Anweisungen auf den Keks geht, wirst du nicht umhin
kommmen, dich mit den Regeln der Abarbeitung von Ausdrücken bzw. wann
welche Operation zum Einsatz kommt auseinanderzusetzen. Das ist nun mal
so, egal welche Sprache du nimmst.
Der wesentliche Unterschied zwischen BASCOM und C (avr-gcc) besteht
darin, dass du in BASCOM einen Haufen vorgefertigte Module hast (Timer,
LCD, UART, SPI, ...) die du mit einfachen Config-Befehln aktivieren bzw.
konfigurieren kannst. Das ist allerdings BASCOM-spezifisch und damit
wirst du in jeder anderen Sprache als BASCOM auf die Schnautze fallen.
Selbst wenn es dort ebenfalls einfache Konfigurationsmöglichkeiten gibt,
so sind die dann auch dort wieder spezfifisch. Der avr-gcc Ansatz ist es
nun mal, Zugang zu den µC-vorgegebenen Registern zu ermöglichen und sich
ansonste aus allem anderen raus zu halten. Damit hat man maximale
Flexibilität bei etwas höherem Lernaufwand. Aber wer in BASCOM begriffen
hat, was ein CTC-Modus bei einem Timer ist, der hat es auch in C
begriffen. Die Konfiguration sieht anders aus, aber der Timer
funktioniert genau gleich und macht auch exakt das gleiche.
> Es liegt mir einfach nicht, so wirds Vielen> gehen denen "ausgeschriebene" Strukturbefehle lieber sind. Lassen wir> das also bitte außen vor.
Genau darum gehst aber. C ist eine ausgewachsene Sprache, die
Sprachmittel mitbringt, die einem bei der Bearbeitung von großen,
ausgewachsenen Projekten helfen. Disziplin muss man nach wie vor haben.
Aber das ist in BASCOM ja auch nicht anders.
Hallo Karl Heinz,
es tut mir Leid, du hast durchaus Recht was die technischen Dinge
betrifft, aber ich will mich nicht mit C beschäftigen. Es sind nicht
nur die unübersichtlichen Sonderzeichen die mich verwirren, sondern auch
die viel zu mächtigen Möglichkeiten die mich hier ständig in tausend
Fallen tappen lassen würden. Von Zeigern über Pointer und sonstwas, was
für sich genommen sicher nicht das große Problem wäre, aber alles mit
tausend verschiedenen Sonderzeichen und h-files und wasweißich. Ich mags
nicht und ich will es nicht.
newcat schrieb:> Es sind nicht nur die unübersichtlichen Sonderzeichennewcat schrieb:> alles mit tausend verschiedenen Sonderzeichen
Was für Sonderzeichen? oO
newcat schrieb:> Hallo Karl Heinz,>> es tut mir Leid, du hast durchaus Recht was die technischen Dinge> betrifft, aber ich will mich nicht mit C beschäftigen. Es sind nicht> nur die unübersichtlichen Sonderzeichen die mich verwirren, sondern auch> die viel zu mächtigen Möglichkeiten die mich hier ständig in tausend> Fallen tappen lassen würden. Von Zeigern über Pointer und sonstwas, was> für sich genommen sicher nicht das große Problem wäre, aber alles mit> tausend verschiedenen Sonderzeichen und h-files und wasweißich. Ich mags> nicht und ich will es nicht.
Mit so einer Einstellung wäre es angebracht die Mängel der
angesprochenen BASICs leise und still hinzunehmen.
Denn du kannst nicht beides haben. Du kannt keine mächtige und
gleichzeitig super einfache Sprache haben. Du kannst nicht viele
Möglichkeiten haben und gleichzeitig nichts lernen und nichts verstehen
wollen. Das ist halt so. Einen Tod musst du sterben.
newcat schrieb:> sondern auch> die viel zu mächtigen Möglichkeiten
Wenn du dein BASCOM beherrscht, dann ist C abgesehen von der Syntax und
der anderen Hardwarekonfiguration erst mal auch nicht viel anders.
Mit dem einen Unterschied, dass du bei BASCOM dann schon das Ende der
Fahnenstange erreicht hast, während es in C noch weiter geht. Ob es das
jedoch tut, das entscheidest du selber und sonst niemand.
Aber ist ok. Wenn du C partout nicht magst, dann magst du es eben nicht.
Mir ging es nur um den Begriff 'C-Profi'. Denn Hand aufs Herz: bis man
ein Profi ist vergehen Jahre. Die Syntax von C zu lernen ist dabei noch
das kleinste Übel.
Ansonsten seh ich das so wie cyblord oder Sven: Auf der einen Seite
beschwerst du dich über fehlende Performance bei großen komplexen
Programmen, auf der anderen Seite willst du aber nicht wahrhaben, dass
man dazu nun mal etwas mehr Aufwand treiben muss als einfach nur alle
Variablen global zu machen und sich keine Gedanken über atomaren Zugriff
zu machen zu müssen. Das kannst du in C auch haben: schalt den Optimizer
aus und du bist wieder genau dort - inklusive fehlender Performance.
cyblord ---- schrieb:> Denn du kannst nicht beides haben. Du kannt keine mächtige und> gleichzeitig super einfache Sprache haben. Du kannst nicht viele> Möglichkeiten haben und gleichzeitig nichts lernen und nichts verstehen> wollen. Das ist halt so. Einen Tod musst du sterben.
werde ich hier tatsächlich so missverstanden?
nein so ist es nicht, ich lerne gern. Meine Abneigung bezüglich C hat
doch rein gar nichts mit meiner Lernfähigkeit zutun, wie kann man das so
hineininterpretieren? Es ist eine persönliche Abneigung gegenüber dier
technischen Anwendung und der verwendeten Syntax, nicht mehr und auch
nicht weniger.
mikroBasic ist auf den ersten Blick gegenüber BASCOM wesentlich
leistungsfähiger und solche Beschränkungen wie das nervige aufdröseln
von math. Ausdrücken gibt es da nicht, aber das erkauft man sich mit
einem - aus meiner Sicht - unbenutzbaren fehlerhaften Compiler und
stiefmütterlich behandelten Bibliotheken (zumindest im AVR-bereich).
Mehr gibts ja auch nicht für AVR nach meinem Wissensstand.
Mich interessieren tatsächlich Erfahrungsberichte und von mir aus auch
Beispiele wie man einzelne Probleme umschiffen kann, ala "nimm diesen
Patch" oder "jene Version von Bascom" usw. oder ob man halt damit leben
muss. Ich kann doch wohl nicht der Einzige sein, der sich mit Basics
befasst und Probleme festgestellt hat?
Bin auch genervt von Bascom gewesen und schon lange auf Luna
umgestiegen.
Genau das Richtige für Leute die C nicht mögen und mehr als Bascom
wollen.
http://avr.myluna.de/doku.php?id=de:about
LunaAVR...Luna ist kein Basic, eher nen aufgebohrtes Pascal mit vielen
Vorzügen aus Basic, PAscal und C
Ich arbeite auch viel mit Mikroe aber mit Mirkropascal.
Da bin ich soweit ganz zufrieden mit.
Da man auf lebenszeit gratis Updates bekommt, kann man mit einigen Bugs
leben.
Die meisten werden auch behoben, leider brauchen die immer etwas....
Mit Mikrobasic habe ich noch nicht gearbeitet, aber bei C und Pascal
scheint es halbwegs brauchbar gepflegt zu sein.
GCC habe ich auch sehr schnell verworden, alleine bis man einen
vernünftgien Compiler findet der auch gleich läuft ohne sich erst ewig
durch hunderte readme zu arbeiten..fragt man dann hier an wird man nur
beschimpft und auf readmeas verwieses...
daher würde ich nur mikroe, bascom, Lunaavr (gute community!)
ausweichen.
Die laufen, haben ne vernünftige community, bei gcc sind einfach zu
viele Klugscheißer die selber aber nichts gebacken bekommen, aber auch
keien Lust haben Anfängern zu helfen, weil ihnen damals auch nicht
geholfen wurde...ich hoffe solche bekommen niemals eigene Kinder
achja, luna hat auch noch diverse Bugs, aber das ist völlig egal, weil
oftmals bekommst Du am selben oder näcshten Tag noch ein uodate.
Die Jungs sind echt fleißig
ich dachte erst es wird Lua gemeint, das ist keine Alternative!
War mir nicht bekannt, danke, aber bevor ich wieder in neue Sachen
investiere wüsste ich doch gerne Anderer Erfahrungen dazu (ich habe mir
die umfangreichen Seiten noch nicht durchgelesen).
vielleicht eine Kurzeinschätzung zu:
- was kostets?
- muss ich mathematische Rechnungen aufdröseln?
- kann man auch mehrere Prozesse und Interrupts parallel bearbeiten
ohne dass man Angst haben muss das sich durch den Compiler alles selbst
zerschießt?
- wie groß sind die Kompilate (die sind bei mikroBasic ganz passabel)?
- ist die IDE benutzbar und unterstützt sie mich?
- gibts Bibliotheken und kann ich da auch reinschauen?
- wie ist die Geschwindigkeit?
- welche Debugmöglichkeiten gibts (Simulator, Debugger oder
Code-interne Anweisungen)?
- kann man Assembler einbinden?
- kann man Bootloader auch direkt in der Sprache schreiben oder ist man
auf Assembler angewiesen?
- wird Atxmega unterstützt?
?
Die IDe ist der Hammer, und extrem einfach.
Du tippst den Processor in die erste zeile und bekommst lgeich ein Bild
von ihm samt Pinbelegung eingeblendet!
Aufbröseln für mathmatische funktionen mußt Du weniger als bei Bascom,.
Da entspricht es Pascal, besser gehts im normlaen Programmierbereich
nicht wenn es keine spezielle Programmiersprache für Mathematik sein
soll
Xmega wird durch meine Anregung untersützt (2 Tage später!!!)
NAchdem der Hauptprogrammierer geshen hat, das die Unterscheide gar
nicht so groß sind, hat er alles für Xmega freigeschalte.
Asm ist problemlos einbindbar wie bei mikroe auch.
Ba, alle Libs sind Quelloffen! es können auch eigene eignebrunden werden
etc pp..
schau es Dir an, es wird Dir gefallen.
Viele denken im ersten moment Luna währe nen aufgebohrtes Basic, weil
es auf dem ersten Blick Bascom ähnlich sieht..auf dem zweiten dann
PAscal :-)
Ob auch C auf den zweiten Blick zu sehen ist, k.a. dafür habe ich zu
nweig mit C gespielt
> Die IDe ist der Hammer, und extrem einfach.> Du tippst den Processor in die erste zeile und bekommst lgeich ein Bild> von ihm samt Pinbelegung eingeblendet!
Das schaut ja wirklich in jeder Hinsicht Spitze aus! Ich glaube, das
wäre was für mich.
Karl Heinz schrieb:> dann ist C abgesehen von der Syntax und> der anderen Hardwarekonfiguration erst mal auch nicht viel anders.
Karlheinz!
Du weißt es besser, also schreib es auch besser!!
"abgesehen von der Syntax.."
C ist vollgestopft mit Seiteneffekten und unlogischen Definitionen a la
"Ordre de Mufti", die man allesamt erstmal lernen muß. Sonst fällt man
mit C gnadenlos auf die Nase. Das ist hinlänglich bekannt und
vollständig anders als bei jedem BASIC-Dialekt - und auch anders als
bei Pascal, nebenbei gesagt.
Abgesehen davon ist das Gewurschtel mit Sonderzeichen tatsächlich nicht
jedermanns Fall. Ich kann da den TO durchaus verstehen. Es macht eben
einen Unterschied in der schlichten Lesbarkeit zwischen && und AND oder
A * P und A P^ und Konsorten. Bedenke mal, daß all dieses Gekringel
außerhalb der C-Käseglocke herzlich abwegig erscheint - eben als
Programmiersprache von und für Sprachgestörte.
Ähem.. nochwas:
"Auf einem C optimierten Mikrocontroller sollte man C programmieren"
Sowas gibt es nicht. Ein µC kann für Hochsprachen insgesamt optimiert
sein oder eben nicht. Typisches Beispiel sind die PIC16xxx, die für
Assembler gedacht sind und sich bei eigentlich allen
hardware-abstrahierenden Sprachen eher störrisch zeigen. Der eigentliche
Knackpunkt bei solchen Sprachen ist es ja eben gerade, daß sie dem
Programmierer eine Programmierumgebung bieten, die NICHTS mit der
darunter liegenden Hardware zu tun hat, auf der später das Kompilat
laufen soll.
W.S.
hmmm, also das ist ja alles schön bunt usw., aber bevor ich jetzt meine
beiden Lizenzen wegwerfe und umsteige: hast du eventuell ein Beispiel
für mich bezüglich das was ich oben genannt habe (atmega32u4 USB)? Damit
würde ich gerne mal spielen um mir eine Meinung bilden zu können.
ne, ich selber arbeite schon länger nicht mehr mit Luna, wie gesagt,
nutze ich mikroe, da man da sehr einfach von einem zum anderen Processor
springen kann, also ARM, AVR etc...
Dann gibt es auch nicht die Probleme die hier so oft besprochen werden,
da man eben nicht direkt auf den Controller zugreift sondern immer über
die Libs .
Frag doch einfach mal im Forum bei luna an, die sind echt freundlich
dort auch wenn die Frage schon mehrfach gestellt worden..wird sie
beantwortet!! Was die meisten hier irgendwie verlernt haben.
Ich vemrute mal das die noch kein USb unterstützen, mach Mikroe derzeit
noch nicht mal.
Würde mich aber nicht wundern, wenn Du dort eine Umfrage machst, und
viele das gut finden würden, das Du in zweo Wochen oder so Deine USb
Unterstützung hast :-)
Wer hier meint, dass Bascom nur für Anfänger gut ist, der sollte sich
doch mal ein Bascom Programm vom "Assemblermeister" Hannes Lux
anschauen: Beitrag "Re: Bascom AVR endlich meins"
Was sagt uns das? Wenn man keine Idee hat, hilft auch keine IDE weiter.
Ein richtig guter Programmierer wie H.L. kann seine Ziele mit jeder IDE
umsetzen, auch - oder gerade mit- Bascom.
SCNR
Ich schrieb:> Wer hier meint, dass Bascom nur für Anfänger gut ist, der sollte sich> doch mal ein Bascom Programm vom "Assemblermeister" Hannes Lux> anschauen:
Besagter 'Hannes Lux' sagte aber auch im betreffenden Thread:
1
Auch das kommt auf den Programmierer an. Wer ohne jegliches
2
Hintergrundwissen betreffs Architektur (und damit auch ASM-Befehlssatz)
3
drauflos programmiert, wird mit keiner Programmiersprache was Brauchbares
4
zustande bringen.
und darin stimme ich ihm zu 100% und uneingeschränkt zu.
Im übrigen habe ich mit Hannes schon vor Jahren meinen Frieden
geschlossen. Wir beide sehen 'unsere' Sprachen als ein Werkzeug an.
Nicht mehr und nicht weniger.
newcat schrieb:> ich dachte erst es wird Lua gemeint, das ist keine Alternative!> War mir nicht bekannt, danke, aber bevor ich wieder in neue Sachen> investiere wüsste ich doch gerne Anderer Erfahrungen dazu (ich habe mir> die umfangreichen Seiten noch nicht durchgelesen).>> vielleicht eine Kurzeinschätzung zu:
Meine Kurzeinschätzung ist, dass es sich für dich lohnen wird dich in
LunAVR einzulesen ;o)
Und ja, LunaAVR ist kostenlos. Ich zitiere aus den FAQ:
"Die Philosophie der Programmiersprache Luna ist, Privatanwendern und
auch Firmen ein innovatives Werkzeug für die Softwareentwicklung
kostenlos zur Verfügung zu stellen. Erst bei einer kommerziellen
Verwendung von einzelnen für Luna verfügbaren Klassen oder
Funktionsbibliotheken verschiedener Autoren werden Ggf. Lizenzgebühren
fällig. Dies ist im Einzelnen von den Lizenzbestimmungen der jeweiligen
Autoren abhängig."
kopfkratz
Immer diese sinnlosen Diskussionen m(
Wer Assembler auf seinem Lieblings-µC aus dem FF kann soll Assembler
programmieren, wer C++/C beherrscht und abstrakt sowie relativ Plattform
unabhängig denken/programmieren kann soll das tun und wer schnell und
ohne sich viel in die Architektur einarbeiten zu müssen programmieren
will soll BASIC nehmen.
Der Compiler baut ja erstmal Assembler der dann in den OPCode verwandelt
wird.
Wie gut die jeweilige Architektur unterstützt wird hängt halt vom
Entwicklerteam des jeweiligen Compilers ab, welche formale Sprache das
ist bleibt sich gleich.
Daher einfach vorher austesten bzw. Reviews durchlesen (und zwar alle
die man bekommen kann) bevor man Geld für etwas ausgibt was den Vorgaben
nicht gerecht wird.
ElektronikFreak schrieb:> Ich sehe das wie Michael.>> Auf einem C optimierten Mikrocontroller sollte man C programmieren. Mehr> kann man dazu nicht sagen. Für Spielereien mag Bascom und mikroBasic> ganz nett sein.>> Viele Grüße
Hallo ElektronikFreak ???
was um Odin's Willen ist ein:
"C optimierter Mikrocontroller" - bitte um eine sinnige Erklärung bzw.
Antwort.
In den Forenregeln von Andreas steht u.a. "Wichtige Regel - erst lesen,
dann posten!
Die "neue Katze" outet sich als Hobbyist, wo ist das Problem.
Ein Beispiel: Wieviele Menschen versuchen tagtäglich Fussball zu
spielen, wievielen gelingt das in einer akzeptablen Qualität.
Als Hobbyist wird die "neue Katze" keine Grossflughäfen (wahrscheinlich
ein schlechtes Beispiel) programmieren. Das ist auch gar nicht der Sinn
- die "Arbeit" nach der Arbeit verschafft den notwendigen Abstand zu der
vom Arbeitgeber verordneten !!!!!
Ob Basic, Pascal, Fortran, C, Assembler, itd, zum Schluss ist es eine
xxx.HEX die in den Controller kommt. Wenn das Endprodukt dem Erzeuger
gefällt ist das O.K.
@ Autor: Karl Heinz (kbuchegg) (Moderator)
Datum: 02.01.2014 16:44
Du bist Moderator !?
Zitat:
Der wesentliche Unterschied zwischen BASCOM und C (avr-gcc) besteht
darin, dass du in BASCOM einen Haufen vorgefertigte Module hast (Timer,
LCD, UART, SPI, ...)
Wenn ich das dem Peter erzähle.
Ein Beispiel:
Title: Interrupt UART library with receive/transmit circular buffers
Author: Peter Fleury <pfleury@gmx.ch> http://jump.to/fleury
Zum Schluss, laut Marc Alberts soll Assembler in Bascom implementierbar
sein.
einen schönen Abend
Grelli
Ralf-Peter Grellmann schrieb:> "C optimierter Mikrocontroller" - bitte um eine sinnige Erklärung bzw.> Antwort.
Als Vorteilhaft für die Implementierung von C ist es, wenn die
Zielarchitektur einen Stack und Zeigerregister besitzt. Das sind Dinge,
die z.B. AVR oder STM32 für C sinnvoll machen, die PIC16 aber
beispielsweise nicht.
Mehr als diese Frage konnte ich deinem Gestammel leider nicht entnehmen.
Ralf-Peter Grellmann schrieb:> Ob Basic, Pascal, Fortran, C, Assembler, itd, zum Schluss ist es eine> xxx.HEX die in den Controller kommt. Wenn das Endprodukt dem Erzeuger> gefällt ist das O.K.
Das ist der große Trugschluss der Software-Entwicklung. Für Hobby kann
man das vielleicht noch ignorieren... Bei sehr viel Software zählt aber
auch die Qualität des Quell-Codes (und nicht nur der .hex), wie sauber
der strukturiert ist, wie gut/schnell man Änderungen vornehmen kann. Und
da helfen richtige™ Programmiersprachen wie C++ eine Menge bei.
Ich schrieb:> vom "Assemblermeister"
Du übertreibst schamlos! Die Meister musst Du woanders suchen.
Ich benutze Assembler, weil mir für meine Zwecke Portablität nicht
wichtig ist und weil mir C zu kryptisch ist. Der Vorteil von Assembler
ist ja, dass nur das Datenblatt (incl. Befehlssatzbeschreibung, die ich
als ausgelagerten Teil des Datenblattes verstehe) gilt und ich mich
nicht mit Eigenheiten von Compilern herumärgern muss. Bascom nutze ich
nur bei Programmen, die nicht viel Ressourcen benötigen und wenn der
"Auftraggeber" meint, er würde es besser verstehen, weil er aus
C64-Zeiten oder Z80-Zeiten noch Basic kennt.
Karl Heinz schrieb:> Im übrigen habe ich mit Hannes schon vor Jahren meinen Frieden> geschlossen. Wir beide sehen 'unsere' Sprachen als ein Werkzeug an.
Richtig. Wer C kann, der soll es benutzen. Wer Basic kann, und in der
Lage ist, es so ressourcenschonend einzusetzen, dass die Programme auf
dem kleinen AVR laufen, der soll es nutzen. Luna und das andere
Mikro-Zeugs kenne ich nicht und kann es daher auch nicht beurteilen.
AVR-ASM ist für mich der einfachste Weg, da gibt es die wenigsten
Fallstricke und Fußangeln. Wer aber meint, er brauche eine
Programmiersprache, mit der man auch das programmieren kann, was man gar
nicht verstanden hat, der irrt...
newcat schrieb:> das nervige aufdröseln von math. Ausdrücken
Hmmm... Wer den Ausdruck verstanden hat, der kann ihn auch ohne Mühe
aufdröseln. Wer die "Formel" nicht verstanden hat, der sollte vermeiden,
sie unbesehen zu benutzen. Klingt jetzt etwas hart oder sogar arrogant,
ist aber unterm Strich so. Außerdem bieten aufgedröselte Berechnungen
Zwischenergebnisse, anhand derer man die Rechnung überprüfen kann. Das
zahlt sich dann bei der Fehlersuche aus, wenn man z.B. übersehen hat,
dass ein Zwischenwert zu groß für seine Variable ist und die oberen Bits
abgeschnitten wurden. Oder umgekehrt, dass der Wert zu klein wurde und
mit 0 weitergerechnet wird.
...
Hannes Lux schrieb:> Hmmm... Wer den Ausdruck verstanden hat, der kann ihn auch ohne Mühe> aufdröseln. Wer die "Formel" nicht verstanden hat, der sollte vermeiden,> sie unbesehen zu benutzen. Klingt jetzt etwas hart oder sogar arrogant,> ist aber unterm Strich so. Außerdem bieten aufgedröselte Berechnungen> Zwischenergebnisse, anhand derer man die Rechnung überprüfen kann. Das> zahlt sich dann bei der Fehlersuche aus, wenn man z.B. übersehen hat,> dass ein Zwischenwert zu groß für seine Variable ist und die oberen Bits> abgeschnitten wurden. Oder umgekehrt, dass der Wert zu klein wurde und> mit 0 weitergerechnet wird.
Ich programmiere auch schon sehr lange parallel mit Assembler, das Eine
hat aber mit dem Anderen nichts zutun, denn von einer Hochsprache darf
man schon erwarten, dass sie einem gerade das abnehmen kann. Wenn ich
aber nichtmal a * b + c schreiben kann, sondern das in einzelne
Variablen aufdröseln muss um diese ausgesprochen pupssimple Rechnung
auszuführen, dann ist das für mich eher behindernd als eine
Verbesserung. Da kann ich dann ebend nicht wie in Assembler die
Argumente in Registern vorhalten, sondern muss extra Variablen auch noch
dimensionieren und hin und herschaufeln. Was hat das bitteschön mit der
Unterstellung gemein man würde ja dann "die Formel" nicht verstehen?
sorry, aber das ist doch nun wirklich totaler Quark!
Ich möchte auch nochmal betonen, was ich als Anfangspost geschrieben
habe. Ich habe für mich eklatante Qualitätsmängel an kommerziellen
Produkten festgestellt, von denen ich etwas enttäuscht bin und versuche
einfach ein paar Tips und Kniffe hinzuzulernen bzw. Meinungen
einzuholen. Hätte ja auch sein können, dass ich hier der Einzige bin der
diese Probleme hat und ich einfach zu blöd bin das versteckte Feature zu
finden um z.Bsp. bei Bascom die "lange Formel" einzuschalten (um es mal
mit deinen Worten zu sagen).
was "luna" betrifft bin ich tatsächlich begeistert auf den ersten Blick,
da wurde nichts zuviel versprochen, aber ich bleibe skeptisch und sehe
mir das ganz genau an bevor ich mir da eine konstruktive Meinung bilden
will.
Jetzt wird es mir klar! Ich dachte immer, die fehlende Möglichkeit,
Ausdrücke in weniger umständlich als in ASM hinschreiben zu können, wäre
ein Manko. Aber das ist ein Debug-Feature um die Zwischenergebnisse
sehen zu können. Schade daß das in anderen Sprache nicht erzwungen wird.
Mal Ironie (kurz) beiseite. Hochsprachen macht aus, daß man nicht jede
Bitschieberei hinschreiben muß (bestenfall aber gerne kann), denn dann
kann man auch gleich ASM verwenden. Dann darf man sich auch merken, in
welchem Register man gerade welches Zwischenergebnis abgelegt hat. Und
das über das ganze Programm, falls man ein Register als
"static"-Variable vorgesehen hat. Ich lasse das lieber den GCC machen,
dem macht das mehr Spaß.
Wenn schon "nicht C", dann scheint mir Luna obige Kriterien besser zu
erfüllen. Kenn ich aber nur von Doku lesen und was die so als
"Objektorientierung" ansehen, na ja. Besser als baschcom aber immer. Ist
ja auch nicht schwer.
newcat schrieb:> Ich habe für mich eklatante Qualitätsmängel an kommerziellen> Produkten festgestellt,
Die von dir beschriebenen "Qualitätsmängel" werden aber in der Regel von
dem Typen vor dem Bildschirm verursacht.
newcat schrieb:> - instabile Kompilate, insbesondere bei Projekten die mal übers Geblinke> oder von "Hallo" auf einem LCD hinaus gehen.> - ineffiziente Codeerzeugung, je größer und komplexer - um so riesiger> und langsamer das Kompilat> - unübersichtlicher Code
Das sind typische Beispiele für schlechte Progrmmierarbeit. Der Compiler
übersetzt nur das was du so zusammen schreibst. Bis auf einen
Syntaxcheck wird er deine Fehler mit übersetzen.
Meine Programme laufen normalerweise ohne Probleme, wenn der Quellcode
stimmt. Und wirklich langsam sind die auch nicht und manche sehr
umfangreich.
Ich habe selber auch schon Fehler in Bascom gefunden. Das waren meistens
fehlerhafte Registereinstellungen bei config ... zum Beispiel.
newcat schrieb:> Wenn ich> aber nichtmal a * b + c schreiben kann, sondern das in einzelne> Variablen aufdröseln muss
Das würde folgendes ergeben:
Result = a * b
Result = Result + c
Nicht sehr effizient, funktioniert aber trotzdem.
Tom schrieb:> wieso ist das nicht effizient?> Du weißt doch gar nicht, was der compiler daraus macht...
Nicht effizient zu coden. Basic ist sowieso schon viel zu geschwätzig,
aber wenn man dann auch noch Rechnungen aufdröseln muss. Ich überlege
gerade ob man das bei meinem Apple IIc auch musste. Ich glaube
Applesoft Basic hatte hier keine Einschränkungen. Peinlich sowas
heutzutage.
Das kommt da raus. Und ja, ich kann auch Assembler.
28: Result = A * B
+00000079: E0A0 LDI R26,0x00 Load immediate
+0000007A: E0B1 LDI R27,0x01 Load immediate
28: Result = A * B
+0000007B: 910D LD R16,X+ Load indirect and
postincrement
+0000007C: 2711 CLR R17 Clear Register
28: Result = A * B
+0000007D: E0A1 LDI R26,0x01 Load immediate
+0000007E: E0B1 LDI R27,0x01 Load immediate
28: Result = A * B
+0000007F: 914D LD R20,X+ Load indirect and
postincrement
+00000080: 2755 CLR R21 Clear Register
28: Result = A * B
+00000081: 940E00C2 CALL 0x000000C2 Call subroutine
28: Result = A * B
+00000083: E0A3 LDI R26,0x03 Load immediate
+00000084: E0B1 LDI R27,0x01 Load immediate
28: Result = A * B
+00000085: 930D ST X+,R16 Store indirect and
postincrement
+00000086: 931C ST X,R17 Store indirect
29: Result = Result + C
+00000087: E0A3 LDI R26,0x03 Load immediate
+00000088: E0B1 LDI R27,0x01 Load immediate
29: Result = Result + C
+00000089: 910D LD R16,X+ Load indirect and
postincrement
+0000008A: 911C LD R17,X Load indirect
29: Result = Result + C
+0000008B: E0A2 LDI R26,0x02 Load immediate
+0000008C: E0B1 LDI R27,0x01 Load immediate
29: Result = Result + C
+0000008D: 914D LD R20,X+ Load indirect and
postincrement
+0000008E: 2755 CLR R21 Clear Register
29: Result = Result + C
+0000008F: 0F04 ADD R16,R20 Add without carry
+00000090: 1F15 ADC R17,R21 Add with carry
29: Result = Result + C
+00000091: E0A3 LDI R26,0x03 Load immediate
+00000092: E0B1 LDI R27,0x01 Load immediate
29: Result = Result + C
+00000093: 930D ST X+,R16 Store indirect and
postincrement
+00000094: 931C ST X,R17 Store indirect
32: Loop
+00000095: 940C0079 JMP 0x00000079 Jump
+000000C2: 920F PUSH R0 Push register on stack
34465: Error: Invalid line
+000000C3: 01B8 MOVW R22,R16 Copy register pair
+000000C4: 9F46 MUL R20,R22 Multiply unsigned
34465: Error: Invalid line
+000000C5: 0180 MOVW R16,R0 Copy register pair
+000000C6: 9F47 MUL R20,R23 Multiply unsigned
34465: Error: Invalid line
+000000C7: 0D10 ADD R17,R0 Add without carry
+000000C8: 9F56 MUL R21,R22 Multiply unsigned
34465: Error: Invalid line
+000000C9: 0D10 ADD R17,R0 Add without carry
+000000CA: 900F POP R0 Pop register from
stack
34465: Error: Invalid line
+000000CB: 9508 RET
ich nahm mal an das a,b und c byte sind und result word, dann spuckt der
luna compiler das aus (es wird löblicherweise ein assembler-output
generiert):
1
;{15}{ result = a*b+c } ------------------------------------------------
2
lds _HB0,dVarClassAvrA
3
lds _HA0,dVarClassAvrB
4
rcall _MathMUL8x8_16U
5
movw _HB1:_HB0,_HA1:_HA0
6
lds _HA0,dVarClassAvrC
7
clr _HA1
8
add _HA0,_HB0
9
adc _HA1,_HB1
10
sts dVarClassAvrResult+0,_HA0
11
sts dVarClassAvrResult+1,_HA1
nicht ganz optimal aber schon besser als was ich bisher so gesehen
hatte. Da gibts noch irgendwelche Optimierungsoptionen bei den
Compilerparametern, keine Ahnung ob da noch was anderes geht.
Holli schrieb:> Das kommt da raus. Und ja, ich kann auch Assembler.Sven P. schrieb:> Ralf-Peter Grellmann schrieb:>> "C optimierter Mikrocontroller" - bitte um eine sinnige Erklärung bzw.>> Antwort.> Als Vorteilhaft für die Implementierung von C ist es, wenn die> Zielarchitektur einen Stack und Zeigerregister besitzt. Das sind Dinge,> die z.B. AVR oder STM32 für C sinnvoll machen, die PIC16 aber> beispielsweise nicht.>> Mehr als diese Frage konnte ich deinem Gestammel leider nicht entnehmen.
Gerade habe ich eine EMail von 'Ralf-Peter Grellmann' bekommen. Ich bin
so frei, das zu zitieren:
> Der Benutzer 'ralfpeter' hat Ihnen die folgende Nachricht geschickt:>> ====================================> kiffen schadet dem Hirn> ====================================>> Den Benutzer können Sie erreichen, indem Sie einfach auf diese E-Mail> antworten, oder ihm eine Benutzernachricht über das Forum senden:> http://www.mikrocontroller.net/user/show/ralfpeter
Ich klink mich jetzt aus, der Kindergarten hier wird ernstlich
unerträglich.
Sven P. schrieb:>> Der Benutzer 'ralfpeter' hat Ihnen die folgende Nachricht geschickt:>>>> ====================================>> kiffen schadet dem Hirn>> ====================================
Vielleicht schreibt er nur dass, was ihn selbst passiert ist und meint
gar nicht Dich. ;-)
Bleib einfach gelassen und ignoriere so ein Geschreibsel.
cyblord ---- schrieb:> Ich glaube Applesoft Basic hatte hier keine Einschränkungen.
War das nicht ein Interpreter? An compilerläufe kann ich mich nicht
erinnern.
W.S. schrieb:> "abgesehen von der Syntax.."> C ist vollgestopft mit Seiteneffekten und unlogischen Definitionen a la> "Ordre de Mufti", die man allesamt erstmal lernen muß. Sonst fällt man> mit C gnadenlos auf die Nase. Das ist hinlänglich bekannt und> vollständig anders als bei jedem BASIC-Dialekt - und auch anders als> bei Pascal, nebenbei gesagt.
Es ist nun mal ne Art Assemblersteno
>> Abgesehen davon ist das Gewurschtel mit Sonderzeichen tatsächlich nicht> jedermanns Fall. Ich kann da den TO durchaus verstehen. Es macht eben> einen Unterschied in der schlichten Lesbarkeit zwischen && und AND oder> A * P und A P^ und Konsorten. Bedenke mal, daß all dieses Gekringel> außerhalb der C-Käseglocke herzlich abwegig erscheint - eben als> Programmiersprache von und für Sprachgestörte.
So kam es mir auch vor, aber inzwischen habe ich das zu schätzen
gelernt.
Basic ist ne gute Sprache wenn es um Lösungen geht, aber auf einem uC
schreibt man nun mal ein Betriebssystem. Da hat C richtig Power
Angefangen habe ich mit HP Basic. Eine Sprache von hoher Qualität für
Messgeräte. Die war so gut da will man nicht von weg.
Habe dann 20 Jahre Basic gemacht, auch auf Mikrocontrollern. Jetzt Will
ich aber nicht mehr zurück. Bin froh mich durch diesen C Dschungel
durchgewühlt zu haben.
Die größte Hürde war komischerweise zu kapieren das ein Programm hinter
der main(){ Klammer anfängt und nicht bei Zeile 10 (was nun auch nicht
gerade logisch ist).
Da ich die strikte Zeilenordnung von Basic verinnerlicht hatte schwebte
C-Code für mich am Anfang haltlos im Raum. Bis sich das feeling von
Zeile
10
20
30
zu
Ergebnis function(Parameter);
gewandelt hatte verging gefühlt ne Ewigkeit
Holli schrieb:> Das kommt da raus.
Oh mein Gott. 53 Takte und das ohne jede Überlaufprüfung. Man muß sich
schon ziemlich anstrengen, das irgendwie noch langsamer hinzubekommen,
ohne mit NOPs oder Zählschleifen gleich direkt offensichtliche Bremsen
einzubauen.
Die optimale Umsetzung (unter voller Berücksichtigung zumindest aller
aus dem Code offensichtlichen Randbedingungen des Compilers bezüglich
der Registernutzung) sähe etwa so aus:
lds R16,$100 ; 2
lds R20,$101 ; 2
clr R21 ; 1
mov R22,R0 ; 1 ;keine Ahnung, weswegen er eigentlich R0 rettet
mul R16,R20 ; 2
movw R16,R0 ; 1
mov R0,R22 ; 1 ;aber R22 ist offensichtlich unwichtig->als scratch
ok
lds R20,$102 ; 2
add R16,R20 ; 1
adc R17,R21 ; 1
sts $103,R16 ; 1
sts $104,R17 ; 1
;--
;16
Das BASCOM-Compilat ist also ca. 3,5 mal langsamer als nötig und
nebenbei auch noch ca. 3 mal so groß wie nötig.
Das ist eigentlich wohl kein wirklicher Compiler, sondern mehr sowas wie
ein primitiver Interpreter, dessen Operationen als Binäry eingefroren
werden. Und für sowas wird auch noch Geld verlangt? Kaum zu fassen...
> Angefangen habe ich mit HP Basic. Eine Sprache von hoher Qualität für
Messgeräte. Die war so gut da will man nicht von weg.
Da werden Erinnerungen wach. Dieses Rocky Mountain Basic war damals um
Lichtjahre allen anderen Basic-Dialekten voraus. Es lief aber nur auf
HP-Rechnern. Ich hatte damit einen Simulator für eine mikroprommierbare
Hardware geschrieben.
http://en.wikipedia.org/wiki/Rocky_Mountain_BASIC
Zurück zu C. Ich hatte vor mehr als 10 Jahren ein bisschen mit
AVR-Assembler experimentiert und dann die AVRs beiseite gelegt. Kürzlich
habe ich mit C für AVRs mit AVR-Studio angefangen. Es ist eine echte
Wohltat weg von Assembler zu sein. Allerdings kannte ich
C-Programmierung schon vom PC. Als Programmer habe ich den AVRISP mkII.
Damit ist alles schön integriert in der IDE von AVR.
Gruß
Helmut
Der Rächer der Transistormorde schrieb:> cyblord ---- schrieb:>> Ich glaube Applesoft Basic hatte hier keine Einschränkungen.>> War das nicht ein Interpreter? An compilerläufe kann ich mich nicht> erinnern.
Das ist völlig richtig. Es war ein Interpreter. Trotzdem kann ich mich
an keine solchen Einschränkungen bezüglich arithmetischer Ausdrücke
erinnern, wie sie hier bemängelt werden.
Und wann war der IIc aktuell? 1984 schätz ich.
gruß cyblord
cyblord ---- schrieb:> Das ist völlig richtig. Es war ein Interpreter. Trotzdem kann ich mich> an keine solchen Einschränkungen bezüglich arithmetischer Ausdrücke> erinnern, wie sie hier bemängelt werden.
Die gabs auch nie. Zumal das Aufdröseln von arithmetischen Ausdrücken in
eine Sequenz von Operationen eine leichte Übung ist, die im Compilerbau
sozusagen als Aufwärmübung benutzt wird. Schwieriger ist es dann schon,
eine vernünftige Registerbelegung zu finden. Aber solange man das als
UPN abhandelt, ist es reichlich trivial.
BASCOM ist der einzige Compiler den ich kenne, der dieses nicht
beherrscht. Warum das so ist? Ehrlich - keine Ahnung. Es gibt IMHO
keinen wirklichen Grund dafür, den Programmierer nicht von dieser Bürde
zu befreien.
Karl Heinz schrieb:> BASCOM ist der einzige Compiler den ich kenne, der dieses nicht> beherrscht. Warum das so ist? Ehrlich - keine Ahnung. Es gibt IMHO> keinen wirklichen Grund dafür, den Programmierer nicht von dieser Bürde> zu befreien.
Werden die Kosten sein. Entweder man hat selbst eine Compilerkern
gefummelt und es war zu umständlich oder man hat nen scheiß eingekauft
weils billig war.
Aber das Kalkül geht ja auf, denn die ganzen Anfänger stürzen sich
darauf und zahlen auch noch dafür, als einen ausgereiften gratis
Compiler wie gcc zu nehmen, der sich über solche Animositäten scheckig
lacht.
Auch das Commodore Basic V1 auf dem originalen PET (1977) konnte ohne
Probleme komplexe arithmetische Ausdrücke verarbeiten.
Es ist schon merkwürdig, wie stark viele Leute an BASCOM klammern, trotz
guter Alternativen (muss ja kein C sein). Aber die irrationale Abneigung
gegenüber C ist mir ebenso ein Rätsel.
> BASCOM ist der einzige Compiler den ich kenne, der dieses nicht
beherrscht. Warum das so ist?
Ich denke der Grund ist einfach der, dass Bascom auch auf einem AVR mit
64 Byte RAM laufen muss. Da hat man einfach nicht viel
Extra-Speicherplatz um lange Zeilen zu interpretieren.
cyblord ---- schrieb:> Karl Heinz schrieb:>>> BASCOM ist der einzige Compiler den ich kenne, der dieses nicht>> beherrscht. Warum das so ist? Ehrlich - keine Ahnung. Es gibt IMHO>> keinen wirklichen Grund dafür, den Programmierer nicht von dieser Bürde>> zu befreien.>> Werden die Kosten sein.
Das geile daran ist ja, dass die Auflösung einer Expression jeder
Compilerbauanfänger in einem Vormittag runterprogrammiert. Von daher seh
ich das noch nicht mal als Kostenfrage.
Helmut S. schrieb:>> BASCOM ist der einzige Compiler den ich kenne, der dieses nicht> beherrscht. Warum das so ist?>> Ich denke der Grund ist einfach der, dass Bascom auch auf einem AVR mit> 64 Byte RAM laufen muss. Da hat man einfach nicht viel> Extra-Speicherplatz um lange Zeilen zu interpretieren.
Daran hatte ich zuerst auch gedacht. Aber dann kann man immer noch eine
Fehlermeldung ausgeben: Expression too complex.
Wenn man mit selbstgestrickten Hilfsvariablen ans Ziel kommt, dann gibt
es kaum einen Grund, warum sich nicht der Compiler selber derartige
Hilfsvariablen erzeugen können soll, solange der Platz dafür reicht.
Prüfen muss er den Platz so oder so.
> Das geile daran ist ja, dass die Auflösung einer Expression jeder
Compilerbauanfänger in einem Vormittag runterprogrammiert.
So so und dann mit 64Byte RAM auskommt. Das will ich sehen.
Helmut S. schrieb:> Ich denke der Grund ist einfach der, dass Bascom auch auf einem AVR mit> 64 Byte RAM laufen muss. Da hat man einfach nicht viel> Extra-Speicherplatz um lange Zeilen zu interpretieren.
BASCOM ist aber kein Interpreter, sondern (in der Theorie) ein richtiger
Compiler. Mehr schlecht als recht, aber wenn man sowieso einen Compiler
implementiert, kann man es mit minimalem Aufwand hinbekommen,
verschachtelte Ausdrücke auszuwerten.
Helmut S. schrieb:>> Das geile daran ist ja, dass die Auflösung einer Expression jeder> Compilerbauanfänger in einem Vormittag runterprogrammiert.>> So so und dann mit 64Byte RAM auskommt. Das will ich sehen.
Unsere Antworten haben sich überschnitten.
Ich hab kein Problem damit, wenn der Compiler bei wirklich großen
Expressions einen 'too complex' Fehler meldet. Wenn ich als
Programmierer Hilfsvariablen benutzen muss, dann kann das der Compiler
auch.
@Karl-Heinz
Da hast du natürlich recht. Wenn BASCOM das vorher schon auf dem PC
auswertet(kompiliert), dann braucht man dafür kein extra-RAM.
Vielleicht kann ja jemand mal eine freundliche Anfrage bei den
BASCOM-Entwicklern machen. Ich denke es gibt da bestimmt einen
nachvollziehbaren Grund warum sie diese Beschränkung eingebaut haben.
greg schrieb:> BASCOM ist aber kein Interpreter, sondern (in der Theorie) ein richtiger> Compiler.
Aber der Compiler laueft ja nicht auf dem AVR sondern auf dem PC und da
hat man RAM ohne Ende. Das fertige Compilat muss ja nur auf dem
Zielprozessor laufen. Von daher gibt es keinen Grund das nicht
hinzubekommen ausser der Compilerprogrammierer hat den Grad seiner
Inkompetenz schon ueberschritten.
Helmut Lenzen schrieb:> greg schrieb:>> BASCOM ist aber kein Interpreter, sondern (in der Theorie) ein richtiger>> Compiler.>> Aber der Compiler laueft ja nicht auf dem AVR sondern auf dem PC und da> hat man RAM ohne Ende. Das fertige Compilat muss ja nur auf dem> Zielprozessor laufen. Von daher gibt es keinen Grund das nicht> hinzubekommen ausser der Compilerprogrammierer hat den Grad seiner> Inkompetenz schon ueberschritten.
Ja, das ist im Prinzip genau mein Argument, hatte nur vergessen das
nochmal zu erwähnen.
Allerdings gibt es in BASCOM auch sonst ein paar Syntax-Besonderheiten,
die mir immer schon etwas seltsam vorgekommen sind.
Beispiel
1
CONFIG LCD = 16*2
Huch! wie jetzt, das LCD ist 32?
Oder
1
if ... then
2
3
else if ...
4
5
endif
zwischen else und if kommt ein Leerzeichen. Zwischen end und if aber
nicht.
Alles in allem sieht die Syntax über weite Strecken sehr
zusammengewürfelt aus. Sowas würde man erwarten, wenn mehrere Personen
über einen längeren Zeitraum Erweiterungen machen und jeder seine
Ansicht über 'dir richtige Syntax' auf Biegen und Brechen durchdrücken
will.
Das wars von mir. Alles in allem finde ich BASCOM grundsätzlich nicht so
schlecht. Verwenden tu ich es trotzdem nicht, denn die genannten
Unlogikkeiten sind mir persönlich zu viel. Da bleib ich lieber bei C.
Das hat zwar auch so seine Fallen, aber in Summe finde ich die Syntax
davon durchgängiger.
Helmut S. schrieb:> Vielleicht kann ja jemand mal eine freundliche Anfrage bei den> BASCOM-Entwicklern machen. Ich denke es gibt da bestimmt einen> nachvollziehbaren Grund warum sie diese Beschränkung eingebaut haben.
Bei der Gelegenheit kann man den auch fragen, warum er keine
Schachtelungskontrolle für FOR-NEXT gemacht hat
das hier
1
for i = 1 to 5
2
for j = 2 to 8
3
next i
4
next j
wird anstandslos compiliert. Noch nicht mal eine Warnung.
Karl Heinz schrieb:> Allerdings gibt es in BASCOM auch sonst ein paar Syntax-Besonderheiten,> die mir immer schon etwas seltsam vorgekommen sind.>> BeispielCONFIG LCD = 16*2>> Huch! wie jetzt, das LCD ist 32?
Ist wie beim Deo 8x4, habe mich schon seit meiner Kindheit gefragt warum
die da nicht 32 draufschreiben :=)
Helmut Lenzen schrieb:> Zielprozessor laufen. Von daher gibt es keinen Grund das nicht> hinzubekommen ausser der Compilerprogrammierer hat den Grad seiner> Inkompetenz schon ueberschritten.
so könnte man das als Statement stehen lassen, wobei ich aber die
Definition eines Compilers daran festmache was er wirklich macht. Im
Falle von Bascom sieht mir das sehr stark nach einem simplen
Makroprozessor aus der nur vorgefertigte Teile mit parametern
zusammenkopiert. Von einem Compiler kann man da meiner Ansicht nach
nicht wirklich sprechen.
Karl Heinz schrieb:> Bei der Gelegenheit kann man den auch fragen, warum er keine> Schachtelungskontrolle für FOR-NEXT gemacht hat>> das hierfor i = 1 to 5> for j = 2 to 8> next i> next j> wird anstandslos compiliert. Noch nicht mal eine Warnung.
das ist dann auch kein Wunder. Das dafür Geld verlangt und als Prädikat
"THE BEST BASIC COMPILER FOR AVR" vergeben wird erschließt sich mir
nicht wirklich und dem TO kann man da wohl seine Enttäuschung als
begründet abnehmen.
Karl Heinz schrieb:> Allerdings gibt es in BASCOM auch sonst ein paar Syntax-Besonderheiten,> die mir immer schon etwas seltsam vorgekommen sind.>> BeispielCONFIG LCD = 16*2>> Huch! wie jetzt, das LCD ist 32?
16 Zeichen in 2 Zeilen
Manchmal sollte man sein Gehirn auch mal einschalten.
Holli schrieb:> Karl Heinz schrieb:>> Allerdings gibt es in BASCOM auch sonst ein paar Syntax-Besonderheiten,>> die mir immer schon etwas seltsam vorgekommen sind.>>>> BeispielCONFIG LCD = 16*2>>>> Huch! wie jetzt, das LCD ist 32?>> 16 Zeichen in 2 Zeilen>> Manchmal sollte man sein Gehirn auch mal einschalten.
Und manchmal sollte man seine eigenen Tips beherzigen.
Das weiß KHB auch. Aber es ist ein Bruch in der ganzen Programmierlogik,
das man 16*2 hinschreibt und das bedeutet was anderes als 32. Denn
eigentlich sollte es egal sein, ob man 16*2 oder 32 oder 8*4 oder 64/2
da hinschreibt.
Aber bei BASCOM nicht,hier ist 16*2 nur ein Symbol für eine LCD
Konfiguration. Und genau solche Extrawürste gibt es z.B. bei C gar
nicht. DAS wollte KHB damit sagen. Und genau das macht BASCOM auch so
unsäglich.
Allein dass die ganze Funktionalität über "Befehle" hergestellt wird,
welche alle unterschiedliche Syntax haben können. Wohingegen eine
Sprache mit wenigen Schlüsselwörtern, ganz automatisch immer gleich
funktionieren muss. Ohne Extrawürste und zig Befehle.
Karl Heinz schrieb:> Da bleib ich lieber bei C.
Du bist doch als eingefleischter C'ler bekannt, der nur in den letzten
Jahren weniger aggressiv missionarisch in dieser Richtung tätig ist und
so auch mal einem Bascom-Hifesuchenden einen Ratschlag erteilt.
Allein zu implizieren, dass Du irgend etwas Anderes verwenden würdest,
ist doch fern jeder Grundlage.
Heisenberg schrieb:> Von einem Compiler kann man da meiner Ansicht nach> nicht wirklich sprechen.
Richtig, das ist nur Deine persönliche Ansicht, die nicht mit der
gültigen Definition übereinstimmt. Da googelst jetzt ein bisserl, liest
und versuchst die Suchergebnisse für "Compiler" zu verstehen und schon
hast Du etwas für Deine Bildung getan.
Ist schon lustig, wie sich die Threads immer entwickeln, andererseits
liebe ich das Forum dafür.
Bascom scheint ein rotes Tuch für manche zu sein, als Ziel der Häme
beliebt bei den Überheblichen und Eingebildeten.
Andererseits ist MC.net auch eine C-Taliban-Hochburg, da kommt's dann
regelmäßig zu solchen Reaktionen, wenn sich ein Infidel als solcher
outet.
Wenn ich mir jedoch den Murks betrachte, der hier täglich im Forum in
beliebigen Sprachen so abgesetzt wird, dann sollten alle ihre Füße schön
still halten.
Auch zu bedenken: wäre C durch die Bank so toll, dann würd's jeder
benutzen. Das ist aber nicht der Fall, es gibt nachvollziehbar viele
Nutzer, die Probleme damit haben. Sind also die Nutzer daran schuld,
dass sie die alleinig heilbringende Glaubensrichtung nicht annehmen
wollen?
Jede Sprache, oder sagen wir jeder Compiler, hat bestimmte Vor- und
Nachteile. Letzten Endes wird der Nutzwert durch mehrere Faktoren
bestimmt. Codegröße, Geschwindigkeit, Lernaufwand und damit
Zugänglichkeit sind nur einige davon. Ich kenne keine Sprache, die dabei
ausschließlich Pluspunkte sammelt.
Abgesehen davon ist dieser Thread doch nur von ein paar Bluna-Fanboys
erstellt worden, welche die mangelnde Verbreitung "ihrer" Sprache ein
wenig fördern wollen.
Aber wie zu erwarten wurd's sowieso wieder ein kleiner Flamewar.
Oha, bisher wars ja relativ sachlich, aber du MWS hast die ganze
überflüssige Sachlichkeit beiseite gewischt und einfach mal so richtig
draufgehauen. Ohne ein einziges Argument, ohne einen einzigen sachlichen
Hinweis, einfach nur Polemik und dümmliche Allgemeinplätze. Und am Ende
dann noch genau diese Art der Diskussion kritisieren und sich womöglich
noch davon distanzieren, ja über sie stellen. Merkst du noch was?
cyblord ---- schrieb:> Oha, bisher wars ja relativ sachlich, aber du MWS hast die ganze> überflüssige Sachlichkeit beiseite gewischt und einfach mal so richtig> draufgehauen.
Er will sicher wieder einen Popcorn Thread haben ....
Helmut Lenzen schrieb:> cyblord ---- schrieb:>> Oha, bisher wars ja relativ sachlich, aber du MWS hast die ganze>> überflüssige Sachlichkeit beiseite gewischt und einfach mal so richtig>> draufgehauen.>> Er will sicher wieder einen Popcorn Thread haben ....
richtig, Geplappere, das klügste ist, sich nicht darauf einzulassen.
cyblord ---- schrieb:> Oha, bisher wars ja relativ sachlich
Einen Schmarrn war's, sonst wäre das Thema "C" hier gar nicht
aufgetaucht.
cyblord ---- schrieb:> Merkst du noch was?
Ja, ich hab' gemerkt was Du über eine Compilereigenheit schreibst:
cyblord ---- schrieb:> Das weiß KHB auch. Aber es ist ein Bruch in der ganzen Programmierlogik,
Nimm's doch einfach hin, dass es in dieser Form ein Display mit 16
Zeichen und 2 Zeilen bezeichnet, da kommt dann so ein Geschwurbel von
wegen Bruch der Programmierlogik.
cyblord ---- schrieb:> das man 16*2 hinschreibt und das bedeutet was anderes als 32.
16 * 2 sind 32 Zeichen, was bedeutet das nun anderes?
Original ist's übrigens "16x2", "16*2" geht aber auch, schon wieder ein
Bruch der Logik...
Komisch, dass es in anderen Sprachen keine Eigenheiten zu beachten gibt,
siehe Unterschiede in Keil und GCC.
Heisenberg schrieb:> Helmut Lenzen schrieb:>> cyblord ---- schrieb:>>> Oha, bisher wars ja relativ sachlich, aber du MWS hast die ganze>>> überflüssige Sachlichkeit beiseite gewischt und einfach mal so richtig>>> draufgehauen.>>>> Er will sicher wieder einen Popcorn Thread haben ....>> richtig, Geplappere, das klügste ist, sich nicht darauf einzulassen.
Aber es hört einfach nicht auf...
@MWS:
Du scheinst wirklich in keiner Weise an einer Diskussion interessiert zu
sein. Dann lass es doch einfach. Deine Einwände sind von unterirdischer
Qualität. Ehrlich.
Ich hatte mich DAMALS, mit Basic auf einem Kaypro II befasst, um zu
sehen, was man damit anstellen kann.
Und da ich schon immer hardwarenahe programmiert habe, habe ich das ganz
schnell wieder aufgegeben und mit dem Z80-ASM weitergemacht.
Denn mit BASIC geht hardwarenah GARNICHT. Da bricht man sich die Finger
mit den ganze Peek und Poke. Ob es mit BASCOM besser geht weiss ich
nicht, da ich mir das noch nie angeschaut habe.
ASM war ja schon gut, aber viele Library-Routinen die im Laufe der Zeit
entstanden sind, waren nicht portabel. Bzw. nur mit erhöhtem Aufwand
dann auf die neuen Zielsysteme zu bringen.
Das war der Punkt, an dem ich mich mit C befasst habe und es war der
richtige Weg. Denn C, so habe ich es immer verstanden und stehe auch
dazu, ist nur 1/2 Stockwerk über dem ASM, d.h. sehr nahe an der
Hardware.
Für mich gibt es keine bessere Sprache im Bereich Hardwareprogrammierung
wenn
es um die Portabilität geht.
Sicher hat BASIC seine Daseinsberechtigung, wie alle anderen Sprachen
auch.
Aber wenn, wie in den Beispielen gezeigt, so grottenschlechter ASM
erzeugt wird, dann hat der Entwickler des "BASIC Compilers" noch nie
selbst ASM programmiert und schlicht keine Ahnung vom Compilerbau.
Noch eine kleine Anmerkung zu C-optimierter CPU. Die gab es tatsächlich,
das war die NS32000-Familie (CISC-Architektur). Schon die Opcodes waren
fast wie C. Aber der C-Compiler dazu war perfekt. Leider hat sich diese
Prozessorfamilie, wie auch die 68000er, nie am Massenmarkt durchgesetzt.
Je öfter man sich aus Langeweile versehentlich in dieses Forum begibt,
desto öfter muss man feststellen, dass es eigentlich nicht
"Mikrocontrontroller-Forum", sondern eher "C-Forum" heißen müsste.
Jedem, der eine andere Meinung hat als die werten Oberprogrammierer und
C-Spezialisten, wird ein Schild vor die Nase gehalten: "Du musst
draussen bleiben!" Ähnlich wie im Supermarkt mit den Hunden.
Das Forum verdient eher die Bezeichnung: "Forum für abgehobene und
profilierungssüchtige Silizium-Fans" und auch hier gilt: Die am
lautesten schreien, haben am wenigsten vorzuweisen in der Praxis. Gelle?
(Um einer etwaigen Frage vorzubeugen: Selbst, wenn ich etwas vorzuweisen
hätte, würde ich es hier nicht tun bei derart vielen Präpotenzlern)
cyblord ---- schrieb:> @MWS:> Du scheinst wirklich in keiner Weise an einer Diskussion interessiert zu> sein. Dann lass es doch einfach. Deine Einwände sind von unterirdischer> Qualität. Ehrlich.
...
Wer nicht in der Lage ist, seine Aussagen zu oder über etwas zu
begründen, hat keine Meinung.
Wer nicht in der Lage ist, ein Kriterium oder mehrere Kriterien
anzugeben, das/die seine Meinung für Dritte nachvollziehbar und prüfbar
macht/en, hat keine Meinung.
Wer weder begründen noch Kriterien angeben kann, aber dennoch behauptet,
eine Meinung zu haben, macht sich entsprechend etwas vor. Er ist zum
Opfer seiner eigenen Empfindungen geworden, von Emotionen und Affekten
gesteuert und zu keiner rationalen Selbtsreflexion in der Lage. Er hat
sich selbst aus der Reihe derer, die am Meinungswettstreit teilnehmen,
ausgeschlossen.
http://sciencefiles.org/2014/01/01/traktat-einer-wehrhaften-demokratie-verteidigung-der-meinungsfreiheit/
Ach sonst sehr empfehlenswert.
Cerberus schrieb:> Je öfter man sich aus Langeweile versehentlich in dieses Forum begibt,> desto öfter muss man feststellen, dass es eigentlich nicht> "Mikrocontrontroller-Forum", sondern eher "C-Forum" heißen müsste.
Oder AVM Fanboyz oder sonst irgendwas was einem zufällig gerade nicht in
den Kram passt.
Mir sind Menschen die sich aus Hilfsbereitschaft für andere einsetzen,
ihre Fragen beantworten und ihre Zeit für die Probleme anderer verwenden
alle mal lieber als gelangweilte Nörgler mit ihren kruden Thesen.
Danke nochmal an alle die sich einsetzen, unter vielen anderen
Karl-Heinz B in Sachen C und Helmut S. in Sachen LTspice.
Ich habe viel gelernt und bemühe mich das auch weiter zu tragen bzw.
etwas zurück zu geben.
@Maze69
kann man in Mikroe in 44 ROM und 4 RAM Zellen bekommen.
Aber ist es nicht auch so, dass so manche Bastler mit Basic was bauen
können, was sonst nicht in der gleichen Zeit in "C" nicht hinbekommen
würden.
Und dann ist es doch gut. Ist mit Layout's doch genauso, Lochraster vs
EAGLE
cyblord ---- schrieb:> Deine Einwände sind von unterirdischer> Qualität. Ehrlich.
Musst Du bestätigen, dass das Deine ehrliche Meinung ist, oder ist Deine
Meinung sonst nicht ehrlich?
Was hast Du von meinen Aussagen nicht verstanden, bzw. was davon denkst
Du ist davon ähnlich weit weg wie C vom Thema Basic?
Es geht doch gar nicht um die Sprache. Weiter oben kann man aber den
Unterschied zwischen einem ordentlichen "BASIC nach AVR"-Übersetzer und
geqw. Sch. sehen. Wenn ich dafür auch noch Geld bezahlt hätte, würde ich
das nicht auch noch in den Himmel loben, sondern mich ruhig verhalten.
Die Frage ist nicht welche Sprache, sondern wie gut der Übersetzer
arbeitet. AVR GCC hat viele funktionen schlecht implementiert. Bascom
soll wohl für viele Operationen weniger Zyklen brauchen. Ich persönlich
finde Bascom gut implementiert und gut dokumentiert. Wenn es mal zu
langsam ist, kann man in Bascom auch ASM nutzen...
MWS schrieb:> cyblord ---- schrieb:>> Deine Einwände sind von unterirdischer>> Qualität. Ehrlich.>> Musst Du bestätigen, dass das Deine ehrliche Meinung ist, oder ist Deine> Meinung sonst nicht ehrlich?
Eher ein Apell an dich, deine Posts nochmal durchzulesen und zu erkennen
dass deren Niveau fachlich unterirdisch ist.
> Was hast Du von meinen Aussagen nicht verstanden, bzw. was davon denkst> Du ist davon ähnlich weit weg wie C vom Thema Basic?
Es spielt keine Rolle wie weit C von Basic weg ist. Stell dir mal vor,
jemand fährt bei der DTM mit und zwar mit einem Trabbi. So und nun stell
dir weiter vor, Abends am Fahrerstammtisch, beschwert der sich lauthals
darüber, wie scheiße sein Trabbi ist. Was meinst du wird passieren? Wird
man über Trabbi-Tuning reden, oder wo man bessere Trabbis kaufen kann?
Oder wird man ihm einfach mal nahelegen, vielleicht ein richtiges DTM
Auto zu fahren? Hmmm
Basti schrieb:> Die Frage ist nicht welche Sprache, sondern wie gut der Übersetzer> arbeitet. AVR GCC hat viele funktionen schlecht implementiert.
Stimmt nicht. Die Sprache hat nichts mit der Ausgabe zu tun. Das ist in
C strikt getrennt. Der Compiler soll lediglich einen Sourcecode in
Maschinensprache uebersetzen. Alles andere ist Sache von Bibliotheken
und die kann man tauschen.
Bascom
> soll wohl für viele Operationen weniger Zyklen brauchen.
Wenn ich mir oben das Compilat ansehen habe ich da meine Zweifel ...
Ich persönlich
> finde Bascom gut implementiert und gut dokumentiert. Wenn es mal zu> langsam ist, kann man in Bascom auch ASM nutzen...
Das kann man in C auch ist aber sehr selten erfoderlich.
> Aber ist es nicht auch so, dass so manche Bastler mit Basic was bauen> können, was sonst nicht in der gleichen Zeit in "C" nicht hinbekommen> würden
Eben! Mir geht es darum, ein Erfolgserlebnis in Form eines selbst
entwickelten und selbst gebauten Gerätes zu haben. Und dazu taugen auch
Bascom, Arduino, Pascal und sogar Forth, stellt Euch vor! Dabei kann man
sogar noch was lernen.
Wie wäre es, wenn man in dem Forum einmal mehr Frieden und vor allem die
heutzutage ach so gepriesene Toleranz (die immer mehr zu schwinden
scheint) geniessen dürfte?
Ihr habt mit Karl-Heinz einen Administrator und Moderator, der alles
friedlich zu regeln versucht und der tut, was in seiner Macht steht.
Sogar zu ihm seid ihr nicht gerecht!
Mr. van Devil
Cerberus schrieb:> Wie wäre es, wenn man in dem Forum einmal mehr Frieden und vor allem die> heutzutage ach so gepriesene Toleranz (die immer mehr zu schwinden> scheint) geniessen dürfte?
Da solltest Du Dich mal an die eigene Nase fassen, da hast Du schon
genügend zu tun.
> Ihr habt mit Karl-Heinz einen Administrator und Moderator, der alles> friedlich zu regeln versucht und der tut, was in seiner Macht steht.
Ja klar.
> Sogar zu ihm seid ihr nicht gerecht!
Schwachfug. Es gibt auf diesen Erden leider keine praktische
Gerechtigkeit gegenüber Mods (oh jetzt ist das Wasser zu warm und dann
ist es wieder zu kalt). Habe hier übrigens aber gar keine extrem-Fälle
entdeckt.
Wir erleben hier jetzt den absehbaren Austausch zwischen Leuten, wie
z.B. cyblord und MWS. Der OP wurde IMHO in diesem Thread davor zufrieden
gestellt, dann ist da ja im grünen Bereich und wir können weiter machen
und das Popcorn in die Microwelle zubereiten.
Also los jetzt: "Zwei gehen rein, einer kommt raus!" ;o)
cyblord ---- schrieb:> dass deren Niveau fachlich unterirdisch ist.
Durch Verwenden von Wörtern wie "fachlich" bekommt Dein Post auch nicht
mehr Gehalt.
Mein Statement ist: es ist wurscht, was verwendet wird, wenn's für den
Verwender passt und da gibt's viele Gründe warum etwas für jemanden
passt.
Wer sich die Konventionen von C nicht antun möchte, der nimmt was
anderes, wer im beruflichen Umfeld auf anderen Prozessoren als AVR
arbeiten muss, wird dagegen C den Vorzug geben. Größerer Code, na und?
Schlecht, wenn's 10000 Stück werden, dann zählt jeder kleinere Prozessor
und damit geringere Kosten, dann muss derjenige halt in den sauren
C-Apfel beißen. Kleine Serie? Dann halt 'nen 328er statt 'nen 168er.
cyblord ---- schrieb:> Es spielt keine Rolle wie weit C von Basic weg ist.
Ich glaub' wirklich, Du hast Probleme damit Sätze im Kontext mit diesem
Thread zu erfassen, ich zitier' mich mal:
MWS schrieb:> Was hast Du von meinen Aussagen nicht verstanden, bzw. was davon denkst> Du ist davon ähnlich weit weg wie C vom Thema Basic?
Das Thema war Unterschied zwischen zwei Basics und nicht eine Diskussion
um C, die ist weit weg davon, nicht wahr? Es ist dabei völlig egal, ob
Du C als Deinen Liebling betrachtest oder nicht, es ist einfach weit weg
vom Thema.
Und DTM? LOL, viele hier können froh sein, wenn sie nicht schon vom
Fahrrad fallen.
Klaus I. schrieb:> gestellt, dann ist da ja im grünen Bereich und wir können weiter machen> und das Popcorn in die Microwelle zubereiten.
Popcorn im Mikrowellenherd? Das ist kulinarisches Banausentum!
Coquus schrieb:> Klaus I. schrieb:>>> gestellt, dann ist da ja im grünen Bereich und wir können weiter machen>> und das Popcorn in die Microwelle zubereiten.>> Popcorn im Mikrowellenherd? Das ist kulinarisches Banausentum!
Da magst Du sogar Recht haben. Aber solange ich dazu ein gutes
Angerwirts-Weizen aus einem guten Weißbierglas trinke und kein
angebliches Weißbier wie es z.B. Paulaner verhökert, hab ich persönlich
meinen Genuß.
Das ist ja schon fast so wie mit den Mikrocontrollern und womit man sie
programmiert ;o)
>Wir erleben hier jetzt den absehbaren Austausch zwischen Leuten, wie>z.B. cyblord und MWS.
Wer MWS ist, weiss ich nicht, aber Mr. Cyblord - Verbeugung, Eurer C
-Gnaden- , wären ein seehr würdiger Nachfolger in negativer Hinsicht,
besonders bezüglich Intoleranz! winke
Wenn das so weitergeht, Herrschaftn, geht es intellektuell den Bach
runter!
Grüsse,
Mister van Devil
Cerberus schrieb:> Wer MWS ist, weiss ich nicht,
MWS ist Moderator mit eiserner Faust im Bascom Forum und steht in Fehde
mit dem Entwickler von Luna.
Deshalb zieht er auch so voller Hass über das technisch bessere und
modernere Luna her.
Einfach armselig und bemitleidenswert.
ManGlaubtEsKaum schrieb:> Cerberus schrieb:>> Wer MWS ist, weiss ich nicht,>> MWS ist Moderator mit eiserner Faust im Bascom Forum
Das erklärt so einiges. Vielleicht kann er sich ja dann mal vom
polemischen Lösen und z.B. auf die weiter oben besprochene
Arithmetik-Problematik eingehen. Kurz: Warum es heute noch sein muss,
dass man keine kompletten arithmetischen Ausdrücke in BASCOM
hinschreiben darf. Evt. hat er, in seiner Funktion als einer obersten
Hüter von BASCOM dafür ja eine Erklärung. Oder wenigstens eine
Entschuldigung.
gruß cyblord
ManGlaubtEsKaum schrieb:> MWS ist Moderator mit eiserner Faust im Bascom Forum und steht in Fehde> mit dem Entwickler von Luna.> Deshalb zieht er auch so voller Hass über das technisch bessere und> modernere Luna her.> Einfach armselig und bemitleidenswert.
das stimmt nicht
Ich sehe keinen Beitrag von MWS in diesem Thread, in dem er hier die
Leute runtermacht wie es ein Cyblord oder Helmut Lenzen machten.
Schade, dass die 2 den Thread so runterziehen mit ihrem Basci. Gebashe.
Danke auch Cerberus für die deutlichen Worte.
Es ist halt µC.net. Du sollst keinen Gott neben C haben.
Beobachter
Dann solltest Du mal hier nach MWS und Luna suchen.
Nur ein Beispiel von hier
(Beitrag "Vorteile von Basic, Pascal, C und C++ in einem: LunaAVR"):
"Vorteile hab' ich noch keine gesehen, aber Schwachstellen seh' ich
genügend, zuvorderst die Kreation einer Sprache von ein paar Hanseln und
einem Oberhansel. Und was der von demokratischer Kultur hält, hab' ich
bereits gesehen, Uwe S. ist mit seinem "Schnauze jetzt" lediglich ein
geeigneter Mitstreiter."
Die "Hanseln und einem Oberhansel" sind MWS intellektuell bei weitem
überlegen und waren zuerst seine Mitsteiter im Bascom Forum. Dann hatten
sie die besseren Ideen, die MWS wohl nicht so recht verstanden hat.
Ausser seinem Hass hat MWS allerdings keinerlei überzeugende Argumente
zu bieten.
ManGlaubtEsKaum schrieb:> MWS ist Moderator mit eiserner Faust im Bascom Forum und steht in Fehde> mit dem Entwickler von Luna.
Falsch und falsch. Zum Entwickler der Software habe ich eine für ihn
unvorteilhafte Meinung, ansonsten ist er mir egal.
> Deshalb zieht er auch so voller Hass über das technisch bessere und> modernere Luna her.
Mein Misstrauen gilt den Motiven, unter denen diese Sprache angepriesen
wird d.h. die erheischte Teilnahme von Freiwilligen, aber unter
Kontrolle einer einzelnen Person.
Die Libs mögen quelloffen sein, dürften aber ohne Grundgerüst des nicht
quelloffenen Compilers weitestgehend nutzlos sein, für den Fall dass der
Erbauer mal die Lust verliert.
Mir ist's deshalb am Liebsten, wenn ich die Motive eines
Entwicklers/Anbieters kenne.
microBasic und Bascom wollen Geld verdienen, das ist genügend Motivation
für die vernünftige Fortführung und damit keine Merkwürdigkeiten
passieren, bloß weil Cheffo mal grantig wird.
Keil will auch Geld verdienen und Geld verdienen zu wollen ist einfach
ein starkes Motiv, damit die Kundschaft fröhlich gehalten wird.
GCC wird von einer Gruppe geführt und ist wirklich Opensource, da hab'
ich deutlich mehr Vertrauen dazu, als zu einer einzelnen Person, welcher
vorgibt Gutes zu tun.
Darüber hinaus ist es meine Meinung, dass für den Fall jemand bereit
ist, eine in Richtung C/C++ gehende komplexere Kunstsprache wie Luna zu
erlernen, es (höflich ausgedrückt) höchst ungeschickt ist, nicht gleich
C oder C++ zu nehmen, denn C existiert auch dann noch, wenn's um Luna
längst dunkel geworden ist.
Aber C war eben hier nicht das Thema, gleichwohl ich solche Leute
gefressen habe, die denken, sie müssen ihre eigenen Vorlieben anderen um
jeden Preis aufpressen.
MWS schrieb:> Die Libs mögen quelloffen sein, dürften aber ohne Grundgerüst des nicht> quelloffenen Compilers weitestgehend nutzlos sein, für den Fall dass der> Erbauer mal die Lust verliert.
Das ist für einen Hobbyisten ziemlich egal. Dafür kostet es eben keinen
Cent.
ManGlaubtEsKaum schrieb:> Die "Hanseln und einem Oberhansel" sind MWS intellektuell bei weitem> überlegen und waren zuerst seine Mitsteiter im Bascom Forum. Dann hatten> sie die besseren Ideen, die MWS wohl nicht so recht verstanden hat.> Ausser seinem Hass hat MWS allerdings keinerlei überzeugende Argumente> zu bieten.
Ich find's immer wieder nett, wenn des Meisters kleine Minions sich
ranschmeißen ;D
Außerdem, wenn Du den alten Thread schon zitierst, dann zitier' doch
gleich ein wenig vollständiger:
Von Harry L:
> Wenn bei LUNA der Hauptentwickler morgen einen Autounfall hat, wars das.> Frag dich doch mal, warum der Quellcode von dem Teil nicht öffentlich> ist!
Von Uwe S.:
> Hallo Harry L.,> ich habe gerade noch mal mit Richard telefoniert und er wird den> Quellcode weiter geben, aber nicht an jeden, nur an die die das Projekt> weiterschreiben könnten.> Damit ist alles gesagt - und ruhe jetzt.
"Ruhe jetzt", ein schönes Beispiel, womit man sich der Öffentlichkeit
präsentiert. Passt.
ManGlaubtEsKaum schrieb:> Das ist für einen Hobbyisten ziemlich egal. Dafür kostet es eben keinen> Cent.
Schön, dass Du weißt, was für einen Hobbyisten egal ist. Und was nun?
Vielleicht: "Ruhe jetzt"? LOL
Schau einfach mal Big Bang Theory, identifizier Dich mit einem der
Protagonisten oder leg Dich gleich auf die Couch.
Du bist für mich einfach kein ernst zu nehmender Diskussionspartner.
Bascom ist eben eine Anfängersprache, die aber schnell in eine Sackgasse
führt.
Wahrscheinlich könnte man den "Komfort" von Bascom mit anderen Compilern
ziemlich einfach über Makros oder Libraries implementieren.
Wenn sich aber jemand weigert, geschweifte Klammern zu lernen und zu
verstehen, dann kann dem nicht geholfen werden...
ManGlaubtEsKaum schrieb:> Schau einfach mal Big Bang Theory, identifizier Dich mit einem der> Protagonisten oder leg Dich gleich auf die Couch.
Hört sich jetzt so an, als ob die echten Argumente ausgegangen sind...
> Du bist für mich einfach kein ernst zu nehmender Diskussionspartner.
Liegt wahrscheinlich daran, dass Du Dich als einen der "Hanseln" des
"Oberhansel" identifizierst und damit nach Deinem Glauben so weit
intellektuell überlegen bist. LOL
Dann red' mal weiter mit Deinesgleichen und sei glücklich, dass
Brainfarts nicht riechen. ;-)
ManGlaubtEsKaum schrieb:> MWS ist Moderator mit eiserner Faust im Bascom Forum und steht in Fehde> mit dem Entwickler von Luna.> Deshalb zieht er auch so voller Hass über das technisch bessere und> modernere Luna her.> Einfach armselig und bemitleidenswert.
MWS war bis 2011 Moderator, wir haben jetzt übrigens schon 2014.
ManGlaubtEsKaum schrieb:> ...sind MWS intellektuell ... überlegen ... besseren Ideen, ... nicht so> recht verstanden ... seinem Hass ... keinerlei ... Argumente
Du scheinst auch einer von den "intellektuell Überlegenen" zu sein wenn
du dich solcher "Argumente" bedienen musst.
Bascom schrieb:> Bascom ist eben eine Anfängersprache, die aber schnell in eine Sackgasse> führt.
Man kann mit jeder Sprache anfangen zu programmieren, also ist jede
Sprache eine Anfängersprache, auch C.
Mit Bascom gibt es keine Sackgasse, wenn man die Kunst des
Programmierens beherrscht.
Ich hab noch keine entdeckt. Und wir reden hier von Hobby, nicht
selbsternannten "Professionellen".
Hallo,
Luna war ein sehr guter Tip.
Man muß programmieren können, dann kann man über die Sprache
diskutieren. Aber dieser Meinung war ich schon immer.
Gruß
Beobachter schrieb:> Ich sehe keinen Beitrag von MWS in diesem Thread, in dem er hier die> Leute runtermacht wie es ein Cyblord oder Helmut Lenzen machten.> Schade, dass die 2 den Thread so runterziehen mit ihrem Basci. Gebashe.
Weil ich hier mal etwas klar gestellt habe in Bezug auf C das in C die
Ein/Ausgabe nicht Bestandteil der Sprache an sich ist sondern ein Teil
der Bibliotheken und das man in C auch Assemblerteile einbauen kann. Das
ist im Normalfall aber nicht nötig weil das Compilat eh schnell genug
ist. Und das nennst du runterziehen.
MWS schrieb:> Komisch, dass es in anderen Sprachen keine Eigenheiten zu beachten gibt,> siehe Unterschiede in Keil und GCC.
Oops...
Mir scheint es angesichts der schier unendlichen #ifdef-Wüsten in vielen
C-Programmen, insbesondere in solchen für kleine µC, irgendwie wohl doch
gewisse Unterschiede zu geben...
Ich schrieb:> Man kann mit jeder Sprache anfangen zu programmieren, also ist jede> Sprache eine Anfängersprache, auch C.
Mein Reden, auch Anfänger können C verwenden!
Ich schrieb:> Mit Bascom gibt es keine Sackgasse, wenn man die Kunst des> Programmierens beherrscht.
Ab einem bestimmten Schwierigkeitsgrad komme ich nicht umhin, die Bits
in den Registern direkt zu schreiben, und dann sehe ich in Bascom aber
kein Vorteil mehr.
Ich schrieb:> Ich hab noch keine entdeckt. Und wir reden hier von Hobby, nicht> selbsternannten "Professionellen".
Es gibt hier im Forum wirklich Professionelle, auf deren Ratschläge man
hören sollte.
c-hater schrieb:> Oops...>> Mir scheint es angesichts der schier unendlichen #ifdef-Wüsten in vielen> C-Programmen, insbesondere in solchen für kleine µC, irgendwie wohl doch> gewisse Unterschiede zu geben...
Hätt' ich [ironie]...[/ironie]-Tags verwenden sollen?
c-hater schrieb:> Mir scheint es angesichts der schier unendlichen #ifdef-Wüsten in vielen> C-Programmen, insbesondere in solchen für kleine µC, irgendwie wohl doch> gewisse Unterschiede zu geben...
Das hat aber nix mit C an sich zu tun sondern mit den
Hardwareunterschieden der einzelnen Chips.
bernd schrieb:> Und dann ist es doch gut. Ist mit Layout's doch genauso, Lochraster vs> EAGLE
Ich entwickle auch meine Lochraster-PCBs immer mit Eagle.
Soll heißen: Wo genau siehst du da einen Widerspruch?
Den Schaltplan muß ich sowieso zeichnen. ERC und DRC sind sinnvoll, egal
ob Lochraster oder "richtiges" PCB. Und eine schicke Ansicht für jeden
Bearbeitungschritt (freibohren/ritzen Streifenleiter, Brücken einlöten,
BE bestücken) kann mir das Programm auch noch generieren.
Also ich sehe da keinen direkten Widerspruch. Man muß das Werkzeug
einfach nur beherrschen, dann geht damit auch Lochraster-Design ziemlich
gut zu machen.
> Ab einem bestimmten Schwierigkeitsgrad komme ich nicht umhin, die Bits> in den Registern direkt zu schreiben, und dann sehe ich in Bascom aber> kein Vorteil mehr.
Selbiges, ehrenwerter Herr, lässt sich aber auch mit Bascom
bewerkstelligen, denn auch mit selbigem Werkzeuge lässt sich ohn Problem
Assemblersprach einfügen, sofern er dieses nicht weiss!
Ohn Wissens der Register ist auch ein Bascom-Jünger nur ein armer
Schelm! So sieht auch ein einfach Schreyber sich genötigt, sich mit den
Adresskästen näher zu befassen. Erst späteren Zeytpunktes wird er zum
weisen Mann, so der hohe Adminstrateur es will, besonders, wenn Selbiger
den Namen "Cyblord, der grosse Behüter des hohen C" trägt.
Vor seinem Zorne hütet Euch , Ihr Neuen, denn er beherrschet die Künste
der µC-Hexerei!
Und Gundel Gaukeley ist seine Gefährtin!
Helmut Lenzen schrieb:> Das hat aber nix mit C an sich zu tun sondern mit den> Hardwareunterschieden der einzelnen Chips.
Oh mein Gott. Du bist mit Sicherheit eins nicht: ein erfahrener
C-Programmierer...
Natürlich gibt es auch reichlichlich #ifdefs, die sich mit
Hardwarunterschieden beschäftigen, aber eben längst nicht nur solche...
Hardus, der Alte schrieb:> "Cyblord, der grosse Behüter des hohen C" trägt.> Vor seinem Zorne hütet Euch , Ihr Neuen, denn er beherrschet die Künste> der µC-Hexerei!
Der Titel könnte mir gefallen. Wenn er sich weniger nach einem Vertreter
für Orangensaft anhören würde... Egal mal schauen ob ich den auf die
Visitenkarte bekommen kann.
Aber verschiedene Compiler, wie GCC und Keil zu vergleichen ist nicht
fair. Wenn dann muss man eine Sprache vergleichen. Hier wäre das
Äquivalent zu Bascom, C99 oder Ansi-C. Und diese Sprachen sind in sich
selbst konsistent, was natürlich vor allem an den wenigen
Schlüsselwörtern liegt.
Die #ifdef Geschichten stammen natürlich daher dass man einen einzigen
Quellcode für a.) unterscheidliche Archtitekturen und b.)
unterschiedliche Compiler und c.) vielleicht sogar für unterschiedliche
Sprachstandard haben will. Das ist aber lediglich eine Programmierweise
und keine zwingende Eigenschaft von C.
Meine Kritik an Bascom richtete sich aber gegen die vielen verschiedenen
Befehle (was alle Basic Dialekte gemein haben) und deren inkonsitente
Benutzung, was im Endeffekt zu solchen 16*2 Konstrukten führt.
gruß cyblord
c-hater schrieb:> Helmut Lenzen schrieb:>>> Das hat aber nix mit C an sich zu tun sondern mit den>> Hardwareunterschieden der einzelnen Chips.>> Oh mein Gott. Du bist mit Sicherheit eins nicht: ein erfahrener> C-Programmierer...
"Mit Sicherheit kein erfahrener C-Programmierer". Das schreibt nun
ausgerechnet ein "C-Hasser". Wir - die armseligen C'ler - warten seit
Jahren auf eine Alternative. Aber da kommt nichts. Mit was soll ich also
ein µC programmieren wenn nicht in "C" ? Nein, ich erwarte keine
ernsthafte Antwort.
Ja, ich kenne neben C auch noch andere Sprachen... Ich warte immer noch
auf eine USB-CDC Klasse in Pascal oder einen TCP-Stack in Basic. Bitte
"C-Hater", kläre mich auf!
C-User schrieb:> "Mit Sicherheit kein erfahrener C-Programmierer". Das schreibt nun> ausgerechnet ein "C-Hasser".
Natürlich, was dachtest du denn?
Man muß C natürlich beherrschen (und darüber hinaus auch noch gezwungen
werden, es regelmäßig zu benutzen), um es überhaupt so intensiv hassen
zu können, wie ich das tue.
Noch mehr als C selber hasse ich allerdings die Lügen, die regelmäßig
darüber verbreitet werden, insbesondere die Portabilitätslüge hat es mir
wahrlich angetan.
Denn, wenn du auch nur den Arsch in der Hose hast, halbwegs ehrlich zu
sein, wirst du ja wohl nicht abstreiten können, daß es völlig normal
ist, daß C-Programme Compiler-spezifische Verzweigungen für den
Präprozessor enthalten.
Nun ist aber allein die bloße Existenz derartiger Konstrukte nach den
Gesetzen der formalen Logik der sichere und unwiderlegbare Beweis, daß C
eben NICHT portabel ist. Es sei denn, man betrachtet derartige
Präprozessor-Verzweigungen als Teil der Portabilität. Wenn man das aber
tut, ist auch (Macro-)Assembler plötzlich portabel!
Aber egal, ich erwarte sowieso nicht, daß Leute wie du zu solchen
abstrakten Denkleistungen in der Lage sind...
C-User schrieb:> Ja, ich kenne neben C auch noch andere Sprachen... Ich warte immer noch> auf eine USB-CDC Klasse in Pascal oder einen TCP-Stack in Basic.
microBasic: ja (Bibliothek) genaue Anwendung ist mir nicht bekannt.
Luna: ja, vollständiger TCP-Stack (neben ARP, ICMP, UDP und Services wie
Telnet, httpd, udpd, ftpd):
http://avr.myluna.de/doku.php?id=de:openmlp
USB-CDC:
http://forum.myluna.de/viewtopic.php?f=8&t=460
Bascom? mir nicht bekannt, auf keinen Fall ein kompletter TCP-Stack,
höchstens rudimentär als Einzel-Bearbeitung von HTTP ohne echte (eigene)
Paketbehandlung, schon gar nicht parallel.
c-hater schrieb:> Nun ist aber allein die bloße Existenz derartiger Konstrukte nach den> Gesetzen der formalen Logik der sichere und unwiderlegbare Beweis, daß C> eben NICHT portabel ist.
Naja die Frage ist wie man portabel definiert. C abstrahiert über die
Maschine, die Register, den Stack, den Speicher usw. Es abstrahiert
NICHT über den verwendeten Compiler der den Sprachstandard. Aber da C
trotz Hochsprache immer noch sehr hardwarenah ist, gibt es auch dort
Module welche eben genau nicht unabhängig von der Hardware arbeiten. Und
diese müssen dann mit #ifdef Geschichten ausgewählt werden.
Wobei in meinen Augen auch das Portable nicht DER Grund für C ist. Der
Grund ist einfach genau die Mischung aus Hochsprache, d.h. keine Sorgen
machen über Variablen und einfache Rechenoperationen, über die
Speicheraufteilung, Register, sichern derselben bei Sprüngen und
natürlich die einfachere Handhabung sämtlicher Kontrollstrukturen.
Trotzdem verstellt C nicht den Blick auf die Hardware und lässt genug
Kontrolle. Die verhassten Pointer sind hierbei eigentlich genau das
Feature der Sprache und nicht der Bug.
gruß cyblord
>Meine Kritik an Bascom richtete sich aber gegen die vielen verschiedenen>Befehle (was alle Basic Dialekte gemein haben) und deren inkonsitente>Benutzung, was im Endeffekt zu solchen 16*2 Konstrukten führt.
Da muss ich Dir beipflichten, oh hoher Vitaminmeister! Jetzt denke aber
mal, Du hättest einen 13-jährigen Sohn! Von Datenblättern hat der Null
Ahnung und von Elektronik auch so viel. Aber, er interessiert sich für
die Materie.
Was sagst Du einem Kind? Sagst Du ihm, er soll sich verkrümeln, bis er
sich selbst schlau gemacht hat oder , versuchst Du , ihm zu helfen? Ich
würde Letzteres tun. Wir sollten uns die die Hand geben, anstatt uns mit
Schmutz zu bewerfern.
Heisenberg schrieb:> Luna: ja, vollständiger TCP-Stack
Ja, man hat einfach OpenMCP für den uralten ENC28J60 "portiert".
Heisenberg schrieb:> Bascom? mir nicht bekannt,
Du solltest ehrlicherweise sagen das du nicht mal den Versuch gemacht
hast das heraus zu finden bzw. das einfach unterschlägst. Bascom
unterstützt inzwischen 4 verschiedene WIZNET Chips.
Heisenberg schrieb:> USB-CDC:
Hier wurden wieder die C-Teensy-Sourcen portiert.
Hardus, der Alte schrieb:>>Meine Kritik an Bascom richtete sich aber gegen die vielen verschiedenen>>Befehle (was alle Basic Dialekte gemein haben) und deren inkonsitente>>Benutzung, was im Endeffekt zu solchen 16*2 Konstrukten führt.> Da muss ich Dir beipflichten, oh hoher Vitaminmeister! Jetzt denke aber> mal, Du hättest einen 13-jährigen Sohn! Von Datenblättern hat der Null> Ahnung und von Elektronik auch so viel. Aber, er interessiert sich für> die Materie.
Ach das ist doch keine Ausrede. Mit 13 hab ich schon Pic Programmer
(nach)gebaut und die in ASM programmiert. Der soll sich mal trauen mit
nem Arduino anzukommen das Bürschchen... ;-)
Außerdem sind doch 13 jährige Bengel ohne jegliches Elektronikwissen,
nicht das Maß der Dinge bei der Beurteilung einer Programmiersprache.
Und wer keine Datenblätter lesen will, der kann sowieso gleich
fortbleiben. Die braucht man nämlich immer. Sogar bei BASCOM.
Aber seht doch selbst, in den neusten Thread zu Arduino. Dort gehts um
die liebliche PulseIn Funktion. Ist zwar nicht Bascom, aber man sieht
was dabei herauskommt, wenn Menschen einfach mal schnell so einen Befehl
an die Hand bekommen ohne jegliches Grundwissen. Kein schöner Anblick.
gruß cyblord
Holli schrieb:> Hier wurden wieder die C-Teensy-Sourcen portiert.
Ob portiert oder nicht, es ist nativ in der entsprechenden Sprache
vollständig geschrieben und funktioniert sogar. Auch zeigt es, dass die
Portierung von dem dir verhassten "C" scheinbar recht einfach ist. Bei
Bascom sehe ich da mehr Schwierigkeiten, ich glaube das tut sich keiner
an wenns mal um komplexere Anforderungen geht.
Holli schrieb:> Du solltest ehrlicherweise sagen das du nicht mal den Versuch gemacht> hast das heraus zu finden bzw. das einfach unterschlägst. Bascom> unterstützt inzwischen 4 verschiedene WIZNET Chips.
Bei den Wiznet Chips ist der TCP-Stack im Chip. Zeig mir einen echten,
vollständigen TCP-Stack in Bascom und nicht das gefummelte Zeugs das
ohne jegliche anständige Verbindungs- und Paketverwaltung angeblich ein
Webserver sein soll. Kläre mich auf, ich bin gespannt.
"Die Spezies Mensch zeichnet sich durch die umstittene Fähigkeit aus,
die Lösung des Überbevölkerungsproblems durch die Schaffung von heiligen
Religionskriegen zu bewerkstelligen." ;-)
Heisenberg schrieb:> Auch zeigt es, dass die> Portierung von dem dir verhassten "C" scheinbar recht einfach ist.
Das wiederum stützt mein Argument, welches da heißt: wer braucht's?
Wenn so wenig Unterschied dazwischen ist, bzw. die Ähnlichkeit zu C so
groß ist, warum sollte man dann nicht das Original nehmen?
Und das heißt in diesem Fall: C.
Nicht dass ich jetzt ein spezieller Fan von C geworden wäre, aber eins
ist doch wohl klar: müsste ich zwischen zwei sehr ähnlichen Sprachen
wählen, bei der eine eine Kunstdefinition von de Facto einer einzigen
Person ist, dann wähle ich zu 100% die Sprache welche lange etabliert
ist und die von vielen Entwicklern getragen wird. Also C.
Da Du weiter oben im Thread bereits nicht wusstest, wie das Wort
"Compiler" definiert ist, und da von "Makro-Compiler" phantasiert hast,
stelle ich mal in den Raum, dass mit einem Schwung Makros in C
weitestgehend das look-and-feel von Luna hergestellt werden kann.
> Bei Bascom sehe ich da mehr Schwierigkeiten, ich glaube das tut sich> keiner an wenns mal um komplexere Anforderungen geht.
Du glaubst einfach zu viel und weist zu wenig, scheinbar bist Du ja eher
ein Bluna-Fanboy und hast eher wenig bis keine Ahnung von Bascom, traust
Dich aber nicht so recht Dich zu outen.
Hab' ich schon öfter bemerkt - da findet sich eher jemand, der sich
traut in einem C-Forum wie MC.net nach Bascom zu fragen, als jemand nach
Luna, wenn man mal von Threads zu Werbezwecken wie diesem hier absieht.
Das ist aber auch kein Wunder, wenn man davon ausgeht, dass Luna ein mit
einem bisserl Objektorientiertheit verbrämter Abklatsch von C ist.
> Bei den Wiznet Chips ist der TCP-Stack im Chip.
Die eine Seite dieser Medaille ist, dass man sich durch die Verwendung
des Wiznet an Hardware bindet, auf Hardware gehen muss allerdings auch
ein reiner Soft-Stack irgendwann. Die andere Seite ist, dass durch in
Silizium gegossene Funktionen im Wiznet der µC diesen Job nicht mehr
erledigen muss.
Was ist nun schlauer, die Soft-Implementation oder die Nutzung der
Funktionen in Hardware? Ich meine Letzteres ist deutlich schlauer und
auch fortschrittlicher.
Heisenberg schrieb:> von dem dir verhassten "C"
Vom User "Holli", der hiermit bezeichnet wird, habe ich nie bemerkt dass
ihm "C" verhasst ist. Ich weiß, dass er in Bascom programmiert und dafür
bekannt ist, jedoch von "verhasst" in Bezug auf andere Sprachen ist mir
nichts bekannt.
Auch wenn man sich diesen Thread hier betrachtet, dann ist kein Wort von
ihm zu finden, dass er über C herziehen würde. Er argumentiert lediglich
Pro-Bascom.
Du plapperst scheint's gerne Unwahrheiten. Aber auch das denke ich
bereits bei Luna-Hanseln bemerkt zu haben: es wird schon mal zum Zwecke
die eigene Sache zu fördern ein wenig verschleiert oder etwas falsch
behauptet. Lügen, beissen und spucken ist da offenbar erlaubt, solang's
der Sache dienen kann.
Da sind mir ja noch Leute wie Cyblord lieber, der ist zwar auch von
seinem C als alleinig heilbringend überzeugt und korintenkackerische
Neigungen sind offenbar, aber ehrlich scheint er mir zumindest zu sein,
so dass er das von ihm Vertretene nicht mit Lügen stützen muss.
c-hater schrieb:> Nun ist aber allein die bloße Existenz derartiger Konstrukte nach den> Gesetzen der formalen Logik der sichere und unwiderlegbare Beweis, daß C> eben NICHT portabel ist.
Was wiederum der C-Logik widerspricht die besagt das diese Sprache auf
anderen Zielsystemen kompiliert werden kann so lange man nur mit
"portablen" Elementen hantiert.
Das macht in der Praxis keiner sondern nimmt alles was ihm nutzt. Das
ist aber wiederum in Quelltext und dem ganzen drumherum ersichtlich so
das dein Programmierer diese Teile anpassen kann. Das ist auch so
vorgesehen eben um die Sprache eben portabel zu machen.
Eine automatische und reiner Logik gehorchenden Universalität (was etwas
anderes ist als Portabilität) sieht die Sprache nicht vor und ist auch
nicht ihre Intention (die auch darin besteht Arbeitsplätze für
Spezialisten zu erhalten was wiederum ihre Professionalität zeigt womit
die Diskussion hier etwas fehl am Platze ist;-) ).
Das ist dann eher ein Konzept von Java etc.
> Es sei denn, man betrachtet derartige> Präprozessor-Verzweigungen als Teil der Portabilität. Wenn man das aber> tut, ist auch (Macro-)Assembler plötzlich portabel!
Kann man aber so betrachten wenn man "Portabilität" nicht überlädt.
Basic z.B. ist im Gegensatz zu C nicht portabel, was im nicht
vorhandenen Standard auch nicht vorgesehen ist.
Das diese doppelte Negation nicht zum vorhanden sein diese Features
führt zeigt im übrigen das krude mathematische Logik Einschränkungen
unterliegt die Sie außerhalb deterministischer Systeme nur eingeschränkt
Nutzbar macht sei nur am Rande vermerkt.
MWS schrieb:> Nicht dass ich jetzt ein spezieller Fan von C geworden wäre, aber eins> ist doch wohl klar: müsste ich zwischen zwei sehr ähnlichen Sprachen> wählen, bei der eine eine Kunstdefinition von de Facto einer einzigen> Person ist, dann wähle ich zu 100% die Sprache welche lange etabliert> ist und die von vielen Entwicklern getragen wird. Also C.>> Da Du weiter oben im Thread bereits nicht wusstest, wie das Wort> "Compiler" definiert ist, und da von "Makro-Compiler" phantasiert hast,> stelle ich mal in den Raum, dass mit einem Schwung Makros in C> weitestgehend das look-and-feel von Luna hergestellt werden kann.
Sorry, aber dein wiedergekäutes Geschwurbel wird durch ständiges
Wiederholen auch nicht besser. Das eigentliche Thema ist nunmal
mikrobasic und bascom. Was du daraus aus krankhaftem Wahn
hervorplapperst, offenbart ja fast schon eine krankhafte Paranoia.
Der User "Heisenberg" ist übrigens C-Programmierer. Wenn der übern
Tellerrand schauen kann spricht das für ihn. Ob MWS-Bascom-Oberprimat
oder Luna-Hanseln ist mir dabei absolut wurscht.
MWS schrieb:> Die eine Seite dieser Medaille ist, dass man sich durch die Verwendung> des Wiznet an Hardware bindet, auf Hardware gehen muss allerdings auch> ein reiner Soft-Stack irgendwann. Die andere Seite ist, dass durch in> Silizium gegossene Funktionen im Wiznet der µC diesen Job nicht mehr> erledigen muss.
nochmal verständlich zusammengefasst:
C-User schrieb:> Ja, ich kenne neben C auch noch andere Sprachen... Ich warte immer noch> auf eine USB-CDC Klasse in Pascal oder einen TCP-Stack in Basic. Bitte> "C-Hater", kläre mich auf!
es wurde ein kompletter TCP-Stack angefragt und kein Solcher der gar
nicht in dem Basic-Zeugs selbst geschrieben, sondern sich in einem Chip
befindet. Es wurde nicht gefragt "was ist die bessere Anbindung an
Netzwerke". Klickerts jetzt Nikolaus?
Na dann zeig mal Oberbascomking ..nix da? achwas!
Der Freitag schrieb:> Es wurde nicht gefragt "was ist die bessere Anbindung an> Netzwerke". Klickerts jetzt Nikolaus?>> Na dann zeig mal Oberbascomking ..nix da? achwas!
Und ich hab dazu meine Meinung gesagt, ist das schwierig zu verstehen?
Übersetzt für Dich - und ich hoff' mal es nicht wieder mit so 'ner
intellektuellen Elite zu tun zu haben, sonst wirst auch Du wieder nix
verstehen:
Die einen haben sich, im übertragenen Sinn, 'ne Soft-PWM von jemandem
abgeschrieben, der selbst offenbar programmieren konnte, die anderen
nehmen 'nen Chip dafür und machen Hard-PWM. Beide Gruppen nutzen das
Wissen anderer, aber welche Lösung ist wohl geschickter?
Kauf Dir 'nen Net-IO und bilde Dir was ein, wenn Du den Kram mit dem
alten Netzwerkchip zum Laufen bringst. Für akademische Zecke nett, aber
zu Zeiten eines Raspberry zweckfrei und Anachronismus.
Deswegen, ein vollständiger, wenn auch zurechtgekupferter Soft-Stack auf
'nem Oldtimerchip, selbst wenn akademisch wertvoll - so what...
Beeindruckt mich nicht.
Aber wenn C-User damit glücklich wurde, dann freut mich das natürlich.
Der schmeisst dann alles hin was er in C gelernt hat, nur weil's 'nen
Basic Stack gibt, den er allerdings genauso im abgekupferten C-Original
haben könnte.
Ich wart' schon drauf, dass C-User nochmal sowas sinnlos Lustiges sagt,
ein richtiger Komiker der Typ.
MWS schrieb:> Kauf Dir 'nen Net-IO und bilde Dir was ein, wenn Du den Kram mit dem> alten Netzwerkchip zum Laufen bringst. Für akademische Zecke nett, aber> zu Zeiten eines Raspberry zweckfrei und Anachronismus.>> Deswegen, ein vollständiger, wenn auch zurechtgekupferter Soft-Stack auf> 'nem Oldtimerchip, selbst wenn akademisch wertvoll - so what...> Beeindruckt mich nicht.>> Aber wenn C-User damit glücklich wurde, dann freut mich das natürlich.> Der schmeisst dann alles hin was er in C gelernt hat, nur weil's 'nen> Basic Stack gibt, den er allerdings genauso im abgekupferten C-Original> haben könnte.
also nochmal nett und gaaanz langsam, damit auch du es eventuell
verstehen kannst:
Der Post von "C-User" implizierte das das mit dem Basic-geraffel nicht
geht. Dahinter steckte keinerlei Anmerkungen was das schlussendlich für
einen Sinn macht. Es ging allein um die hintergründige Behauptung, dass
das Basiczeugs einfach sprachlich nicht technisch weit genug wäre um das
funktionsfähig und ohne Klimmzüge umzusetzen.
Darauf folgten Antworten das es mit Basicgeraffel mikrobasic und luna
scheinbar problemlos geht und die Annahme aufgestellt mit Bascom gibts
da nix.
so, dein Post und du als offensichtlicher Bascom-Experte/Guru!? wirst
uns doch wohl jetzt nicht mit solchen Ausflüchten hängen lassen und uns
einen Solchen zeigen können, oder etwa doch nicht? hmm.
Der Freitag schrieb:> Es ging allein um die hintergründige Behauptung, dass> das Basiczeugs einfach sprachlich nicht technisch weit genug wäre um das> funktionsfähig und ohne Klimmzüge umzusetzen.
Das war übrigens C-User's Originalpost:
C-User schrieb:> Ja, ich kenne neben C auch noch andere Sprachen... Ich warte immer noch> auf eine USB-CDC Klasse in Pascal oder einen TCP-Stack in Basic. Bitte> "C-Hater", kläre mich auf!
Er wird auch noch lange darauf warten dürfen, denn niemand wird dank
fortschrittlicherer Hardware so doof sein, seine Zeit damit zu
verplempern, das vollständig in Software zu implementieren.
Aber natürlich ist mir klar, worum's hier geht, "Ein Compiler muss mit
sich selbst nativ geschrieben werden können", oder "Einen Stack in
seiner nativen Sprache schreiben"
Wenn sich für Bluna jemand die Mühe gemacht hat, einen Stack von C nativ
in Basic abzukopieren, ist das schön, jedoch im Zeitalter
fortschrittlicherer Lösungen auch schön doof.
Aber um das geht's Dir ja nicht, sondern: ist's ein Maß für Qualität
oder Nützlichkeit der Sprache, oder beeindruckt's mich? Nö ;D
Hab's doch schon erwähnt, die Luna-Geschichte ist ein geschmacklich
veränderter C-Abklatsch mit Stilelementen, die man wahrscheinlich recht
einfach mit entsprechenden Makros dem GCC aufpfropfen könnte.
Ist eigentlich bekannt, dass Luna auf dem Atari als Datei-Editor begann?
Danach hat der Entwickler weitergewurstelt und wollte es als Oberfläche
für den Bascom-Kommandozeilencompiler andienen. Nachdem das nicht
hinhaute (wahrscheinlich zu elitär LOL) wurd's ein an C angelehnter
Compiler, der sich 'nen Basic-Touch gibt. Kopiert wird auch heut' noch
gern, siehe eben besagter TCP-Stack.
Soweit mir bekannt ist, hat dagegen bei den Bascom Libs der Wiznet
Module noch jemand selbst nachgedacht und selbst programmiert. ;-)
aha, um es also Zusammenzufassen: mit Bascom ist man da auf dem Holzweg,
gibts nix. Eine Portierung von nützlichen Sourcen ist auch mal eine
Vorlage für Einsteiger. Es geht bei Examples manchmal nur um ein
Example, wobei ich USB-CDC durchaus für sinnvoll erachte. Bei bascom
scheint das ja alles anders zu sein, da muss man dann wohl halt darauf
warten das sich irgendeiner von den Würstchen hinsetzt und ein neues
Makro bastelt, damits auch der geneigte Bascom-frickler benutzen kann.
Was der luna-typ da macht und seit wieviel Jahrzehnten der programmiert
ist mir absolut wurscht. Ich weiß sowieso nicht warum man sich so
dermaßen an sowas verbeißen kann. Komplexe?
Deine persönliche Meinung zu der offensichtlich potenteren Konkurrenz
hast ja nun schon ausreichend vorgekaut. Erzähl mal was Neues - ach
nein, lass es lieber, wenn man sich mal ein wenig durchs Forum hangelt,
ist von einem MWS sowieso nichts sinnvolles zu finden außer aufgeblähtes
möchtegern-intellektuelles Geschwafel. Viel heiße Luft, sonst nichts.
moin moin,
C-User schrieb:
> Ja, ich kenne neben C auch noch andere Sprachen... Ich warte immer noch> auf eine USB-CDC Klasse in Pascal oder einen TCP-Stack in Basic. Bitte
da progt jemand ausschliesslich in Pascal:
http://www.rosseeld.be/DRO/PIC/index.htm
Mit Gruß
Pieter
Der Freitag schrieb:> aha, um es also Zusammenzufassen: mit Bascom ist man da auf dem> Holzweg,> gibts nix. Eine Portierung von nützlichen Sourcen ist auch mal eine> Vorlage für Einsteiger. Es geht bei Examples manchmal nur um ein> Example, wobei ich USB-CDC durchaus für sinnvoll erachte. Bei bascom> scheint das ja alles anders zu sein, da muss man dann wohl halt darauf> warten das sich irgendeiner von den Würstchen hinsetzt und ein neues> Makro bastelt, damits auch der geneigte Bascom-frickler benutzen kann.>> Was der luna-typ da macht und seit wieviel Jahrzehnten der programmiert> ist mir absolut wurscht. Ich weiß sowieso nicht warum man sich so> dermaßen an sowas verbeißen kann. Komplexe?>> Deine persönliche Meinung zu der offensichtlich potenteren Konkurrenz> hast ja nun schon ausreichend vorgekaut. Erzähl mal was Neues - ach> nein, lass es lieber, wenn man sich mal ein wenig durchs Forum hangelt,> ist von einem MWS sowieso nichts sinnvolles zu finden außer aufgeblähtes> möchtegern-intellektuelles Geschwafel. Viel heiße Luft, sonst nichts.
Da brüllt aber der Löwe, oder sagen wir besser die Maus.
Abgesehen davon scheinst mir nicht viel Ahnung zu haben und wieso Du
Programmierer, die eine Lib in Assembler schreiben, denkst als
"Würstchen" zu bezeichnen, erschliesst sich mir auch nicht. Und nein,
eine Funktion in Assembler ist deswegen auch kein Makro.
Und ja, in Bascom, genauso wie in jeder anderen Programmiersprache
braucht's jemand mit spezialisiertem Wissen, der sich einer Sache
annimmt. Ohne mich sehr gründlich damit zu beschäftigen, könnt ich
keinen TCP-Stack schreiben, genausowenig offenbar der Erzeuger des
Luna-Stacks, sonst hätte er nicht abkopiert. Hinzu kommt, ich würd's
auch nicht da ich nicht so doof bin, mir Arbeit zu machen, wenn's
bereits verfügbar ist. D.h. ein Anwender, der eine Funktion selbst nicht
schreiben kann, wird immer auf jemand Anderen angewiesen sein. Je größer
die Community dazu oder je umtriebiger der Hersteller/Anbieter, desto
schneller geht das.
Komplexe scheinen Dir übrigens nicht fremd zu sein,sonst müsstest jetzt
nicht so um Dich schlagen. Und wenn ich nach "Der Freitag" und dessen
Posts suche, findet sich bis auf Dein Auftreten in diesem Thread genau:
nichts. Also wieder ein Bluna-Fanboy, mit fluggs erstelltem Usernamen,
der Sturm läuft LOL
Interessant ist, dass des Meisters kleine Minions sich nie dazu
bekennen, immer schön im Hintergrund bleiben, nicht wahr?
MWS schrieb:> Da brüllt aber der Löwe, oder sagen wir besser die Maus.> Abgesehen davon scheinst mir nicht viel Ahnung zu haben und wieso Du> Programmierer, die eine Lib in Assembler schreiben, denkst als> "Würstchen" zu bezeichnen, erschliesst sich mir auch nicht. Und nein,> eine Funktion in Assembler ist deswegen auch kein Makro.
Da isser wieder, der Luftpuster, "Würstchen" im gleichen Sinne von
"Hanseln".
Nein, ich muss dich enttäuschen, ich habe mit den anderen "Würstchen"
auch nichts zu tun. Ich habe nur mächtig Spaß daran dich hier poltern zu
sehen und wie du eine putzig anmutende Paranoia pflegst.
Der Freitag schrieb:> auch nichts zu tun. Ich habe nur mächtig Spaß daran dich hier poltern zu> sehen
Lies Dir mal Dein voriges Post durch, dann erkennst Du wer da poltert.
Aber freut mich, wenn ich einem schlichten Gemüt etwas Spaß bereiten
konnte ;-)
Du hättest jetzt durchaus gegenteiliges Beweisen können, indem du Sätze
formulierst, die nicht inhaltslos sind, aber ich habe mich da scheinbar
getäuscht. Schade.
Ich bin aber fest davon überzeugt, dass du immer gern das letzte Wort
haben musst, einfach nur damit du die Überheblichkeit düngen kannst.
Insofern werden wir sicher noch viel Spaß hier an deinem einfach
gestrickten Geschwabbel haben.
Na, Freitag, wenn Du bis jetzt den Inhalt nicht verstehen konntest, dann
wird das auch nix mehr. Und wie ich schon sagte, freut mich, wenn Simpel
ihren Spaß dran haben.
>instabile Kompilate, insbesondere bei Projekten die mal übers Geblinke> oder von "Hallo" auf einem LCD hinaus gehen.
das problem hatte ich letztens auch. programm lief nicht. Ich konnte es
mit nicht erklären, weil ich die libs immer nutze. dann merkte ich, wenn
ich ein debug "geblinke" an einer stelle einfügte, das das programm
lief.. Im finalen programm habe ich es mit 2 "nop"s gelöst. der compiler
scheint wirklich problematisch. solche probleme haben wir hier in der
firma öfters - auch mit C. Die Sprache allein steht nicht für die
qualität der codeübersetzung oder die qualität des compilats. Bascom an
sich erzeugt mitunter (bei rechenoperationen) vergleichbar schnellen
code wie C. wenn interesse besteht können wir ja mal ein paar probleme
simulieren (das wurde vor langer zeit mal im roboternetz gemacht) und
die cycles vergleichen!
Schade, dass die ursprüngliche frage mal wieder nicht beantwortet wurde
- wie hier im forum üblich. Alles Trolle warscheinlich.
Habe mir heute luna und mikro runtergeladen und werde mal testen.
Thread beobachten
Seitenaufteilung abschalten