www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik C-Programmierung und Mikrokontroller


Autor: Bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Michael M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: momo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ASM programme sind immer kleiner als C, wenn man sich mit ASM gut
auskennt

Autor: thkais (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Peter Dannegger (peda)
Datum:
Angehängte Dateien:
  • AC.BAT (506 Bytes, 57 Downloads)

Bewertung
0 lesenswert
nicht 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

Autor: thkais (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: thkais (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.