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.
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.