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?
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...
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 | if Variable = 5 then |
2 | ...
|
3 | end if |
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 Sonderzeichen newcat 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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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? ?
ich vergaß noch: aktuell würde ich beispielsweise gern den USB-Kram von z.Bsp. 32u4 sinnvoll einsetzen (zumindest serielle Kommunikation).
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.
Nachtrag: manchmal kommt der Asterisk (*) eben nicht so wie gedacht im Text..
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 :-)
danke, habs schon gefunden: http://forum.myluna.de/viewtopic.php?f=8&t=460 dann werde ich mal damit herumspielen..
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.
wieso ist das nicht effizient? Du weißt doch gar nicht, was der compiler daraus macht...
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
Um den Vergleich abzuschließen: Es ging um BASCOM vs. mikroBasic 6.0.1 mikroBasic Source:
1 | program SimpleMath |
2 | |
3 | DIM a as byte |
4 | DIM b as byte |
5 | DIM c as byte |
6 | DIM d as byte |
7 | |
8 | Sub Procedure DoIt |
9 | d = a * b + c |
10 | end sub |
11 | |
12 | main: |
13 | a = 2 |
14 | b = 5 |
15 | c = 10 |
16 | DoIt
|
17 | end. |
mikroBasic ASM output ergibt:
1 | _DoIt:
|
2 | |
3 | ;SimpleMath.mbas,9 :: Sub Procedure DoIt |
4 | ;SimpleMath.mbas,10 :: d = a * b + c |
5 | LDS R17, _a+0 |
6 | LDS R16, _b+0 |
7 | MUL R17, R16 |
8 | MOV R17, R0 |
9 | LDS R16, _c+0 |
10 | ADD R16, R17 |
11 | STS _d+0, R16 |
12 | ;SimpleMath.mbas,11 :: end sub |
13 | L_end_DoIt: |
14 | RET
|
15 | ; end of _DoIt |
16 | |
17 | _main: |
18 | LDI R27, 255 |
19 | OUT SPL+0, R27 |
20 | LDI R27, 0 |
21 | OUT SPL+1, R27 |
22 | |
23 | ;SimpleMath.mbas,13 :: main: |
24 | ;SimpleMath.mbas,14 :: a = 2 |
25 | LDI R27, 2 |
26 | STS _a+0, R27 |
27 | ;SimpleMath.mbas,15 :: b = 5 |
28 | LDI R27, 5 |
29 | STS _b+0, R27 |
30 | ;SimpleMath.mbas,16 :: c = 10 |
31 | LDI R27, 10 |
32 | STS _c+0, R27 |
33 | ;SimpleMath.mbas,17 :: DoIt |
34 | CALL _DoIt+0 |
35 | L_end_main: |
36 | L__main_end_loop: |
37 | JMP L__main_end_loop |
38 | ; end of _main |
Used ROM (bytes): 138 Static RAM (bytes): 4
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.
:
Bearbeitet durch User
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.
D. V. schrieb: > Um den Vergleich abzuschließen: > Es ging um BASCOM vs. mikroBasic 6.0.1 ordentlicher code, so muss das aussehen.
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
:
Bearbeitet durch User
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!
>Da solltest Du Dich mal an die eigene Nase fassen, da hast Du schon >genügend zu tun. Du meinst mich, als Gehilfen des Grauens? Ja, das stimmt.
Wobei ich noch zusätzlich bemerken möchte, dass Popcorn, nicht µC-gerecht zubereitet, ungenießbar ist.
Helmut Lenzen schrieb:
>Das kann man in C auch ist aber sehr selten erfoderlich.
Ja hängt von deiner Anwendung ab,
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?
So, nun kriegt euch mal wieder ein, muß ja auch mal Schluß sein. Zur Frage passt es nicht mehr. Jeder macht was er möchte.
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
:
Bearbeitet durch User
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 abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.