Hi, wie weit kann man sich das Leben erleichtern, wenn man von Assembler auf C umsteigt? Bei PC Programmen ist es doch in der Regel so, dass das Betriebssystem alle I/Os handlet, und man mit den entsprechenden C Befehlen dann z.B. die Daten vom seriellen Port liest. Allerdings buffert das OS die einkommenden Daten, so dass man die Daten abrufen kann, wenn man sie braucht, und nicht wenn sie empfangen werden. Gibt es in der Mikrokontrollerprogramierung unter C etwas ähnliches? So etwas wie ein Mini-OS, dass im Rahmen der Möglichkeiten (RAM) z.B. die Daten vom I2C Bus automatisch einließt, ohne das man eine eigene ISR schreiben muss? So dass man im nachhinein eine komplette Nachricht auf einmal auslesen kann, und nicht jedes Byte einzeln lesen muss? Danke, Bernd
Das geht so bei Mcs nicht, da solche Treiber immer an eine konkrete Hardwarebeschaltung gebunden sind. Aber bei MC-Projekten will man ja gerade möglichst flexibel sein. Auch würden dann sämtliche unbenutzten Treiber nur unnötig Flash belegen (Treiber nachladen geht ja nicht). Und bei I2C gehts schonmal garnicht, da ja die verschiedenen I2C-Chips völlig unterschiedlich angesprochen werden (IO-Expander, RTC, EEPROM usw.). Allerdings ist es unter C viel leichter, sich fertige Module für die einzelnen Funktionen zu schreiben und die dann, wenn man sie wieder benötigt, einfach dazu zu linken. Ich hab z.B. für die UART nen Haufen verschiedener Funktionen, je nachdem, ob man mit Polling oder im Interrupt, gepuffert oder ungepuffert, linear oder zirkular gepuffert, mit Text oder Binärdaten arbeiten will. Peter
Tja, die eierlegende Wollmilchsau ist dafür weder C noch ein wie auch immer geartetes Betriebssystem. Für ein echtes Betriebssystem im PC-Sinne sind die Resourcen zu knapp (ROM, RAM, Rechenzeit), universell kann es sowieso nicht sein, im Zweifelsfall würde also immer genau das fehlen, was man gerade braucht. Funktionalität, die man braucht, müssen entweder -direkt vom Compiler unterstützt werden -aus einer library eingebunden werden -selbst geschrieben werden.
Wenn ich das also richtig verstehe, sind die Vorteile von C gegenüber Assembler (mit reichlich Macros + Quelltext Generator) nur klein. Also hauptsächlich wenn man rechnen will, oder Funktionen à la printf verwendet. Habe mir mal den Overhead von einem kleinen C-Programm beim PIC18 angesehen. Ich glaube, hätte man das ganze in gutem Assembler programmiert, wäre es deutlich kleiner und schneller gewesen. "Und bei I2C gehts schonmal garnicht, da ja die verschiedenen I2C-Chips völlig unterschiedlich angesprochen werden (IO-Expander, RTC, EEPROM usw.)." Hätte man die Möglichkeit dem Compiler/Assembler mitzuteilen, welche ICs zum Einsatz kommen, würde es ja reichen, nur für diese den Objectcode zu linken. "Allerdings ist es unter C viel leichter, sich fertige Module für die einzelnen Funktionen zu schreiben und die dann, wenn man sie wieder benötigt, einfach dazu zu linken." Das hört sich für mich danach an, dass ich mir einen Source-Code Generator für Assembler bauen muss, der dann je nach Bedarf die entsprechenden Funktionen und Variablen generiert. Dann hätte ich's fast genau so Bequem wie in C. Gruß, Bernd
Bei sehr kleinen Programmen sind in der Tat Assemblerprogramme kleiner, aber was macht das schon, solange das Programm in den gewünschten Chip passt? Habe ich 1kB zur Verfügung, ist es mir völlig wurscht, ob das Programm 100 oder 400Byte belegt. Wird das Programm komplexer, hat C eindeutig auch in Codegrösse die Nase vorn (hat nichts mit C speziell an sich zu tun, sondern mit optimierenden Algorithmen des Compilers), es sei denn, man will Unmengen von Zeit in die Optimierung des Asseblerprogramms stecken - dann kann ein guter Programmierer noch was rausholen. Hauptvorteile einer Hochsprache für mich: -Zeitersparnis beim Programmieren (geschätzt 20% gegenüber Assembler, eher noch weniger) -keine Probleme mit Variablenverwaltung und Stack -enorme Vereinfachung bei Berechnungen -meist weniger RAM-Bedarf durch konsequente Nutzung lokaler Variablen -wesentlich vereinfachte Wiederverwendbarkeit von Funktionen, da man sich Art der Parameterübergabe und Rückgabewert keine Gedanken machen muss. Aber die Diskussion hatten wir schon öfter, und ich halte es fast für unverzichtbar, dass einer, der in C programmieren will, auch zumindest die Grundzüge der Assemblerprogrammierung und die jeweilige Hardware des Chips beherrscht.
@crazy horse, Du nimmst mir das Wort aus dem Mund. C steigert das Entwicklungstempo drastisch und reduziert die Fehlerquellen drastisch. Das sind also definitiv keine "kleinen" Vorteile. Auch muß ein Assemblerprogrammierer immer Kompromisse zwischen Lesbarkeit und Optimierung schließen, ein Compiler hat dagegen die Freiheit völlig unlesbaren optimierten Code zu erzeugen. Z.B. hat der Keil C51 die Option "Common block subroutine packing", d.h. er sucht selbsttätig gleichartige Codesequenzen und packt sie in ein Unterprogramm. Um den realen Overhead eines C-Programms zu ermitteln, muß man sich entweder das Assemblerlisting ansehen oder erst ein leeres Programm erstellen und den Grundbedarf dieses leeren Programms abziehen. Der PIC ist auch kein gutes Beispiel für einen C/Assembler Vergleich, da seine Architektur sehr C feindlich ist. Beim 8051 oder AVR sieht das schon wesentlich günstiger aus, da ist ein Overhead von nur 5..50% realistisch. Einer der größten Vorteile von C ist, daß es portabel ist, nur die Hardwarezugriffe müssen natürlich angepaßt werden. Wenn Du Dir z.B. mal in der Codesammlung meine Routine für die Datums- und Uhrzeitberechnung ansiehst, dann sind dort 2 Files, "TIME.C" und "TIME.C51". Das ist nur ein Scherz gewesen, beide sind nämlich völlig gleich (getestet mit WINAVR, Borland C und Keil C51). Peter
"...2 Files... Uhrzeitberechnung... Das ist nur ein Scherz gewesen..." Die 2 Links führen konsequenterweise auch noch auf verschiedene (aber inhaltlich identische) Dateien... gg
Na ja, macht ja vielleicht doch Sinn, sich mal mit C auseinander zu setzen. Habe mir mal das WinAVR Paket herruntergeladen. Gibt es dazu irgendwo eine Dokumentation, die man sich komplett herrunterladen kann? Habe nur eine Online-Doku gefunden.
ASM programme sind immer kleiner als C, wenn man sich mit ASM gut auskennt
Nachdem ich bei den bisherigen Diskussionen um C immer als Assembler-Hardliner aufgetreten bin, möchte ich auch meine Erfahrungen mit C kurz anreißen. Argwöhnisch habe ich mich an das Thema herangetastet, C war (und ist teilweise immer noch) für mich eine recht kryptische Angelegenheit. Ich habe momentan ein größeres Projekt am Bein - zu groß für Assembler, außerdem ist Gleitkomma notwendig, das waren die K.O.-Kriterien. Nächste Entscheidung: Basic oder C. Basic kenne ich schon, und ich habe mir BASCOM angeschaut. Der erste Eindruck: Sehr gut, aber: Zu abstrakt, zu weit weg von der Maschine. Blieb noch C, aber das von Grund auf. Das Vorurteil, C sei nur ein Makro-Assembler, hat sich bestätigt - aber im positiven Sinn. Auf der einen Seite hat man alle Möglichkeiten offen, auf der anderen Seite wird der Code doch wesentlich einfacher lesbar - das muß ich sogar zugeben. Fazit: -Es lohnt sich auf jeden Fall, sich die Sache mal anzuschauen. -Die Portabilität ist nur theoretisch vorhanden, teilweise unterscheiden sich bereits die Codes verschiedener Compiler für den gleichen Controller. -Für Anfänger gibt es einige Hürden zu nehmen. Zwar ist das WINAVR-Paket wirklich gut (Respekt vor dieser Leistung), aber was genau ich mit dem makefile so einstellen kann, das verstehe ich nicht so richtig - obwohl ich Batch-Files von Clipper gewohnt bin. Zum Thema I²C (bzw. TWI): Ich arbeite momentan genau am gleichen Problem. Hinzu kommt, daß ich unnötige Wartezyklen beim Zugriff auf den I²C vermeiden will, am liebsten wäre mir eine Bedienung des Ganzen im Hintergrund per Interrupt. Meine bisherigen Überlegungen gehen dahin, einen Ringpuffer anzulegen, der von der Interrupt-basierten I²C-Routine abgefragt wird. Einziges Problem: Die Zuordnung von Daten beim Lesen, beim Schreiben ist ja alles klar. Und dann noch die Fehlerbehandlung, weil ja der Befehl zum Schreiben und der tatsächliche Vorgang zeitlich getrennt sind. Naja, ich werde noch ein wenig darüber brüten.
Na ja, C++ ist mir vertraut, also sollte C nicht fern sein. @thkais: Du erwähnst auch WinAVR. Wo findet man den eine möglichst kompakte Einführung (z.B. als PDF), damit man es auch mal ordentlich ausdrucken kann.
Zum Thema Doku, such mal nach "avr-libc-user-manual-1.0.3.pdf". Zum Thema Make, ich mache das mit einer Batch im DOS-Fenster, die compiliert alle *.C im aktuellen Verzeichnis zusammen. Die muß man nur editieren, wenn man den AVR-Typ ändern will. Zum Thema I2C: Bei AVRs mit Hardware I2C kann man das im Interrupt machen. Allerdings wird das eben ganz speziell auf bestimmte I2C-Chips zugeschnitten sein, da die einfach zu unterschiedlich sind. Peter
@Bernd: So etwas suche ich auch... Leider sind die Informationen sehr verteilt... Hier einige Seiten, die mir weitergeholfen haben: Das hiesige Wiki hat ein gutes Tutorial für die ersten Schritte: http://www.mikrocontroller.net/wiki/AVR-GCC-Tutorial http://www.pronix.de/modules/C/openbook/ (Ich habe mir inzwischen das Buch auch gekauft) Dann helfen natürlich auch Beispielcodes weiter, z.B: http://www.mc-project.de (u.a. auch ein makefile-Beispiel) http://home.t-online.de/home/holger.klabunde/homepage.htm (Hier hat mir der Code für das T6963-Display sehr weitergeholfen) http://homepage.sunrise.ch/mysunrise/peterfleury/ Vielleicht hilft diese Linkliste ja schon weiter. Sicherlich wäre es auch interessant, das Wiki zu erweitern, sobald ich ein wenig Luft habe, werde ich mal schauen, ob ich etwas beitragen kann.
Nachtrag zum Thema "makefile": Im neuesten WinAvr-Paket wird das sehr komfortabel gelöst, ein DOS-Batchfile ist nicht mehr notwendig. Mit dem mitgelieferten Beispiel-makefile klappt bei mir sogar das Programmieren mit Ponyprog direkt aus "Programmers Notepad" heraus. Einfacher gehts fast nicht mehr.
Durch die ganzen Links muss ich mich jetzt erst mal durcharbeiten. Habt ihr vielleicht auch noch einen Dokumentationslink zu Programmers Notepad? Auf http://www.pnotepad.org/download.php werde ich einfach nicht fündig.
Bitte 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.