ARM-9 Einstieg: Linux und die IO Ports

> Kann man die I/O Pins genau so einfach (bzw. für die
> Pessimisten: genau so schwer) programmieren,
> als würde man es ohne das Betriebssystem tun?

Das sollte funktionieren. Allerdings musst Du darauf achten, daß es 
keine Nebenwirkungen geben kann; wenn eine andere Task des Linux-Systems 
(oder auch ein Devicetreiber) auf Register zugreift, die Du für Deine 
Aktivitäten nutzen möchtest, kann das im Falle eines Taskwechsels zu 
sehr interessanten Nebenwirkungen führen.

Außerdem darf Dein Code keine Interrupts auslösen bzw. Peripherie des 
Controllers dazu bringen, dies zu tun; der Kernel ist sicherlich nicht 
nur amüsiert, wenn da ein ihm nicht bekannter Interrupt daherkommt.

Sofern aber sichergestellt ist, daß außer Deiner Task wirklich nichts 
anderes auf die zu verwendenden Register zugreift, sollte alles 
funktionieren. Einfach so.

Die von Dir angeführten Schnittstellen (Software-I²C und GPIB) jedoch 
sollten besser als Linux-Devicetreiber implementiert werden, was 
natürlich ein wenig komplizierter ist als direktes Bit-I/O.


> damit man nicht auf die Bugs von anderen angewiesen ist?

Sehr schön formuliert. Nein, natürlich darfst Du auch Deine eigenen Bugs 
verwenden 8^)

Es ist schon sinnvoll, ein OS zu verwenden, wenn man damit 
Standardfunktionalität nutzen kann, wie einen stabilen TCP/IP-Stack oder 
Anwendungen, die darauf zugreifen (Webserver etc.).

Hi

Also zum Ansprechen der Ports... diverse Linux Kernel Version haben 
bereits GPIO Driver mit dabei. D.h. du musst den Kernel kompilieren und 
den entsprechenden Treiber entweder direkt in den Kernel kompilieren 
oder später als Modul nachladen. Wenn so ein Treiber vorhanden ist, dann 
bekommst du meist irgendein Device (in etwa /dev/gpio) das du dann unter 
Linux ähnlich wie ein File verwenden kannst. D.h. du kannst es in einem 
C Programm beispielsweise öffnen und Daten hinschreiben. Die Daten 
werden dann z.B. als Bitmuster auf dem Port ausgegeben.

Ansonsten kannst du natürlich auch deine eigenen Linux Kernel Treiber 
schreiben um auf die Ports zugreifen zu können (für den Kernel Treiber 
musst du dann ähnlich programmieren, wie du es bei Mikrocontrollern 
gemacht hast (also dort kannst du direkt auf die Ports/Register 
zugreifen und Bits setzen oder löschen).
Für ein Software I2C Interface würde sich so ein Kernel Treiber 
anbieten... in den Treiber schreibst du dann deine low-level Routinen 
(wie werden Daten rausgetaktet, eingelesen usw.). Dann kannst du ein 
Device unter /dev anlegen (z.B. /dev/i2c) und dann kannst du mit C 
Programmen oder was auch immer auf das Device zugreifen. Wenn du Daten 
auf das Device schreibst, werden sie per I2C rausgetaktet und umgekehrt.

Also für "Prozessoren" wie es die ARM9 sind, würde ich auf jedenfall ein 
Betriebssystem empfehlen. Wobei ich vorallem die OpenSource OS empfehlen 
würde... dort kannst du wenigstens selbst eingreifen, wenn du einen Bug 
findest (was du bei Windows CE oder dergleichen nicht kannst).
So "große" Prozessoren sind meiner Meinung nach rein low-level mäßig nur 
noch sehr schwer ohne Fehler zu programmieren. Die haben einfach schon 
so viele Features, die man mit einer Single-Threaded Low-Level 
Application erstens gar nicht alle nutzt und zweitens schon relativ 
umfangreich und komplex sind. Außerdem hat man mit einem OS schon eine 
gute Abstraktion zur Hardware geschaffen und die geschrieben Programme 
könnte man bei Bedarf leichter auf andere Architekturen portieren.

mfg
Andreas

Das mit den Interrupts ist nicht 100%ig richtig... man kann Interrupts 
im Kernel duchaus verwenden - und sollte dies auch für gewisse Teile 
natürlich auch machen.
Z.B. wird die UART so programmiert sein... oder HDD Treiber und 
ähnliche... (hab mal Linux auf einen 300 MHz PowerPC laufen gehabt, wo 
ein CompactFlash Interface aufgrund eines Hardwarefehlers ohne 
Interrupts lief... das ganze System war unglaublich langsam, weil die 
CompactFlash ständig gepollt werden musste). Wenn du mit Interrupts 
arbeitest musst du diese nur richtig behandeln. Es gibt hier auch sowas 
wie Interrupt Service Routinen usw.

mfg
Andreas

Moooment, das ist ein Missverständnis. Ich meinte, daß der 
nicht-Kernel-Code im Userland keine Interrupts verwenden darf, der die 
Hardware am OS vorbei "befummelt".
Selbstverständlich muss, soll, kann und darf der Kernel resp. Treiber 
Interrupts verwenden, dazu sind die Dinger ja schließlich da.

Aber eben nicht für eine Userland-Anwendung.

Oh... sorry... das hab ich falsch gelesen! Stimmt... im Userspace sollte 
man lieber keine Interrupts verwenden ;-).