Es ist schon richtig, dass es nicht sofort klar wird, wie ein Compiler diesen oder jeden Quelltext umsetzt. Das gilt selbstverständlich auch für C. In Bascom aber sind fertige Funktionen enthalten, über deren innere Abläufe man nix erfährt. Es werden bei AVR-GCC aber List-Files ausgegeben, in denen die C-Implementation und ihr ASM-Widerpart dargestellt sind, so dass man selber nachlesen kann, was wie gemacht wurde (vorausgesetzt, man beherrscht ASM). Außerdem gibt es vier verschiedene Optimierungsstufen, plus weitere Attribute, mit denen man die Codegenerierung zugunsten von Geschwindigkeit oder Speicherökonomie modifizieren kann. Wie es damit in Bascom steht, weiß ich nicht.
Also wenn man C programmiert muss man auch Assembler perfekt können! Dies hast du mit deinen Argumenten gesagt. Ich denke allein da sspricht gegen C. Man entscheidet sich für eine Sprache um Vereinfachungen zu haben und nicht nachher noch in Assembler debuggen zu müssen.

Abgesehen davon gibt es sowas wie eine Listfunktion in Basom Basic auch. Auch die Codeoptimierung kennt Bascom.


Bei einer eigenen Implementierung von einer pulsein-ähnlichen Funktion in C hätte man von vorneherein die Option, das Ganze interruptbasiert oder mit Polling aufzubauen. Bei Bascom hat man nur letztere Möglichkeit, oder man muss es selbermachen, und dann ist der Arbeitsaufwand in etwa gleich.
Falsch! Selbstverständlich hat man in Bascom auch beide Möglichkeiten! Gewöhnlich nimmt man jedoch den kürzesten Weg.
Ich würde nun gerne mal ein gegenstück zu dem Source in C sehen. Komisch das die C Leute immer theoretisch drüber reden aber praktsich kein Beispiel hin bringen. Ich will damit nicht sagen da sdu es nicht könntest, aber das der Overhead so groß ist, das die C-Programmierer oft keine Lust haben (zu faul sind) sowas aufzusetzen. Oder haben sie nur Angst schlecht auszusehen wenn der Code 5 mal so lang und 10 mal zu kompliziert aussieht?

Ein weiteres Beispiel wären die polling-basierten Empfangsfunktionen für das U(S)ART von Bascom. Sie funktionieren zwar, sind auch erstmal einfach zu verwenden, bremsen aber unangenehm aus und sind fehleranfällig. Ich muss gestehen, dass ich nicht weiß, ob es auch interruptbasierte UART-Funktionen für den Empfang gibt, die im "Hintergrund" arbeiten. Das würde Bascom in meinen Augen ein wenig rehabilitieren.
Dann sage ich es dir hiermit. Es gibt diese UART interrupt Funktionen! Hier gibt es in Bascom gegenüber C keine Nachteile.

Wenn man seine Treiber selber programmieren will, um Begrenzungen von Bascom-Funktionen aus dem Weg zu gehen, dann ist die Wahl zw. BASIC und C nur noch eine reine Geschmacksfrage, die man meiner Meinung nach aber zugunsten von C entscheiden sollte : es ist kostenlos und flexibler.
Welche Begrenzungen???? Es gibt keine Nun wenn dem Programmierer, der offenbar Bascom Basic wenig kennt kein Argunment mehr einfällt, dann kommt nur noch der Preis-Hammer
Und da muss ich sagen das ich den Preis schon alleine wegen der Entwicklungsumgebung für ausgesprochen niedrig halte. Der enorme Zeitgewinn beim entwickeln einer Anwendung macht den innerhalb kürzester zeit wett. Schau dir mal die preise bei C-COmpilern mit so einer Entwicklungsumgebung an!!!


ARMs verwendet man, wenn andere Controller nicht mehr ebenbürtig sind. Das setzt meinem Verständnis nach voraus, dass man andere Controller bereits ausgereizt hat. Wenn man bereits so weit ist, das man mit Bascom jeden Hardwaretreiber selber schreiben/optimieren muss/kann, dann hat man die Vorzüge von diesem Compiler sowieso längst hinter sich gelassen. ARMs haben eine wesentlich größere Flexibilität, die hinter Bascom-Funktionen zu verkapseln, macht keinen Sinn. Entweder, sie sind einfach zu verwenden, und sie unterschlagen Optionen, oder sie können alles, sind aber wieder komplex.
32 Bit Controller nimmt man vorwiegend wenn viele Rechenoperationen und viel Speicher notwendig werden. Und da ein gute rBasic Compiler kaum schlechteren Code als C produziert laufen deien Argumente ins Leere. Wir haben doch gesagt das gerade Hochsprachen bei mehr Rechenleistung gewöhnlich auch immer mehr zum Zue kommen. Bei bestimmten Anwendungen kann dann sogar ein Betriebsystem sinnvoll sein. Hier bewegen wir uns aber im Kreis!

Noch nie was von ANSI-C gehört?
Doch, nur es gibt nahezu keine Anwendung die mit reinem ANSI-C programmiert wird. Was nützt einem die Kompatiblität auf dem Papier?

Ebenfalls schönen Sonntag
Gruß Frank