Announcement: there is an English version of this forum on Hallo, ich beschäftige mich gerade damit an einem ATMEGA2561 eine SD-Karte mit FatFS anzusprechen. Das Programm selbst belegt aktuell 21% Flash und 73% SRAM. Wenn ich nun auf die SD-Karte ca 85 Zeichen Schreiben möchte, welche ich vorher mit MEMSET, STRCPY, STRCAT vorbereite, damit ein Datensatz drauß wird, dann funktioniert zwar das schreiben jedoch sind danach zum Beispiel Interrupts deaktiviert oder vorher festgelegte Variablen auf einmal genullt. Wenn ich das Schreiben auf die SD-karte weg lasse, dann läuft alles normal durch. Also scheint das ganze String kopieren zu groß zu werden? Wer kann hier helfen?
Klingt nach Stack- oder Heap-Überlauf. Möchtest du, dass wir uns etwas konkretes anschauen?
Piere schrieb: > Wer kann hier helfen? Hast du schon versucht alle festen Strings ins PROGMEM zu verlegen? Bringt oft eine ganze Menge freien RAM. Vielleicht hast du auch noch zu viele einzelne String- Zwischenspeicher die zu zusammenfassen könntest ....
beo bachta schrieb: > Hast du schon versucht alle festen Strings ins PROGMEM zu > verlegen? Bringt oft eine ganze Menge freien RAM. > > Vielleicht hast du auch noch zu viele einzelne String- > Zwischenspeicher die zu zusammenfassen könntest .... Nein. Also alle String mit PROGMEM festschreiben und dann über Pointer verwenden?
Piere schrieb: > dann über Pointer verwenden? Nein, dafür gibt es äquivalente Funktionen, z.B. strcpy (...) --> strcpy_P (...)
Piere schrieb: > Also alle String mit PROGMEM festschreiben und dann über Pointer > verwenden? Pointer zeigen normalerweise ins RAM. Die Adressen des Programmspeichers überlappen sich mit dem RAM, deswegen musst du alle Zugriffe auf andere befehle umschreiben. Zum Beispiel musst du puts() in puts_P() ändern. Da steht alles, was man dazu wissen muss: https://www.nongnu.org/avr-libc/user-manual/pgmspace.html
beo bachta schrieb: > Nein, dafür gibt es äquivalente Funktionen, z.B. Alle verfügbaren Funktionen kann man einfach in pgmspace.h nachlesen.
Dein aktuelles Problem ist mit Sicherheit ein Programmierfehler. Du solltest aber wissen, dass Du bei Deinem AVR recht einfach externes SRAM anschließen kannst, das Du dann genauso wie internes ansteuern kannst. Du brauchst dafür die Ports A, C und G am AVR, einen 74HC573 und ein paralleles SRAM von 32KByte oder mehr. Wie es geht, steht in Kapitel 9 des Datenblatts oder z.B. hier: https://scienceprog.com/adding-external-memory-to-atmega128/ fchk
Frank K. schrieb: > Dein aktuelles Problem ist mit Sicherheit ein Programmierfehler. Naja, er kann ja auch beim Hantieren mit den Strings mal die rettende Null am Ende vergessen / überlaufen.
Bin jetzt dabei alles ins Flash zu legen was constant ist. Schade dass beim compilieren nicht darauf eingegangen wird, was im Ablauf noch benötigt wird.
Frank K. schrieb: > Dein aktuelles Problem ist mit Sicherheit ein Programmierfehler. Ich habe schon mit Chans FATFs gearbeitet, dabei fällt auf dass dieses System eine recht grosse Tiefe (Verschachtelung) in den Funktionsaufrufen aufweist. Zudem sind die Funktionsaufrufe oft mit vielen Parametern ausgestattet sodass hier für beide Eigenschaften auch eine hohe Wahrscheinlichkeit besteht dass es mal zu einem "grossen" Stack kommt. Zumindest was die AVR-Familie betrifft ....
Gibt es eine Möglichkeit beim Ausführen des Codes den SRAM zu beobachten? Ich arbeite mit Atmel Studio und Atmel ICE als programmiergerät
Peter schrieb: > Gibt es eine Möglichkeit beim Ausführen des Codes den SRAM zu > beobachten? Heap und Stack wachsen aufeinander zu. Wenn die beiden Zeiger sich treffen, ist der Speicher voll. https://rn-wissen.de/wiki/index.php/Speicherverbrauch_bestimmen_mit_avr-gcc
Wenn ich es richtig verstehe, sollte man bei verwenden von FatFs bis zu 2 - 4 KB SRAM freilassen?
Peter schrieb: > Wenn ich es richtig verstehe, sollte man bei verwenden von FatFs bis zu > 2 - 4 KB SRAM freilassen? Kommt ganz auf die Konfiguration an. Siehe http://elm-chan.org/fsw/ff/doc/appnote.html#memory
Stefan ⛄ F. schrieb: > Kommt ganz auf die Konfiguration an. Siehe > http://elm-chan.org/fsw/ff/doc/appnote.html#memory Werde da nur nicht schlau wie viel SRAM nun gebraucht wird...
Peter schrieb: > Wenn ich es richtig verstehe, sollte man bei verwenden von FatFs bis zu > 2 - 4 KB SRAM freilassen? Nein, da braucht man neben den ~1kB für die festen Puffer bestenfalls 500B Stack oder so.
Peter schrieb: >> Kommt ganz auf die Konfiguration an. Siehe >> http://elm-chan.org/fsw/ff/doc/appnote.html#memory > > Werde da nur nicht schlau wie viel SRAM nun gebraucht wird... Das was dort dargestellt ist, ist der KONSTANTE RAM-Bedarf (globale bzw. lokal-statische Variablen). Den zeigt dir der Compiler an. Was dort NICHT steht, ist der DYNAMISCHE RAM-Bedarf auf dem Stack. Der hängt von den Funktionen und der Verschachtelungstiefe ab. Aber mehr als 500B sollte man nicht brauchen. Wirklich gemessen hab ich es aber auch nicht. Die Wahrscheinlichkeit ist hoch, daß der Fehler in deinem Programm steckt und nicht durch geringen verfügbaren RAM verursacht wird.
Danke Falk, habe die Abschnitte, wo der String für die SD-Karte gebaut wird, geprüft aber finde nix was darauf hindeutet dass es zum Fehler kommt. Die Datei auf der SD sieht auch top aus.
Wenn ich natürlich das Schreiben und vorbereiten des String weglasse, geht alles 🤔
Was mir generell auffällt, vielleicht kann es jemand auflösen, wenn ich ein puffer für einen String genau bestimme, String 10 Zeichen, Puffer hat Platz für 10 Zeichen, läuft immer was schief. Lasse ich etwas Reserve, passt es...
Und wenn ich mit STRCPY und STRCAT arbeite, kommt das an jeden String oder nur ganz zum Schluss?
Peter schrieb: > Und wenn ich mit STRCPY und STRCAT arbeite, kommt das an jeden String > oder nur ganz zum Schluss? Muss, sonst wäre das Ergebnis kein gültiger String. Ob diese Funktionen das Null-Byte selbst anhängen oder es dir überlassen, kannst du ihrer Doku entnehmen. https://www.nongnu.org/avr-libc/user-manual/group__avr__string.html Verlasse dich nicht darauf, dass sich da alle Funktionen gleich verhalten, tun sie nämlich nicht. Lieber nachlesen.
Piere schrieb: > Hallo, > ich beschäftige mich gerade damit an einem ATMEGA2561 eine SD-Karte mit > FatFS anzusprechen. Das Programm selbst belegt aktuell 21% Flash und 73% > SRAM. > ....Wenn ich das Schreiben auf die SD-karte weg lasse, dann > läuft alles normal durch. Also scheint das ganze String kopieren zu groß > zu werden? > > Wer kann hier helfen? nimm einen AVR mit mehr SRAM und weniger flash: ATmega1284p 128K flash und 16K SRAM!
Ich werde den Zwischenspeicher mal erweitern und schauen ob es dann schon passt. Aktuell ist genau Platz für den kompletten String + 2 Reserve
Joachim B. schrieb: > nimm einen AVR mit mehr SRAM und weniger flash: > ATmega1284p 128K flash und 16K SRAM! Das ist leider nur dann ein Ausweg, wenn man mit max. 32 GPIOs auskommt. Eine Alternative könnten vielleicht die AVR128Dx sein. Die haben ebenfalls 16k SRAM und 128k Flash, aber bis zu 54,5 GPIOs. Leider ziemlich andere Peripherie, da gibt es viel Neues zu lernen, wenn man von den "klassischen" AVR8 kommt. Hat man hingegen schon mit XMegas hantiert, ist der Schock nicht gar so groß.
c-hater schrieb: > Das ist leider nur dann ein Ausweg, wenn man mit max. 32 GPIOs auskommt. na die Anwendung will ich sehen die unbedingt Ports an der MPU benötigt! Porterweiterung ist ja nun kein Neuland! c-hater schrieb: > AVR128Dx 3,3V oder 5V?
:
Bearbeitet durch User
Die MCU tauschen wäre der letzte Auswwg, ich versuche den Puffer zum Zwischenspeichern zu erweitern und wenn das nicht klappt alle String in den Flash legen um SRAM zu sparen
Joachim B. schrieb: > na die Anwendung will ich sehen die unbedingt Ports an der MPU benötigt! > Porterweiterung ist ja nun kein Neuland! Nur langsam. Und eben gelegentlich langsamer als für die Anwendung gut ist. Es gibt nämlich Anwendungen, die auch noch was anderes tun, als ein GUI aus Tastern und LEDs und ein paar Relais anzusteuern... > c-hater schrieb: >> AVR128Dx > > 3,3V oder 5V? Egal. die laufen von 1,8 bis 5,5V mit vollem Takt von 24MHz. Das ist anders als bei den klassischen AVR8 und auch anders als bei den XMega.
Joachim B. schrieb: > nimm einen AVR mit mehr SRAM und weniger flash: > ATmega1284p 128K flash und 16K SRAM! Klar, ein ganz tolles Mittel gegen Programmierfehler und Pufferüberläufe! TOP-EXPERTEN-TIP!
Wie wirkt sich eigentlich das \0 auf die SD-Karte aus? Wird es als Bit gezählt und ist im Editor am PC nicht sichtbar?
Peter schrieb: > Wie wirkt sich eigentlich das \0 auf die SD-Karte aus? Wird es als Bit > gezählt und ist im Editor am PC nicht sichtbar? Kommt erstens drauf an an welcher Stelle das auftaucht und zweitens darauf, welchen Editor man verwendet...
Peter schrieb: > Wie wirkt sich eigentlich das \0 auf die SD-Karte aus? Gar nicht. > Wird es als Bit > gezählt Byte. > und ist im Editor am PC nicht sichtbar? Es wird nur im C-Program zu Erkennung des Stringendes benutzt, aber nicht in die Datei geschrieben.
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.