ARM7 mit Windows/Linux, einige Grudlegende Fragen

[PCF8574P]

Hallo,

Ich habe einige Grundsatzfragen zu Betriebssytemen auf einen ARM7.

-Wie wird überhaupt das System auf den ARM7 übertragen? JTAG/USB?
-Wie läuft dass dann mit dem Speicher, wenn ich über SPI eine SD-Karte
anbinde muss Windows/Linux ja wissen wie man darauf zugreift oder
als festspeicher erkennt.
-Grafische ausgabe: Woher weis Windows/Linux wie es das LCD
anzusteuern hat?
-Wenn ich z.B. ein Programm unter C# progge, dann auf die SD-Karte speichern? In den Flash? wie wird es aufgerufen?


Ich hoffe ihr könnt mir helfen

MFG Max

[hillger]

Hat der ARM7 überhaupt eine MMU (Memory Management Unit)?
Wenn nein, wird WinCE nicht funktionieren. Ich glaube es gab da mal ein Projekt, wo Leute dabei sind Linux auch ohne MMU arbeiten zu lassen...

JTAG wird wohl auf jedem ARM funktionieren. Einige Hersteller bieten auch Möglichkeiten über einen im Chip integrierten Bootloader, die OS-Images über seriell, USB oder SD-Karte zu laden.

Im OS befinden sich Treiber für die einzelnen Aufgaben. Die Treiber bestimmen dann wie darauf zugegriffen wird. Wenn man eine eigene Platine erstellt, muß man selber Änderungen machen. z.B. die Zuordnung GPIO-Pin zu Funktion. Wenn man anfängt sollte man sich aber lieber ein fertiges Board kaufen und dann Modifikationen machen.

Eine SD-Karte wird als Block-Storage erkannt. Es wird also nur Speicher (RAM) zum Zwischenspeichern einzelner Blöcke benötigt. ( Bei SD typ. 512 Byte).

Bei der grafischen Ausgabe das selbe. Die meisten ARM's verwenden einen Framebuffer. Das ist ein Speicher, der das angezeigte Bild enthält. z.B. bei 16Bit Farben, zwei Byte pro Pixel aufgeteilt in 5bits für blau, 6 für grün, 5 für rot. Der Treiber bestimmt wo der Framebuffer liegt und wie groß er ist. Typischerweise ist das ganz normaler RAM.
Das Betriebssystem malt dann über den Treiber Linien oder kopiert einfach Bitmaps in den Framebuffer. Da bei den meisten ARM der integr. Grafik-Controller ständig über DMA den Inhalt auf den Bildschirm wirft, erscheint jede Änderung in dem RAM-bereich des Framebuffers auf dem Bildschirm.
Falls es ein spezielles "intelligentes" Display ist, hat man evtl. mehr Aufwand. Entweder man überträgt diesen vom Betriebssystem gefüllten Framebuffer über eine eigene Applikation/Treiber oder man muß einen Treiber mit den entsprechenden Einsprungpunkte für "male Linie", "male Bitmap" schreiben.
Wenn es nur ein Text-LCD ist muß man selber einen Treiber mit eigenen Routinen schreiben oder man schreibt eine Art seriellen Treiber (COM-Port). Dieser würde vom Betriebsystem Konsolen-Ausgaben erhalten können.

C# meine ich geht nur auf WinCE. Wenn Du ein Bildschirm hast: doppelklicke auf die Applikation. Es gibt natürlich auch diverse Möglichkeiten es automatisch zu starten. i.d.R. kann sich die C#-Applikation auf jedem angeschlossenem Speichermedium befinden.
In diesem Fall sorgt das Betriebssystem dafür, dass die Applikation vom Speichermedium ins RAM kopiert wird um dann dort ausgeübt zu werden.
Besonders für solche Aufgaben ist die MMU für das Betriebssystem von größter Bedeutung. Sie ermöglicht das verwalten von "virtuellen" Speicherbereichen.

[Mountainking]

Das würde mich auch interessieren. Es wird also nicht wie bei AVRs der Code "direkt" in den Microcontroller geflashed, sondern z.B. ein Linux auf den ARM übertragen. Mein eigentlicher Code ist dann einfach eine Anwendung die das Linux nach dem Booten automatisch ausführt? Führt dies aber nicht zu einem insgesamt instabileren und langsameren System? Hier ist evtl. nicht nur mein Programmcode fehlerhaft, sondern auch der des Linux-Systems. Fehler in letzterem wären natürlich noch schwieriger auszumachen bzw. zu korrigieren.