Atmel AVR "Multitasking"

Gast #3290485
Lesenswert?

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
Gast #3290527
Lesenswert?

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.
Gast #3290555
Lesenswert?

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.
#3290641
Lesenswert?

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.
Gast #3290662
Lesenswert?

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.
Gast #3291004
Lesenswert?

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?
Gast #3291030
Lesenswert?

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/
Gast #3292152
Lesenswert?

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
#3292223
Lesenswert?

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
Gast #3292258
Lesenswert?

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
Gast #3293388
Lesenswert?

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
#3293430
Lesenswert?

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
Gast #3293499
Lesenswert?

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.
Gast #3293533
Lesenswert?

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.
#3293981
Lesenswert?

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.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren