Hi Leute, ich habe Google schon um einiges bemüht, aber keine Antwort auf meine Frage gefunden. Und zwar möchte ich Programme für meinen ATMega aus einem externen EEprom nachladen und dann ausführen. Leider habe ich bis jetzt keine Möglichkeit gefunden mein Vorhaben zu realisieren. Vielen Dank schon mal im Voraus. Marcel H.
Marcel H. schrieb: > ich habe Google schon um einiges bemüht, aber keine Antwort auf meine > Frage gefunden. Dann bemühe Google nochmal, aber diesmal mit dem Begriff "Bootloader". Marcel H. schrieb: > Und zwar möchte ich Programme für meinen ATMega aus einem externen > EEprom nachladen und dann ausführen. Dir ist aber schon klar, dass das Flash eine begrenzte Anzahl von Lösch-/Schreibzyklen hat, und damit auch dieses "Nachladen" nur begrenzt oft funktioniert, oder?
Hallo Stefan, erstmal vielen Dank für deine schnelle Antwort. Ein Bootloader würde zumindest meinen Zweck erfüllen. Ich glaube, ich muss mein Problem etwas genauer erklären. Und zwar möchte ich den Mikrocontroller starten und der soll dann nachschauen, ob ein EEprom über I²C angeschlossen ist. Wenn dies der Fall ist, soll er in diesem EEprom nachschauen, ob sich darin ein ausführbares Programm befindet. Nun komme ich zu meinem Problem. Und zwar frage ich mich, ob es möglich ist dieses Programm in den RAM zu laden und von dort auszuführen. Meinen ersten Gedanken, das Programm direkt aus dem EEprom auszuführen, habe ich schnell wieder verworfen, weil ich mir gedacht habe, dass es an der Geschwindigkeit des I²C-Bus scheitert. Marcel H.
Marcel H. schrieb: > dieses Programm in den RAM zu laden und von dort auszuführen. Hättest du einen Interperter als Programm im µC, dann könntest du Macros aus dem EEPROM laden, die dieser Interpreter dann abarbeitet.
Oder du nimmst einem STM32Fxxx, die können Programmcode aus dem RAM ausführen. Es handelt sich dabei aber um einen ARM Prozesor, der für den Design möglicherweise Overkill ist. Gruß Jannis
Nein, der ATMega kann keine Programme aus dem RAM ausführen, auch nicht vom EEPROM, die Programme müssen ins Flash. Da bekommst Du sie hin entweder via ISP oder per Bootloader, das wars. Alternativ ein Interpreter, was aber wieder Geschwindigkeitseinbußen bedeutet.
Dann vermute ich, dass mir nichts anderes als ein Interpreter übrig bleibt. Da ein Programm ja bei jedem Start in den Flash geladen werden müsste, würde ich dann alle paar Monate einen neuen µC brauchen. Das kann ja auch nicht Sinn der Sache sein. Allerdings muss ich mir dann wieder Gedanken um den Speicher machen. Der Verbrauch wird dann ja "minimal" anwachsen. Vielen Dank für eure Hilfe. Gruß Marcel H.
Hintergrund: Der ATMega/AVR hat eine Harvard-Architektur mit getrenntem Daten- und Programmspeicher. Als Programmspeicher ist beim AVR lediglich Flash-Speicher verfügbar. Du kannst die Zahl der Schreibzyklen auf den Flash-Speicher signifikant reduzieren, wenn Du nur dann das Programm überträgst, wenn es notwendig ist. Z.B. wenn eine neuere Version im EEPROM verfügbar ist. Was ist der Grund dafür das Programm im EEPROM zu speichern?
Meine Schaltung soll (Welch neuartige Idee :D) eine Art kleiner Computer werden. Mein Grundgedanke ist, dass ein Hauptcontroller als eine Art BIOS fungiert und beliebige "Betriebssyteme" aus einem EEprom nachladen kann. Hier steht mir allerdings die begrenzte Anzahl von Schreibzyklen im Weg.
Ein (größeres) EEPROM ließe sich via I2C anbinden. Auch mehrere wären möglich. So habe ich es jedenfalls bei meiner SPS gemacht.
Marcel H. schrieb: > Meine Schaltung soll (Welch neuartige Idee :D) eine Art kleiner Computer > werden. Mein Grundgedanke ist, dass ein Hauptcontroller als eine Art > BIOS fungiert und beliebige "Betriebssyteme" aus einem EEprom nachladen > kann. Hier steht mir allerdings die begrenzte Anzahl von Schreibzyklen > im Weg. Du verwendest einfach die falsche Architektur. ARM und MIPS können das. Da Du sicher DIL bevorzugst, nimmst Du einfach einen PIC32MX150F128B-I/SP, kostet bei R. 3.60€, und da hast Du 32k RAM, in denen Du auch Programme ausführen kannst. Ganz einfach. fchk
Hi
>Da Du sicher DIL bevorzugst, nimmst Du einfach einen
Z80
MfG Spess
Nach einigem Überlegen und Recherchieren hat sich mir eine Frage an mich selbst aufgetan, die ich mir auch schon teilweise beantworten konnte: Wie wahrscheinlich ist es, dass ich so viele verschiedene Systeme programmiere, dass es sich wirklich lohnen würde, sich in die 32-Bit-Architektur des PICs einzuarbeiten? Solange ich bei vielleicht zwei oder maximal drei Systemen bleibe, könnte auch schon ein etwas größerer ATMega reichen. Da könnten mit viel Glück so zwei bis drei Systeme reinpassen. Ich muss zugeben, dass mich die Idee mit dem Z80 schon etwas angeregt hat, aber der könnte für einige Anwendungen zu schwach sein. Ich habe mein Konzept jetzt nochmal überarbeitet und habe mir gedacht, dass man ja eigentlich alles, was man auslagern kann auch auslagern sollte. Da wäre zum Beispiel die Ein-/Ausgabe und der Sound. So könnte man ja eigentlich kleinere Megas nehmen und diese zum Beispiel als Tastaturcontroller oder Grafikchip einsetzen. Zur Kommunikation der Chips untereinander würde sich ja der I²C-Bus anbieten.
Marcel H. schrieb: > Nach einigem Überlegen und Recherchieren hat sich mir eine Frage an mich > selbst aufgetan, die ich mir auch schon teilweise beantworten konnte: > > Wie wahrscheinlich ist es, dass ich so viele verschiedene Systeme > programmiere, dass es sich wirklich lohnen würde, sich in die > 32-Bit-Architektur des PICs einzuarbeiten? Solange ich bei vielleicht > zwei oder maximal drei Systemen bleibe, könnte auch schon ein etwas > größerer ATMega reichen. Da könnten mit viel Glück so zwei bis drei > Systeme reinpassen. Wie gesagt: Der AVR ist für Dein Vorhaben ungeeignet, weil Du keinen Code im RAM ausführen kannst. Die kleineren PIC18/PIC24 können das auch nicht. Der MIPS-Kern des PIC32 kann das. ARMs können das auch, aber da wirst Du Dich mit SMD-Technik auseinandersetzen müssen. Z80 kann das auch, aber da wird die Hardware aufwändiger und damit teurer, weil Du Dir alles aus Einzelbausteinen zusammenbauen musst, was beim PIC32 gleich mit eingebaut ist. Und der PIC32 ist eine bis zwei Zehnerpotenzen schneller als AVR oder Z80. > Ich habe mein Konzept jetzt nochmal überarbeitet und habe mir gedacht, > dass man ja eigentlich alles, was man auslagern kann auch auslagern > sollte. Da wäre zum Beispiel die Ein-/Ausgabe und der Sound. So könnte > man ja eigentlich kleinere Megas nehmen und diese zum Beispiel als > Tastaturcontroller oder Grafikchip einsetzen. Zur Kommunikation der > Chips untereinander würde sich ja der I²C-Bus anbieten. Trotzdem bleibt die Architektur für Dich ungeeignet. Und berücksichtige, dass die Kommunikation zwischen den Prozessoren auch ein ganz erheblicher Aufwand ist - bei der Entwicklung, beim Debuggen (hast Du mehrere JTAG ICE 3, um Sender und Empfänger gleichzeitig debuggen zu können? Hast Du einen guten Logicanalyzer für die Protokollanayse auf dem Bus?), und nicht zuletzt bei der für Kommunikation und Synchronisation benötigten Rechenleistung. Die meisten Anfänger wissen nicht, dass Multiprozessorsysteme in der Informatik schon was für Fortgeschrittene ist. Darüber schreiben andere Leute dicke Bücher. Siehe z.B. http://www.amazon.de/s/ref=nb_sb_noss?field-keywords=0123973376 528 Seiten. fchk
Frank K. schrieb: > bei der Entwicklung, beim Debuggen (hast Du > mehrere JTAG ICE 3, um Sender und Empfänger gleichzeitig debuggen zu > können? Hast Du einen guten Logicanalyzer für die Protokollanayse auf > dem Bus?), und nicht zuletzt bei der für Kommunikation und > Synchronisation benötigten Rechenleistung. Quatsch doch nicht so einen blödsinn. Ich habe schon komplexe Funksysteme mit einem ISP programmiert. Nur Luschen brauchen so ein Equipment. Da fehlt der Pioniergeist. @TO Lass Dir mal nicht den Wind aus den Segeln nehmen.
Ne ne ne schrieb: > Quatsch doch nicht so einen blödsinn. Ich habe schon komplexe > Funksysteme mit einem ISP programmiert. Nur Luschen brauchen so ein > Equipment. Da fehlt der Pioniergeist. Wenn $(zahlender_kunde) wartet, dann ist Pioniergeist das Letzte, was ich brauche. Zeit isst Geld bei mir, und wenn ein 200€-Tool mir 3 Stunden Debugging erspart, dann hat es sich wirtschaftlich rentiert. Wer studiert, sollte sich an diese Denkweise gewöhnen. fchk
@Ne ne ne: Soweit, wie ich mit meinen Gedanken schon bin, nimmt mir niemand mehr den Wind aus den Segeln :D Ich habe natürlich auch an die Programmierung der Controller gedacht und habe mich für ISP entschieden, wobei ich schon überlege, die Controller später über die RS232-Schnittstelle zu programmieren. Die Kommunikation der Controller untereinander habe ich auch noch mal überdacht und habe mir zumindest für die Videoausgabe (über FBAS) überlegt, dass ich immer ganze Bilder in einen externen RAM-Baustein schreibe, die dann wiederum von dem Video-Controller eingelesen werden können und in ein brauchbares Videosignal umgewandelt werden können (eine Umsetzung dazu fehlt mir noch, aber ich denke, dass ich dazu genug im Internet finden werde) Wer jetzt beim Lesen gedacht hat, dass hier so ein vollkommen Ahnungsloser sitzt und erwartet, dass man ihm sein Projekt fertig vorsetzt, der hat sich geirrt :D Ich bin zwar auch kein Profi, aber für solche Anwendungen reicht es dann doch noch MfG, Marcel H.
Hi >Wer jetzt beim Lesen gedacht hat, dass hier so ein vollkommen >Ahnungsloser sitzt Hatte ich bis jetzt eigentlich nicht. Aber du bist sehr überzeugend. MfG Spess
Marcel H. schrieb: > Hier steht mir allerdings die begrenzte Anzahl von Schreibzyklen > im Weg. Hallo Marcel. Ich finde deine Idee eingentlich nicht schlecht, um einmal damit zu spielen. Um einmal ein praktisches Gefuehl zu bekommen, wie lange es dauert bis der Flash hinueber ist, hier mein kleiner Shredder. (Vielleicht kann man eine einzelne Seite zur Laufzeit beliebig oft beschreiben, da deren Inhalt im Hintergrund in einem SRAM gehalten wird. Natuerlich ist nach Poweroff der Inhalt durch den defekten Speicher korrumpiert - aber solange es nicht alle Seiten betrifft ist dies ggf. egal...) Ich habe das "Experiment" auf einen alten ATmega8 laufen. Momentan wird nur Seite 95 geroestet - obwohl ich nicht davon ausgehe - sollte der Flash selbst nach dem Test noch groesstenteils verwendbar sein. Produktive Anmerkungen sind herzlich willkommen. p.s.: Man kann das SPM Interface dann auch dazu benutzen, spaeter einmal Programmcode per firmware zur Laufzeit zu aendern. (Letztere main.c enthaelt mehr Kommentare)
Stephan B. schrieb: > Vielleicht kann man eine einzelne Seite zur Laufzeit beliebig oft > beschreiben, da deren Inhalt im Hintergrund in einem SRAM gehalten wird. So, man kann sagen das Experiment ist zu Ende. Leider trifft die zitierte Aussage nicht zu. Der SRAM Speicher, welche den Seiteninhalt zwischenspeichert scheint nur dem Schreiben zu dienen und wird scheinbar nicht gelesen. Nach ziemlich genau 10h Durchlauf mit ca. 256 pagewrites pro 5 Sekunden (1.843.200 pagewrites total) treten vereinzelt erste Lesefehler auf. MfG Stephan
kuk mal via smart in deine hdd wie oft die ein spinup hatte und vergleich das mit der laufzeit deines pcs (es gibt mindestens ein spinup pro boot-vorgang), du wirst sehen man kommt mit 10k so weit dass es bei so einem hobby-projekt locker reicht ....
Ja der Aussage von Max D. stimme ich im Prinzip zu. Vorallem wenn man nicht den gesamten Flash auf einmal aufbraucht, so kann man ja defekte Seite vermerkten und stattdessen andere benutzen...
Stephan B. schrieb: > Vorallem wenn man nicht den gesamten Flash auf einmal aufbraucht, so > kann man ja defekte Seite vermerkten und stattdessen andere benutzen... Cool... Und wo schreibst Du dann Reset- und Interrupt-Vektoren hin? Träum weiter... ...
Stichwort: trampoline Solange wie entsprechende Seiten unbenutzt sind, enthalten Sie z.B. Sprunganweisungen. Ich sehe da kein Problem bei Interrupts. (Siehe http://matrixstorm.com/avr/tinyusbboard/examples/empty3.hex )
Hannes Lux schrieb: > Stephan B. schrieb: >> Vorallem wenn man nicht den gesamten Flash auf einmal aufbraucht, so >> kann man ja defekte Seite vermerkten und stattdessen andere benutzen... > > Cool... > > Und wo schreibst Du dann Reset- und Interrupt-Vektoren hin? > > Träum weiter... > > ... Man kann die ganzen vektoren in den bl-bereich schieben, dort muss dann der (vorhandene & gehardcodete) bootloader nach dem Start einfach an eine (im RAM geladene?) Adresse springen, die paar cycles mehr sollten kein problem sein (wenn doch dann nimmt man am besten gleich ne nummer größer)...
Also ich wollte jetzt zwar eigentlich nicht meinen µC systematisch zerlegen, aber es ist doch gut zu wissen, dass die Speicher doch einiges aushalten (zumindest ausreichend viel für meine Anwendungen). Falls Interesse besteht, kann ich ja in einem gesonderten Thread mein Projekt ein bisschen genauer vorstellen und Interessierte auf dem Laufenden halten. MfG Marcel H.
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.