Mikrocontroller in c und Assembler programmieren

Und, zu welcher Antwort bist du gekommen?

Es ist möglich Assembler Code mit C Code zu verheiraten.

Frag doch mal Tante Google die weiß wie!!!

JA

und hier bekommst Du für den AVR-GCC sogar gezeigt wie es geht.
http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Assembler_und_Inline-Assembler
Inline und als externes Assembler File

HI

Wenn du Assembler kannst, wozu brauchst du dann noch C?

MfG Spess

Tobi schrieb:
> ob es
> möglich ist, einen Teil eines Programms in c zu programmieren
> und einen (zeitkritischen) Teil, des gleichen Programms in Assembler??

Ja es geht.
Aber warum ?????

Wenn ein Teil so zeitkritisch ist , das es auf einzelne Takte ankommt, 
ist im Projekt von Anfang an etwas total falsch gelaufen.

Eine solche Software wird nie und nimmer auf Dauer stabil und 
zuverlässig laufen.  Dafür gibt es durch Interrupts, unterschiedliche 
Ausführungszeiten von Maschinencode, Latenzen beim 
Interrupteinstieg,...... viel zu viele mögliche Verzögerungen die nicht 
kalkulierbar sind.

Abhilfe :
Die Zeitkritischen Teile so entwickeln das sie nicht mehr zeitkritisch 
sind.
Also zb , nur Daten sammeln aber nicht verarbeiten. Das Verarbeiten hat 
meist Zeit.
Oder einen µC mit mehr Leistung auswählen.

Tobi schrieb:
> ob es
> möglich ist, einen Teil eines Programms in c zu programmieren
> und einen (zeitkritischen) Teil, des gleichen Programms in Assembler??

Von einigen ideologischen Eiferern abgesehen, ist das eigentlich im 
Embedded-Bereich der Normalfall. Nicht nur bei zeitkritischen Teilen, 
der Zugriff auf Hardware ist oft in Assembler eher einfacher als in C - 
so man denn Assembler kann.

Du brauchsr aber eine sehr gute Dokumentation, besonders wenn Assembler 
und C-Compiler nicht aus einer Hand sind - man muss schon genau wissen, 
wie eine Assembler-Prozedur von C aus aufgerufen wird, und manchmal auch 
umgekehrt, obwohl das eher selten vorkommt. Im Handbuch gibt es dafür 
einen Abschnitt "Interfacing to Assembler" oder so ähnlich. Beherrscht 
man das, kann man einfach alles machen, auch 5 verschiedene Sprachen 
gemischt einsetzen, vorausgesetzt, alle Compiler produzieren Files, die 
der Linker verarbeiten kann (z.B. .OBJ). Wenns sein muss, geht es auch 
ohne das, mit Sprungtabellen, aber das ist dann schon mühsam.

Gruss Reinhard

Ralph schrieb:
> Ja es geht.
> Aber warum ?????
>
> Wenn ein Teil so zeitkritisch ist , das es auf einzelne Takte ankommt,
> ist im Projekt von Anfang an etwas total falsch gelaufen.

Du hast wohl noch nie was DSP-mäßiges (Filter, FFT ..) programmiert.

Da kann es durchaus passieren, dass nur ein paar Routinen (komplexe 
Schleifen) die meiste Prozessorzeit verbrauchen. Der Unterschied 
zwischen nichtoptimiertem C, optimiertem C und Assembler kann gewaltig 
sein und hängt oft stark mit den Möglichkeiten der CPU zusammen.

Ein Vorteil bei selbstgeschriebenen Assemblerroutinen ist auch, dass man 
im C nichtoptimiert laufen kann, was das Debugging wesentlich 
vereinfacht.

Ralph schrieb:

> Wenn ein Teil so zeitkritisch ist , das es auf einzelne Takte ankommt,
> ist im Projekt von Anfang an etwas total falsch gelaufen.

Einfaches Beispiel, was man in C nicht lösen kann:

Der 8051 hat einen Timer 0, den man im 16-bit-Mode betreiben kann. 
Verwendet man ihn als Systemtakt, dann muß man ihn nach einem Überlauf 
im Interrupt präzise mit dem errechneten Wert nachladen. Und das geht 
nur mit genau aufeinander abgestimmten Assemblerbefehlen.

Für sowas habe ich neben dem C-Code dann auch ein Assemblerfile.

Wohl sah ich schon Leute, die das ganz pragmatisch mit dem Oszi machen, 
und die Zahl durch Probieren ermitteln. Das geht natürlich auch, mehr 
oder weniger fehlerbehaftet, gehört aber zum Thema "Bastelei".

>Ja es geht.
> Aber warum ?????
>
> Wenn ein Teil so zeitkritisch ist , das es auf einzelne Takte ankommt,
> ist im Projekt von Anfang an etwas total falsch gelaufen.

Was ist denn, wenn eine Interuptroutine besonders schnell sein muss?
Die hat dann nichts mit der Laufzeit des Hauptprogramms zu tun, und das 
Programm wird sehr wohl stabil laufen

