Na klar würde das gehen, aber dann kann ich auch gleich den TCP/IP-Stack dort auch laufen lassen und einem kleinen Web-Server zum bedienen implementieren (z.B. AVR-IO-Pollin-Board mit Atmega). Das habe ich gerade am Laufen, aber halt auch nur eine 100us Task zusätzlich zum Web-Server, die aber mit sehr kleinem Jitter!. Das ist für 32kByte Flash, ca 1k RAM bei einem 8Bit-Prozessor und 10 MHz enorm und viel mehr geht halt nicht! Da ist natürlich meine Erwartungshaltung bei einem 32Bit-Prozessor mit 700Mhz, 512Mbyte RAM und 16Gbyte Flash deutlich höher.
Im Prinzip muss es gehen, denn seit ca 5 Jahren sind Echtzeittasks bei "richtigen" Betriebssystemen wie Linux in der Diskussion. Nach dem man Anfangs bei Linux den Kerneln "patchte" ist es gelungen Echtzeittasks mit dem Kernel zu ermöglichen (soll mit jedem neueren Kernel gehen). Ich selbst kann es leider nicht, da ich damals nur zugeschaut habe als wir das auf einem x86-Sytem ausprobierten (es lief!). Bei anderen Betriebssystemen benötigt man Zusatzsoftware (i.d.R. lizenz- und kostenpflichtig).
Die Trennung Echtzeit auf zusätzlichem Mikroprozessor und den Rest auf Linux-Plattform ist halt blöd, wenn man auf dem Mikroprozessor rechnen muss und genau weiss das hätte die FPU der Linuxplattform in einigen Nanosekunden erledigt. Selbst wenn man auf dem Linus-System rechnen lässt müssen die Ergebnisse rechtzeitig (halt in Echtzeit) an den Mikroprozessor.
Ausserdem würde ich sehr gerne den Komfort einer Linux-Plattform mit ssh-login, gcc aufrufen aus der Ferne nutzen. Im Moment renne ich von einem Raum zum anderen um den Mikroprozessor auszubauen zu meiner Entwicklungsumgebung zu bringen dort neu zu flashen um dann wieder in umgekehrter Reihenfolge den Erfolg der kleinen Programmänderung zu prüfen.
Der Echtzeittask auf einer Linux-Plattform wäre da halt die perfekte Lösung und aus meiner Sicht für viele Mikroprozessor-Probleme (Floating-Point, Speicherbedarf, Filesystem, TCP/IP, Bildschirmanbindung) die perfekte Lösung.
