Ich habe schon viele Beiträge zum Thema Multitasking gelesen, aber da war nicht das dabei, was ich meine. Ich suche eine Bibliothek oder ähnliches, welche erlaubt, das aktuelle main-Programm zu "pausieren" bzw. zu unterbrechen und ein anderes Programm von einem speichermedium (einer microSD karte) zu starten. Bei verschiedenen Bedingungen soll das Programm stoppen, und zum Hauptprogramm zurückkehren. Hat jemand Ideen oder Vorschläge? Gruß Jul
Jul schrieb: > Hat jemand Ideen oder Vorschläge? Ein Atmel AVR (8bit typen) können überhaupt kein Programm von einer Speicherkarte ausführen.
Peter II schrieb: > Ein Atmel AVR (8bit typen) können überhaupt kein Programm von einer > Speicherkarte ausführen. Doch, das können sie. Aber nur ein interpretiertes Programm, keinen Maschinencode.
Jul schrieb: > Hat jemand Ideen oder Vorschläge? Andere Plattform verwenden. AVR ist dafür reichlich unpraktisch. Ein AVR ist ein Microcontroller, kein Universalrechner.
> Ein Atmel AVR (8bit typen) können überhaupt kein Programm von einer > Speicherkarte ausführen. Nicht nativ aber interpretiert werden kann ein programm schon.
A. K. schrieb: > Peter II schrieb: >> Ein Atmel AVR (8bit typen) können überhaupt kein Programm von einer >> Speicherkarte ausführen. > > Doch, das können sie. Aber nur ein interpretiertes Programm, keinen > Maschinencode. Bei Beachtung der max. Anzahl von Programmierzyklen (10.000 o. s.) ist es möglich ein Programm von der SD-Card zu lesen, zu brennen und auszuführen.
meine wenigkeit schrieb: > Nicht nativ aber interpretiert werden kann ein programm schon. dann läuft aber immer noch die main schleife aus dem Flash. Nur das sich das Programm abhängig voin den Daten der SD karte anders verhält. Ausgeführt wird damit immer noch das normale Programm.
Für so etwas sind z.B. die ARMv7M viel besser geeignet, die STM32 sind so welche. Da kann man problemlos Programmcode von einer SD-Karte in den RAM kopieren und direkt von dort ohne Probleme ausführen (es macht hier überhaupt keinen Unterschied ob Programmcode im RAM oder Flash liegt, da ein Adressbereich). Außerdem haben diese Prozessoren explizite Unterstützung für Multitasking, so kann man effizient zwischen laufenden Prozessen wechseln (Kontextswitch) und einzelne Prozesse vom Überschreiben des Speichers anderer Prozesse abhalten (Speicherschutz). Allerdings haben die ARMv7M keine MMU, also keinen virtuellen Speicher (d.h. für alle Prozesse verweist die Adresse 27 auf die selbe Speicherzelle); dafür braucht es zB einen ARMv7A mit MMU (dort kann dann jeder Prozess seine eigene Speicherzelle 27 haben), dies ermöglicht völlig unabhängige Prozesse mit eigenem Speicher, sodass man dann auch richtige Betriebssysteme wie Linux, WindowsRT, iOS starten kann.
Es gibt auch Leute die mit einem AVR einen ARM emulieren um damit Linux zu starten. Beitrag "Linux on AVR" Das geht, ist aber ein wenig um die Ecke gedacht. Alles was eine primitive Turingmaschine emulieren kann, kann auch jeden anderen Prozessor emulieren und somit Multitasking von SD-Karte. Da die Hardware das nicht nativ unterstützt, muß die Software entsprechend komplexer werden um das nachzurüsten. Nur wenn der Emulator zu komplex werden sollte um ihn im internen Speicher zu lassen und man daher Speicher extern nachrüsten muß, so stellt sich dann die Frage ob das Sinn macht oder ob man dann besser gleich etwas nimmt, das dafür auch von Haus aus gedacht, entworfen und gebaut wurde.
Peter II schrieb: > Ein Atmel AVR (8bit typen) können überhaupt kein Programm von einer > Speicherkarte ausführen. Direkt sicher nicht, aber es in den Flash laden und dann ausführen geht natürlich schon. Schließlich ist das prinzipiell ganz genau dasselbe, was auch ein Bootloader macht. Man kann sowas bloß nicht sehr oft machen, weil die Zahl der Lösch-Schreib-Zyklen des Flash doch ziemlich begrenzt ist. Garantiert sind i.A. nur 1.000. In der Praxis wird man sicher mehr erreichen, aber ich schätze mal so spätestens bei 10.000en Mal wird wohl der erste Verify-Fehler auf jeden Fall schon aufgetaucht sein. Wenn man allerdings ein Teil mit viel Flash nimmt und eine Funktion zum Relozieren des nachzuladenden Codes einbaut (oder alternativ: ausschließlich positionsunabhängigen Code nachlädt), kann man eine Art "wear leveling" basteln und die Sache damit durchaus in den Bereich der praktischen Anwendbarkeit bringen.
Garantiert sind i. A. 10 000 Zyklen z. B.ATMega88: Write/Erase Cycles: 10,000 Flash/100,000 EEPROM
Vielen Dank für die schnelle Hilfe! :) Gute und interessante Ideen waren au jeden Fall dabei. Mir ist allerdings noch die theorethische Idee gekommen, dass man den interpretierten Code von der SD-Karte sozusagen in das main programm implementiert, und so gar nicht das aktuelle programm beendet, sondern einfach nach belieben erweitern kann. Ist dies technisch möglich, wenn ja, kann jemand vielleicht code dazu posten, wie sowas gehen würde?
c-hater schrieb: > kann man eine Art > "wear leveling" basteln und die Sache damit durchaus in den Bereich der > praktischen Anwendbarkeit bringen. Ohgott, dieser Aufwand, wenn man auch einfach einen µC nehmen könnte der Code aus dem RAM ausführen kann (MSP430, ARM,...) Das ginge Pseudocodeartig etwa so:
1 | char progbuffer [1024]; |
2 | |
3 | void main () { |
4 | // Lade progbuffer von SD-Karte ...
|
5 | load_sd (progbuffer, 1024); |
6 | // Nehme an die geladenen Daten sind eine C-Funktion
|
7 | void (*ptr) (void) = (void (*) (void)) &progbuffer; |
8 | // Führe diese Funktion aus dem RAM aus
|
9 | ptr (); |
10 | // Programm aus dem RAM fertig
|
11 | }
|
Jul schrieb: > Ist dies technisch möglich, wenn ja, kann jemand vielleicht code dazu > posten, wie sowas gehen würde? http://www.eluaproject.net/
Ich habe irgendwo gelesen, dass man befehle aus dem EEPROM ausführen kann. Kann das vielleicht auch eine möglichkeit sein? Ich weiß nicht ob das geht aber vielleicht hat ja einer schon mal damit gearbeitet. Jul
@ Jul (Gast) >Ich habe irgendwo gelesen, dass man befehle aus dem EEPROM ausführen >kann. Nein. > Kann das vielleicht auch eine möglichkeit sein? Nein.
Multitasking läuft immer über eine Zeitscheibe. Ein Bsp. findet man unter www.mikrocontroller.net/topic/165249 Joe
c-hater schrieb: > Man kann sowas bloß nicht sehr oft machen, weil die Zahl der > Lösch-Schreib-Zyklen des Flash doch ziemlich begrenzt ist. Garantiert > sind i.A. nur 1.000. Hallo. Eine aehnliche Diskussion gab es bereits vor einiger Zeit. (Wie kann man Programmcode zur Laufzeit nach-/umladen und wie lange haelt der Flash...) Anbei die URL zum Beispielcode: ...oops, flasche URL - ich suche die richtige raus... MfG
Hallo, würde es nicht eventuell gehen, wenn man ein Bootloader programmiert, der den Code von der SD-Karte in den Flash schreibt und dann ausführt? Aus dem Programm müsste man dann aber wieder zurück in den Bootloader springen, wenn fertig. Aber mit Cortex M oder so sollte einfacher sein. Moritz
Hallo nochmal. Moritz M. schrieb: > würde es nicht eventuell gehen, wenn man ein Bootloader programmiert, > der den Code von der SD-Karte in den Flash schreibt und dann ausführt? es geht noch eleganter - ich habe auch jetzt die korrekte URL gefunden: Beitrag "Re: [ATMega] Programm aus externem EEprom laden" MfG
Achja, fuer diejenigen die mehr am Multitasking mit AVR, als am Nachladen von Code mit AVR interessiert sind: http://matrixstorm.com/avr/tinyusbboard/#examples "avr-threaddemo" MfG
Den Antworten kann ich gerade entnehmen, das das ausführen von compiliertem Code aus dem RAM bei Controllern der ARM Serie einfacher ist? Dazu eine frage: Kann man compilierten Code, der im RAM liegt, in einen externen EEprom laden und von dort ausführen? So würde man nicht die Schreibzyklen des Flash überschreiten, und man könnte, falls man die Schreibzyklen des EEprom überschreitet, diesen austauschen. Ist das theoretisch und auch in der Praxis lösbar? Wäre echt nett, wenn ihr mir weiterhin so gut helfen könntet :) Jul
Jul schrieb: > Kann man compilierten Code, der im RAM liegt, in einen externen EEprom > laden und von dort ausführen? AVR nein. ARMs der Cortex-M Klasse teilweise ja, nämlich wenn ein externer Bus unterstützt wird, aber vergleichsweise langsam.
Ah ok. Geschwindigkeit ist nicht so entscheidend. Geht das auch bei der SAM reihe? Z.B. dem AT91SAM9G35-EK? P.S. danke für die schnelle Antwort :D
Hi. Jul schrieb: > Kann man compilierten Code, der im RAM liegt, in einen externen EEprom > laden und von dort ausführen? So würde man nicht die Schreibzyklen des > Flash überschreiten, und man könnte, falls man die Schreibzyklen des > EEprom überschreitet, diesen austauschen. Ist das theoretisch und auch > in der Praxis lösbar? Compilier deinen Code positionsunabhaengig (-fPic) dann kannst du bei AVR den Code von verschiedenen Flashseiten ausfuehren. Wenn also irgendwann einmal (hat bei mir mehr als 10h bei nichts anderem als staendigen Schreiben im Test gedauert) eine Seite ausfaellt, migrist du zu einer anderen... Sicherlich ein Hack - aber das duerfte je nach Anzahl freier Seiten fuer alle gaengigen Anwendungen lange genug laufen... MfG
Jul schrieb: > Ah ok. Geschwindigkeit ist nicht so entscheidend. > Geht das auch bei der SAM reihe? Z.B. dem AT91SAM9G35-EK? Schau ins Manual, ob der einen externen Bus hat.
Läßt sich denn bei einem AVR der PC direkt beschreiben ? Wenn ja könnte man den auf das Register umbiegen wo der aktuelle Befehl drin steht, vorher von SD in die Register laden. Oder auf den Stack legen ?
cppler schrieb: > Läßt sich denn bei einem AVR der PC direkt beschreiben ? Ja, über den "rjmp" Befehl. > Wenn ja könnte man den auf das Register umbiegen wo der aktuelle Befehl > drin steht, vorher von SD in die Register laden. Ja, aber trotzdem referenzieren alle möglichen werte, die PC annehmen kann, immer nur Positionen im Flash, egal was du reinschreibst. > Oder auf den Stack legen ? Der Stack ist Teil des RAM's, und wie gesagt können die AVR's keinen Code aus dem RAM ausführen. Sondern nur aus dem Flash. Nehme einen Cortex-M, der kann so etwas.
cppler schrieb: > Läßt sich denn bei einem AVR der PC direkt beschreiben ? Mehr oder weniger Ja: Man kann das Z-Register beschreiben und iJmp ausloesen. Das ist aber langsamer udn vermutlich hat man nicht genug Flash um alle Opcodes mit allen moeglichen Operanden zu speichern/adressieren.
Ein nettes kleines RTOS ist z.B. FreeRTOS (www.freertos.org). Allerdings muss man auf ein paar Kleinigkeiten achten. Ein Beispiel wäre der fehlende Schutz vor "Task starvation", was einem bei all dem schönen Multitasking einiges an Kopfschmerzen bereiten kann. Ansonsten ist das relativ einfach aufgebaut. Ich empfehle allerdings, die Doku sorgfältig zu lesen, da es in der "config" einige Optionen gibt, deren Funktion man kennen sollte. Ansonsten hat man nur mit den "üblichen" Kleinigkeiten zu kämpfen: - Kommunikation zw. den Tasks (falls nötig) - Critical Sections - Stack/Heap Verwaltung etc.
Ich soll einfach in das Manual gucken, ob ein externer EEprom-Bus unterstützt wird, oder hat der noch andere Namen von denen ich wissen sollte?
Das wird auch EBI (External Bus Interface) genannt. Oder, oder, oder... Wie man es auch immer nennen mag, da mußt du schon die Datenblätter wälzen, um herauszufinden ob etwas passendes im Chip steckt, weil die Bezeichnung nicht einheitlich ist. Das bloße Vorhandensein eines ROM-Interfaces reicht aber nicht. Zwei Dinge müssen gegeben sein. 1. Du brauchst ein Businterface, welches ein solches Rom ansteuern kann. 2. Die Datenleitungen müssen, wenn auch nur zumindest indirekt, Zugang zum Befehlsbus des Controllers haben. Indirekt wäre beispielswise ein Umweg über den Ram wenn der Controller Befehle vom Ram ausführen kann. Es gibt zwar AVR mit EBI aber die zweite Bedingung ist nicht gegeben. AVR ist eine Harvard-Architektur. Bei der sind Daten- und Befehlsbus getrennt. Solange also das externe Businterface nicht explizit und somit, dank Harvard, exklusiv an den Befehlsbus angebunden ist, und das ist hier nicht der Fall, besteht einzige Möglichkeit "Daten" vom Datenbus auszuführen geht also nur über eine Interpretersoftware. Gäbe es allerdings eine solche Anbindung beim einem Harvard-Dystem, So würde dies im Umkehrschluß edeuten, daß man in diesem (Flash)-Rom keine daten ablegen könnte. Diese beiden Möglichkeiten schließen sich bei Harvard gegenseitig aus. Eine Alternative Architektur wird von Neumann Architektur genannt. Hier laufen Daten und Befehle über den selben Bus. Diese Maschinen können dann in aller Regel auch Code vom (internen) Ram ausführen. Dann reicht es wenn man die Befehls"Daten" irgendwie in den Chip bekommt. Zur Not ginge es dann auch über irgendein serielles Interface oder über ein mittels 74er Logik zusamengestricktes Interface welches die Daten an ein paar Portpins leitet. Beispielsweise ARM ist eine von Neumann Architektur. Kurz: Nicht nur das Vorhandensein eines (Rom-)Interfaces ist entscheidend, sondern auch wie es intern angebunden ist entscheidet über die Möglichkeiten die Daten als Code auszuführen.
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.