Code von EEPROM

[Philipp9494]

Hallo.

Ich habe da mal eine Frage. Ich habe mir vor ein paar Tagen einen ATMega32 gekauft.
Und da wollte ich wissen, ob es etwas gibt um einen "Pseudo-Code" von einem EEPROM zu laden und dann auszuführen. Also nicht auf den Flash schreiben. Nicht ein HEX-File auf den Programmspeicher schreiben.
Wenn möglich gar OpenSource.

So will ich dann einfach nur den EEPROM wechseln und dann einfach ein anderes Programm abspielen.

MfG
Philipp

[fhs]

Hallo Philipp,

Dein Posting wirft Fragen auf, ohne deren Beantwortung ich mich nicht richtig in Deine Fragestellung eindenken kann:

• 1. Was meinst Du mit Pseudo-Code? Z.B. den Code für eine Sprache wie FORTH?
  2. Welche Vorteile soll "EEPROM-Wechseln" gegenüber dem Neuschreiben des Flash bringen?
  3. An wieviel ext. EEPROM denkst Du? Welche Ansteuerung?

Wenn Du etwas mehr von Deiner Idee preisgibst, bekommst Du sicher bessere Antworten!

MfG

Fred

[Philipp9494]

Nehmen wir an ich habe 2 Platinen mit unterschiedlicher Hardware und nur einen uC. Wenn ich den dann schnell wechseln will und keinen Programmer zur Hand habe.
So soll der uC nur Code von einem EEPROM lesen und den dann ausführen. Ich habe aber schon gelesen, dass das nicht geht, einen C++ Code auszuführen, da man den dann auch auf den Flash speichern muss also einen eigenen Code der dann vom uC nur interpretiert wird.

Ja..
MfG
Philipp

[fhs]

Hallo Philipp,

vermutlich ist es einfacher, 2 Platinen mit jeweils einem μC (mit unterschiedlichen Programmen im Flash) aufzubauen, Du ersparst Dir dann die Ansteuerung für ext. EEPROM. Kostengünstiger wird das vermutlich auch.

Wenn Du unbedingt den Weg über 2 EEPROMs gehen möchtest, könntest Du in den μC einen "EEPROM-Bootloader" (müsstest Du selbst schreiben) flashen, der beim Starten Kontakt mit dem EEPROM aufnimmt und dessen Daten mit Hilfe der SPM Instruktion dann in ein Flash-Segment lädt.

C++ auf AVRs: hat nur Nachteile -- bleib bei C!

Zwei meiner Fragen von oben sind noch offen:
1. An welche Art EEPROM denkst Du -- warum kein Flash?
2. Was Du mit Pseudocode (interpretierbarer Code?) meinst, hast Du noch nicht erklärt.

Gruß

Fred

[Besserwessi]

Pseudocode ist eine Art abstarkte Maschinensprache, für die es in der Regel keine echte Hardware gibt. Wurde/wird zum Beispiel gerne bei Forth oder Java benutzt. Damit kann der Compiler dann einen protablen Code erzeugen, der halt etwas langsamer als echter Code läuft. Dafür ist Pseudocode oft deutlich kürzer als normale Maschinensprachen.

C++ hat nicht nur Nachteile, aber das normale C ist oft besser geeignet. Wenn man wirklich den Weg über Pseudocode gehen will, dann wird das aber wohl auf Java hinauslaufen, es sei denn man ist ein Fan von Forth.

[fhs]

Hallo Besserwessi,

Thema Pseudocode:
In meinem ersten Beitrag habe ich ja selbst auf FORTH hingewiesen! Was Pseudocode ist, ist mir völlig klar. Ich hinterfrage hier nur, was der OP unter Pseudocode versteht; denn ich bin mir nicht sicher, dass seine Problemstellung wirklich verständlich formuliert ist bzw. er ein klares Konzept seiner Anforderungen an die Soft- und Hardware hat. Weshalb er unbedingt EEPROM (gegenüber z.B. Flash) einsetzen möchte, hat der OP auch noch nicht stringent erklärt.

