Zitat Zitat von Marco78
Das du nichts weiter schreiben möchtest finde ich schade
Na, dann antworte ich nochmal

Ist das mit C anders? Es ist ja auch nur ein Compiler. So wie ich die C-Codes sehe, sehen sie für mich aus wie Basic-Codes. Abgesehen von der Sprache
Aber was im Controller später abläuft ist für mich auch noch nicht erkennbar.
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.

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.

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.

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.

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.

Zitat Zitat von Frank
Die sind noch nicht mal standardisiert, jeder Hersteller packt andere Funktionen zusammen.
Noch nie was von ANSI-C gehört?


Schönen Sonntag,

Jan