Forum: Mikrocontroller und Digitale Elektronik C-Programmierung und Mikrokontroller


von Bernd (Gast)


Lesenswert?

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

von Peter D. (peda)


Lesenswert?

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

von crazy horse (Gast)


Lesenswert?

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.

von Bernd (Gast)


Lesenswert?

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

von crazy horse (Gast)


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

@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

von Michael M. (Gast)


Lesenswert?

"...2 Files... Uhrzeitberechnung... Das ist nur ein Scherz
gewesen..."

Die 2 Links führen konsequenterweise auch noch auf verschiedene (aber
inhaltlich identische) Dateien... gg

von Bernd (Gast)


Lesenswert?

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.

von momo (Gast)


Lesenswert?

ASM programme sind immer kleiner als C, wenn man sich mit ASM gut
auskennt

von thkais (Gast)


Lesenswert?

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.

von Bernd (Gast)


Lesenswert?

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.

von Peter D. (peda)


Angehängte Dateien:

Lesenswert?

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

von thkais (Gast)


Lesenswert?

@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.

von thkais (Gast)


Lesenswert?

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.

von Bernd (Gast)


Lesenswert?

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
Noch kein Account? Hier anmelden.