Ich beschäftige mich seit 2 Tagen mit dem Einstieg in die ARM-9 Welt (davor nur µc's, FPGA's und GAL's gearbeitet). Habe bereits ein Board von Olimex ausgesucht, welches meinen Ansprüchen entsprechen würde: http://olimex.com/dev/sam9-L9261.html Dass man auf den ARM-9 Modulen Linux drauf laufen lassen kann, klingt sehr verlockend. Habe mir das Linux Paket für das Board angeschaut, ist fast alles dabei was ich brauche. Nun die Frage, wie einfach lassen sich dann die unbenutzten IO-Ports programmieren? 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? Sagen wir mal, ich würde eine softwaremäßige I2C-Master Schnittstelle unter Linux implementieren wollen, oder das GPIB Interface? Habe leider mit Linux an sich nicht so viele Erfahrungen, mich reizt es aber auch irgendwie mich in das Thema einzuarbeiten und dazu habe ich auch durch das anstehende Projekt eine gute Möglichkeit. Oder soll man die Finger von Linux lassen und auf dem low-lewel programmieren wie, damit man nicht auf die Bugs von anderen angewiesen ist? Würde als ARM-Einsteiger gerne eure Meinund hören.
> 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.).
i.d.R. sind alle Treiber dabei. I2C ist auf alle Fälle bereits im Linux-Kernel vorhanden, mit Sicherheit auch direkt der SAM9261-I2C. Auf die ungenutzten Ports lässt sich mittels speziellen Treibern (die ebenfalls i.d.R. dabei sind) zugreifen. Ist ein Treiber mal nicht dabei, ist es kein Hexenwerk diesen selber zu implementieren. Die weiteren Funktionen wie Framebuffer-Treiber, Videos via MPlayer etc. werden Dich sicherlich begeistern.
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
>> Außerdem darf Dein Code keine Interrupts auslösen bzw. Peripherie des >> Controllers dazu bringen, dies zu tun; Ok, das könnte zu einem Problem werden. Den Rest muss ich erst lesen und verdauen. Das mache ich morgen früh zum Frühstück :) Werde mich sicherlich noch mal melden. Danke euch für die super Antworten, wünsche allen einen schönen Feierabend.
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 ;-).
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.