Thema C++:
Ich bin kein Fan von C++ auf AVRs; das Verhältnis von Overhead zu Nutzen erscheint mir einfach zu ungünstig. (Zudem bin ich ein miserabler C++ Programmierer; ich habe nie richtig den Sprung von Assembler und C zu OOP geschafft.)

Gruß

Fred

[wkrug]

Ich Denke mal, wenn man einen Pseudocode verwenden will wird es vermutlich sehr schwierig bis überhaupt nicht gehen.
Der Pseudocode müsste ja von einem Interpreter wieder in Maschinencode umgewandelt und dann wieder in den Flash geschrieben werden.
Wo soll dann dieser Interpreter hin?
Im Bootloader kann er eigentlich nicht sein, es sei denn man kopiert ihn dann vom Bootloader in den Flash und startet ihn dort.

Der Flash Speicher hat auch nur eine begrenzte Anzahl von Schreibzyklen.
Eine Überprüfung ob sich der Code des EEPROM beim Einschalten des µC nicht schon im Flash befindet müsste somit auch gemacht werden.

Mit Maschinencode wäre das einfacher, da ja kein Interpreter benötigt wird.
Einen echten Vorteil dieser Methode kann ich auch nicht wirklich erkennen.

Es sei denn man möchte Spiele mit wechselbaren EEPROM Einschüben programmieren - Aber ich denke dafür sind die AVR Controller nicht unbedingt geeignet.

[sternst]

Ich Denke mal, wenn man einen Pseudocode verwenden will wird es vermutlich sehr schwierig bis überhaupt nicht gehen.
Der Pseudocode müsste ja von einem Interpreter wieder in Maschinencode umgewandelt und dann wieder in den Flash geschrieben werden.

Was du da beschreibst ist kein Interpreter, sondern ein Compiler. Ein Interpreter würde normal im Flash sitzen und den Pseudo-Code direkt ausführen und nicht übersetzen. Ein Interpreter ist quasi eine Software-CPU.

[fhs]

Hallo,

momentan spekulieren wir hier nur, was der OP wirklich meint. Falls Philipp wirklich in Spiele einsteigen möchte, rate ich, dass er einfach einen GameBoyAdvance (initial z.B. mit Hilfe von Multiboot, z.B. über ein XBoo Kabel) programmieren lernt. Wenn das erst einmal klappt, kann man dann zu größeren Programmen übergehen und diese in eine Flash Cartridge schreiben, ehe man an EEPROMs denkt. Mit 'nem ARM7 hat schon mehr Möglichkeiten als mit den AVRs. Das GBA-BIOS bietet auch viele Möglichkeiten, insbesondere hinsichtlich Graphik. Natürlich hängt es von der Anwendung ab, welcher Prozessor die beste Wahl ist!

Philipp, erklär doch einfach Deine konkrete Anwendung; sonst kann Dir hier niemand richtig helfen.

Gruß

Fred

PS: Da hier die Sprache auf FORTH gekommen ist und ich meinen letzten FORTH Interpreter in den 80er Jahren für einen Data General Nova Minicomputer geschrieben habe (seitdem habe ich nie mehr was in bzw. mit FORTH entwickelt), war ich neugierig und habe mal nach FORTH für den AVR gesucht. Hier 2 der Ergebnisse:
http://claymore.engineer.gvsu.edu/~s...avr/index.html
http://swik.net/programming-language...guages%2FForth

[wkrug]

Was du da beschreibst ist kein Interpreter, sondern ein Compiler. Ein Interpreter würde normal im Flash sitzen und den Pseudo-Code direkt ausführen und nicht übersetzen.

Ich meine, das ist es auch was der Threatstarter hier will.
Pseudocode soll direkt ausgeführt werden.
Dazu muß, wie Du schon richtig bemerkt hast der Interpreter im Flash sitzen.

Ein Compiler würde den kompletten Code in Maschinenbefehle umsetzen und die dann in den Flash laden.