hi
Ich wollte gerne in die Welt der ARM's einsteigen. Habe vorher schon
viele Projekte mit dem AVR bewältigt. Nun ist es zeit für die ersten
ARM's geh versuche. Ich möchte gerne die ARM's mit WinARM Programmieren,
dazu habe ich paar fragen:
Natürlich möchte ich bei den ARM's von der Von-Neumann-Architektur
Gebrauch machen. Jetzt stell ich mir die frage wie ich es in C
realisieren kann, ein Programm in den RAM zu laden und zu starten. Habe
gehört bzw. gelesen das es bei WinARM einige Funktionen gibt die so was
bewerkstelligen ist das so korrekt?
Im grossen Ganzen korrekt.
Du kannst Programmcode im RAM ausführen. Es gibt mehrere Möglichkeiten
wie der Programmcode ins RAM kommt.
Ein Weg kann sein, über ein Linker Control Script die Lage des
kompletten Programmcodes im RAM oder ROM festzulegen. Genau kannst du
in dieses Thema einsteigen, wenn du dir Beispielcode für deinen
Wunsch-ARM mal ansiehst. Eine gute Quelle für solchen Beispielcode sind
die Seiten von Martin Thomas.
Eine andere Variante ist es, die Lage einzelner Funktionen im C Code
mit Attributen in eine Section zu legen und wieder im Linker Control
Script (oder auf Kommandozeilen beim Make) zu sagen, dass diese Sektion
bei einer bestimmten Adresse liegt (natürlich dann eine RAM Adresse).
Danke für die schnelle Antwort.
>> Eine gute Quelle für solchen Beispielcode sind
die Seiten von Martin Thomas
Kannst du mir mal bitte einen Link geben weis jetzt nicht welche Seite
zu meinst.
>>Wunsch-ARM
Verstehe ich nicht ganz^^
>> Eine gute Quelle für solchen Beispielcode sind>> die Seiten von Martin Thomas> Kannst du mir mal bitte einen Link geben weis jetzt nicht> welche Seite zu meinst.
-> google
-> martin thomas arm
-> http://gandalf.arubi.uni-kl.de/avr_projects/arm_projects/
-> ;-)
tim wrote:
>>>Wunsch-ARM> Verstehe ich nicht ganz^^ARM ist eine Firma, die das Design von Rechenknechten verkauft.
µC und µP Hersteller können das Design übernehmen, noch mehr Funktionen,
Speicher, Pins... je nach Gusto dazu packen und das Gesamtergebnis unter
verschiedenen Modellnamen verkaufen.
Du als User kannst dir dann aus dem entstehenden grossen Angebot der
verschiedenen Hersteller deinen Wunsch-µC aussuchen. Wie du dabei
vorgehen könntest (Techn. Daten, Preis, Entwicklungswerkzeuge,
Community,...) , ist in längst von anderen geschriebenen Artikeln
erläutert.
ok danke
Hab mir jetzt paar beispiele angeguckt. Hab aber noch nicht das richtige
gefunden. Wie ich ein, auf einer SD-Karte liegendes, Programm aufrufen
und starten kann. Habe nur beispiele gefunden wo erklärt wurde wie man
Code aus den Flashspeicher in den RAM lädt.
habt ihr vll noch paar Links für mich?
Hab mir auch mal dieses Beispiel angeschaut:
http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/index.html#gcc_ramfunc
Aber dies ich auch nicht das Richtige. Ich möchte gerne das, dass
komplette Programm geladen wird. Und das, dass Programm nicht geändert
werden muss also (wie im Beispiel) FASTRUN vor Funktionen geschrieben
werden muss. Es sollte mit einer Normalen Main Funktion anfangen.
tim wrote:
> Hab mir jetzt paar beispiele angeguckt. Hab aber noch nicht das richtige> gefunden. Wie ich ein, auf einer SD-Karte liegendes, Programm aufrufen> und starten kann.
Hmm. Wie sprichst du mit dem AVR eine SD-Karte an und lädst Daten ins
RAM?
So ähnlich geht es auch mit dem ARM nur kommt dann noch das Ausführen
als Code hinzu.
Die Routinen dafür musst du selber schreiben, wenn du einen nackigen ARM
ohne Betriebssystem auf ein eigenes Board gepackt hast, oder von anderen
übernehmen.
Eine Quelle bei nackigem ARM wäre vielleicht ein Bootloader, der von SD
Daten ziehen kann und das RAM damit bestücken kann (übliche Bootloader
bestücken das Flash-ROM).
Oder wenn du einen ARM mit Betriebssystem hast (ein sog. embedded Linux)
und wenn das einen Devicetreiber für SD/MMC mitbringt, dann kann dieses
Linux die Programme laden und ausführen.
In jedem Fall muss das auf der SD Karte befindliche Programm fürs
Laufenlassen im RAM übersetzt sein.
Und im Fall von Linux muss das nachgeladene Programm sich ausserdem an
die Regeln unter diesem OS halten.
> ... Und das, dass Programm nicht geändert> werden muss also (wie im Beispiel) FASTRUN vor Funktionen geschrieben> werden muss. Es sollte mit einer Normalen Main Funktion anfangen.
Ohne Änderungen im Quellcode, das ist möglich. Änderungen im Makefile
zur Auswahl ob Laufen im ROM oder RAM sind aber mindestens notwendig.
Das sollte aber kein Problem sein, oder?
>Ohne Änderungen im Quellcode, das ist möglich. Änderungen im Makefile>zur Auswahl ob Laufen im ROM oder RAM sind aber mindestens notwendig.>Das sollte aber kein Problem sein, oder?
Ich glaub ich hab es bissl blöd formuliert. Der Start-Code der auf dem
ARM liegt müss natürlich geändert werden. Aber wenn ich ein Programm für
den ARM schreibe der dann geladen wird. Will ich in der Programmierung
nicht änder (auser dann den Linker-Script). (ich glaub das ich wieder
bissl blöd formuliert :)) Also wenn ich unter Linux, Windows,... ein
Programm schreibe muss ich ja auch nicht was ändern.
>Eine Quelle bei nackigem ARM wäre vielleicht ein Bootloader, der von SD>Daten ziehen kann und das RAM damit bestücken kann (übliche Bootloader>bestücken das Flash-ROM).
Hab mir jetzt mal paar Bootloader angeguckt, wie z.B. den von Ulrich
Radig. In einen Bootloader wird ja das Betriebsystem an eine festgelegte
addresse geladen. Aber dies kann ich ja so nicht machen weil ich weis ja
nicht wo noch platz im RAM ist. Oder kann ich dies mit Dynamische
Speicherallokierung lösen? Oder muss ich einfach nur eine section
erstellen im "Betriebsystem" die groß genug ist um das Programm oder
rein zuladen?
Bei einem µC solltest du schon wissen, wo noch Platz im RAM ist ;-)
Vereinfacht ausgedrückt: Auch ein Windows oder ein Linux weiss das. Es
lädt einfach alle Userprogramme in den Adressraum ab Adresse 0... Bloss
setzt dieser Weg einen Speichermanager voraus, der den virtuellen
Adressraum ab Adresse 0 auf irgendeinen pygsikalischen Adressraum ab
Adresse xyz abbildet und wenn mehrere Programme den virtuellen
Adressraum ab Adresse 0 wollen, die pyhsikalisch auseinander hält.
Diesen Luxus eines virtuellen Adressraums hast du bei einem µC im
allgemeinen nicht. Also musst du dir überlegen, wie du mit deinem
physikalischen Speicher umgehst.
Weg 1: Alle Programme an Adresse "0" laden und von dort ausführen. Das
bedeutet in deinem Fall, dass du zu einer Zeit nur ein Programm im
Speicher haben kannst. Bei mehreren, aber nicht gleichzeitig laufenden
Programmen könnte man überlegen zu swappen, d.h. den kompletten
Adressraum, Prozesorregister, ... zu sichern, das andere Programm zu
laden und nach dessen Ablauf oder bei einer Unterbrechung die Sicherung
zurückzuholen.
Weg 2: Den Adressraum fix oder dynamisch unterteilen und die Programme
an verschiedene Adressen laden. Dazu müssen die Adressen im Programm an
die startadresse angepasst werden oder davon unabhängig sein. Letzetes
habe ich bei einem µC und C Programmen noch nicht gesehen. Die Anpassung
könnte zur Linkzeit gemacht werden oder zur Laufzeit (Relozieren).
Letzetes habe ich bei einem µC noch nicht gesehen.
Beide Wege setzen einiges an Programmierarbeit voraus. Aber die
Diskussion wird mir hier zu theoretisch. Überleg dir genau, was du auf
"dem ARM" µC machen willst oder ob ein kleiner PC (oder PocketPC mit
ARM-Prozessor) mit einem fertigen Betriebssystem nicht die bessere
Lösung ist.
>Vereinfacht ausgedrückt: Auch ein Windows oder ein Linux weiss das. Es>lädt einfach alle Userprogramme in den Adressraum ab Adresse 0... Bloss>setzt dieser Weg einen Speichermanager voraus, der den virtuellen>Adressraum ab Adresse 0 auf irgendeinen pygsikalischen Adressraum ab>Adresse xyz abbildet und wenn mehrere Programme den virtuellen>Adressraum ab Adresse 0 wollen, die pyhsikalisch auseinander hält.
Damit meinst du MMU oder?
>Diesen Luxus eines virtuellen Adressraums hast du bei einem µC im>allgemeinen nicht. Also musst du dir überlegen, wie du mit deinem>physikalischen Speicher umgehst.
Ich möchte mir gerne ein Board mit einem AT91SAM9260 kaufen. Auf diesem
Chip ist MMU verbaut.
>Weg 1:...
Dies ist aber nicht die Lösung. Weil ich möchte gerne von meine
"User-"Programm Funktionen vom "Betriebssystem" nutzen.
>Weg 2:...
Dann fällt dieser Weg wo weg.
>Beide Wege setzen einiges an Programmierarbeit voraus. Aber die>Diskussion wird mir hier zu theoretisch. Überleg dir genau, was du auf>"dem ARM" µC machen willst oder ob ein kleiner PC (oder PocketPC mit>ARM-Prozessor) mit einem fertigen Betriebssystem nicht die bessere>Lösung ist.
Wenn ich mir ein fertiges Betriebssystem drauf Spiele ist das zwar eine
gute Lösung aber ich möchte gerne dabei was lernen und den aufbau eines
Betriebssystemes verstehen.
tim wrote:
> Wenn ich mir ein fertiges Betriebssystem drauf spiele, ist das zwar eine> gute Lösung aber ich möchte gerne dabei was lernen und den Aufbau eines> Betriebssystems verstehen.
Löblich, wobei man auch durch die Analyse von Bestehendem was lernen
kann.
MMU bei µC ist IMHO nicht mit einer MMU bei Prozessoren zu vergleichen.
Bei µC ist die MMU-Funktion auf dem µC meistens nur dafür da, um den
Adressraum eines externen Speichers (Dataflash o.ä.) in einen Teil des
Adressraums des µC einzublenden und den Zugriff darauf zu erleichtern
(z.B. Wortzugriff bei technisch bedingt byteweise organisiertem,externem
Speicher). Ganz ganz vergröbert entspricht dies bloss einer Erweiterung
des RAM-Bereichs. Die Probl^H^H^H Herausforderungen bleiben die
gleichen.
Es spricht ja nichts dagegen, dass ein Userprogramm Funktionen des
"Betriebssystems" benutzen kann. Die Probl^H^H^H Herausforderungen
entstehen, wenn gleichzeitig mehrere Userprogramme vorhanden sein
sollen.
>MMU bei µC ist IMHO nicht mit einer MMU bei Prozessoren zu vergleichen.>Bei µC ist die MMU-Funktion auf dem µC meistens nur dafür da, um den>Adressraum eines externen Speichers (Dataflash o.ä.) in einen Teil des>Adressraums des µC einzublenden und den Zugriff darauf zu erleichtern>(z.B. Wortzugriff bei technisch bedingt byteweise organisiertem,externem>Speicher). Ganz ganz vergröbert entspricht dies bloss einer Erweiterung>des RAM-Bereichs. Die Probl^H^H^H Herausforderungen bleiben die>gleichen.
Achso gut zu wissen
>Es spricht ja nichts dagegen, dass ein Userprogramm Funktionen des>"Betriebssystems" benutzen kann. Die Probl^H^H^H Herausforderungen>entstehen, wenn gleichzeitig mehrere Userprogramme vorhanden sein>sollen.
Also ich denk mal des es max 1 "User-"Programm geben wird/soll.
Wenn ich es so machen würde, wie du es im Weg1 beschreiben hast. Dann
wird doch das "Betriebssystem" überschrieben, wenn ich das
"User-"Programm ab der Adresse 0 lade, weil doch das Betriebssystem auch
ab der Adresse 0 begingt? Oder nicht?
Du musst ja das Userprogramm nicht für den Start ab Adresse 0 auslegen.
Erfordert einiges an Anpassung in dem Linkercontrolskript, Makefile und
Startupcode aller Userprogramme.
Oder du musst das OS nicht für den Start ab Adresse 0 auslegen. Du lässt
dem Userprogramm die Startadresse und hälst das Betriebssystem aus dem
Bereich raus.
Ich könnte mir vorstellen, dass du einen Teil des OS im
Bpptloaderbereich haben willst ("Init-OS") und einen Teil des OS in
einem RAM Bereich (z.B. oberes Ende).
Das Init-OS kann sich dann selbst seinen RAM-Teil von der SD Karte
hochziehen, sich zum Voll-OS aufplustern und später Userprogramme
starten.
Erfordert logischerweise Anpassung in dem Linkercontrolskript, Makefile
und Startupcode des Betriebssystems. Aber erfordert bei den
Userprogrammen u.U. nur eine Beschränkung der RAM Grösse.
Stefan "stefb" B. wrote:
> MMU bei µC ist IMHO nicht mit einer MMU bei Prozessoren zu vergleichen.
Alle ARM MMU sind durchaus mit denen von "Prozessoren" (was bedeutet
das?) zu vergleichen. Du hast Page Tables, TLB, Attribute, alles was man
braucht.
> Es spricht ja nichts dagegen, dass ein Userprogramm Funktionen des> "Betriebssystems" benutzen kann.
Dafür wird auch keine MMU benötigt.
Gruß
Marcus
So jetzt schreib ich mal das was ich bis jetzt immer vergessen habe:
DANKE schön für all die Infos und Hilfe!!
Mit der ganzen Hilfe versuche ich jetzt mal das Programm in der Theorie
zuschreiben:
- Betriebssystem schreiben
- Start-Code schreiben
- Linker-Script erstellen und die RAM Größe auf die hälfte halbieren und
start Adresse auf 0 setzten
- Userprogramm schreiben
- minimaler Start-Code schreiben der den Einstigspunkt auf die Main
Funktion legt
- Linker-Script erstellen der die Adresse auf die obere hälfte des RAM's
legt
- Betriebssystem lädt das User-Programm in die entsprechende Adresse
- Betriebssystem startet das Programm
- ? Wie starte ich jetzt das User-Programm ?
- ? mit inline Assembler der mit ein jmp befehl zu der Adresse springt?
Im einfachsten Fall so:
void (*app)(void);
app = (void(*)(void)) 0x40004000;
app();
So starte ich die Firmware von meinem Ethernet-Bootloader aus.
Nur das das Programm bei mir im Flash ab 0x8000 steht. Sollte
aber egal sein.
Marcus Harnisch wrote:
> Alle ARM MMU sind durchaus mit denen von "Prozessoren" (was bedeutet> das?) zu vergleichen. Du hast Page Tables, TLB, Attribute, alles was man> braucht.
Danke für die Korrektur.
