> hat der Abart Compiler Fenster für die Eingabe/Ausgabe die später am
> Controller Displays und Taster übernehmen sollen?

Äh, was ist dieser \"Abart Compiler\"? Gibt es den, oder meinst Du damit einen \"abartigen Compiler\"?

Ansonsten... Das, was ich als Compiler kenne, schnappt sich nur Deine Textdatei mit den C-Befehlen darin und wandelt das in etwas um, was man prinzipiell dem entsprechenden Prozessor (i386, oder eben dem von Dir gewählten Mikrocontroller) als ausführbares Programm vorsetzen kann. Häufig muss aber danach noch ein anderes Programm (der Linker) an diesem \"Compiler-Ergebnis\" herumfummeln, bis etwas entsteht, womit der Ziel-Prozessor dann wirklich was anfangen kann. Es gibt aber auch ein paar Fälle, wo bereits der Compiler etwas erzeugen kann, was dann ein ausführbares Programm ist. Dann würde er am Schluss ein .EXE-Programm \"ausspucken\" (wenn die i386-Prozessorarchitektur als \"Zielplattform\" gewählt wurde), oder vielleicht auch eine .BIN-Datei.

Keines dieser beiden Programme stellt aber, soweit ich es weiß, einen Ersatz für die Ein-/Ausgabegeräte Deiner Zielplattform zur Verfügung. Dafür braucht man meistens einen Emulator, der eben gegenüber Deinem fertig compilierten und ggf. \"gelinkten\" Programm so tut, als wär\' er ein echter Mikrocontroller (o.ä.) mitsamt den zugehörigen Ein-/Ausgabegeräten und was noch so alles zur \"Zielplattform\" dazu gehört.

Falls ich mit all dem Recht habe, müsstest Du so vorgehen:

1. Compilieren Deines C-Programms (des \"Quellcodes\"), Ergebnis: meist eine .OUT- oder .BIN-Datei, seltener .EXE oder gar .OBJ
2. ggf. das \"Ergebnis\" noch \"linken\", Ergebnis: beim PC (\"i386\") als Zielplattform meistens eine .EXE-Datei (DOS/Windows), seltener auch eine .BIN-Datei (Unix/Linux)
3. dieses Ergebnis entweder direkt dem Mikrocontroller übergeben, oder erst mal zu Testzwecken einem Emulator (auch schon mal \"Simulator\" oder \"virtuelle Maschine\" genannt).

> Oder ich stelle mir das alles zu einfach vor?

Keine Ahnung, ich habe bisher nur extrem wenig C-Programmierung (kaum mehr als \"HELLO.C\"  ) unter DOS, Windows und Linux gemacht. Und dieses \"Cross-Compilieren\", also C-Programme auf der einen Plattform (PC) schreiben und compilieren, um sie dann auf der anderen Plattform (Mikrocontroller) laufen zu lassen, also das habe ich noch nie gemacht.

Was mich aber wundert: In der Antwort an karlchen schreibst Du, der Compiler erzeuge eine .c-Datei. Ich kenne .c-Dateien eigentlich nur für den C-Quellcode, also das, was Du am Anfang eingibst. Also z.B. \"hello.c\" für den Kram, den man irgendwo abtippt (oder gleich fertig in die Finger kriegt) und aus dem der Compiler dann dieses \"Zwischenergebnis\" (.OUT, .BIN oder vielleicht .OBJ) \"herstellt\". Diese .c-Dateien sind also normalerweise Textdateien, die man mit Texteditoren lesen und bearbeiten kann. Und der Compiler liest diese .c-Dateien dann, schreibt/erzeugt sie aber nicht.

Was verbirgt sich also tatsächlich hinter Deiner geheimnisvollen .c-Datei? Erstellt Dir hier etwa ein Editor oder eine Entwicklungsumgebung eine .c-Datei, ohne dass Du das mitkriegst? Und wenn ja: Macht der Compiler dann überhaupt irgendwas damit, oder gibt er auf, ohne es Dir mitzuteilen?