>C ist nämlich nicht so langsam, wie manche denken. D.h. oftmals gibt es
>gar keinen so zeitkritischen Teil, wo Assembler wirklich helfen würde.
>C hat nur bestimmte Vorlieben, die manchmal auf einem 8-Bitter etwas
>umständlichen Code erzeugen können.

Sehr richtig. Nur dem einem fällt das eine leichter, eimem anderen die 
Assembler Methode.
Deshalb ist es ja schön, dass man beide Möglichkeiten hat.

Reinhard Kern schrieb:
> Von einigen ideologischen Eiferern abgesehen, ist das eigentlich im
> Embedded-Bereich der Normalfall. Nicht nur bei zeitkritischen Teilen,
> der Zugriff auf Hardware ist oft in Assembler eher einfacher als in C -
> so man denn Assembler kann.

So kenne und sehe ich das auch, immer noch fast täglich.

PS: Ralph hat keine Anhnung

Peter Dannegger schrieb:

> Das ist aber auch eine typische Anfänger-Vorgehensweise, mit dem Oszi
> geht Deine Uhr dann nach dem Mond.

Ja eben, wenn es um eine Uhr geht.

Sorry, daß ich das jetzt sagen muß, aber ich sah das genau bei einem 
langjährigen Profi.

> Oder man schaut ins Assemblerlisting, wieviel Zyklen genau das Laden
> kostet.

Ich verlasse mich nicht gerne auf den Compiler, der mir dann irgendwann 
mal was anderes serviert, und neue Störungen einbringt. Das braucht nur 
ein Versions-Update zu sein, wo was geändert wurde. Man compiliert, und 
hat dann auf einmal anderen Code im Listing stehen.

Ansonsten finde ich ein Assemblerfile zwischen C-Files nicht häßlich. 
Und wartbar muß die Timernachladung für den 8051 auch nicht mehr sein. 
Die bleibt für alle Zeiten so, wie sie auch vor 20 Jahren schon war. Da 
gibts dann nichts mehr zu optimieren.



Ein weiteres Beispiel von mir:

Keil hat für die LPC2000 ein Startup-File in Assembler. Das hat bestimmt 
auch so seinen Grund. Ob das aktuell immer noch so ist, weiß ich 
indessen nicht.

Oder, was ich im LPC2000 in Assembler selbst machte: Den 
Spurious-Interrupt-Handler, den Surprise-Interrupt-Handler, beide ins 
Startup-File an den Vektoren eingefügt, und den Nesting-IRQ-Handler. 
Irgendwas war dort immer drin, was in C nicht geht.

Das LPC2000-Tutorial von Trevor Martin (von Rowley, Compilerhersteller) 
hatte da auch die Assemblerbeispiele. Der müht sich sicherlich nicht 
umsonst damit ab.

Wenn man das Interface zwischen Assembler und C einmal raus hat, ist 
doch alles kein Problem mehr.

SDCC hat im Manual zum Compiler auch was über Assembler-Interface 
stehen, aber nur minimalst. Dort mußte ich einige Zeit herum probieren, 
bis es klappte. Denn mit Beispielen haben die es da nicht so. Die 
Übergabe- und Rückgabeparameter waren noch beschrieben. Und wenn man 
dann assembliert, hat man auf einmal die ellenlange Registersicherung 
mit drin. Dann beginnt man dort wieder zu suchen. Also, es gab da so 
einige Dinge zu beachten. Wenn ein anderer das dann sieht, was man 
machte, sagt er natürlich: Sieht doch simpel aus, das hätte ich locker 
auch gekonnt. Wie immer, wenn man was fertiges sieht. ;-)

Peter Dannegger schrieb:
> Wilhelm Ferkes schrieb:
>> Wohl sah ich schon Leute, die das ganz pragmatisch mit dem Oszi machen,
>> und die Zahl durch Probieren ermitteln.
>
> Das ist aber auch eine typische Anfänger-Vorgehensweise, mit dem Oszi
> geht Deine Uhr dann nach dem Mond.
> Man sollte schon den Simulator nehmen, der Oszi kann ja nicht eine
> Sekunde auf den CPU-Zyklus genau auflösen.

Nein, man sollte eine Sprache nehmen, mit der man die Zahl an Taktzyklen 
genau kontrollieren kann. Alles andere ist Gemurkse, egal ob per Oszi, 
per Simulator oder per Ausrechnen aus generiertem Assembler-Code.
Wenn es wirklich um zyklengenaue Timings geht, ist eine Implementation 
in Assembler die einzige saubere Möglichkeit, und meistens sind diese 
zeitkritischen Code-Teile auch sehr klein.
Es hat schon einen Grund, warum die Loops der delay-Funktionen der 
avr-libc in Assembler implementiert sind und nicht in C und dann per 
Austesten im Simulator auf die richtige Zeit hingefrickelt wurden.