Hallo, und zwar geht meinem ATmega2560 langsam der Speicher aus, da ich ein paar Bilder habe die am Display angezeigt werden. Jetzt wollte ich einen externen Flash einbauen (W25Q16JV) der die (Bild-)Daten speichern soll, damit am uC nur noch das Programm gespeichert ist. Der W25Q16JV bekommt die Daten über SPI. Allerdings muss ich ja die Bilder erst am uC gespeichert haben, dass ich sie an den externen Flash senden kann was irgendwie nicht Sinn der Sache ist. Gibt es überhaupt eine Lösung für mein Problem? (Außer den Flash vorm Einbauen über einen anderen uC bespeichern und meinen eigentlichen uC nur lesen lassen)
:
Bearbeitet durch Admin
(u)SD karte nehmen, einen FAT32 library benutzen zB 2GB Dann kann man am anfang die benoetigte dateien direct mittels PC schreiben und spaeter routinen schreiben damit du das auch via den processor laufen lassen kannst. Bei ein etwas elteres Projekt habe ich da FATFS benutzt. Kann sein das heutzutage auch andere libraries dafuer gibt.
MCUA schrieb: > Der ATmega2560 hat doch Ext.BusInterface, da kannst du alles dran > hängen. Echt? das wär ja super. Unter welchem Punkt find ich dazu was im Datenblatt?
Wenn's denn unbedingt ein SPI-Flash sein soll und die Alternativen wie SD-Karte nicht in Frage kommen: 1) kleines Programm im Flash, dass über UART die Daten fürs externe Flash bekommt und dort hinein schreibt. oder 2) Über JTAG Bitbanging ans SPI-Flash machen. Aber das muss man erstmal programmieren ... Einmalig recht hoher Aufwand. Bei so einem kleinen Flash geht das sicher auch in erträglicher Zeit, bei einem großen mit 64 MByte wird es eher unbequem langwierig. oder 3) RESET mit einem Jumper auf '0', dann kann man mit einem externen Programmer an die Pins vom SPI-Flash ran.
A. B. schrieb: > Wenn's denn unbedingt ein SPI-Flash sein soll und die Alternativen > wie > SD-Karte nicht in Frage kommen: Muss nicht unbedingt ein SPI-Flash sein, hatte nur noch welche rumliegen. Die einfachste Variante wär mir am liebsten.
> Stichwort XMEM.
Hab ich mittlerweile auch schon entdeckt, allerdings ist das mit 64kB
bzw. tatsächlichen 56kB doch recht dürftig
Fragensteller schrieb: > und zwar geht meinem ATmega2560 langsam der Speicher aus, da ich ein > paar Bilder habe die am Display angezeigt werden. Wirklich? Hast du die vollen 256kB genutzt? Beitrag "Re: AVR Flash jenseits der 64kB" > Jetzt wollte ich einen > externen Flash einbauen (W25Q16JV) der die (Bild-)Daten speichern soll, > damit am uC nur noch das Programm gespeichert ist. Der W25Q16JV bekommt > die Daten über SPI. Allerdings muss ich ja die Bilder erst am uC > gespeichert haben, dass ich sie an den externen Flash senden kann Nö, man kann sie auch von einer seriellen Schnittstelle direkt in den Flash schreiben. Oder man nimmt gleich eine MicroSD Card.
Fragensteller schrieb: > Muss nicht unbedingt ein SPI-Flash sein, hatte nur noch welche > rumliegen. > Die einfachste Variante wär mir am liebsten. SPI-Flash IST einfach. Einfacher geht es kaum.
Fragensteller schrieb: > Hab ich mittlerweile auch schon entdeckt, allerdings ist das mit 64kB > bzw. tatsächlichen 56kB doch recht dürftig Man kann ja mit guten, alten Pages arbeiten. Einfach die oberen 32k nutzen, dann geht das lückenlos.
Fragensteller schrieb: > Die einfachste Variante wär mir am liebsten. Was ist fuer dich einfach ? Extra XMEM = mehr hardware aufwand Memory via SD = mehr software aufwand Wenn moeglich wuerde ich fuer uSD gehen, sonnst ist gleich die naechste Frage wie bekomme ich bmp files im XMEM
> Wirklich? Hast du die vollen 256kB genutzt? Die HEX Datei ist jetzt bei 228kB > Nö, man kann sie auch von einer seriellen Schnittstelle direkt in den > Flash schreiben. Wie kann ich mir das vorstellen? Hast du ein paar Schlagwörter für mich, dass ich dazu recherchieren kann?
>sonnst ist gleich die naechste > Frage wie bekomme ich bmp files im XMEM die Bilder sind auch HEX Dateien
Fragensteller schrieb: >> Wirklich? Hast du die vollen 256kB genutzt? > > Die HEX Datei ist jetzt bei 228kB Also nutzt du schon die pgm_read_byte_far() Funktionen? >> Nö, man kann sie auch von einer seriellen Schnittstelle direkt in den >> Flash schreiben. > > Wie kann ich mir das vorstellen? Hast du ein paar Schlagwörter für > mich, dass ich dazu recherchieren kann? XMODEM, sftp & Co.
Fragensteller schrieb: >> Wirklich? Hast du die vollen 256kB genutzt? > > Die HEX Datei ist jetzt bei 228kB die Datei im HEX Format ist wesentlich größer als der Speicherbedarf da die Daten als Text abgelegt sind. Oder meinst du eine Datei im BIN Format? Sascha
Sascha W. schrieb: > Fragensteller schrieb: >>> Wirklich? Hast du die vollen 256kB genutzt? >> >> Die HEX Datei ist jetzt bei 228kB > die Datei im HEX Format ist wesentlich größer als der Speicherbedarf da > die Daten als Text abgelegt sind. Oder meinst du eine Datei im BIN > Format? Hehe, guter Punkt! Eine Intel-Hex-Datei ist ca. 2,25x größer als die reinen Binärdaten, macht hier bei 228kB ca. 100kB. Davon sind im Normalfall nur 64kB per pgm_read_byte() & Co addressierbar. Wenn man den gesamten Speicher für Daten nutzen will, dann so. https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Flash_mit_PROGMEM_und_pgm_read
> die Datei im HEX Format ist wesentlich größer als der Speicherbedarf da > die Daten als Text abgelegt sind. Oder meinst du eine Datei im BIN > Format? Ich bin im Explorer meinem Pfad so lange gefolgt bis ich in dem Ordner bin wo die myProgram.hex Datei liegt. Rechts daneben wird mir die Größe mit 228kB angezeigt.
> Hehe, guter Punkt! Eine Intel-Hex-Datei ist ca. 2,25x größer als die > reinen Binärdaten, macht hier bei 228kB ca. 100kB. Davon sind im > Normalfall nur 64kB per pgm_read_byte() & Co addressierbar. > Gibt es eine Möglichkeit die reine Binärdatengröße zu bestimmen? Wenn ich tatsächlich erst um die 100kB verbraucht habe spare ich mir den ganzen Aufwand nämllich.
Habe diesen Befehl gefunden, um mir den Verbrauch des gesamten Programms anzeigen zu lassen: avr-size -x -A foo.elf Wie genau ist der? Schreibe ich die Zeile einfach in meine main.cpp oder wie bau ich das ein? Muss ich mir den Wert dann am Display anzeigen lassen oder geht das in Atmel Studio 7.0? Falls ich sie am Display zeigen muss kann ich einfach schreiben: myVar = avr-size -x -A foo.elf und myVar am Display ausgeben?
Fragensteller schrieb: > Muss ich mir den Wert dann am Display anzeigen lassen oder geht das in > Atmel Studio 7.0? Kopfschüttel. Atmel Studio gibt dir doch am Ende des Build aus wie gross das Binary ist.
Fragensteller schrieb: > Gibt es eine Möglichkeit die reine Binärdatengröße zu bestimmen? Wenn > ich tatsächlich erst um die 100kB verbraucht habe spare ich mir den > ganzen Aufwand nämllich. Ja, in deiner Die die Speicherauslastung anschauen. Sowohl Atmel/AVR/Microchip Studio als auch Arduino geben das direkt nach dem Kompilieren an.
> Kopfschüttel. > Atmel Studio gibt dir doch am Ende des Build aus wie gross das > Binary ist. Ja ich kenne den Speicherverbrauch den Atmel Studio nach dem buid angiebt. Jemand hat mal zu mir gemeint, dass der nicht richtig ist und ich mir die Größe der .hex Datei ansehen soll. Also kann ich doch auf den Vertrauen?
> Ja, in deiner Die die Speicherauslastung anschauen. Sowohl > Atmel/AVR/Microchip Studio als auch Arduino geben das direkt nach dem > Kompilieren an. Ok da bin ich dann erst bei 83kB
Fragensteller schrieb: > Jemand hat mal zu mir gemeint, dass der nicht richtig ist und > ich mir die Größe der .hex Datei ansehen soll. Ja und der Jemand spricht Käse. Fragensteller schrieb: > Also kann ich doch auf den Vertrauen? Warum bildest du dir nicht deine eigene Meinung? Sollen wir für dich enstcheiden wem du vertrauen sollst?
> Warum bildest du dir nicht deine eigene Meinung? Sollen wir > für dich enstcheiden wem du vertrauen sollst? Ich will ja auch keine Meinung sondern Fakten Trotzdem Danke!
Kauf dir in China (oder DE) für ein paar Euro ein normalen SD-Karten-Reader. Den steuerst du einfach an und gut ist. z.b. https://www.ebay.de/itm/SD-Card-Reader-Modul-5-Stuck-geeignet-fur-Arduino-Co/402675349203 Such bei Ebay nach "Arduino SD" und der zeigt sie dir in Masse. Die kannst auch mit den "kleinen" Arduinos Problemlos über Libs ansteuern. Mit den Pc das Bild via FAT-16/32 auf die Speicherkarte kopieren. Dabei drauf achten das du die alten Dos-Regeln nutzt. (8.3 und keine Leerzeichen). Via Libs das Bild laden und genießen.
jo mei schrieb: > Atmel Studio gibt dir doch am Ende des Build aus wie gross das > Binary ist. Das macht sogar die Arduino-IDE. ;) Bis auf das Bytes genau und in Prozent umgerechnet sogar. ;)
Fragensteller schrieb: >> Stichwort XMEM. > > Hab ich mittlerweile auch schon entdeckt, > allerdings ist das mit 64kB > bzw. tatsächlichen 56kB doch recht dürftig Da der AVR nur 64 KB Adressraum hat, bist du natürlich etwas beschränkt in den Möglichkeiten. Von maximal 64 KB Speicher steht da nichts. Ein Gameboy hat auch nur 64 KB Adressraum und es gibt Cartridges mit 8 MB ROM und zusätzlich noch RAM.
Schlaumaier schrieb: > Kauf dir in China (oder DE) für ein paar Euro ein normalen > SD-Karten-Reader. > Den steuerst du einfach an und gut ist. Ist kein "SD-Karten-Reader", das ist nur ein SD Slot mit Breakout Board und Hühnerfutter.
S. R. schrieb: > Fragensteller schrieb: >>> Stichwort XMEM. >> >> Hab ich mittlerweile auch schon entdeckt, >> allerdings ist das mit 64kB >> bzw. tatsächlichen 56kB doch recht dürftig > > Da der AVR nur 64 KB Adressraum hat, Nö. Die großen AVRs mit >64kB Flash haben 17 oder 18 Bit Adressraum! Siehe RAMPZ Register.
Fragensteller schrieb: > Ja ich kenne den Speicherverbrauch den Atmel Studio nach dem buid > angiebt. Jemand hat mal zu mir gemeint, dass der nicht richtig ist und > ich mir die Größe der .hex Datei ansehen soll. Unsinn. > Also kann ich doch auf den Vertrauen? Ja. Beitrag "Re: Speicherplatz eines .hex Files auf dem Microcontroller"
Ja, mit Pages und Zusatz-Registern kann man alles mögliche adressieren, auch GB's an Daten. Aber doch umständlicher als wenn man gleich die passende OPcode- und Indexregister -Breite hätte.
Fragensteller schrieb: > Ich will ja auch keine Meinung sondern Fakten Grundsätzlich ein sehr guter Ansatz. Blöderweise erfordert das Ermitteln und Prüfen von Fakten eigene Kompetenz, die man wiederum nur durch zeitaufwendiges und anstrengendes LERNEN erwerben kann. Aber bei dem konkreten Problem hält sich der Schaden in Grenzen. Man muss erstens verstehen, dass man eine Zahl auf viele verschiedene Arten darstellen kann. Theoretisch unendlich viele, praktisch sind aber nur wesentlich weniger im Gebrauch. Hier geht es erstmal um den Unterschied zwischen einem Byte in binärer Repräsentation (das ist, was der Compiler am Ende erzeugt und was der µC als Programm abarbeitet oder als Daten verwendet) und der Darstellung desselben Bytes als menschenlesbare zweistellige hexadezimale ASCII-Zahl (das ist, was z.B. ein Debugger anzeigt oder auch das, was in einem Hexfile steht). Nun ist ASCII-Code seinerseits aber am Ende auch wieder binär. Er braucht aber zur Abbildung dieser zweistelligen Zahl zwei Bytes. Weil das so ist, ist ein Hexfile schonmal mindestens doppelt so groß wie die Daten, die es darstellt. Für den Rest muss verstehen, wie ein Hex-File grundsätzlich aufgebaut ist. Der entsprechende Wikipedia-Artikel liefert alle Informationen, die man dazu braucht. Es kommen zu den Nutzbytes noch pro Zeile Informationen über die Adresse, an die sie zu schreiben sind und eine Prüfsumme. Dazu gibt es noch ein paar Steuerdaten, um größere Adressblöcke als 64k behandeln zu können und um das Dateiende zweifelsfrei zu markieren. All dieser Kram wird auch wieder in ASCII-Hexzahlen dargestellt. Weiterhin kommen dazu diverse Trennzeichen im ASCII-Code, die die einzelnen Zeilen des Hexfiles voneinander trennen. Weil das alles so ist, ist ein Hexfile am Ende immer deutlich größer als das doppelte der Binärdaten. Es ist übrigens nicht möglich, einen genauen Faktor anzugeben, um den das Hexfile größer ist als die Daten, die es repräsentiert. Zum einen hängt der Overhead von der gewählten Zeilenlänge ab, zum anderen kann man im Prinzip so ein Hexfile auch noch beliebig aufblasen, indem man ein und dieselben Adressen wieder und immer wieder mit Daten füllt. Sicher ist also nur eins: der Faktor 2 als Minimum.
Cyblord -. schrieb: > Ist kein "SD-Karten-Reader", das ist nur ein SD Slot mit Breakout Board > und Hühnerfutter. Reicht aber aus um ihn mit eine Libs anzusteuern. ;) Und ich verbaue sehr oft Breakout Board direkt auf meiner selbst erstellten Platine. Der Grund ist einfach nur das ich zu faul bin das "Hühnerfutter" zu beschaffen und dann auch noch zu löten. Solang sich das rechnet.... ;) Ich nehme z.b. auch Arduinos-Nanos (2.50 Euro China-Boards), Sockel die auf meiner Platine und baue meine Bauteile drumherum. Ist alles eine Frage des Kosten-/Nutzen Faktors.
Falk B. schrieb: >>>> Stichwort XMEM. >> Da der AVR nur 64 KB Adressraum hat, > Nö. Die großen AVRs mit >64kB Flash haben 17 oder 18 Bit Adressraum! Ein Atmega2560 besitzt nur AD[7:0] und A[15:8]. Wenn ich mich nicht verzählt habe, sind das 16 Adressleitungen für einen 64 KB Adressraum am XMEM. Darum ging es hier. Wärst du fair gewesen, hättest du das mit erwähnt statt einfach nur "falsch" zu brüllen. Du bist schließlich nicht blöd.
S. R. schrieb: > Ein Atmega2560 besitzt nur AD[7:0] und A[15:8]. Wenn ich mich nicht > verzählt habe, sind das 16 Adressleitungen für einen 64 KB Adressraum am > XMEM. Ja. >Darum ging es hier. Nein. Es ging dem OP darumm, mehr Speicherplatz für Grafiken zu haben. Die brauchen Flash, kein RAM. "und zwar geht meinem ATmega2560 langsam der Speicher aus, da ich ein paar Bilder habe die am Display angezeigt werden." > Wärst du fair gewesen, Das war ich.
Falk B. schrieb: > Nein. Es ging dem OP darumm, mehr Speicherplatz für Grafiken zu haben. > Die brauchen Flash, kein RAM. So what? Man kann natürlich über den XMEM-Mechanismus auch Flash anbinden, zumindest zum Lesen ist das überhaupt kein Problem. Nur, wenn man darauf auch schreiben will, wird es etwas komplizierter. Naja, ein paar Extra-GPIOs für's Bank-Switching und die zum Schreiben nötigen Signale sollten sich an einem 2560 ja irgendwie finden lassen.
c-hater schrieb: > So what? Man kann natürlich über den XMEM-Mechanismus auch Flash > anbinden, Kann man, löst aber das Problem des OP nicht sinnvoll. Außerdem sind wir schon lange weiter, selbst der OP.
> Man kann natürlich über den XMEM-Mechanismus.. ..alles dran hängen, was sich irgentwie par. adressieren lässt. RAM ist einfacher und auch schneller. Das was hier benötigt wird/würde kostet fast nichts. > Was heißt "OP"? Operationsverstärker!
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.