Druckbare Version
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
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
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
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
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.
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
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.
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.Zitat:
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.
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
Ich meine, das ist es auch was der Threatstarter hier will.Zitat:
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.
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.
Genau, nur dass du das vorhin noch "Interpreter" genannt hast.Zitat:
Zitat von wkrug
Zitat:
Zitat von wkrug
Ja, ich meine einen Interpreter.
Vorerst will ich ja noch keine Spiele programmieren, aber einfach nur Programme schnell wechseln..
Muss ja nicht unbedingt EEPROM sein, könnte ja auch MMC oder so sein.. Da Flash ja nur eine begrenzte Schreibzyklenanzahl hat..
MfG
Philipp
Hallo Philipp,
also musst Du Dir überlegen, auf welchem Controller Du z.B. eine Java oder eine FORTH Umgebung installieren möchtest und wie das Interface zu Deinem Wechselspeicher aussehen soll (wird in keinem der Interpreter vorgesehen sein; zumindest geht das o.g. Java davon aus, dass die Applikation im internen EEPROM gespeichert ist), das Du selbst entwickeln musst.Zitat:
Zitat von Philipp9494
MMC ist auch "nur" Flash, oder? Unterschätze nicht den Hardware-Aufwand für das externe EEPROM/ext. Flash oder was auch immer Du einsetzt! Alterntiv kann man auch überlegen, den μC direkt austauschbar zu machen (Steckplatz).Zitat:
Muss ja nicht unbedingt EEPROM sein, könnte ja auch MMC oder so sein.. Da Flash ja nur eine begrenzte Schreibzyklenanzahl hat..
Wie gesagt, da ich die Größe der von Dir ins Auge gefassten Programme nicht kenne, kann ich dazu nichts weiter wenig sagen. Wenn es um Spieleprogrammierung (reicht die geringe Geschwindigkeit interpretierter Sprachen für Deine Pläne?) geht, bleibe ich bei meinem Vorschlag mit dem GameBoyAdvance von oben; der ist für Spiele realistischer als die Verwendung von 8-Bit-μContollern.
"Programme wechseln" geht auch direkt mit den AVRs ganz gut, indem man den internen Flash-Speicher neu beschreibt; selbst bei längeren Entwicklungsarbeiten habe ich nie die Grenze von 10000 Flash-Zyklen erreicht (geschweige denn überschritten). Falls Du zum Neuprogrammieren des Flash nicht immer den PC nutzen willst, könntest Du Dir ein Programmiergerät mit einem AVR, einer FlashKarte und einem LCD bauen: auf der FlashKarte wären die HEX-Dateien, Du würdest davon eine aussuchen und könntest sie dann in Dein Zielsystem (z.B. per ISP oder JTAG) übertragen (weiß nicht, ob es so etwas schon gibt). Der Vorteil gegenüber einem PC ist allerdings nicht besonders klar...
Ohne ganz konkrete Details zu Deinen avisierten Projekten lässt sich sonst wenig vorschlagen.
Gruß
Fred
Es könnte ein bischen eng werden...
aber evtl. kannst du einen Bootloader schreiben, der das Programm von einer SD oder MMC Karte lädt.
Beim Mega32 darf der Bootloader maximal 2k groß sein, und da drin musst du eine simple FAT16 bzw. FAT32 Implementierung unterbringen, sowie einige weitere Kleinigkeiten um das Programm dann letztendlich in den Flash-Speicher zu kopieren. Erfahrungswerte dazu habe ich keine, ich kann dir also nicht sagen, ob man FAT32 überhaupt in <2k quetschen kann.
Okay, danke.. Ich werd dann mal schauen was geht ;-)